Re: Staging/Master Merge - James' Patchy

[David Kastrup]

Graham Percival <address@hidden> writes:

> On Wed, Apr 11, 2012 at 12:50:16PM +0200, David Kastrup wrote:
>> > My comment relates to the need to git add as a separate step.
>> 
>> You _only_ need to use git add if you made your changes _manually_ in
>> the work directory instead of going through git.
>
> I had to read David's email a few times, and I'm still not certain
> that I understood this.  Here's my understanding:
>
> 1. when you (or makelsr.py) adds a new snippets, you must run
>   git add SNIPPET-NAMES
>
> Note that makelsr.py tells you to do this; all you need to do is
> copy&paste the command that makelsr.py gives you.
>
> 2. for all other changes, doing
>   git commit -a
> will save all changes to the repo.

Wrong.  git commit -a will update files it sees already in the index
(because they were put there by a checkout or a git add).  It never adds
_any_ new file it can't already see in the index.

> Now the problem comes when you do
>   git format-patch > foo.patch
>   patch -p1 < foo.patch
>   git commit -a
> ; even if you follow the above commands, it will *not* include any
> new files that were added to the git repo in step 1.

patch -p1 is _really_ the wrong tool to use as it is not git-aware.
There is no reason not to use git apply instead (which obviously knows
all about the patches git generates), and almost always you want to add
the --index option so that any changes are already put into the index
without the need to add them via git add or (partly) with commit -a.

And juggling with patches is _totally_ braindead anyway.  Use git
cherry-pick or even better git rebase -i for that sort of thing.

Did I mention git rebase -i already?  You don't need a separate branch
to work with it.  You can just use it to streamline an uncoordinated
sequence of commits wherever you committed it.

-- 
David Kastrup