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