Junio C Hamano <gitster@xxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html