"Phil Holmes" <m...@philholmes.net> writes: > From: "David Kastrup" <d...@gnu.org> > To: <lilypond-devel@gnu.org> > Sent: Wednesday, April 11, 2012 10:46 AM > Subject: Re: Staging/Master Merge - James' Patchy > > >> David Kastrup <d...@gnu.org> writes: >> >>> "Phil Holmes" <m...@philholmes.net> writes: >>> >>>> If I could have worked out how to split them, while at the same >>>> time being able to keep track of what changes were still needed, I >>>> would have done. However, doing things like having a >>>> screech-boink.ly in new, with a screech-and-boink.ly in snippets, >>>> and remembering to keep checking that the docs were all up to date >>>> and the one in new could be deleted was too much for my brain. The >>>> problem was that I believe I needed to get them into a single patch >>>> for the benefit of patchy, >> >> You don't. What makes you think that? > > The patches were interdependent. I was working on the assumption that > it was possible I'd push the first. Then start the commands to push > the next, but in the meantime patchy had been running and had pulled > staging with only my first patch in it. It would therefore fail?
Why would you push two times instead of one time? > I'm also not sure whether it pulls all staging in one go, or a commit > at a time. All staging in one go. It is, you are right, a good idea not to have intermediate commits that don't check out: that's bad news when you use git bisect for trying to find a commit introducing a particular bug. No way to sort the patches in a manner where they work out at every step? >>>> TBH that seems a duff aspect of git. >>> >>> No, it isn't. git apply _only_ touches the work directory, so whatever >>> happens, git does not remember anything about it. Use >>> >>> git apply --index >>> >>> if you want git to also _register_ the changes. >> >> In short: it is a duff aspect of your workflow _bypassing_ git. How do >> you expect git to deal with things you don't even tell it, and which you >> choose to do outside of git's control? > > 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. > If I modify a file and commit, the modified file is updated in the > repo. No, it isn't. You need to use "git add" in order to add it to the index. You can abbreviate some use cases by using "git commit -a" (guess what the -a option stands for), but you need to add _every_ change to the index before committing. > If I add a file to the source tree and commit, it isn't, and I need to > do a separate step. You _always_ need to add what you are going to commit. I repeat: if you choose to juggle around manually by applying patches on the work directory instead of using git commands like "git rebase -i" which work directly with the repository, git has no way to guess which changes in the work directory are to be committed and which not. If you work with "commit -a", the assumption is that changes of registered files are to be committed. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
