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

[Bruce Stephens]

Patrick Georgi <address@hidden> writes:

> Am Sun, 4 May 2008 08:18:25 +0000 (UTC)
> schrieb Holger Freyther <address@hidden>:
>>      - git-rev-list origin/qtwebkit.. (to show what I would push now)
>> is missing
> What's origin - the last server you connected, or the default one?

origin is (usually) the first server.

That is, if you do "git clone
git://git.kernel.org/pub/scm/git/git.git" then in the resulting
repository "origin" refers to that server.

That creates copies of the branches, naming them with the prefix
"origin/".  You also get (by default) a branch "master" which is
initially has the same value as "origin/master", and is set up with a
certain amount of magic so that if the current branch is "master" then
"git fetch" will fetch from "origin", "git merge" will merge with
"origin/master" and so on.

"origin" need not be the last server or the default one.  There may be
different defaults for different branches.

I guess that's a result of one important difference between monotone
and everything else: in monotone branches are global, but in
everything else they're (more or less) strictly per-repository.  In
git the remote branches are also kept locally; I'm not sure whether
that's true in other systems.

> It should be possible to track a list of head revisions per server (or
> the default one, etc.) after each pull or sync, and use "automate
> ancestry_difference" to calculate that.
> I'd write a wrapper-script for that (as proof of concept, at least), if
> we get sorted out, what to check against.

That would probably be about right.

>>      - gitk is almost instantly working on the OE tree
> what's the complaint here - speed? features?

Dunno.  Probably a bit of both.  gitk produces the same kind of graph
that "mtn log" does, so I guess the layout is much faster.  (On git
repositories that works well since the graphs tend to be more linear.
I'm a bit surprised it's acceptable for OE's.)

>>      - git-fetch will tell me what was updated, which branches
>> created, mtn doesn't have this. 
> Again, I could write a wrapper script for that (though an inline
> variant would be more efficient, avoiding the second "ls branches",
> by looking at the incoming packets): ls branches, pull, ls branches,
> diff

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?

[...]

> As for the other "forced to a work flow" issues, I don't know what
> the git commands provide (and I fear that I won't get a 100% idea
> from reading the docs)

That seems likely, yeah.

Some issues (like being able to commit parts of a single file change
("git add --patch") are things that front-ends and scripts can do just
as well (or better), I'd guess.  (Indeed, qct does that, IIRC.)

I'd guess a lot of the other stuff probably relies on git's
implementation: the DAG contains no branch information, branches are
files containing the hash of the branch head.  So amending the last
commit is easy, you just create the new commit and move the branch
ref.  Similarly you can rewrite sequences of commits in the same way
(which is what "git rebase" is about).

In principle monotone could offer some of those things (graydon
outlined an implementation of some of it a while ago), but I can
understand why you wouldn't want to.  There'd be some danger of trying
to copy git too closely, and git's interface obviously builds on
implementation details (in particular the (awkwardly named) index), so
you might end up with something that feels ugly and slow which in git
feels fluid.

If you want to read documentation for git, the user manual is really
pretty good now:
<http://www.kernel.org/pub/software/scm/git/docs/user-manual.html>.