Re: Git hosting

[Behdad Esfahbod <behdad behdad org>]

Thanks Elijah for jumping in.

On Wed, 2008-03-05 at 06:25 -0700, Elijah Newren wrote:
[...]
> I crave the wonderful usability of bzr.  In my mind, it's a notch
> above the rest.  svn and hg aren't too far off, but bzr has some extra
> polish.  However, it has parallels to svn here in that the format is
> going to limit its utility to many people.  I was talking to Ian
> Clatworthy (bzr dev) about all kinds of bzr and DVCS issues; cool
> things in bzr, stuff to put in his writeups, etc.  He did his best to
> answer questions and sell bzr, but when I pointed out the most obvious
> and painful missing feature in bzr that I'd miss the most from using
> git -- being a branch container -- there was simply no response.  The
> ramifications of this single feature are huge, though -- it means much
> more than what you'd expect from a single listed feature.  In fact,
> when you look closely enough, you find that *several* of the features
> being developed by bzr in many ways amount to partial workarounds for
> this missing functionality.  Also, if you read through the bzr layout
> model and read over their documentation, you find that their
> assumption of branch==directory goes all the way to their very core,
> so this will be something that would be extremely difficult for them
> to change.  And I'd be worried about pushing bzr on the developers of
> large and low-level modules, because missing this feature would be
> painful to them.

Right.  When I started git first I was shocked that I need two clones to
keep the stable and the devel branches *around*.  But very soon I found
that indeed I just want a single clone, and switching branches is so
fast that I actually don't mind switching over all the time.  And we
optimized our autotools stuff to minimize rebuilds needed.

> What's the rationale for having everybody use the same thing?  I will
> likely agree with it, but it is worth noting that some of the reasons
> for such a requirement may not be as important anymore.  I'll note the
> changes in progress already mentioned in this thread to allow
> translators to not have to use a VCS at all, and also the existence of
> a simple tool called 'mr' which can be used to interact with projects
> under half a dozen different VCSes all using the same commands (sure,
> you're limited to the lowest common denominator, but that essentially
> amounts to the common operations of cvs/svn).

Didn't know about 'mr', but always thought about something like that.
The only times I've found it's hard to emulate one VCS' behavior with
another one is times like a merge failing and needing intervention.
Otherwise, the routine things can really be wrapped very easily.


> >  >   - *very* easy to commit to e.g. gnome-2-22 branch, 'trunk', etc
> 
> svn does this in one step, you can turn it into a single step in bzr
> (a combined local commit + push; see 'bound branches'), and in hg and
> git it will be just two steps (commit + push).
> 
> I don't think this rules out any system.
> 
> >  One can write shell scripts that make it very easy to do so...  We can
> 
> Bah!  "The tool is broken but I know how to work around it".
> 
> The tool is stupid and lacking if you have to do this, IMO.

Well, there are as many different workflows as there are users.  A tool
having one command for each of them is not necessarily the most flexible
and better one.  If a workflow is logically divided into multiple steps:

  - Checkout the gnome-2-22 branch
  - Edit the .po file
  - Commit it
  - Fetch any possible remote changes, rebase
  - Push it out

and if the user can't be bothered to run three commands, I don't see why
a shell script is stupid.  I have a shell script in my cairo tree,
called 'g', that does:

  git fetch cairo
  git rebase cairo-origin

Sure, one may go lobby for calling that git-update.  For me, it does the
job, and I better understand what's going on.  The above is kinda
non-standard.  A more standard version would be:

  git fetch origin
  git rebase origin/master

that's pretty much equivalent to 'svn update'.


> I haven't looked at the bindings side myself, but from what I've read
> bzr would be the winner here, then hg, and git doesn't have much of
> anything at all.  (git is really nice from a shell scripting side...in
> fact, it seems like it was designed for someone else to write a
> wrapper around it...oh, wait, it was.  Too bad no one has made a good
> one yet and published it)

That's not true.  Tim Janik has published one for example, called
YummyYummySourceControl:

  http://blogs.gnome.org/timj/category/tools/


> Elijah
-- 
behdad
http://behdad.org/

"Those who would give up Essential Liberty to purchase a little
 Temporary Safety, deserve neither Liberty nor Safety."
        -- Benjamin Franklin, 1759