[PLUG-Devel] Rah, rah git! [Was: OT: sourceforge or codeplex or googlecode for OSS hosting]

[voltagespike+plugdevel at fastmail.fm]

On Sep 18, 2008, at 8:02 AM, Ted Gould wrote:

>>   * Far smaller repositories than any other tool
>
> This was true of the original repository format bzr used.  But, the
> newer formats are more efficient.  Since the repository formats are
> plugable, they get upgraded (see below).

I thought this made its way in 1.3, so this 1.5 test would be relevant:

http://vcscompare.blogspot.com/2008/06/git-mercurial-bazaar-repository-size.html

I see that there is a 1.6, though, so I'd appreciate a heads-up as to  
where the new format became standard.

>>   * Far faster than the other tools
>
> Most of that performance has been eclipsed with recent versions of  
> both
> tools also.  Git is still faster, but I wouldn't put it in the "human
> can notice" faster category.

Again, perhaps this changed with 1.6 so I'll give it another try.

I should have mentioned up front that for smaller repositories (let's  
say less than a few hundred megabytes and a history with less than 5  
digits) most people will not care about size or performance ... but  
it's nice to know that you can grow.

>>   * git rebase is superior to bazaar's mainline
>>
>
> Heh, well, I would say that this is a flaw of Git and find it
> interesting that you put it in the pluses category.  Basically the git
> log format is date based not taking into account merges.

By default it is date based, but you can easily call up a topology if  
you wish. I'm not certain off the top of my head how to show _only_  
merge commits (as in bzr). I think a date order makes more sense in a  
distributed system, but, you are correct, bzr works harder to be  
_like_ a centralized SCM while still offering the strengths of a  
distributed system.

> So there is a rebase command to move where your log is from so that  
> it can
> be readable again.  Bazaar solves this by having a readable log in the
> first place :)

I'm not sure I follow. Because it is date based, rebase doesn't change  
the log output. People rebase to linearize history and clean up their  
changes (most tools, including some git users, accomplish this through  
stacks of patches). It is more of a discipline than anything else with  
the goal of making sure that every commit is clean and functional.  
This is especially important when performing a bisect, but it also  
helps tremendously when performing code reviews.

>>   * git as everything built-in, I don't have to hunt for plug-ins
>
> Again, I'm surprised this is a plus.  Bazaar has a rich plugin  
> interface
> that allows for end users to add functionality easily.

It isn't the lack of a plug-in interface that is a plus. It is the  
fact that the I download the core package and get everything I need.

> One that makes it so that your laptop won't suspend while doing  
> Bazaar operations

In git, someone accomplished this same task a while back using the  
hooks[1] mechanism. Someone took it a step further and taught git to  
postpone CPU/disk intensive operations while on battery. :-P

[1] A hook is simply a program that git executes at certain stages of  
its operation (e.g., a verifier before committing to make sure that  
your code matches the formatting requirements). These are usually  
written as shell scripts.

> and the other that pops up a notification when long operations  
> complete.

Again, that sounds like a hook would work (although hooks are per- 
operation so you'd have to add the hook to the few potentially-long  
operations).

>>   * git instaweb! Single command web setup for browsing
>
> Cool.  I haven't heard that anyone cried installing Loggerhead ;)

Anything that makes my life easier is okay in my book.

>>   * git bisect: binomial search of history for find a bug fix/break
>>
>
> Yeah, and one-upped it.  There is now a bazaar search plugin that is
> really, really cool.  Plus Loggerhead support.

git has had such search capabilities for as long as I've been using  
it. I don't believe that gitweb supports change searching, though.

I'll have to check out this Loggerhead. Do you have a list of  
recommended plug-ins and external tools I should install along with  
bazaar?

>>   * git diff --color-words
>>
>>     - Amazingly wonderful when you have to work with reflowed text
>
> I guess I always do "bzr diff --using=meld" so that wouldn't effect me
> much :)  I really like the way that meld displays my diffs.

That's an external GUI tool, right? I'd try it out, but my development  
machine at the moment is missing almost all of the requirements to get  
that one going.

I am curious if it works how you say, though, because I've never  
encountered anything like color-words before. All I can find is a post  
from 2006 stating that it most definitely does _not_ work for diffing  
LaTeX files.

>>   * Individual hunk commits
>>
>
> Again, I would say that this is a negative on git.  For other folks,  
> the
> way that git works is that you create your own changeset.  So if you  
> do
> "git commit" it does nothing until you go along and build up your
> changeset so that it knows what to do.

Sort of true, yes. People should add the individual files pertinent to  
the commit, but "git commit -a" exists to check in all changes. Most  
people work this latter way because having a clean history and  
performing code reviews is seen as unnecessary (and I'm certainly not  
going to argue here what is best for a particular project).

What I refer to as "Individual hunk commits" is an interactive mode  
where, within the file, I can say "yes, I want to check this change  
in" or "no, that change shouldn't be seen by others". Note that it  
does this without touching the original file.

>>   * In-directory branching
>>
>
> Bazaar supports looms.  Which basically means you can do stackable
> branches, commit to them and build them at will.

Looms are patch stacks (more like Stacked Git) rather than different  
branches. It's really more of a development preference, but  
lightweight branching is one of those features that I didn't know I  
was missing until I used it.

>>   * Fantastic integration with other VCS (especially svn and p4)
>
> Bazaar also.  And someone is working on even getting Git repository
> integration -- so then you never actually have to use Git's  
> interface ;)

People are crazy. There is git-bzr, git-svn, and even a git-cvsserver.  
There was a project to implement git-svnserver and another to  
implement git as the backend storage mechanism for svn, but I'm not  
sure if they ever got anywhere.

For whatever reason, git users have been fanatic about using git  
subversively.

>>   * The documentation is all over the place
>>
>
> I guess I would describe this as: Git is by hacker for hackers.  End
> users are something they're planning for in version 2 ;)

That's not really fair, but git seems that the git people would rather  
describe how git works than publish documentation encouraging a  
particular way to work.

One might comment that git comes with all of the functionality but you  
have to seek the larger community for documentation, while bazaar  
comes with the documentation but you have to seek the larger community  
for functionality.

>>   * Submodule support is, in my opinion, horrendous
>>
>
> Honestly, I've never used a VCS where I've seen this work the way one
> would expect.  I don't understand why.

I expect to see patches (I kid, I kid).

A large part of the problem with git is that the maintainers actively  
prevent breaking backwards compatibility, so a feature that stinks is  
likely to remain a stinker (unless there is a clear migration path).  
This is especially problematic with submodules because none of the  
core developers use the feature.

> I think I also want to add a negative for some users.
>
>      * Git sucks on Windows.

Not for the past 9 months or so. Most of the limitations of the FAT  
filesystem (case insensitivity, limited charset, symbolic links, etc.)  
have workarounds that are nicer than I would have expected. What git  
lacks is a "compatibility" mode for Linux users interacting with  
Windows users. I'm not sure how well Bazaar handles this.

>      * As far as I know there is no one providing professional  
> services
>        based on Git.

Well, there is github and Codebase but I couldn't even begin to  
compare the commercial offerings.


>      * No project hosting using Git.

That's just silly. There's gitorious, github, git.or.cz, and a slew of  
others.

http://git.or.cz/gitwiki/GitHosting

> You can also get some comments from people that know better than I: http://bazaar-vcs.org/BzrVsGit

Warning! That link is extremely convincing in favor Bazaar.

It is also misleading, sometimes outdated, and decidedly one-sided. It  
does, however, highlight some of the fundamental differences in the  
two approaches.

>> That ended up being longer than expected, but it should give those
>> Bazaar supporters something to chew on. :-)
>
> Heh, and at the end of the day if people are choosing between Bazaar  
> and
> Git I'm happy.  As long as they don't choose Clearcase or Bitkeeper ;)

I agree, and I think every organization should switch to a distributed  
system. I thought it was a clear race between Mercurial and Git, but  
the Bazaar developer support is still there (even if it is shunned in  
the open source community) and the tools seem well done.

In the end, I think it comes down to mental inertia. Bazaar is quite  
clearly the most like a traditional, centralized tool while adding the  
features and benefits of a distributed system. Git is a distributed  
system that also introduces new, powerful features that may be  
especially confusing to those with SCM experience.



And for those we haven't lost yet, some weaknesses of the distributed  
approach:

   * It is easy for changes to be committed but not shared

     - Bazaar has "bound" branches but I've never used them

   * All of these systems track content, not files

     - This means no partial/sparse checkout. git has experimental
       support, but few are interested in developing it.

     - It also means that merging individual files can be problematic
       (merge one file from a commit and later merge the commit when
       there have been more changes made to the file). Perforce would
       never have a problem with that.

Others?

-- 
                                                         Voltage Spike
       ,,,
      (. .)
--ooO-(_)-Ooo--