Theodore Tso <tytso@mit.edu> wrote:
quoted text
> On Tue, Oct 23, 2007 at 01:07:26AM -0400, Shawn O. Pearce wrote:
> > 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 text
> > 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

quoted text
> 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.
 
quoted text
> 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.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html