Re: An alternate model for preparing partial commits

From: Björn Steinbrink <b.steinbrink@gmx.de>
Date: Jun 27, 2008, 17:27 UTC
Message-ID: <20080627172701.GB15359@atjola.homenet>
In-Reply-To: <9af502e50806270954q613087efub0eb05c25f2eefb9@mail.gmail.com>

On 2008.06.27 09:54:43 -0700, Robert Anderson wrote:

Show 11 quoted lines

> On Fri, Jun 27, 2008 at 12:10 AM, Björn Steinbrink <B.Steinbrink@gmx.de> wrote:
> > Hm, I use "stash" for that purpose, which leads to kind of the reverse
> > of your approach. So I do sth. like this:
> >  - hack hack hack
> >  - Notice that I want to make two commits out of what I have in my
> >   working tree
> >  - git add -p -- stage what I want in the first commit
> >  - git commit -m tmp -- temporary commit
> 
> This is a guess at the first commit?  I don't like it, but I'm still
> listening.

It's rather a work-around to stash away only the changes that are not in the index. See the other reply to my mail for a patch that adds an option to stash to do that without the commit/reset hack.

Show 10 quoted lines

> >  - git stash -- stash away what doesn't belong in the first commit
> >  - git reset HEAD^ -- drop the temporary commit, with the changes kept
> >   in the working tree
> 
> Now I have my guess at the first commit as my tree state, correct?
> What happens when I decide I need a couple of hunks from another file
> which I missed in my first guess, and is now in the stashed state?
> How do I get those out of the stash and into the working tree?  If
> there is no convenient way to do that, then this method is not
> sufficient to cover the use case I am talking about.

git stash pop eventually fix conflicts if you changed the working tree in the meantime go back to the "git add -p" step

Björn