Re: Data Integrity & un-Commited Branches

It was a misunderstanding of Git's work flow. By switching from 'an
un-committed demo' to a previously committed master: I was expecting
Git to give me the content last commited to master while at the same
time preserving(without having to commit) the changes made in demo.
Intuitively, this is how I expected Git to function.

Indeed, I read through the Crash Courses: 'Git for everyone' & 'Git
for SVN users'.
-- 
Brian Scott Dobrovodsky

Brian Scott Dobrovodsky [off-list ref] wrote:

It was a misunderstanding of Git's work flow. By switching from 'an
un-committed demo' to a previously committed master: I was expecting
Git to give me the content last commited to master while at the same
time preserving(without having to commit) the changes made in demo.
Intuitively, this is how I expected Git to function.

You aren't the only one.

Several of my day-job coworkers have also thought the same thing.
Only they use git-gui, and have never read any of the Git docs.
Because nobody ever reads the docs.  Nope, not if you can just dial
my extension and browbeat me into giving you an answer to your most
urgent question.  :-\

My point is just that some people actually assume that work done
while having one branch checked out is related to that branch and
that branch alone and that switching a branch should put that work
on hold.  Unfortunately for me some of these people at day-job have
also just assumed Git can read their mind and forget to switch
branches at the proper times, resulting in unrelated work mashed
together for days straight (and criss-crossed merge to hell and back)
before they call me and say "MAKEITWORKNOW".
</rant>

It isn't unreasonable to want Git to save uncommitted work for the
current branch and then you switch to another, ending up with a
clean working directory when you finally get there.  Today we have
git-stash to help you with this, but I'm thinking maybe we want to
connect git-checkout with it?

I see `-s` isn't used as an option yet.  What about:

	$ git init
	$ echo master >file
	$ git add file && git commit -m initial

	$ git checkout -b demo         ;  # switch to demo
    $ echo demo >file              ;  # dirty the tree

	$ git checkout -s master       ;  # stash and switch to master
	Uncommitted changes stashed on branch 'demo'.
	$ cat file
	master

	$ git checkout demo            ;  # return to demo
	Uncommitted changes were stashed for 'demo'.
	To recover them now run:

	  git stash apply -s

    $ cat file
	master
	$ git stash apply -s
	$ cat file
	demo

The new `git stash apply -s` here is defined to find the most
recent stash for the current branch (which may not be the top of
the stash!) and apply it.

If you know you want to just reapply the stash when you switch back
we could define `git checkout -a` (also unused) to automatically
execute `git stash apply -s` if a stash is available for the
destination branch.

Just thinking out loud.  I probably won't code up a patch that
implements this but I don't think it would be too difficult for
someone else who wants to get their feet wet.

-- 
Shawn.

My point is just that some people actually assume that work done
while having one branch checked out is related to that branch and
that branch alone and that switching a branch should put that work
on hold.  Unfortunately for me some of these people at day-job have
also just assumed Git can read their mind and forget to switch
branches at the proper times, resulting in unrelated work mashed
together for days straight (and criss-crossed merge to hell and back)
before they call me and say "MAKEITWORKNOW".
</rant>

As I have learned over the years, assumptions can be fatal. I can not
use something until I wrap my head around it and test it. Especially
for managing something in production! So far, this has been the only
problem/mis-understanding.

It isn't unreasonable to want Git to save uncommitted work for the
current branch and then you switch to another, ending up with a
clean working directory when you finally get there.  Today we have
git-stash to help you with this, but I'm thinking maybe we want to
connect git-checkout with it?

That would be great as a default action when using checkout!
+Switching branches without having to commit improves work flow.
+Fewer commits = cleaner logs.
+More Intuitive!

I am currently using git-1.5.1.6, which apparently does not have
git-stash. I will upgrade and check it out.

Cheers,
-- 
Brian Scott Dobrovodsky

Brian Scott Dobrovodsky [off-list ref] wrote:

quoted

It isn't unreasonable to want Git to save uncommitted work for the
current branch and then you switch to another, ending up with a
clean working directory when you finally get there.  Today we have
git-stash to help you with this, but I'm thinking maybe we want to
connect git-checkout with it?

That would be great as a default action when using checkout!

Well, a lot of "Git old timers" like the current action of keeping
the tree dirty during a switch.  But maybe we could also teach `git
checkout` that a user specified configuration option can cause it
to automatically stash/unstash unless -m is supplied.  Or something.

Patches are always welcome.  ;-)

+Switching branches without having to commit improves work flow.
+Fewer commits = cleaner logs.

Well, I'm not sure that matters here.  Typically Git users will make
heavy use of commit rewriting features (e.g. `git commit --amend`
or `git rebase -i`) to cleanup changes on a side branch before they
submit them to the mainline.  This makes it easy to commit all of
the time and not worry about how the resulting logs will look.
Plus they can have look like they have some serious code-fu and
always write things perfectly the first time. :)

Indeed, before git-stash came about I parked changes on a branch
using the following technique:

	$ git commit -a -m PARK       ; # stash on "demo"
	$ git checkout master         ; # tree is now clean
	$ git checkout demo           ; # back on demo
	$ git reset --soft HEAD^      ; # undo the stash

No messy history, nice neat per-branch stash.  Oh, you can do that
in Git 1.3.  And even earlier probably.  I actually still use this
trick from time to time as I find it flowing out of my fingers far
easier than git-stash.

-- 
Shawn.

On Fri, Sep 14, 2007 at 22:51:29 -0400, Shawn O. Pearce wrote:

It isn't unreasonable to want Git to save uncommitted work for the
current branch and then you switch to another, ending up with a
clean working directory when you finally get there.  Today we have
git-stash to help you with this, but I'm thinking maybe we want to
connect git-checkout with it?

I think it would be reasonable if it just forced you to decide about it. That
is reading the documentation, checkout only switches branches if the merge of
each modified file is trivial and only does 3-way merge if it got -m option.

It might be reasonable to requre that option for all cases, where there are
local changes and the branches don't point to the same commit and without it,
checkout should say something like:

  Cannot switch branches, because the tree is modified. You can apply the
  modifications to the target branch by using -m option, or commit them
  before switching branches (you can undo or amend that commit later if it's
  not finished yet).

The case with branches pointing to the same commit is for checkout -b,
reverting that command if you do it too early/by mistake/wanted branch
instead and for doing it with branch + checkout.

-- 
						 Jan 'Bulb' Hudec [off-list ref]

Jan Hudec [off-list ref] wrote:

On Fri, Sep 14, 2007 at 22:51:29 -0400, Shawn O. Pearce wrote:

quoted

It isn't unreasonable to want Git to save uncommitted work for the
current branch and then you switch to another, ending up with a
clean working directory when you finally get there.  Today we have
git-stash to help you with this, but I'm thinking maybe we want to
connect git-checkout with it?

I think it would be reasonable if it just forced you to decide about it. That
is reading the documentation, checkout only switches branches if the merge of
each modified file is trivial and only does 3-way merge if it got -m option.

It might be reasonable to requre that option for all cases, where there are
local changes and the branches don't point to the same commit and without it,
checkout should say something like:

  Cannot switch branches, because the tree is modified. You can apply the
  modifications to the target branch by using -m option

The thing there is `git checkout` by default does a switch only
if the merge is really trivial.  In such cases its probably sane
to carry the changes with you to the new branch/parent commit.
At worst you can safely carry them right back.  Or stash them.
But -m does a three-way file merge, which isn't trivial, and can
result in conflicts.

So I know that myself and Junio both rely on the default behavior
to tell us if a switch is even a good idea right now, or if we
should stash the changes and *then* do the switch.  Because if you
do the switch with -m and there are conflicts you are up a creek
with no paddle... and there's a mighty big water fall coming up
in 3 feet... 2 feet... oh crap!

Making -m the only way to switch with dirty state is not a feature.
Its a regression.

-- 
Shawn.

One thing that I've been bitten a couple of times is that
I think I'm on branch X, which should be clean, whereas
I'm really on branch Y with uncommitted changes. Then I
checkout another branch, and see the uncommitted work -- and
given that I have a couple of dozen related feature branches
in my tree it may take a while to figure which branch the
uncommitted work came from.

It would be nice if the "uncommitted changes" message when
swithching branches told you which branch you came from...

Cheers,

 -- Nikodemus