Re: Better cooperation between checkouts and stashing

From: Markus Elfring <markus.elfring@web.de>
Date: Feb 28, 2010, 13:55 UTC
Message-ID: <4B8A75D9.2090702@web.de>
In-Reply-To: <7vr5o6s5xf.fsf@alter.siamese.dyndns.org>

> It is important to understand that a local change does not belong to your
> current branch (it does not belong to _any_ branch).  It belongs to you,
> and you can take it around while switching between branches.  And that is
> a big time-saving feature.

It seems that we have got different expectations on the editing work flow when we discuss the following situation.

elfring@Sonne:~/Projekte> git --version && mkdir try && cd try && git init --quiet \

> && echo one > XYZ.h && git add . && git commit --message=check-in --quiet \
> && git checkout --quiet -b feature1 && echo two > XYZ.h \
> && git checkout --quiet master && git status

git version 1.7.0 # On branch master # Changed but not updated: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: XYZ.h # no changes added to commit (use "git add" and/or "git commit -a")

I would prefer to return to the unchanged work tree because I made an adjustment for a source file with the intention that this update should only belong to the new topic branch. The switch did not provide a clean state from my view.

>  - You are reading a mailing list message that asks for help, and you know
>    the solution---you can give the help real quick.
> 
>  - You hack in whatever branch that happen to be checked out.

I would create another topic branch before.

Show 7 quoted lines

>  - The branch you happen to have checked out was 'next', but the solution
>    is a bugfix, and should go to 'maint'.
> 
> Now, at this point, you want to checkout 'maint' without losing your local
> change.  The paths you touched with your quick fix are often not different
> between the two branches, and "checkout maint" will checkout the branch
> while keeping your local changes intact.

I can follow your view on convenience if the desired software maintenance is so easy as in this example. I guess that it matters if only a simple branch switch is needed or a corresponding content restore will also be required.

Show 5 quoted lines

> In a case where "checkout -m" would result in a conflict too big to
> resolve, the original fix you made would not be applicable to 'maint'
> (iow, you should have solved it differently starting from 'maint'), and
> you may end up doing "reset --hard" and start from scratch, but that is a
> rare worst case.

I would like to be more careful so that I do not want to mix changes by accident.

Show 5 quoted lines

> I said it is rare, because you would notice, while doing the "quick fix"
> based on 'next' codebase, that the code you are touching have changed
> since 'maint' and won't be applicable to its final destination (by that
> time you know you are "fixing"), and you won't waste too much time
> continuing to work in a checkout of 'next'.

I imagine that stashing will help to split the collected changes for different branch targets.

Regards, Markus