Re: Staging/Master Merge - James' Patchy

[Phil Holmes]

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

I'm also not sure whether it pulls all staging in one go, or a commit at a 
time.

> > > 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.  If I modify a 
file and commit, the modified file is updated in the repo.  If I add a file 
to the source tree and commit, it isn't, and I need to do a separate step.

--
Phil Holmes