Re: [PATCH] Clarification for the command "git checkout <branch>"

From: Markus Elfring <markus.elfring@web.de>
Date: Mar 19, 2010, 08:15 UTC
Message-ID: <4BA3329E.6050304@web.de>
In-Reply-To: <b4087cc51003181019r4408953bxcd5049c9521b8173@mail.gmail.com>

> Are you not reading? Are you not comprehending? Are you trolling?

I answer these three questions with "NO".

I find that the discussion is not finished yet. It was not achieved a common conclusion and consensus on all mentioned details so far.

>> stashing isn't really something you'd want to do on a per-branch
>> basis.  Most of the point is that you stash away your changes, then
>> switch to another branch, then restore your stash to your *current*
>> working state sometime later.

I have got different expectations. I would expect that there are enough intermediate work results available to justify a stash per branch so that unwanted "temporary" or "throw-away" commits can be avoided.

> As you may know, "git checkout" carries local modifications to the new
> working tree if there are no conflicts, so no explicit stash usage is
> necessary in many cases.

Various software projects have got different amounts of uncommitted changes between branches.

Show 5 quoted lines

> Anyway, I think it would be useful to be able to manage multiple
> stashes rather than having to rely on just one global stash. However,
> I imagine than explicit Work In Progress (WIP) commits as sketched
> above would go a long way in keeping histories and workflows clean
> and organized.

I am also interested in improvements for this feature request. Does a "WIP" really need a commit to get the unfinished changes stored?

Regards, Markus