Graham Percival <gra...@percival-music.ca> 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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
