On Sun, Jul 20, 2008 at 11:30:21AM -0700, Junio C Hamano wrote:
> So for such people who would find "add -A" useful, "commit -a" will not be
> "unrelated changes in the same commit". And for such people, I would even
> say "commit -A" would be even more useful, too.
>
> I'll never be in that camp of perfect people myself, though..
I don't claim to be perfect, but I do use "commit -a" and I haven't ever
had a problem committing unrelated changes. My secret is to keep a good
.gitignore, and to peek at "git status" and "git diff" before
committing. So it's just a shorthand because after seeing that
everything is ready for commit, I'm too lazy to type each filename. I
also use "git add ." for the same purpose if files are to be added.
But note that avoiding "-a" doesn't save you from unrelated changes
anyway; it only saves you from changes in unrelated files. You still
have to look below the file granularity with "git diff" to avoid (for
example) a debugging printf. I often will use "git add -i" if I have a
lot of complex changes, even if I end up staging _everything_. But it
lets me say "yes, this should go in" for each hunk.
So maybe I will use "git add -A", but I have to admit to not really
having felt its lack to this point. However, something Lars said makes
me wonder: do people _really_ want this as an option to add? I seem to
recall the primary request for this being the "undisciplined" approach
you gave ("I have a project that periodically gets data dumped by an
external program, and I want to commit it all"). In that case, the next
step is always commit, so what would be most convenient is "commit -A".
But again, I haven ever felt the lack of this feature; such usage for me
always goes in scripts, where I am more than happy to write out "add .
&& add -u && commit".
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
