Re: Data Integrity & un-Commited Branches

Re: Data Integrity & un-Commited Branches

[Brian Scott Dobrovodsky]

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

Re: Data Integrity & un-Commited Branches

[Shawn O. Pearce]

Brian Scott Dobrovodsky <brian@pontech.com> 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.

Re: Data Integrity & un-Commited Branches

[Brian Scott Dobrovodsky]

> 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

Re: Data Integrity & un-Commited Branches

[Shawn O. Pearce]

Brian Scott Dobrovodsky <brian@pontech.com> 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?
> 
> 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.

Re: Data Integrity & un-Commited Branches

[Junio C Hamano]

"Brian Scott Dobrovodsky" <brian@pontech.com> writes:

>> 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!

I would not bet you will stay feeling that way as you gain
experience.  With "git stash create" (will be in 'next' this
weekend), we could start using stashes more transparently from
other commands, but I do not think this will ever become the
default for branch switching, while I do not oppose to have such
an option.

Re: Data Integrity & un-Commited Branches

[Brian Scott Dobrovodsky]

> I would not bet you will stay feeling that way as you gain
> experience.  With "git stash create" (will be in 'next' this
> weekend), we could start using stashes more transparently from
> other commands, but I do not think this will ever become the
> default for branch switching, while I do not oppose to have such
> an option.

Stashing as the core default may have been over zealous..

Cheers,
-- 
Brian Scott Dobrovodsky

Re: Data Integrity & un-Commited Branches

[Jan Hudec]

[-- Attachment #1: Type: text/plain, Size: 1299 bytes --]

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 <bulb@ucw.cz>

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Data Integrity & un-Commited Branches

[Shawn O. Pearce]

Jan Hudec <bulb@ucw.cz> wrote:
> 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

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.

Re: Data Integrity & un-Commited Branches

[Nikodemus Siivola]

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

Re: Data Integrity & un-Commited Branches

[David Kastrup]

"Nikodemus Siivola" <nikodemus@random-state.net> writes:

> 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.

"Take a while"?  What's wrong with git-reflog?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Data Integrity & un-Commited Branches

[Nikodemus Siivola]

On 9/15/07, David Kastrup <dak@gnu.org> wrote:

> "Take a while"?  What's wrong with git-reflog?

Not needing it as a part of my regular workflow, and therefore
not thinking about it. *blush*

Cheers,

 -- Nikodemus

Re: Data Integrity & un-Commited Branches

[David Kastrup]

"Nikodemus Siivola" <nikodemus@random-state.net> writes:

> On 9/15/07, David Kastrup <dak@gnu.org> wrote:
>
>> "Take a while"?  What's wrong with git-reflog?
>
> Not needing it as a part of my regular workflow, and therefore
> not thinking about it. *blush*

"Oh no, what have I done now?"

I am afraid that working with git still exposes me to this question
time and again.  And git-reflog usually provides the answer, as well
as what I need to recover.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum