Re: VCS comparison table

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Erik Bågfors wrote:
> I think this disussion is getting out of hand.
> 
> There are a few things that are being discussed
> 1. Revnos are bad/good
> 2. treating "leftmost" parrent special is bad/good
> 3. plugins are useless/useful
> 4. And now, storing branch information should be done manually (if
> wanted) and not automatically.
> 
> 1. I don't really care, I haven't seen any confusion based on it, but
> I don't have a very strong opinion about it either.

To use revnos[*1*] you have to have branch as path through DAG. Bzr does
that by treating first parent special, which leads to empty merges
in fast-forward case.

Using revnos as implemented in bzr leads to some (perhaps unforeseen)
consequences.

[*1*] Meaning that revnos won't change on you.

> 2. This is something I do care about.  For me, this is the only
> logical way of doing it. It might be because I am used to it now, but
> when I started to look at bzr/hg/git/darcs/etc, I just got a so much
> more clear view of the history when running a standard log command,
> that it was one of the first things that attracted me to bzr. This is
> just a user talking.

Git has reflog for when you are interested in branch tip history
(which also stores "reason" for branch tip change: pull, amending
a commit, rebase,...). Git doesn't unfortunately have git-ref-log
command (or --ref option to git-log) to display reflog in user friendly 
format.

Git users are used to use graphical history viewers (mainly gitk and 
qgit, but there is also gitview, tig and git-browser) more to have 
clear view of history, view that log cannot provide.

That said I _thing_ that caring about "branch identity" is just 
something you are used to, perhaps because bzr doesn't have wonderfull 
git log limiting specifiers aka. builtin git log searching (a..b, 
a...b, --max-count, -- <path>, --committer, --grep etc.).

> There might be technical reasons why it's better to not do it, but for
> me it works the way I expect, therefore I'm happy

I think it would be better to maintain "branch identity" separately and 
not in DAG, but that might have other problems I have not seen.

> 3. This is just silly

I think the discussion/arguments were twofold. 

First, Bazaar-NG has plugin infrastructure "for free" because it is 
written in Python, which allows modules loading and monkey-patching. 
Git core is written in C, and git is not yet fully libified.

Second, all that can be done with plugins except for core changes can be 
done in Git writing scripts (this also allows for fast prototyping). 
All except core changes can be done writing few lines in C, but you 
have to compile against some version of Git, and don't have advantages 
of bultin command; git is OSS project.

> 4. No comment.

Storing branch information could be done automatically on demand ;-)
-- 
Jakub Narebski
Poland
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]