Re: What's cooking in git/spearce.git (topics)

Theodore Tso [off-list ref] wrote:

On Tue, Oct 23, 2007 at 01:07:26AM -0400, Shawn O. Pearce wrote:

quoted

Junio has in the past proposed rewinding next, especially after a
significant release (e.g. 1.5.3).  

Hmm, yes.  I think I'd want to rewind next after a while; the thought
of next drifting hundreds or thousands of commits away from master
just gives me the heebee-jeebies.  I'm sure it mostly works, but it
just feels wrong.  :-)

There's been a couple of times in git history where Junio has basically
done this to whack next back into line:

	git checkout next
	git diff next master | git apply --index
	git commit -m "Whack next back in line"

Because we've found a change or two lurking in there that shouldn't
have been there after a while.  I think it was related to a merge
conflict that happened in next but didn't in master or something
like that.  But usually this difference exists as there's usually
always something cooking in next.
 

quoted

A bunch of folks (myself included if I recall correctly) didn't want
to do this, as we create topic branches locally from things in next
and sometimes make commits over them to improve the topic further.

I guess I don't see why this would be a hardship; would a quick rebase
on the topic branches more or less take care of the problem?  

Yes.  But you need the prior value of the branch so you can do
something easy like:

	git checkout yourtopic
	git rebase --onto $newtopic $oldtopic

which means you probably need to look through the logs for not just
pu but also pu@{1}.  A script to break out the topic branches from
pu post fetch and store them as proper tracking branches would make
this easier, but that much.  If you plan ahead you can save that
$oldtopic point so you can do something like this:

	git log pu ; # find $newtopic
	git checkout yourtopic
	git rebase --onto $newtopic base-yourtopic
	git tag -f base-yourtopic $newtopic

I guess that brings up another question; I've been regularly rebasing
the topics branches as master and next advances... probably more out
of superstition than anything else.  Is that a bad idea for any reason?

It keeps the history shorter in gitk.  But otherwise it isn't bad.
Unless you are running into a lot of conflicts every time you rebase
and its wasting your time.  ;-)

I prefer to rebase the topics until they've merged to an integration
branch that doesn't rewind (e.g. master or next in git.git).
That way they have the shortest line possible in gitk between the
final merge and the start point.

There are good reasons why there's an "author" and a "committer"
field in commits.  Rebasing will change the committer field's
timestamp, but not the author field.  And author comes from the
email, to preserve the original date of development.
 

Hmm... I guess some of this would be really good to get into the Howto
section of the user guide when talking about git workflows!

Yea, I think so too.  We've adopted this model in git.git because
it works for our community.  A lot of other communities aren't
too far away, as we have a lot of crossover in members.  E.g. we
learned a lot from the kernel community.

-- 
Shawn.