Re: [Gnu-arch-users] Maintainership, and whiners...

[Martin Langhoff]

On 10/13/05, Miles Bader <address@hidden> wrote:
> 2005/10/13, Martin Langhoff <address@hidden>:
> > > In the meantime we'll just have to put up with
> > > the various lousy options current available.
> >
> > Strange. Are you unhappy with the "new generation" SCMs that came
> > forward in the time around the bitkeeper fiasco or soon after? Why?
> > I'm personally really impressed with git/cogito and mercurial.
>
> I dunno, they all seem to have their share of large annoying warts...
>
> BTW, have you used mercurial for real?  When I tried it out, it didn't
> seem to handle file-renaming in any sane manner (as far as I could
> tell, it just modelled renaming as add+delete, which utterly destroys
> merging), and that's a pretty fatal flaw.

No, it's not a fatal flaw... see, I've had too much of Linus'
kool-aid, and I've now seen why it's the right thing to do. Let me
explain...

The problem with "expecting the scm to deal with renames" is that most
SCMs have a very naive implementation, trying to catch renames and
similar operations at _commit_ time. That's putting the smarts in the
wrong place.

GIT stores very stupid (but fast) representation of each commit, with
minimal additional metadata. But the underlying system is fast, and
you can do rename detection at merge time. The current state of merges
in git is that

 + it goes for stupid+fast first, assuming that no files have been
changed by both sides, nor been renamed, nor anything fancy. This is
still 99% of your cases and is _fast_...
 + if it finds that both sides have changed, it'll try diff3, and if
that isn't clean it'll try a sequence of mergers
 + one of those merges deals with renames: if a target file in the
patch isn't there, it walks up the commit history trying to find the
commit where we last saw a file with that name, and then analyses that
particular commit to detect the rename

All these merge-time smarts are not only pluggable+stackable, but can
grow, bringing  improved merging smarts (and annotate-like features)
without changing the repo format or the commit format. Actually, you
can add an {insert language here}-aware merger that can kick in and
try and resolve nontrivial merges based on language-specific criteria.

So no, mercurial and git won't let you record the "move" with magic
metadata or any other strange commit type (darcs anyone?).

> I was kinda hoping codeville would evolve into something cool... it
> seemed promising but immature when I looked at it.

Git+StackedGIT are proving very fun -- we already transitioned several
teams to GIT using cogito+gitk as UIs. And qgit is a qt-based UI for
GIT and StackedGIT that does cherry-picking via drag and drop (this in
particular is both great and awful).

I'm personally having a lot of fun hacking on git and cogito, and they
are proving to be rock-solid tools for us, and we do a lot of merging
and patch-tracking.

cheers,


martin