Question about "git commit -a"

Hi all, I was just wondering why git commit doesn't default to "-a" (yes, it's another question that came up during a chat with a mercurial user) and I didn't find an answer to that.

It's not a big deal but I strongly suspect that the large majority of the git users never user git commit without the option "-a".

Am I wrong?

Regards,

"Paolo Ciarrocchi" <paolo.ciarrocchi@gmail.com> writes:

http://git.or.cz/gitwiki/GitFaq#head-3aa45c7d75d40068e07231a5bf8a1a0db9a8b717

On 10/4/07, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:

Ooops... I'm really that bad in googling for an information ;-(

Thanks and sorry for the noise.

Regads,

El 4/10/2007, a las 17:38, Paolo Ciarrocchi escribió:

<http://git.or.cz/gitwiki/GitFaq>

Specifically:

<http://git.or.cz/gitwiki/ GitFaq#head-3aa45c7d75d40068e07231a5bf8a1a0db9a8b717>

About it being a majority, yes, I suspect so.

Cheers, Wincent

On 10/4/07, Wincent Colaiuta <win@wincent.com> wrote:

Maybe in the next survey we should include question "do you usually do 'git commit' or 'git commit -a'" :-)

Hi,

On Fri, 5 Oct 2007, Nguyen Thai Ngoc Duy wrote:

Not meaning to discourage you, but it is a known fact that Linus does "git commit" without "-a" quite often.

And if that were not bad enough for your plan, I myself omit "-a" regularly. So you would get a veto from me, too.

Ciao, Dscho

On 10/5/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

I obviously forgot to mention I do use git-commit without -a. I just wanted to know which way the real majority of git users prefers.

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

Ditto.  I use `git commit` more often than `git commit -a`.

Actually scratch that, I use `git gui` more often than I use `git commit -a` but the point holds. I stage things long before I ever think about what the commit message should say. Its very rare that I am committing without staging something first, usually its a one liner fix for something and the -a just is the shorter way to stage the change.

Early on in my Git days I didn't grasp how *useful* it is to stage first. Now I can't work without it. At least for any change more than 1 line. :)

On 10/4/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

So you are used to do something like (please correct me if I'm wrong):
- modify A
- modify B
- modify C
- modify D
- modify E

$ git A B E $ git add A B E (A, B and E are now in the staging area) $ git commit -m "I just modified A,B and E" $ git C D $ git add C D (C and D are now in the staging area) $ git commit -m "I just modified C and D"

Ciao,

Paolo Ciarrocchi wrote:

This isn't really a valid command. I'm not sure where you got it from.

I do something like that, except that for full-file commits I'd rather say

	git commit -s A B E

I never pass -m to git commit. It's too easy to get into habit of being sloppy with historic documentation that way.

Again not a valid command, but...

See above :)

There's also the times when I hack on some feature and find some small bug/easy-to-write-feature, so I make the change for that other thing, swap to a different branch and do 'git commit -s --interactive' to just break out that small fix.

Or if I have to add some logic to some other function in a file I've modified for other purposes and want it to be two separate commits, I just make the change and then run 'git commit --interactive' to make it two separate commits.

I just don't do 'git commit -a' for the same reason I don't do 'git commit -m', really. It tends to be habit-forming, and bisect has saved my arse enough times for me to *want* my changes to be small and isolated. Debugging a 5-line patch is so much more pleasant than debugging a 30k-lines one that spans over several different files.

On 10/5/07, Andreas Ericsson <ae@op5.se> wrote:

Doh! Don't consider it, it's just a silly copy and paste error! It has no meaning!

Right. But in the scenario you described isn't enough to type "git commit -s". Why did you write "git commit -s A B E".

See above, just a very silly copy and paste error.

Very interesting!

Yeah, I see. Thanks for your comments Andreas, very appreciated.

Just to clarify my goal, since I had that interesting discussion with an hg user I started looking for simple examples of the usage of the "staging area" to be added to the introduction to git documentation. The role of the index/staging area seems to be something complex for a git newbie.

Regards

Paolo Ciarrocchi wrote:

Because that way I don't have to do "git add A B E" first.

Yes, but it's so enormously powerful once you get a grip on it that I can't for the life of me imagine an scm system without it. You just can't do "scm commit --interactive" without it in a sane way, or check which merge- conflicts you've already resolved, or compare working tree with what the next commit *will* look like, or... The list goes on. Like I said, it's so immensely powerful that all the things you can do when you have one is, all by itself, reason enough to switch from any other scm to git.

As for the "git commit should default to -a" discussion, I think it's pretty clear where I stand ;-)

Andreas Ericsson <ae@op5.se> writes:

darcs|hg record do a very similar job. The real difference between darcs and others here is not "scm commit --interactive", but the fact that you can split the work among multiple commands, the index maintains a persistant state.

At least bzr and baz have this kind of conflict management. It's just a separate file, containing the list of unresolved conflicts.

To me, *that* is the point.

Matthieu Moy wrote:

Can you check them against any revision you want? If so, I'm impressed :)

Andreas Ericsson <ae@op5.se> writes:

If you mean s/check/diff/, not in a simple way, no. Otherwise, I don't understand what you mean by "check merge-conflicts you've already resolved against any revision".

Matthieu Moy wrote:

Actually, I meant "diff the staged area against any random commit". It's really nice to do after a bisect, where you know what the bad commit looks like, and how the code changed to introduce the bug.

On 10/5/07, Andreas Ericsson <ae@op5.se> wrote: [...]

Fair enough.

Another try to have an easy explanation of how the staging area works:

paolo@paolo-desktop:~/HowIndexWorks$ ls A B C D E F G

Now I edit A,B,C,D and E:

$ echo A >> A $ echo B >> B $ echo C >> C $ echo D >> D $ echo E >> E

I now realize want to only commit the changes I did to A,B,C,D. First step is to place A,B,C and D into the staging area: $ git add A B C D

Now I can commit:
$ git commitpaolo@paolo-desktop:~/HowIndexWorks$ git commit
Created commit 16032dc: I modified A,B,C and D
 4 files changed, 4 insertions(+), 0 deletions(-)

It's now time to work on F and G: $ echo F >> F $ echo G >> G

Current status is: paolo@paolo-desktop:~/HowIndexWorks$ git status # On branch master # Changed but not updated: # (use "git add <file>..." to update what will be committed) # # modified: E # modified: F # modified: G

Instead of adding E,F and G to the staging are and then commit them in two steps I can using a single command: $ git commit E F G (in this case it's equivalent to git commit -a)

paolo@paolo-desktop:~/HowIndexWorks$ git commit E F G
Created commit 69ec8be: I modified E, F and G
 3 files changed, 3 insertions(+), 0 deletions(-)

status now is: paolo@paolo-desktop:~/HowIndexWorks$ git status # On branch master nothing to commit (working directory clean)

Regards,

Paolo Ciarrocchi wrote:

He. It's like comparing a duracell battery to the sun, but yes, that's one of the operations where the index is involved. But after doing your git-add thing above, you could also have continued hacking on A B C D, and git would only have committed the state where you did "git add". When you stop to think about this, you'll realize that it's a really powerful thing, as it lets you keep on hacking even when you don't really know where you'll end up.

Andreas Ericsson <ae@op5.se> writes:

That usage is indeed very close to a micro-micro-throwable branch.

Instead of doing:

<hack> <diff> <commit>

<hack> <diff> <commit>

# Oh, gosh, I didn't want that! | # Yes, _this_ is what I want
$ git reset --hard HEAD^^       | $ git checkout HEAD^^
                                | $ git merge --squash HEAD@{1}
                                  (untested)

You'd do:

<hack> <diff> <add>

<hack> <diff> <add>

# Oh, gosh, I didn't want that! | # Yes, _this_ is what I want $ git reset --hard | $ git commit

The two flows are both similar and different. In the first case, you can't come back to an arbitrary step within your development, but since you didn't actually commit, and just ran "add", it's precisely because you thought this state was not one you wanted to come back to later. And at the time you commit, you don't have to tell git to forget about the temporary branch, the succession of "git add" was just for you, not to keep in history.

Actually, most of the time, I commit only when my index matches the working tree (i.e. when status shows me only green, with color.status = auto), so "commit" or "commit -a" don't change the result, but I validate my own changes with "add", and give the whole thing a descriptive message with "commit".

I understand why people like staging and commit without -a, seeing how it's faster and all, but I have a serious problem with this practice that I haven't seen brought up on the list. How do you know what you commit actually works or even compiles? The reason that I almost exclusively use -a with commit is that I want to know that what I just compiled and tested is what I will be committing. I don't want to just commit half the files in my working copy, I want to make sure that the exact state of my project that I just compiled and tested is what gets into version controlled history.

git commit -a isn't sloppy to me - eye balling some subset of your working copy and committing that under the assumption that you don't make mistakes and don't need to compile what you commit... that is sloppy.

Kristian

Kristian Høgsberg <krh@redhat.com> writes:

Actually, commit without -a is not much faster, since it runs "status" internally, to show it to the user when launching the editor. So, it still checks for changes in the working tree.

That's a general problem with partial commits, and that's why I personnaly don't like partial commits in general ($scm commit file1 file2 has the same problem, \forall $scm).

To me, the right approach to partial commit is to stash the unwanted changes, test, commit, and unstash.

(side note: it would be cool to have a "git stash --unstaged" command, to put the unstaged changes aside, and match the tree to the index. A good approximation for that is:

$ git stash # put all aside $ git reset --mixed stash^2 # get back what the index used to be $ git add -u # and put it back into the index. )

*But*, the cool thing with git is that you can view rather easily not only what you're about to commit (git diff --cached), but also what you're about _not_ to commit (git diff). So, if the unstaged changes are trivial enough, it can be OK (for example, Linus changes the linux version in a Makefile a few commits before the release, and doesn't add it to the index, to keep it as a reminder).

But I agree with your that splitting a huge patch into smaller ones using just the index is bad practice, except if you intend to come back to each commit and test it later.

Agreed. For this reason git-commit without -a, staging, index, ... is not really interesting to me.

In CVS and subversion (which has nicer working-copy command line interface IMHO), I simply make a copy of the working copy, revert the non-commitable parts, build, commit the minor changes, and then update the first copy. For larger projects, where this can be slow, I use diff/revert/patch.

Small checkins are nice for git-bisect, but if they don't build...

Mark

On Friday 2007, October 05, Marko Macek wrote:

Who cares?  Commits that build isn't the only reason for small commits.

git-bisect is nice and small buildable commits is something to aim for. However, there is more to software history that buildable commits.

I hardly ever git-bisect, and I hardly ever checkout old revisions, however I read the log _all the time_. The smaller the commit and the better the log message the more quickly I'll understand what was going on. In the end even if the commit doesn't build as long as the log message is a good description of what the commit does and that thing is an isolated change then the revision has achieved its goal for me.

Andy

On Sat, 6 Oct 2007, Andy Parkins wrote:

More importantly, while it's true that you should always test all your changes, quite often they really *are* obviously separate.

I've mentioned this as an example lots of times, but I often tend to have multiple independent things in my tree at the same time. One of the "clearly independent" ones is the fact that I historically tended to update my Makefile for the next version number several days before I do the actual release, just to remind me (I used to forget to bump the version number, so..).

So I often have a dirty main makefile, but that doesn't mean that I'm going to commit it until I'm ready. I want to (no - *need* to) be able to pull and apply patches from other people despite the fact that I have some dirty state.

[ It's not just the makefile: almost all of what I do these days is pull 
  and apply patches, but I also send out suggestions to other developers 
  by email, and I often end up keeping my suggestion around in my tree as 
  dirty state. I could use a topic branch, but the thing is, I don't 
  actually want to save it - but not only do I actually like seeing the 
  "couldn't merge due to dirty state" because that tells me I got the fix 
  back, but I like just eatign my dogfood and compiling the kernel with 
  the suggestions I sent out ]

So it's quite ok to have multiple independent changes going on it the tree, and there's absolutely *zero* reason to think you should commit them together (quite the reverse). Maybe this isn't all that common for a *small* thing, but I pretty much guarantee that large projects always end up doing somethng like this.

And making the *default* workflow do something bad - namely commit everything blindly - is not a good idea. I'd rather have the normal workflow basically try to encourage many small commits, because while it's true that they may not have been tested individually, 99% of the time any linkages are pretty obvious.

(Side note: the *most* common failure to check stuff in completely tends to be one that other SCM's also have, for all the same reasons: forgetting to *add* a new file. I suspect the git model of "add all new changes" whether new files or old, actually _helps_ avoid that error, but quite frankly, I don't think we'll ever get away from it. It's just too easy a mistake to do).

			Linus

El 5/10/2007, a las 20:16, Marko Macek escribió:

This sounds painful compared to Dmitry's method (pasted below) if you care about all published changes being buildable and passing all the tests...

El 5/10/2007, a las 23:10, Dmitry Potapov escribió:

Cheers, Wincent

On Fri, Oct 05, 2007 at 11:56:03AM -0400, Kristian Høgsberg wrote:

You don't. Even with 'commit -a' there is no guarantee that the result will compile, because you can forget to add a new file. IMHO, the best practice is to recompile everything step-wise in a clean directory before you are going to publish your changes. It can be done automatically by script, while you do something useful, like reading this mailing-list :)

Dmitry

Dmitry Potapov wrote:

Actually, it would be a good idea for commit to report an error if there are any new files that have not been 'added' or 'ignored' (or even if there are missing files that have not been 'deleted'.

Perhaps I'll add this to my git wrapper scripts.

Even for normal git-commit it might be nice to report an error if there are any unstaged files unless -a or -i option is specified.

Mark

On 10/7/07, Marko Macek <Marko.Macek@gmx.net> wrote:

If it is good for you, you can add this check to your pre-commit hook. However, I don't like your idea at all. Sometimes, you do want to have some file that is not 'added' or 'ignored' as a reminder that you have something else to do. IMHO, git acts in the most reasonable way in this respect. When you say 'commit -a' and you have some files not added, it will show you all untracked files in your editor when you type a commit message. So, it is more difficult to forget to add a new file with git than with many other version control systems.

Actually, 'commit -a' will automatically delete all missing files. IMHO, it is the right thing to do.

Dmitry

Hi,

On Sun, 7 Oct 2007, Marko Macek wrote:

It is no error.

And it is reported. That is the whole _point_ of having git status output both changed-but-not-staged and untracked files.

Of course, you only see that when you do not provide the message within the editor, but from the command line. But then chances are that your message is too short anyway.

Ciao, Dscho

El 5/10/2007, a las 10:39, Paolo Ciarrocchi escribió:

The conceptual shift is that in Git your index and not your working directory is your staging area, unlike (most/all?) other SCMs. If you fire up gitk and look at the development history of Git itself you'll see that it's one of the "cleanest" out there, and as you learn Git you learn about the various tools and tricks that it provides that makes it easier for a developer community to produce such a clean history; the index as a staging area is one of the key factors.

The basic workflow is:

   # work on a single change
   edit A
   git add A
   edit B
   git add B

   # see unrelated thing that needs to be fixed, but don't add  
(stage) it yet
   edit C

   # commit first change, then second one
   git commit -s
   git commit -s C

This is just one example of how having a staging area that you can control independently of your working tree can help you. There are other possible workflows and you discover them through use, but they all share the basic idea that you use the staging area to provide you with better control.

Sometimes you're trying to work on a single thing and you see a change within a single file that isn't related. In that case you have an even finer level of granularity available and can use "git add -- interactive" to add only specific hunks.

Finally, closely related to this idea of maintaining a clean history is the newly-added and wonderful "git stash". If you have a relatively complicated work in progress already half-staged in the index and you see something else relatively complicated that you want to attend to straight away then you can easily switch to the second task, commit it, and go back to the first task, thus keeping your development history nice and clean. This is a beautiful example of your SCM facilitating your work and making it easy rather than forcing you to jump through hoops. See the git-stash man page for more details.

I think all of this is incredibly powerful useful stuff, and all of it comes at a very low cost; it's easy to learn and doesn't require you to do any magical and complex history rewriting in order to get a nice clean history.

And on the subject of staging areas, thanks to "git commit --amend" you can even use the last commit as a kind of secondary, addditional staging area, providing you haven't published that commit yet. In other words, I frequently do:

   git show HEAD

Immediately after committing and if I don't like what I see I make modifications as necessary and do:

   git commit --amend

Cheers, Wincent

On Thursday 2007, October 04, Paolo Ciarrocchi wrote:

Yes, I think you are. I suspect that most users start out using git commit -a, because that's the workflow they were used to with their previous SCM. What happened to me was I started with

 git commit -a

Then I started adding files one at a time

 git add <file>

Now I cherry pick hunks together in coherent groups 

 git add -i

Once you figure out that git lets you turn your development history from a simple snapshotter to telling the story of the project's development, you'll find you want finer and finer control over what you're committing.

Andy

Andy Parkins <andyparkins@gmail.com> writes:

Ooooohhhhh,.....

Boy I didn't know about add -i... that looks, really, really, really useful...

Thanks,

-miles

Am Thu, 04 Oct 2007 17:38:25 +0200 schrieb Paolo Ciarrocchi:

in fact i do just a git-config alias.commit 'commit -a' in my repository

David Soria, Fri, Oct 05, 2007 00:34:11 +0200:

Either you have a specially modified git (the alias expansion code) or you just said not exactly truth. You can't alias the git commands (see git.c's main).

Hi,

On Thu, 4 Oct 2007, David Soria wrote:

Which will not work, because we do not allow overriding of programs/builtins by aliases.

This has technical reasons and cannot be fixed.

Ciao, Dscho