Re: Staging/Master Merge - James' Patchy

[David Kastrup]

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?

>> but I had them in six patches on my system. I git apply-ed each
>> patch, but didn't remember to git add the files.

Your mistake is that you bypass any operation working within git, and
instead juggle with patches on the work directory exclusively.  If you
want to conflate 5 commits into a single patch for whatever reason (it
is _not_ necessary for working with patchy, and I have no idea why you
would think so), you can do something like

git rebase -i HEAD~5

and do it.  Very, very simply.  Of course, you might want to do

git checkout -b my-squishy-branch

before in order not to change the original branch with 5 commits.  For
any non-trivial change, I tend to have about a dozen iterations of git
rebase -i before everything is one coherent and organized sequence of
commits.

>> 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?

-- 
David Kastrup