Flutterby™! : Git commit

Next unread comment / Catchup all unread comments User Account Info | Logout | XML/Pilot/etc versions | Long version (with comments) | Weblog archives | Site Map | | Browse Topics

Git commit

2012-02-27 16:39:06.836894+00 by Dan Lyke 4 comments

Because @genehack made a post about this, I read his suggestions and still wasn't quite certain:

mkdir gittest; cd gittest; git init

Initialized empty Git repository in /home/dlyke/code/gittest/.git/

for a in First Second Third Fourth ; do echo $a >> abc.txt ; git add abc.txt ; git commit -m $a\ Commit ; done

[master (root-commit) 8c68792] First Commit
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 abc.txt
[master cbccf0c] Second Commit
 1 files changed, 1 insertions(+), 0 deletions(-)
[master 426fd1a] Third Commit
 1 files changed, 1 insertions(+), 0 deletions(-)
[master 94694d7] Fourth Commit
 1 files changed, 1 insertions(+), 0 deletions(-)

If we now do a git rebase -i HEAD~3, we can combine the second and third commit by changing the file to:


pick cbccf0c Second Commit
squash 426fd1a Third Commit
pick 94694d7 Fourth Commit

This will then pop up a second window which lets us amend the revised commit message, which I'll make "Second and Third Commit". git log now shows three commits, and the middle one has 3 lines in it.

[ related topics: Interactive Drama John S Jacobs-Anderson Music Television ]

comments in descending chronological order (reverse):

#Comment Re: made: 2012-02-28 03:30:14.583322+00 by: John Anderson

Mars, the majority of my git rebase use is in reviewing the code of junior developers, who have a real bad habit of fixing bugs, leaving their debug code in the change set with the fix, and then including one (or sometimes more than one) subsequent change that removes the debugging. There's no need for that to be two distinct changes; by squashing those commits into a single one during the review process, the overall history of the project is improved -- there's less noise, it's easier to see the was important in the change, and since I can point out to the junior dev what I did as part of the feedback they get during the code review, it provides a teachable example too.

In other words, I think it's safe to say we disagree about rebase...

#Comment Re: made: 2012-02-27 22:29:29.246417+00 by: Dan Lyke

There are personal projects where I use revision control in the makefile. All sorts of reasons why those intermediate steps never need to make any sort of public branch.

#Comment Re: made: 2012-02-27 19:56:49.009308+00 by: Mars Saxman

git rebase horrifies me and I generally pretend it doesn't exist. It violates the entire purpose of keeping history.

#Comment Re: made: 2012-02-27 17:36:55.927684+00 by: John Anderson

Other fun stuff you can do:

'git rebase -i' is one of my favorite parts of git; I use it near-daily.