[Monotone-devel] Re: OpenEmbedded looking to jump ship

[Bruce Stephens]

Patrick Georgi <address@hidden> writes:

[...]

>> I'd have thought note_netsync_revision_received or something would be
>> OK for that?  Maybe one wants a hook that receives all the revisions
>> in one go or something?
> hmm.. initialize a branch list at the beginning, then check each
> incoming revision - could work.. thanks, I didn't think of the hooks!

Maybe the existing hooks are sufficient, actually.  Or do hooks get
evaluated in different lua interpreters?  If they're evaluated in the
same one, then you could presumably code up something using
note_netsync_start, etc.?

[...]

> That [rebase] could be done by monotone easily, too - but if your
> previous revision was pushed, you have two heads now

Sure.  So you don't (usually) do that.

>(just that git doesn't
> allow for that, "solving" that issue and leaving the old rev for the
> garbage collector, because you push a new head at a completely
> different location.
> ... unless someone else started work from your old head already - right?

Quite.  And that's why git-push (by default) checks that your commit
is a descendent of the current one---because it causes problems if
you've published the old version.  Sometimes you really do want to
rebase and push the result---I do that regularly, but only on branches
I don't expect anyone else to use.

So mostly you use rebase on local work---you commit when it makes
sense, and then reorganise the changes.  Perhaps to improve the
reviewability of the changes, or in response to review, or maybe just
to incorporate upstream changes (you can merge, of course, but
sometimes it makes just as much sense to linearise the changes by
moving your changes to the current head).

> Which is why I still think that rewriting history is a bad idea.

Perhaps.  I'd just comment that git users seem to find it works fine
and is valuable.  I think perhaps you're imagining it gets used in
problematic situations where it (mostly) doesn't.

> For monotone it would be more like "reapply (from, to) to (new base
> rev)".  That isn't _too_ different from just merging.. (just that
> you have one new revision at the top, instead of 250 revs. copied to
> a new location in the DAG)

Maybe, though that would only be one part of what "rebase" is used
for.  I don't know how valuable that would be to monotone users, or
whether it would be enough for people considering monotone and git.