Junio C Hamano <gits...@pobox.com> writes:

> "I have something worth saving, better than HEAD in some way
> (e.g. contains fixes), in my index. I want to keep it while I
> experiment an approach that is unrelated to it, so I want a clean
> slate in the working tree from HEAD without disturbing the index".
> At the first glance, that looks like a reasonable thing to ask, but
> after thinking about it a bit more, I am not sure if it really is,
> primarily because it is unclear what you can productively do to the
> end result next.
> Suppose you matched the working tree to HEAD while keeping a
> valuable change in the index, and after working for a while, now
> have finished the experiment and have something in your working
> tree.
> What is your next move?
> If the end result in the working tree were "Nah, this other approach
> does not work, trash it", you can checkout the working tree from the
> index, so nothing is lost.
> But if your result is _also_ something worth saving, what would you
> do?  "git add" to update the index will trash the work that was in
> the index, and that is by definition unrelated to what you worked on
> in the working tree (you wanted to start from the version in the
> HEAD, not from the version in the index, so the end result is likely
> to lack the work you saved in the index).
> That makes me think that "match working tree from HEAD bypassing
> index" is not a very useful strategy, unless you are expecting a
> failed experiment from the start.
> As Thomas said, I think a more reasonable workflow would begin by
> saving the "somewhat worth saving" state you have in your index as a
> WIP commit, i.e.
>       git commit -m wip
> When I experiment starting from a clean slate (after saving away
> such a WIP commit), I would then do this:
>         git checkout HEAD^
> to start at the state before the WIP commit and hack away.  As I do
> not know how the experiment would go when I do this, I often do not
> bother giving the experiment its own branch.
> If the experiment does not seem to go in a productive direction, I
> can simply "git reset --hard && git checkout -" to get rid of it.
> On the other hand, if its direction shows promise but turns out to
> be more involved than a quick hack, I can at that point decide to
> give it its own branch with "git checkout -b newbranch".  Then I can
> choose to keep working on it, or switch to other tasks after making
> a wip commit on that new branch.
> Or if the experiment results in a series of good and straightforward
> changes that should come _before_ that original wip (which happens
> very often), then I could do:
>       git commit ;# maybe more commits.
>       git cherry-pick @{-1} ;# the one stashed away
>       git co -B @{-1}
> to update the original branch and come back to it.

Also, if the alternative experiment was really to replace what you
originally did to your index, as a natural extension to the above
workflow, you would omit "cherry-pick" step in the above.  Your
perfected alternative solution will become the true history of the
original branch, discarding the tentative solution in the index.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to