"Phil Holmes" <address@hidden> writes:
From: "David Kastrup" <address@hidden>
To: <address@hidden>
Sent: Wednesday, April 11, 2012 10:46 AM
Subject: Re: Staging/Master Merge - James' Patchy
David Kastrup <address@hidden> writes:
"Phil Holmes" <address@hidden> 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.