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

[Bruce Stephens]

Patrick Georgi <address@hidden> writes:

[...]

> Basically mtn-plucking a set of revisions to somewhere else, while
> giving the head of "somewhere else" a suspend cert. That will make the
> repository grow a lot, of course (as we don't throw away things)...

Shouldn't be "a lot", since typically there ought to be lots of shared
text?  Perhaps that's more so for git (where more things end up being
deltad).

> If someone else already worked from the old head, things will be messy:
> two heads with "unrelated" changes (esp. for new files and the like!).
>
> I'm just trying to wrap my head around how such things could be
> approached.

Maybe a useful start would be to mark revisions and so on as "local"
initially, and only permit this kind of operation for those?

>> > 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.
> We thought that would be the case for certain currently problematic
> non-content merge scenarios, too...

Probably the difference is that this case is nice and immediate?  If
you rewrite history then you need to use "git push --force" (or
equivalent), and anyone working from that with immediately see the
problem.

Non-content conflicts can lurk for some time before being noticed, so
you don't necessarily know you're doing anything wrong.

On the other hand, in git a branch can only have one head.  Perhaps in
monotone a rebase-equivalent wouldn't be so obvious in use, so would
end up causing more problems?

[...]

>> Maybe, though that would only be one part of what "rebase" is used
>> for.

> The other(s) being?

It's probably wrong to concentrate too much on what "git rebase" does,
and to think more on what git's ability to rearrange things allows.
(Everything that "rebase" does can be done in other ways, too, and
currently git-rebase is a shellscript.)

<http://tomayko.com/writings/the-thing-about-git> gives some examples.

I don't know how much of this would make any sense in monotone.

I'd just like to emphasize that git (and darcs, though git's faster
enough that I think it wins now) does this kind of thing really well,
and that this kind of (basically local) fiddling around is valuable,
at least for some purposes.

However, it's quite likely something of a philosophical difference.
In git the idea is to permit people to experiment freely, with the
expectation that if something works out then even then some reworking
to get a clean history will be both necessary and desirable.

That fits well for us (at work) because we require code review before
integration (we used to use CVS, with scripts to send out patches).
So we're used to reworking things in that sort of way (git's just a
better set of tools).

But it's reasonable to view things quite differently: that a VCS
should never throw away work in this way, and that you always rework
things by adding further revisions.  In that kind of mindset I guess
you might want "super-revisions", ways to group little changes
together, or perhaps graphical tools that let you mostly ignore merged
subbranches, and that kind of thing.  (IIUC that's more the way bzr is
going, though quite possibly I misunderstand.)

I use rebase commonly for a few things (all involving commits that
haven't yet gone out of my repository):

  * I'm working on something, and (after adding some things that
    aren't ready yet) add something which is (maybe a bugfix that I
    notice while doing that work).  If I'm sure the bugfix works fine
    applied right now, I can use rebase to move it to the front of the
    list and get it integrated quickly.

  * I'm working on something, and once I've got it working realise a
    better way I could have done it, involving doing basically the
    same but in a different order (maybe I change the API first rather
    than last or something), and rebase can help with that.

  * I get to the end of some sequence and realise there's some
    debugging code (or maybe some Makefile hack that works on
    GNU/Linux but nothing else) I inadvertently committed right at the
    beginning.  git-rebase is an easy way to fix that.  Indeed, it's
    so easy that sometimes I use shortcuts like that
    deliberately---just commit all the changes and clean it up later.

  * I email a change for review, and the reviewer actually commits it,
    but they commit something slightly different (in git's model the
    commit message is part of the hash, and we use "Signed-off-by"
    fields to indicate review).  It turns out that rebase recognises
    this kind of thing, so I can just do "git pull --rebase" and my
    versions of the commits disappear while any current work gets
    moved to the current head.  (And I get various options should
    there be any conflicts.)