Re: Multi-branch committing in git, revisited

On Wed, Sep 22, 2010 at 12:40 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> Tom Lane wrote:
>> Bruce Momjian <bruce(at)momjian(dot)us> writes:
>> > There is no need for 'git add' because once you are done you can use git
>> > commmit -a in each branch to add all modifications and commit them.
>>
>> git commit -a is not a universal solution.  In particular, the patch
>> I was dealing with yesterday involved additions and removals of files,
>> neither of which will be implemented by git commit -a.
>
> Uh, why is that?  I see -a saying:
>
>       -a, --all
>           Tell the command to automatically stage files that
>           have been modified and deleted, but new files you have
>           not told git about are not affected.
>
> What is it about add/deletes that it doesn't do?  Is the problem 'git
> add' creates a stage already?  How is that a problem?

Tom is slightly incorrect. Deletions work fine with git commit -a.
git already knows about the files, so everything just works. However,
it won't pick up on added files, because it can't distinguish between
a file that you want added to the repository and a stray file you left
lying around and assumes the latter. But I don't see that this takes
anything away from your point. You can certainly just work on the
patch in each repository separately and then commit everything all at
once at the end, if you're so inclined. Of course, as Tom points out,
it's a lot nicer to apply patches in a way that allows git to try to
auto-merge for you. Sometimes it works, and when it doesn't work
having the merge conflict stuff in the file is still better than
having a .rej hunk leftover that you have to figure out what to do
with. So personally I don't intend to do it that way, but as Larry
Wall said about Perl, There's More Than One Way To Do It.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company