* renames in StGIT
From: Karl Hasselström @ 2006-10-22 1:39 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
It doesn't seem like StGIT uses any of git's rename tracking stuff.
Specifically, pushing patches doesn't seem to use rename-aware
merging, and there is no way to tell diff to detect renames and
copies.
Should this perhaps be an item in the TODO list?
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: VCS comparison table
From: Sean @ 2006-10-22 1:26 UTC (permalink / raw)
To: Jeff Licquia; +Cc: bazaar-ng, git
In-Reply-To: <1161478005.9241.210.camel@localhost.localdomain>
On Sat, 21 Oct 2006 20:46:45 -0400
Jeff Licquia <jeff@licquia.org> wrote:
> Which opinion is this? The opinion that old-style local revnos aren't a
> big deal, or that new-style dotted revnos aren't a big deal?
>
> I suspect you're conflating the two, and interpreting certainty for the
> former as certainty for the latter. Though I don't mind being
> corrected.
The archives have all the posts of people claiming that there were no
issues with revno's and fully distributed models. But it's okay, the
issue really isn't all that important in the big scheme of things. Bzr
and Git have much more in common than they have differences. I reject
that revno's are an example of where bzr is superior than Git, but
there are no doubt examples where I would concede that bzr has the edge.
Cheers,
Sean
^ permalink raw reply
* Re: VCS comparison table
From: Sean @ 2006-10-22 1:26 UTC (permalink / raw)
To: Jeff Licquia; +Cc: bazaar-ng, git
In-Reply-To: <1161478005.9241.210.camel@localhost.localdomain>
On Sat, 21 Oct 2006 20:46:45 -0400
Jeff Licquia <jeff@licquia.org> wrote:
> Which opinion is this? The opinion that old-style local revnos aren't a
> big deal, or that new-style dotted revnos aren't a big deal?
>
> I suspect you're conflating the two, and interpreting certainty for the
> former as certainty for the latter. Though I don't mind being
> corrected.
The archives have all the posts of people claiming that there were no
issues with revno's and fully distributed models. But it's okay, the
issue really isn't all that important in the big scheme of things. Bzr
and Git have much more in common than they have differences. I reject
that revno's are an example of where bzr is superior than Git, but
there are no doubt examples where I would concede that bzr has the edge.
Cheers,
Sean
^ permalink raw reply
* Re: VCS comparison table
From: Theodore Tso @ 2006-10-22 1:00 UTC (permalink / raw)
To: Jakub Narebski
Cc: Erik Bågfors, Linus Torvalds, Sean, Jan Hudec, bazaar-ng,
git, Matthieu Moy
In-Reply-To: <200610220222.29009.jnareb@gmail.com>
On Sun, Oct 22, 2006 at 02:22:28AM +0200, Jakub Narebski wrote:
> If I understand correctly bzr came to life much earlier than Monotone,
> Mercurial and Git but it was in beta stages very long. Bazaar-NG
> "repositories" to group bunch of "branches" seems inspoted by hg or git.
> Git (and probably Mercurial) was inspired both by BitKeeper and Monotone.
> Monotone started to be reasonable fast around time when Git and Mercurial
> came to be.
Yes, bzr predates Mercurial and Git; I remember talking to Martin Pool
about Bazaar-BG at the the 2005 Linux.conf.au, which was before the BK
turnoff. At the time, I had considered using bzr-ng (which has since
been renamed bzr), but it didn't have branch functionality at that
point if I remember correctly. Both git and Mercurial started
development at almost the same time right after the Larry McVoy
announced the pending withdrawal of the BitKeeper no-cost license.
About one month after the announced BK turnoff date, I looked at the
various options for transitioning e2fsprogs, and at that point
Mercurial was **substantially** faster than bzr, and I believe
slightly ahead in features. I also looked at git, but at that point
Hg was easier to learn how to use, and I figured for a project the
size of e2fsprogs, I didn't need the power of git, so I decided in
favor of Mercurial because it looked like it would be easier for
people to learn how to use it.
I think it's fair to say that the exchange in ideas have profited all
three projects, and that the different projects have different
strengths,
- Ted
^ permalink raw reply
* Re: VCS comparison table
From: Linus Torvalds @ 2006-10-22 0:47 UTC (permalink / raw)
To: Jeff Licquia; +Cc: Carl Worth, bazaar-ng, git
In-Reply-To: <1161475645.9241.195.camel@localhost.localdomain>
On Sat, 21 Oct 2006, Jeff Licquia wrote:
>
> You know what? It occurs to me that much of the problem with git
> branches vs. bzr branches might be solved when bzr gets proper tagging
> support. Because, after all, aren't branches more like special tags in
> git?
Both branches _and_ tags in git are 100% the same thing: they're just
shorthand for the commit name. That's _literally_ all they are. They are a
symbolic name for a 160-bit SHA1 hash.
So yes, you can say that branches are like special tags, or that
(unsigned) tags are like special branches. There's no real "technical"
difference: in both cases, it's just an arbitrary name for the top commit.
However, there are some purely UI differences between tags and branches,
which really don't affect any of the "name->SHA1" translation at all, but
which affect how you can _use_ a tag-name vs a branch-name.
- A branch is always a pointer to a _commit_ object.
In contrast, a tag can point to anything. It can point to a tree (and
that means that you can do _diff_ between a tag and a branch, but such
a tree doesn't have any "history" associated with it - it's purely
about a certain "state", so you cannot say that it has a parent or
anything like that).
A tag can also point to a single file object ("blob": pure file
content), which is soemthing that the git.git repository uses to point
to the GPG public key that Junio uses to sign things, for example.
But perhaps more commonly, a tag can also point to a special "tag"
object, which is just a form of indirection that can optionally contain
an explanation and a digitally signed verification. When I cut a kernel
release, for example, my tag's don't point to the commit that is the
release commit, they point to a GPG-signed tag-object that in turn
points to the commit.
With those signed tags, people can verify (if they get my public key)
that a particular release was something I did. And due to the
cryptographic nature of the hash, trusting the tag object also means
that you can trust the commit it points to, and the whole history that
points to.
So while from a _revision_lookup_ standpoint a "branch" and a "tag" do
100% the same thing, we put some limitations on branches: they always
have to point to a commit.
- Thanks to the limitation on branches being commits, branches can be
"checked out" which is saying that you can make it the active working
tree state. You cannot "check out" a tag: you need to have a branch
that you check out and can do development on. So a "tag" is considered
purely a stationary pointer: it cannot be committed to, and it cannot
participate directly in development.
This literally has nothing to do with looking up the SHA1 name
associated with a tag or a branch, this is _purely_ an agreed-upon
convention (that is enforced by higher-level commands like "git
checkout"). So if you want to check out the state as of some tag, you
must always do it within the confines of some branch.
So for example, you could do
git checkout -b newbranch v2.6.18
which uses a tag ("v2.6.18") to define where to start the branch, and
then creates a branch called "newbranch" and checks that out. That's
purely shorthand for
git branch newbranch v2.6.18 # create 'newbranch', initialize
# it at v2.6.18
git checkout newbranch # make 'newbranch' our currently
#active branch
but you are _not_ allowed to do
git checkout v2.6.18
because that would leave you with a situation where your "top-of-tree"
is a tag, and you couldn't do any development on it because you don't
have a branch to develop _on_.
But all of these kinds of differences between tags and branches are really
not "core technology" and are purely about having adopted a convention. It
is literally about just having certain "usage rules" for specific
"symbolic namespaces".
"branch" and "tag" are just the normal namespaces git gives you and always
has. You can have others too (and you can define your own) and those names
will automatically be used for lookup by all the basic git tools. Git
won't _touch_ those names in any other way, but it means that you can
create your own tools around git that have their own rules about how the
names are managed, and you can still use them for lookup.
For example, you could have a "svn" namespace for a project imported from
svn, and that namespace would contain the SVN revision names for the
project, so that you could do
git diff svn/56..
to see the difference between "svn revision 56" and your current HEAD,
without necessarily polluting the "real" git tag namespace.
(Which can matter, since some commands take arguments like "--tags", which
just collects all the regular tags - so you might not want to use normal
tags to remember your SVN revision mapping, even if it might technically
be fine).
(The above was a totally made-up example. I don't think any of the svn
importers actually do anything like that: but we do use a few other
"namespaces" internally: "git bisect" puts the bisection results in the
"bisect" namespace, and the "remotes" namespace can be used to track
remote heads as something _different_ than a local branch - so that you
won't check such a "remote branch" out directly by mistake)
Linus
^ permalink raw reply
* Re: VCS comparison table
From: Jeff Licquia @ 2006-10-22 0:46 UTC (permalink / raw)
To: Sean; +Cc: bazaar-ng, git
In-Reply-To: <20061021192539.4a00cc3e.seanlkml@sympatico.ca>
On Sat, 2006-10-21 at 19:25 -0400, Sean wrote:
> Now the opinion of the bzr people is that it doesn't matter and that for
> all important cases it works well enough. If all the people who don't like
> the look of sha1's self select bzr, so be it, but that doesn't change the
> fundamental argument.
Which opinion is this? The opinion that old-style local revnos aren't a
big deal, or that new-style dotted revnos aren't a big deal?
I suspect you're conflating the two, and interpreting certainty for the
former as certainty for the latter. Though I don't mind being
corrected.
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-22 0:22 UTC (permalink / raw)
To: Erik Bågfors
Cc: Linus Torvalds, Sean, Jan Hudec, bazaar-ng, git, Matthieu Moy
In-Reply-To: <845b6e870610211713m413afd28tcdf24934df25d3f5@mail.gmail.com>
Erik Bågfors wrote:
>> So I sound like I care, but at the same time, I realize very well that
>> when coming from a totally centralized world, the details we're arguing
>> are _so_ not important.
>
> I have to agree. Personally I think both git, bzr and mercurial are
> all VERY nice systems. If they weren't all started about the same
> time, I doubt we would have all three.
If I understand correctly bzr came to life much earlier than Monotone,
Mercurial and Git but it was in beta stages very long. Bazaar-NG
"repositories" to group bunch of "branches" seems inspoted by hg or git.
Git (and probably Mercurial) was inspired both by BitKeeper and Monotone.
Monotone started to be reasonable fast around time when Git and Mercurial
came to be.
P.S. I'd like very much to see "history of SCM", with links denoting
borrowing of ideas, similar to the "history of UNIX" graphs...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-22 0:14 UTC (permalink / raw)
To: Aaron Bentley
Cc: Andreas Ericsson, Linus Torvalds, Carl Worth, bazaar-ng, git
In-Reply-To: <453AAFBD.7020009@utoronto.ca>
Aaron Bentley wrote:
> Jakub Narebski wrote:
>> Aaron Bentley wrote:
>>> A Bazaar branch is a directory inside a repository that contains:
>>> - a name referencing a particular revision
>>> - (optional) the location of the default branch to pull/merge from
>>> - (optional) the location of the default branch to push to
>>> - (optional) the policy for GPG signing
>>> - (optional) an alternate committer-id to use for this branch
>>> - (optional) a nickname for the branch
>>> - other configuration options
>> Erm, wasn't revno to revid mapping also part of bzr "branch"?
>
> It's not part of the conceptual model. The revno-to-revid mapping is
> done using the DAG. The branch just tracks the head.
>
> The .bzr/branch/revision-history file is from an earlier model in which
> branches had a local ordering. Nowadays, it can be treated as:
> - a reference to the head revision
> - a cache of the revno-to-revid mapping
In git DAG is DAG od parents. There are no "child" links. So it is natural
to refer to n-th ancestor of given commit (in git <ref>~<n>, in bzr -<m>).
To have incrementing (from 1 for first revision on given branch) revision
numbers you either have to have links to "children", which automatically
means that revisions cannot be immutable to allow for branching at
arbitrary revision, or to transverse DAG here and back again (perhaps
with cache of revno-to-revid mapping to help performance).
Additionally to have incrementing revision numbers you have to remember
which part of DAG is our branch; which parent in merge to chose to follow.
Bazaar-NG decides here to distinguish first parent; to have first parent
immutable it doesn't use fast-forward and always use merge, sometimes
giving empty-merge. If you use "pull" numbers change.
>>> This layout is an imitation of Git, as I understand it:
>>> Repository:
>>> ~/repo
>>>
>>> Branches:
>>> ~/repo/origin
>>> ~/repo/master
>>>
>>> Workingtree:
>>> ~/repo
>>
>> Workingtree:
>> ~/
>>
>> if I understand notation correctly.
>
> The notation was that ~/repo would contain the .git directory for the
> repository.
The default layout of "clothed" repository is
Repository:
~/repo/.git/
Branches:
~/repo/.git/refs/heads/
Workingtree:
~/repo/
>>> While "bzr merge ../b" is a minor inconvenience, I think that "bzr merge
>>> http://bazaar-vcs.org/bzr/bzr.dev" is a big win.
>>
>> Gaah, it's even more inconvenient. Certainly more than using name
>> of branch itself, like in git.
>
> Of course if you have a copy of bzr.dev on your computer, you don't need
> to type the full URL. it's just like the 'merge ../b' above.
>
> But how can you use the branch name of a branch that isn't on your
> computer? I suspect git requires a separate 'clone' step to get it onto
> your computer first.
No, as it was said in other messages in this thread, you can fetch
a branch (branches), even from other repository that the one you cloned
from, into given branch (branches). For git it would be
$ git fetch <URL> <remotebranch>:<localbranch>
You probably would want to save above info in remotes file or in config.
For cg (Cogito) it would be
$ cg branch-add <localbranch> <URL>#<remotebranch>
$ cg fetch <localbranch>
In git you always use names like 'master', 'next', 'HEAD' (meaning current
branch) and also HEAD^, next~5 when comparing branches, viewing history,
merging branches, switching to branch etc. Not '../master'...
^ permalink raw reply
* Re: VCS comparison table
From: Erik Bågfors @ 2006-10-22 0:13 UTC (permalink / raw)
To: Linus Torvalds
Cc: Sean, Jan Hudec, bazaar-ng, git, Matthieu Moy, Jakub Narebski
In-Reply-To: <Pine.LNX.4.64.0610211655130.3962@g5.osdl.org>
On 10/22/06, Linus Torvalds <torvalds@osdl.org> wrote:
>
>
> On Sat, 21 Oct 2006, Linus Torvalds wrote:
> >
> > And that work-flow is definitely not "distributed" it's much closer to
> > "disconnected centralized".
>
> Side note: the only reason I think that distinction is worth making at all
> is when comparing git to bzr, and even then this is a fairly subtle
> distinction, and probably not a huge deal in practice.
>
> I obviously think git is a nicer distributed design, but in the end, if
> you compare to something like CVS or SVN that isn't even disconnected, the
> difference between git and bzr in this sense is basically zero.
>
> So I sound like I care, but at the same time, I realize very well that
> when coming from a totally centralized world, the details we're arguing
> are _so_ not important.
I have to agree. Personally I think both git, bzr and mercurial are
all VERY nice systems. If they weren't all started about the same
time, I doubt we would have all three.
I am happy to use either, but I have a small preference with bzr
because it suites me. I'm saying this, just as a user, nothing else.
/Erik
--
google talk/jabber. zindar@gmail.com
SIP-phones: sip:erik_bagfors@gizmoproject.com
sip:17476714687@proxy01.sipphone.com
^ permalink raw reply
* Re: VCS comparison table
From: Erik Bågfors @ 2006-10-22 0:09 UTC (permalink / raw)
To: Linus Torvalds
Cc: Sean, Jan Hudec, bazaar-ng, git, Matthieu Moy, Jakub Narebski
In-Reply-To: <Pine.LNX.4.64.0610211353070.3962@g5.osdl.org>
On 10/21/06, Linus Torvalds <torvalds@osdl.org> wrote:
>
>
> On Sat, 21 Oct 2006, Erik Bågfors wrote:
> >
> > bzr is a fully decentralized VCS. I've read this thread for quite some
> > time now and I really cannot understand why people come to this
> > conclusion.
>
> Even the bzr people agree, so what's not to understand?
The use of the word "decentralized".
When I think centralized, I think "all users must commit to a central
repo/branch". In this sense bzr is 100% fully decentralized. You are
free to commit to a none-central branch.
What I mean is that it's fully decentralized, but it may have a bias
to the usage of a central branch/repo.
/Erik
--
google talk/jabber. zindar@gmail.com
SIP-phones: sip:erik_bagfors@gizmoproject.com
sip:17476714687@proxy01.sipphone.com
^ permalink raw reply
* Re: VCS comparison table
From: Jeff Licquia @ 2006-10-22 0:07 UTC (permalink / raw)
To: Carl Worth; +Cc: bazaar-ng, git
In-Reply-To: <8764ed1b7z.wl%cworth@cworth.org>
On Sat, 2006-10-21 at 16:49 -0700, Carl Worth wrote:
> On Sat, 21 Oct 2006 19:42:47 -0400, Jeff Licquia wrote:
> > I don't think so. Recently, I've been trying to track a particular
> > patch in the kernel. It was done as a series of commits, and probably
> > would have been its own branch in bzr, but when I was trying to group
> > the commits together to analyze them as a group, the easiest way to do
> > that was by the original committer's name.
>
> As far as "its own branch in bzr" would such a branch remain available
> indefinitely even after being merged in to the main tree?
Yes, in the sense that you can recreate the branch by using that
branch's last commit. But not in the git sense that there's a branch ID
pointing at the commit in question.
You know what? It occurs to me that much of the problem with git
branches vs. bzr branches might be solved when bzr gets proper tagging
support. Because, after all, aren't branches more like special tags in
git?
> > Now, there's probably a better way to hunt that stuff down, but in this
> > case hunting the user down worked for me. (It may have made a
> > difference that I was using gitweb instead of a local clone.)
>
> Vast, huge, gaping, cosmic difference.
>
> Almost none of the power of git is exposed by gitweb. It's really not
> worth comparing. (Now a gitweb-alike that provided all the kinds of
> very easy browsing and filtering of the history like gitk and git
> might be nice to have.)
So, very probably, I would have had a far easier time of it if I had
been able to really use git to do the work, instead of gitweb.
I still don't think, though, that it's a sign of a small project to be
concerned about one's own branches more than others.
^ permalink raw reply
* Re: VCS comparison table
From: Carl Worth @ 2006-10-22 0:04 UTC (permalink / raw)
To: Aaron Bentley
Cc: Jakub Narebski, Linus Torvalds, Andreas Ericsson, bazaar-ng, git
In-Reply-To: <453AAFBD.7020009@utoronto.ca>
[-- Attachment #1: Type: text/plain, Size: 2390 bytes --]
On Sat, 21 Oct 2006 19:39:41 -0400, Aaron Bentley wrote:
> Of course if you have a copy of bzr.dev on your computer, you don't need
> to type the full URL. it's just like the 'merge ../b' above.
>
> But how can you use the branch name of a branch that isn't on your
> computer? I suspect git requires a separate 'clone' step to get it onto
> your computer first.
No. You can merge a branch from a remote repository in a single step:
git pull http://example.com/git/repo branch-of-interest
But if you want to do something besides (or before) a merge, (for
example, just explore its history, do some diffs etc.) then you would
fetch it instead, assigning it a local branch name in the process:
git fetch http://example.com/git/repo branch-of-interest:local-name
After which "local-name" is all one would need to use. So after a
fetch like the above, the equivalent of "bzr missing --theirs-only"
would be:
git log ..local-name
[This shows some of the expressive power of git revision
specifications. There's no need for a separate "missing" command. It's
just one case of viewing a particular subset of the DAG. And the
specification language makes almost all interesting subsets easy. The
--mine-only specification would be "local-name.."]
And beyond what bzr missing does (I believe) it's easy to also see the
patch content of each commit with:
git log -p ..local-name
And then if everything is happy, one could merge that branch in:
git pull . local-name
(And, yes, it is the case that "pull" with a repository URL of "." is
how merging is done. It's bizarre to me that this is not "git merge
local-name" instead. There actually _is_ a "git merge" command that
could be used here, but it is somewhat awkward to use, (requiring both
a commit message (without the -m of git-commit(!)) and an explicit
mention of the current branch). So using it would be something like:
git merge "merge of local-name" HEAD local-name
I've never claimed that git is completely free of its UI
warts---though there are fewer now than when I started using it.)
But, yes, the notion in git is to bring things in to the current
repository and then work with them locally. This has an advantage that
network traffic is spent only once if doing multiple operations, (say
the three steps shown above: 1) investigate commit messages, 2)
investigate patch content, 3) perform the merge).
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: VCS comparison table
From: Linus Torvalds @ 2006-10-21 23:58 UTC (permalink / raw)
To: Erik Bågfors
Cc: Matthieu Moy, bazaar-ng, Sean, Jan Hudec, git, Jakub Narebski
In-Reply-To: <Pine.LNX.4.64.0610211353070.3962@g5.osdl.org>
On Sat, 21 Oct 2006, Linus Torvalds wrote:
>
> And that work-flow is definitely not "distributed" it's much closer to
> "disconnected centralized".
Side note: the only reason I think that distinction is worth making at all
is when comparing git to bzr, and even then this is a fairly subtle
distinction, and probably not a huge deal in practice.
I obviously think git is a nicer distributed design, but in the end, if
you compare to something like CVS or SVN that isn't even disconnected, the
difference between git and bzr in this sense is basically zero.
So I sound like I care, but at the same time, I realize very well that
when coming from a totally centralized world, the details we're arguing
are _so_ not important.
Linus
^ permalink raw reply
* Re: VCS comparison table
From: Carl Worth @ 2006-10-21 23:49 UTC (permalink / raw)
To: Jeff Licquia; +Cc: Jakub Narebski, bazaar-ng, git
In-Reply-To: <1161474168.9241.188.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 999 bytes --]
On Sat, 21 Oct 2006 19:42:47 -0400, Jeff Licquia wrote:
> I don't think so. Recently, I've been trying to track a particular
> patch in the kernel. It was done as a series of commits, and probably
> would have been its own branch in bzr, but when I was trying to group
> the commits together to analyze them as a group, the easiest way to do
> that was by the original committer's name.
As far as "its own branch in bzr" would such a branch remain available
indefinitely even after being merged in to the main tree?
> Now, there's probably a better way to hunt that stuff down, but in this
> case hunting the user down worked for me. (It may have made a
> difference that I was using gitweb instead of a local clone.)
Vast, huge, gaping, cosmic difference.
Almost none of the power of git is exposed by gitweb. It's really not
worth comparing. (Now a gitweb-alike that provided all the kinds of
very easy browsing and filtering of the history like gitk and git
might be nice to have.)
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: VCS comparison table
From: Jeff Licquia @ 2006-10-21 23:42 UTC (permalink / raw)
To: Jakub Narebski; +Cc: bazaar-ng, git
In-Reply-To: <200610220025.32108.jnareb@gmail.com>
On Sun, 2006-10-22 at 00:25 +0200, Jakub Narebski wrote:
> I wonder if searching for one's own commits isn't the sign that
> the project is of one-main-developer size (i.e. small project,
> without large number of distributed contributors). I think in large
> project you rather ask of history of specified file, of specified part
> of project (specified directory), ask about why certain change was
> introduced etc.
I don't think so. Recently, I've been trying to track a particular
patch in the kernel. It was done as a series of commits, and probably
would have been its own branch in bzr, but when I was trying to group
the commits together to analyze them as a group, the easiest way to do
that was by the original committer's name.
Now, there's probably a better way to hunt that stuff down, but in this
case hunting the user down worked for me. (It may have made a
difference that I was using gitweb instead of a local clone.)
And the case of hunting down your own commits is just a degenerate case
of hunting down someone else's.
^ permalink raw reply
* Re: VCS comparison table
From: Aaron Bentley @ 2006-10-21 23:39 UTC (permalink / raw)
To: Jakub Narebski
Cc: Carl Worth, Linus Torvalds, Andreas Ericsson, bazaar-ng, git
In-Reply-To: <200610212248.37935.jnareb@gmail.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jakub Narebski wrote:
> Aaron Bentley wrote:
>> Carl Worth wrote:
>
> No, there is no such thing like local ordering of revisions.
> You can have (in git repository) also reflog, which records values
> of branch-as-reference, or branch tip of branch-as-named-lineage.
> But for example fetch and fast-forward 5 commits in history is
> recorded as single event, single change in reflog.
That must be what I was thinking of.
>> A Bazaar branch is a directory inside a repository that contains:
>> - a name referencing a particular revision
>> - (optional) the location of the default branch to pull/merge from
>> - (optional) the location of the default branch to push to
>> - (optional) the policy for GPG signing
>> - (optional) an alternate committer-id to use for this branch
>> - (optional) a nickname for the branch
>> - other configuration options
> Erm, wasn't revno to revid mapping also part of bzr "branch"?
It's not part of the conceptual model. The revno-to-revid mapping is
done using the DAG. The branch just tracks the head.
The .bzr/branch/revision-history file is from an earlier model in which
branches had a local ordering. Nowadays, it can be treated as:
- a reference to the head revision
- a cache of the revno-to-revid mapping
>> This layout is an imitation of Git, as I understand it:
>> Repository:
>> ~/repo
>>
>> Branches:
>> ~/repo/origin
>> ~/repo/master
>>
>> Workingtree:
>> ~/repo
>
> Workingtree:
> ~/
>
> if I understand notation correctly.
The notation was that ~/repo would contain the .git directory for the
repository.
>> While "bzr merge ../b" is a minor inconvenience, I think that "bzr merge
>> http://bazaar-vcs.org/bzr/bzr.dev" is a big win.
>
> Gaah, it's even more inconvenient. Certainly more than using name
> of branch itself, like in git.
Of course if you have a copy of bzr.dev on your computer, you don't need
to type the full URL. it's just like the 'merge ../b' above.
But how can you use the branch name of a branch that isn't on your
computer? I suspect git requires a separate 'clone' step to get it onto
your computer first.
> Is there a command to list all branches in bzr?
There's one in the 'bzrtools' plugin.
> Is there a command
> to copy (clone in SCM jargon) whole repository with all branches?
No.
>> My understanding is that ^ is treated as a special metacharacter by some
>> shells, which is why bzr revision specs are more long-winded.
>
> Which shells? If I understand it '^' was chosen (for example as
> NOT operator for specify sub-DAG instead of '!') because of no problems
> for shell expansion. And considering that many git commands are/were
> written in shell, one certainly would notice that.
Sorry, it's been quite a long time since people complained at me for
using ^, so I don't remember. Perhaps Edgar is right about it being the
pipe character in old shells.
Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD4DBQFFOq+80F+nu1YWqI0RAp/KAJ9Bw1q9/nd3gUAjcX3c+24aoEifeQCYlbD0
tUZ01ra11vkQ7V3RzarXeg==
=oFIC
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: VCS comparison table
From: Sean @ 2006-10-21 23:25 UTC (permalink / raw)
To: Jeff Licquia; +Cc: Carl Worth, bazaar-ng, git
In-Reply-To: <1161472030.9241.174.camel@localhost.localdomain>
On Sat, 21 Oct 2006 19:07:10 -0400
Jeff Licquia <jeff@licquia.org> wrote:
> Several of us have pointed to the (branch, revno) combination as a
> sufficiently reliable communication method, and we may be right about
> that. But, so far, those revnos have been entirely local to a single
> branch, and have also been as absolutely reliable (locally speaking) as
> a revid; the branch "foo" may go away, but while it's around, "revision
> 14 of branch foo" will always mean the same thing. But we're now adding
> the 0.12 revno scheme, with "global" revnos. Will those be as reliable?
> Will "revision 2418.1.4 on bzr.dev" work as well as "revision 2418 on
> bzr.dev" does now?
There is no need to speculate, the numbers will only be reliable on a local
basis. So yes you can force a single repository like bzr.dev to always "win"
any conflict and force the other guy to change ie. a central repo model.
But they can not be maintained consistently in a truly distributed
system. As Linus pointed out that is fact, not opinion.
Now the opinion of the bzr people is that it doesn't matter and that for
all important cases it works well enough. If all the people who don't like
the look of sha1's self select bzr, so be it, but that doesn't change the
fundamental argument.
But just to reiterate, the design of Git is flexible enough to where you
can automatically generate "revno" tags for every commit in your repo
_today_. You'd end up with the exact same problems that bzr will
eventually hit, but Git already has everything you need today to refer
to every commit in your repo as r1 r2 r3 r4 etc...
Sean
^ permalink raw reply
* Re: VCS comparison table
From: Sean @ 2006-10-21 23:25 UTC (permalink / raw)
To: Jeff Licquia; +Cc: Carl Worth, bazaar-ng, git
In-Reply-To: <1161472030.9241.174.camel@localhost.localdomain>
On Sat, 21 Oct 2006 19:07:10 -0400
Jeff Licquia <jeff@licquia.org> wrote:
> Several of us have pointed to the (branch, revno) combination as a
> sufficiently reliable communication method, and we may be right about
> that. But, so far, those revnos have been entirely local to a single
> branch, and have also been as absolutely reliable (locally speaking) as
> a revid; the branch "foo" may go away, but while it's around, "revision
> 14 of branch foo" will always mean the same thing. But we're now adding
> the 0.12 revno scheme, with "global" revnos. Will those be as reliable?
> Will "revision 2418.1.4 on bzr.dev" work as well as "revision 2418 on
> bzr.dev" does now?
There is no need to speculate, the numbers will only be reliable on a local
basis. So yes you can force a single repository like bzr.dev to always "win"
any conflict and force the other guy to change ie. a central repo model.
But they can not be maintained consistently in a truly distributed
system. As Linus pointed out that is fact, not opinion.
Now the opinion of the bzr people is that it doesn't matter and that for
all important cases it works well enough. If all the people who don't like
the look of sha1's self select bzr, so be it, but that doesn't change the
fundamental argument.
But just to reiterate, the design of Git is flexible enough to where you
can automatically generate "revno" tags for every commit in your repo
_today_. You'd end up with the exact same problems that bzr will
eventually hit, but Git already has everything you need today to refer
to every commit in your repo as r1 r2 r3 r4 etc...
Sean
^ permalink raw reply
* Re: VCS comparison table
From: Jeff Licquia @ 2006-10-21 23:07 UTC (permalink / raw)
To: Carl Worth; +Cc: bazaar-ng, git
In-Reply-To: <87ac3p1jn7.wl%cworth@cworth.org>
On Sat, 2006-10-21 at 13:47 -0700, Carl Worth wrote:
> I still haven't seen strong examples for this last claim. When are
> they handier? I asked a couple of messages back and two people replied
> that given one revno it's trivial to compute the revno of its
> parent. But that's no win over git's revision specifications,
> (particularly since they provide "parent of" operators).
Having used both (though my familiarity with git is less), in my opinion
the biggest win is the obvious one: sequential numbers work in the head
better than SHA1 checksums.
"But it's not a problem in practice!" is a good retort, except that I
wonder whether the set of "practices" you're using includes anyone who
decided to pass on git in favor of something else--perhaps because they
saw a few SHAs float by and ran in terror. Beware of self-selection
bias.
Put another way, "strength" of example is often in the eye of the
beholder. That we continue to give you the same "weak" examples may be
evidence that we have a different impression of their strengths, and
that your analysis of their strengths isn't convincing to us.
I suppose this line of conversation still has value if you don't see any
benefit at all, but OTOH if you really don't see how sequential numbers
are easier to work with in the head than SHA sums with modifiers, I'm
not sure that's a gap we can bridge.
> Let me know if I botched any of that.
I don't see any problems with it.
> But dropping a merged branch in bzr means throwing away the ability to
> reference any of its commits by its custom, branch-specific revision
> numbers. And the revision numbers _do_ change, pull, branch, and merge
> all introduce revision number differences between branches, (or
> changes within a branch in the case of pull). And there is no simple
> way to correlate the numbers between branches.
>
> Maybe you can argue that there isn't any centralization bias in
> bzr. But anyone that claims that the revnos. are stable really is
> talking from a standpoint that favors centralization.
I wonder if part of the problem is that the revno scheme we've been
talking about (the x.y.z... format) doesn't technically exist in any
released version of bzr that I know of.
Previous to 0.12, bzr revnos were absolutely a local thing; revisions
from merges didn't even have revnos (except for the merge commit
itself). If you merged a branch and you later wanted to recreate that
branch, or see a diff from that branch, etc., you had to use revids.
So when you talk of a "centralization bias" in bzr, a lot of us get
confused, defensive, etc., because from our perspective, bzr and git
weren't all that much different until just recently.
Now it may be that you're right that "global" revnos like bzr has now
introduce a bias in favor of centralization. If that's true, I'm not
sure that totally vindicates the git model. We have to ask if the bias
is a good thing, but so do you; after all, we may have done so because
of user demand, and if our users want it, maybe yours will want it too
someday.
(I say "may" because I haven't been paying close attention to the new
revno conversation, so I don't want to sound more sure than I am.)
But I think bzr people are more willing to take a wait-and-see approach.
Local revnos weren't a big deal, so we're willing to bet that the new
0.12 revnos won't be, either.
> And it turns out that git also allows branch specific naming for the
> exact same reason. In place of 3, 2, 1 in the same situation git would
> allow the names HEAD, HEAD~1, and HEAD~2 to refer to the same three
> revisions. So the easy diff command would be "git diff HEAD~2 HEAD".
> (And where I have HEAD here I could also use any branch name, or any
> other reference to a commit as well.)
FYI: The strict analogy to HEAD~1 in bzr would be -2. And yes, -2 is
every bit as unstable as HEAD~1.
> Finally, since these branch-specific names are changing all the time,
> there's never any temptation for people to attempt to use them to for
> external communication. In contrast, by being numbered in the opposite
> direction, bzr revision numbers give a false appearance of stability
> and people _do_ use them for communication. This is the mistake we've
> been warning bzr users about in this thread.
URLs are also used for communication, despite having many of the same
drawbacks as revnos in DVC systems. This could have been a fatal flaw,
but in reality, this has resulted in some best practices ("permalinks",
for example), and a sense of where a URL is appropriate and where it
isn't. It's not perfect, and yet it's been wildly successful.
Copying the flaws of a highly successful system does not guarantee
success, of course. On the other hand, it does influence our evaluation
of the severity of the flaws.
There may be a danger, though, that the bzr community may want to pay
closer attention to.
Several of us have pointed to the (branch, revno) combination as a
sufficiently reliable communication method, and we may be right about
that. But, so far, those revnos have been entirely local to a single
branch, and have also been as absolutely reliable (locally speaking) as
a revid; the branch "foo" may go away, but while it's around, "revision
14 of branch foo" will always mean the same thing. But we're now adding
the 0.12 revno scheme, with "global" revnos. Will those be as reliable?
Will "revision 2418.1.4 on bzr.dev" work as well as "revision 2418 on
bzr.dev" does now?
^ permalink raw reply
* Re: VCS comparison table
From: Edgar Toernig @ 2006-10-21 22:52 UTC (permalink / raw)
To: Jakub Narebski
Cc: Aaron Bentley, Carl Worth, Linus Torvalds, Andreas Ericsson,
bazaar-ng, git
In-Reply-To: <200610212248.37935.jnareb@gmail.com>
Jakub Narebski wrote:
>
> > My understanding is that ^ is treated as a special metacharacter by some
> > shells, which is why bzr revision specs are more long-winded.
>
> Which shells?
In the traditional Bourne shell ^ is an alias for the pipe symbol |.
Ciao, ET.
^ permalink raw reply
* [PATCH 2/3] git-branch: Add -w option to adjust branchname column width
From: Lars Hjemli @ 2006-10-21 22:33 UTC (permalink / raw)
To: git
In-Reply-To: <1161470004894-git-send-email-hjemli@gmail.com>
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
---
git-branch.sh | 11 ++++++++---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/git-branch.sh b/git-branch.sh
index 25abd4c..0d9eb06 100755
--- a/git-branch.sh
+++ b/git-branch.sh
@@ -1,6 +1,6 @@
#!/bin/sh
-USAGE='[-r] [-v] | (-d | -D) <branchname> | [-l] [-f] <branchname> [<start-point>]'
+USAGE='[-r] [-v [-w <width>]] | (-d | -D) <branchname> | [-l] [-f] <branchname> [<start-point>]'
LONG_USAGE='If no arguments, show available branches and mark current branch with a star.
If one argument, create a new branch <branchname> based off of current HEAD.
If two arguments, create a new branch <branchname> based off of <start-point>.'
@@ -52,6 +52,7 @@ force=
create_log=
verbose=
remotes=
+width=20
ls_remote_branches () {
git-rev-parse --symbolic --all |
@@ -62,7 +63,7 @@ ls_remote_branches () {
if test "$verbose" = "yes"
then
log=$(git-log --max-count=1 --pretty=oneline $ref)
- printf "%-20s %s\n" "$ref" "$log"
+ printf "%-*s %s\n" "$width" "$ref" "$log"
else
echo "$ref"
fi
@@ -83,7 +84,7 @@ ls_local_branches() {
if test "$verbose" = "yes"
then
log=$(git-log --max-count=1 --pretty=oneline $ref)
- printf "%s %-20s %s\n" "$pfx" "$ref" "$log"
+ printf "%s %-*s %s\n" "$pfx" "$width" "$ref" "$log"
else
echo "$pfx $ref"
fi
@@ -108,6 +109,10 @@ do
;;
-v)
verbose="yes"
+ ;;
+ -w)
+ shift
+ width="$1"
;;
--)
shift
--
1.4.3.1
^ permalink raw reply related
* [PATCH 0/3] Extend git-branch list output
From: Lars Hjemli @ 2006-10-21 22:33 UTC (permalink / raw)
To: git
This patch-series is on top of my previous patch to git-branch.sh
Shortlog:
[PATCH 1/3] Make git-branch honor -v when showing remote branches
[PATCH 2/3] git-branch: Add -w option to adjust branchname column width
[PATCH 3/3] Update documentation for git-branch
Diffstat:
Documentation/git-branch.txt | 8 ++++-
git-branch.sh | 79 +++++++++++++++++++++++++++--------------
2 files changed, 59 insertions(+), 28 deletions(-)
^ permalink raw reply
* [PATCH 3/3] Update documentation for git-branch
From: Lars Hjemli @ 2006-10-21 22:33 UTC (permalink / raw)
To: git
In-Reply-To: <1161470004894-git-send-email-hjemli@gmail.com>
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
---
Documentation/git-branch.txt | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index d43ef1d..dc6676e 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -8,7 +8,7 @@ git-branch - List, create, or delete bra
SYNOPSIS
--------
[verse]
-'git-branch' [-r]
+'git-branch' [-r] [-v [-w <width>]]
'git-branch' [-l] [-f] <branchname> [<start-point>]
'git-branch' (-d | -D) <branchname>...
@@ -47,6 +47,12 @@ OPTIONS
-r::
List only the "remote" branches.
+-v::
+ Show sha1 and first line of commit message for each branch
+
+-w <width>::
+ Set columnwidth for branchname (default is 20)
+
<branchname>::
The name of the branch to create or delete.
The new branch name must pass all checks defined by
--
1.4.3.1
^ permalink raw reply related
* [PATCH 1/3] Make git-branch honor -v when showing remote branches
From: Lars Hjemli @ 2006-10-21 22:33 UTC (permalink / raw)
To: git
In-Reply-To: <1161470004894-git-send-email-hjemli@gmail.com>
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
---
git-branch.sh | 74 ++++++++++++++++++++++++++++++++++++--------------------
1 files changed, 47 insertions(+), 27 deletions(-)
diff --git a/git-branch.sh b/git-branch.sh
index ab58737..25abd4c 100755
--- a/git-branch.sh
+++ b/git-branch.sh
@@ -1,6 +1,6 @@
#!/bin/sh
-USAGE='[-l] [(-d | -D) <branchname>] | [[-f] <branchname> [<start-point>]] | -r | -v'
+USAGE='[-r] [-v] | (-d | -D) <branchname> | [-l] [-f] <branchname> [<start-point>]'
LONG_USAGE='If no arguments, show available branches and mark current branch with a star.
If one argument, create a new branch <branchname> based off of current HEAD.
If two arguments, create a new branch <branchname> based off of <start-point>.'
@@ -48,15 +48,48 @@ If you are sure you want to delete it, r
exit 0
}
-ls_remote_branches () {
- git-rev-parse --symbolic --all |
- sed -ne 's|^refs/\(remotes/\)|\1|p' |
- sort
-}
-
force=
create_log=
verbose=
+remotes=
+
+ls_remote_branches () {
+ git-rev-parse --symbolic --all |
+ sed -ne 's|^refs/\(remotes/\)|\1|p' |
+ sort |
+ while read ref
+ do
+ if test "$verbose" = "yes"
+ then
+ log=$(git-log --max-count=1 --pretty=oneline $ref)
+ printf "%-20s %s\n" "$ref" "$log"
+ else
+ echo "$ref"
+ fi
+ done
+}
+
+ls_local_branches() {
+ git-rev-parse --symbolic --branches |
+ sort |
+ while read ref
+ do
+ if test "$headref" = "$ref"
+ then
+ pfx='*'
+ else
+ pfx=' '
+ fi
+ if test "$verbose" = "yes"
+ then
+ log=$(git-log --max-count=1 --pretty=oneline $ref)
+ printf "%s %-20s %s\n" "$pfx" "$ref" "$log"
+ else
+ echo "$pfx $ref"
+ fi
+ done
+}
+
while case "$#,$1" in 0,*) break ;; *,-*) ;; *) break ;; esac
do
case "$1" in
@@ -65,8 +98,7 @@ do
exit
;;
-r)
- ls_remote_branches
- exit
+ remotes="yes"
;;
-f)
force="$1"
@@ -90,24 +122,12 @@ done
case "$#" in
0)
- git-rev-parse --symbolic --branches |
- sort |
- while read ref
- do
- if test "$headref" = "$ref"
- then
- pfx='*'
- else
- pfx=' '
- fi
- if test "$verbose" = "yes"
- then
- log=$(git-log --max-count=1 --pretty=oneline $ref)
- printf "%s %-20s %s\n" "$pfx" "$ref" "$log"
- else
- echo "$pfx $ref"
- fi
- done
+ if test "$remotes" = "yes"
+ then
+ ls_remote_branches
+ else
+ ls_local_branches
+ fi
exit 0 ;;
1)
head=HEAD ;;
--
1.4.3.1
^ permalink raw reply related
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-21 22:25 UTC (permalink / raw)
To: Matthew D. Fuller
Cc: Jeff King, bazaar-ng, Linus Torvalds, Carl Worth,
Andreas Ericsson, git
In-Reply-To: <20061021214629.GO75501@over-yonder.net>
Matthew D. Fuller wrote:
[cut]
> Obviously, this is a totally foreign mentality to git, and that's
> great because it seems to work for you. I can see advantages to it,
> and I can conceive of situations where I might want that behavior.
> But, in my day-to-day VCS use, I don't hit them, which is why I keep
> typing 'bzr' instead of 'git' when I annoyingly need to type 'cvs'.
Well, not exactly. If you are interested in your changes, i.e. commits
generated by you, you can (with new git) filter commits by author name,
e.g. 'git log --author="$(git repo-config --get user.email)"'. If you
are interested in commits which you entered into repository, you can
(with new git) filter commits by commiter.
If you are interested in history of your branch, you can enable reflog
for this branch. This is of course totally local information, and
doesn't get propagated. It records things like commits, merges,
rebasing, starting branch anew, amending commits etc. Because it
is separate from branch and DAG of revisions, we can do fast-forward
and have identical DAG while having information about local history.
Besides git users are used to refer to graphical history viewers,
including gitk (Tcl/Tk, in git repository), qgit (Qt), gitview (GTK+, in
contrib/, less popular), git-show-branch (core git, strange UI, command
line), tig (ncurses) for more complicated cases.
I wonder if searching for one's own commits isn't the sign that
the project is of one-main-developer size (i.e. small project,
without large number of distributed contributors). I think in large
project you rather ask of history of specified file, of specified part
of project (specified directory), ask about why certain change was
introduced etc.
--
Jakub Narebski
Poland
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox