pages tagged git

git pull from master

Thu, 09 Apr 2020 05:00:48 +0000

Check out your development branch

git checkout my_branch

Update your development branch my pulling commits from origin/master

2a. method 1

git pull origin master

ab. method 2 ``` git fetch origin master git merge FETCH_HEAD

Resolving conflcits.

git status

If it shows some files contain conflicts, manually edit the files and resolve the conflict blocks.

git add the files edited. git add my_file_1 ...

git commit git push

(END)

Git core.ignoreCase setting

Tue, 16 May 2017 23:59:39 +0000

I was reviewing my ~/.gitconfig after attending a Git training session in my company. The file was mostly inherited from some source on Internet long time ago, and I hadn't carefully reviewed all the settings there before. I realized that there's an explicit core.ignoreCase setting:

[core]
    ignoreCase = true
    ...

Now I'm not entirely sure if this is a good idea.

My observations:

On my Mac computer which has the default case-INsensitive file system, no matter if ignoreCase = true or false,

git mv myfile myFile does NOT work;
'mybranch' and 'myBranch' branches can NOT coexist.

However, on my Linux computer which has case-sensitive file system, no matter if ignoreCase = true or false,

git mv myfile myFile works, and git status lists it as a commitable change, and moreover if committed and pushed, it can be checked out and reflected on the Mac computer;
'mybranch' and 'myBranch' branches can NOT coexist.

It seems having explicit ignoreCase setting does not make a difference on the same computer, but the behaviors between Mac and Linux differs. From reading the documentation on core.ignoreCase (https://git-scm.com/docs/git-config), I just couldn't decide if keeping ignoreCase = true in my global ~/.gitconfig is helpful or harmful.

Log statistics for revision control systems

Tue, 16 May 2017 23:59:39 +0000

Find the top committers to a file

Mercurial:

$ hg log ./.hgignore | grep user: | sort | uniq -c | sort -r | head -3  
   5 user:        Michael <michael@foomail.com>  
   3 user:        Mary <mary@barmail.com>

Git:

$ git log ./.gitignore | grep ^Author: | sort | uniq -c | sort -r | head -3
   6 Author: Michael <michael@foomail.com>
   2 Author: Mary <mary@foomail.com>

CVS:

$ cvs log ./foo/bar.cpp | grep author | awk '{print $5}' | sort | uniq -c | sort -r | head -3
  92 Michael;
  72 Mary;

Style Guide for Revision Control System Commit Messages

Tue, 16 May 2017 23:59:39 +0000

Was trying to come up with some style guide for commit messages in revision control systems (Subversion, Git, Mercurial, etc.) as very commonly it is a place where people tend to use poor or poorly-managed writing styles when they are in a hurry, or not. The contrast between the sophistication of engineering of automatic revision control systems and the lousiness of majority of commit messages I've seen is ironic, at least to me. Imagine a situation where one wants to data mine the commit message history in a revision control repository and do text analytics with it to find out some interesting thing about the project, it can be very useful for the commit messages to have a uniform format and hence more machine processable.

Some general rule for revisions and commits

try to make a commit self-contained, i.e. logically-closely-related revisions should be committed together in one commit rather than in multiple separate commits
try to make logically-unrelated revisions in their own separate commits rather than make a big revision including many changes that are logically independent to each other

Some general rules for having uniform format of the commit messages

Use a short summary sentence at the top to summarize the main purpose/content of the revision. As both Git and Mercurial use the first sentence ending with period (.) for various purposes. If there are itemized details in the following, use ellipsis (...) instead.
Leave a blank line below the summary sentence.
Keep the lines shorter than 72 characters as that produces better line wrapping behavior for hg log and git log.
If necessary, use bullet items below the blank line to describe details. Use different bullet for different types of revisions
- + added new content
- - removed existing content
- % modified existing content and/or behavior
- ! fixed bugs and errors
- ~ tweaked content by making small and/or insubstantial changes
- * misc and/or other unclassified changes
- > to-do for future
Try to use expressions with simple past tense or noun phrases.

Example commit message to a revision control repository:

Changed the logic dealing with magic input.

+ added an awesome new functionality
- removed obsolete content
% modified some existing code
! fixed a bad bug
~ tweaked some content
* some misc unclassified changes
> make the logic more robust

Examples of using myrepos

Tue, 16 May 2017 23:59:39 +0000

Set user name and email to multiple Git repositories

Set up your myrepos and Git repositories according to https://myrepos.branchable.com/.

Add the following in ~/.mrconfig:

[DEFAULT]
## Teach mr how to config user name and email with `mr configusername` and `mr configuseremail`
configusername = git config user.name "Meng Lu"
configuseremail = git config user.email lumeng.dev@gmail.com

Navigate to a path that contains all the Git repositories you would like to set or update user name and email, and run

mr configusername
mr configuseremail

myrepos will print the paths of the Git repositories whose user name and email are updated.

References

myrepos: https://myrepos.branchable.com/.
Git documentation on configuring user: https://git-scm.com/book/en/v2/Getting-Started-First-Time-Git-Setup

Examples of using Git

Thu, 26 Feb 2015 01:44:09 +0000

Topics

Run git commands from outside of a Git repository

git --git-dir=/Users/meng/my-git-repo/.git --work-tree=/Users/meng/my-git-repo/ status

Remove local branches tracking remote branches that no longer present on remotes

git remote prune origin

Generate a list of my commits

git log --all --no-merges --author='XXX' --stat --after='2015-9-1' | grep -v '^Author: '

Remarks:

--all generates the result for all branches;
--no-merges ignores the merge commits which are often not desirable in a list of additions and revisions one "genuinely authored";
--author='XXX' restricts the list to commits from a specific author;
--after='2015-9-1' restricts the list to commits made after the specified date, which is often desirable for listing one's recent commits;
grep -v '^Author: ': if --author='XXX' is used, the author information for each entry of commit is redundant.

Find all files committed by a user

git log --no-merges --stat --author="PATTERN" --name-only --pretty=format:"" | sort -u

Remarks:

PATTERN is a regex pattern matching the desired user.

Remove ignored files from index

Method 1: `git update-index --assume-unchanged <file>`

If a file has been added to the index, i.e. the staging area, but it's decided it does not need to be version controlled by Git, but it should also not be deleted from the working tree, remove it from index:

git update-index --assume-unchanged myIgnoredFile

This only removes the myIgnoredFile file from the index of the current repository, but will not remove it from the repositories you push to since it only modified the index of the local repository.

To add it back later,

git update-index --no-assume-unchanged myIgnoredFile

List files that are currently assumed unchanged when computing index:

git ls-files -v | grep "^<span class="createlink">:lower:</span>"

TODO: difference between this method and method 2.

Method 2: `git rm --cached <file>`

If a file has been added to the index, i.e. the staging area, but it's decided it does not need to be version controlled by Git, remove it from index:

repo/ $ git rm --cached myIgnoredFile

The option --cached limits the removal to the index only and hence the file myIgnoredFile and any modification to it in the working tree is left alone.

Method 3: Method 2 recursively

If there are many files that are added to the index but are then decided to be ignored, and specified by patterns in the .gitignore file, the index can be cleaned as the following

Commit changes that's already staged in the index, so files that are already staged but will not need to be ignored later is properly committed:

git commit -a -m "XXX"

Recursively remove everything from the index

git rm -r --cached .

Re-add everything, so the modified .gitignore file will ensure the ignored files are not added to the index:

git add .

Commit:

git commit -a -m "XXX"

TODO

Always push to multiple remote repositories and pull from one logical central repository

To push to multiple remote repositories automatically everytime you push, but pull only from one remote repository which might be logically considered as the "authoratative" central repository, configure the remote origin as

[remote "origin"]
    url = USER@MYHOST.COM:/PATH//TO/CENTRAL-REPO
    pushurl = USER@MYHOST.COM:/PATH//TO/CENTRAL-REPO
    pushurl = git@gitlab.com:XXXuserXXX/BACKUP-REPO1
    pushurl = https://XXXuserXXX@bitbucket.org/XXXuserXXX/BACKUP-REPO2.git
    fetch = +refs/heads/*:refs/remotes/origin/*

(The all uppercase parts and the parts sandwiched in between two XXXs should be adjusted to one's real-world values.)

git pull or git pull origin master will pull from central-repo;
git push or git push origin master will push to the logical central repository CENTRAL-REPO as well as the other two backup repositories via the push URLs BACKUP-REPO1 and BACKUP-REPO2. But if the pushurl for the CENTRAL-REPO is not explicitly added, it will not be pushed to, i.e. only having url does not suffice. The repositories other than the logical central repository can be used as back-ups or mirrors.

Rename a branch

Rename a branch:

git branch -m <old_branch_name> <new_branch_name>

git checkout <old_branch_name>
git branch -m <new_branch_name>

Remove old branch from the remote origin [¹]:

git push origin --delete <old_branch_name>

or [²]:

git push origin :<old_branch_name>

Push the new branch to the remote origin

git push origin -u <new_branch_name>

References

git-scm.com, "Deleting Remote Branches," 2016, https://git-scm.com/book/en/v2/Git-Branching-Remote-Branches#Deleting-Remote-Branches ↩
<source>:<destination> specifies the refspec to push from and to. When the <source> is omitted, git push origin :<old_branch_name> indicates it pushes an empty refspec to the remote destination branch <old_branch_name> which effectively deletes it on the remote.↩

pages tagged git

git pull from master

Git core.ignoreCase setting

Log statistics for revision control systems

Find the top committers to a file

Mercurial:

Git:

CVS:

Style Guide for Revision Control System Commit Messages

Some general rule for revisions and commits

Some general rules for having uniform format of the commit messages

Examples of using myrepos

Set user name and email to multiple Git repositories

References

Examples of using Git

Topics

Run git commands from outside of a Git repository

Remove local branches tracking remote branches that no longer present on remotes

Generate a list of my commits

Find all files committed by a user

Remove ignored files from index

Method 1: git update-index --assume-unchanged <file>

Method 2: git rm --cached <file>

Method 3: Method 2 recursively

Always push to multiple remote repositories and pull from one logical central repository

Rename a branch

References

Method 1: `git update-index --assume-unchanged <file>`

Method 2: `git rm --cached <file>`