Re: Staging/Master Merge - James' Patchy

[David Kastrup]

"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.

-- 
David Kastrup