Message-ID: <1335966292.14207.40.camel@gandalf.stny.rr.com>
Date:	Wed, 02 May 2012 09:44:52 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Junio C Hamano <gitster@...ox.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org,
	Git Mailing List <git@...r.kernel.org>
Subject: Re: [PATCH 0/2] [GIT PULL] ktest: A couple of fixes

On Tue, 2012-05-01 at 20:49 -0700, Junio C Hamano wrote:
> Linus Torvalds <torvalds@...ux-foundation.org> writes:
> 

> When a normal developer wants to _reset to_ a particular tagged release,
> in order to _start_ new work, she wouldn't be doing even the above "git
> pull linus v3.4-rc5".  That will contaminate the result with whatever
> random stuff she happened to have on the current branch.  A more natural
> sequence would be "git fetch --tags linus" followed by either
> 
>         git checkout v3.4-rc5 ;# to detach

The problem is, I like to know what has been pulled into mainline. I
have patches in quilt (for ktest only, not for my other work) and will
start adding them on a "clean" release. By doing a git pull (or fetch
and merge), I like to see the fast forward to know if everything that's
in my current branch has been pulled. If it hasn't, then something may
have been missed.

> 
> or
> 
>         git checkout -b mywork v3.4-rc5 ;# to start

But then I would end up with several branches that would require
deleting. One way I could see myself in handling this case would be to
delete the current branch and start again (thinking that everything was
already pulled). But by doing that, if something wasn't pulled in, then
I would have lost those changes without ever knowing.

> 
> So the case to "reset to" is not very interesting.
> 
> But when a normal developer wants to _sync to_ a particular tagged
> release, in order to _continue_ working on her topic, she would need to
> have a merge (unless she does not have _anything_ herself), and at that
> point, merging v3.4-rc5 vs v3.4-rc5^0 would not make that much of a
> difference.  If she absolutely detests the "mergetag" header, she could do
> a "git fetch --tags linus" followed by
> 
> 	git merge v3.4-rc5^0
> 
> which admittedly is two more letters than she used to type.

This would fit into my workflow. Thus I could use this.

> 
> If you mean by "Ideas" for additional features, obviously the last step
> could be enhanced to use a more intuitive command line that requires the
> user to type even more, i.e.
> 
> 	git merge --ff v3.4-rc5
> 
> Once that is done, "git pull --ff linus v3.4-rc5" would fall out as a
> logical consequence.
> 
> But obviously these two would need new code ;-)

The -ff would make sense as it seems to be the logical thing a user
would want. If they specify the fast-forward flag, then the user would
expect the merge to be a fast forward if possible.

BTW, is there a git compare type option. That is, I like to compare two
separate branches with the result that one currently gets with git when
a branch is following another branch. When you check out that branch, it
gives you an update on how those two branches are related (is one a fast
forward of the other, are they off by different commits?). It would be
nice if git could do this with any two branches. I wrote a script to do
this for me (attached) but it would be nice if git had it natively.

$ git-branch-status v3.0.4 v3.0.5              
Branch v3.0.4 can be fast forward to v3.0.5 in 240 commits

$ git-branch-status v3.0.4 v3.1  
Branch v3.0.4 and v3.1
differ by 257 and 9380 commit(s) respectively


-- Steve

Download attachment "git-branch-status" of type "application/x-shellscript" (680 bytes)

Powered by blists - more mailing lists