* 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
* Re: VCS comparison table
From: Sean @ 2006-10-21 22:06 UTC (permalink / raw)
To: Matthew D. Fuller
Cc: Jeff King, Jakub Narebski, bazaar-ng, Linus Torvalds, Carl Worth,
Andreas Ericsson, git
In-Reply-To: <20061021214629.GO75501@over-yonder.net>
On Sat, 21 Oct 2006 16:46:29 -0500
"Matthew D. Fuller" <fullermd@over-yonder.net> wrote:
> 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'.
It's not completely foreign, it's one of the things you can use the
git reflog feature to record. It's just that it's utterly clear in
Git that this is a local feature and is never replicated as part
of the distributed data.
> Depends on what you're fetching. You can always tell 'bzr pull' a new
> URL to look from. If it's a later version of the 'same' branch, it'll
> just update. If it's a 'different' branch (a branch that's a superset
> of your current branch/set-of-revisions, but with a different
> 'mainline' path through the revisions counts as 'different' here),
> pull will complain and require a --overwrite to do the deed.
This is where the git model is clearly superior and allows a true
distributed model. Because there is no concept of a "mainline"
(except locally via reflog) you can always merge with anyone
participating in the DAG without having to overwrite or lose ordering.
Sean
^ permalink raw reply
* Re: VCS comparison table
From: Matthew D. Fuller @ 2006-10-21 21:46 UTC (permalink / raw)
To: Jeff King
Cc: Jakub Narebski, bazaar-ng, Linus Torvalds, Carl Worth,
Andreas Ericsson, git
In-Reply-To: <20061021191949.GA8096@coredump.intra.peff.net>
On Sat, Oct 21, 2006 at 03:19:49PM -0400 I heard the voice of
Jeff King, and lo! it spake thus:
>
> I think the concept of "my" branch doesn't make any sense in git.
> [...]
> So don't think of it as "git throws away branch identity" as much as
> "git never cared about branch identity in the first place, and
> doesn't think it's relevant."
This is as I understand it.
But in my mind, it does make sense. I fundamentally DO think of "my
commits" differently from "revisions I've merged", and I want the tool
to preserve that for me. "My commits" tend to be steps along a path,
"merges" tend to be completed paths. I usually use bzr's "log
--short" for looking at logs, which doesn't show merged revs at all.
That works, because most of the time I don't care about them; I know
if I merged something, it's a completed piece, which I described in
the log message; it's not a PART of a task like my commits usually
are. So, just the message for my merge rev tells me what I need to
know, and if I need to drill down into it, I can use the regular
(--long) log output to look at the revision in it. This lets me know,
for instance, that if I want to re-check something I did 3 commits
ago, and I just merged another branch, the commit I'm interested in is
the 4th commit back on the mainline; I don't need to grub through a
bunch of revisions that aren't mine to try and find it.
So, if me and Bob are working on different bits of the same project in
parallel, finish up, and merge back and forth to sync up (ignoring for
the moment the "empty merge commit" bit), even though we now both have
the 'same' stuff, we have the same head rev with all the same parents,
the parents are in a different order, and my 'mainline' (the path of
left-most parents, or 'first' as I understand git calls them) is
different than his; my mainline is my commits, his mainline is his.
If one of us were to 'pull' the other, our branch would become a
duplicate of his and so adopt his 'mainline', which we want to avoid
because then it doesn't fit the mental model of "what I did", which is
what I think of my branch as.
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'.
> The difference, I think, is that it's easier in git to move the
> upstream around: you simply start fetching from a different place.
> I'm not clear on how that works in bzr (if it invalidates revnos or
> has other side effects).
Depends on what you're fetching. You can always tell 'bzr pull' a new
URL to look from. If it's a later version of the 'same' branch, it'll
just update. If it's a 'different' branch (a branch that's a superset
of your current branch/set-of-revisions, but with a different
'mainline' path through the revisions counts as 'different' here),
pull will complain and require a --overwrite to do the deed.
--
Matthew Fuller (MF4839) | fullermd@over-yonder.net
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
On the Internet, nobody can hear you scream.
^ permalink raw reply
* Re: VCS comparison table
From: Linus Torvalds @ 2006-10-21 21:10 UTC (permalink / raw)
To: Sean
Cc: Aaron Bentley, Carl Worth, Jakub Narebski, Andreas Ericsson,
bazaar-ng, git
In-Reply-To: <BAYC1-PASMTP07D0D16EAA6ABADDAD39B1AE020@CEZ.ICE>
On Sat, 21 Oct 2006, Sean wrote:
>
> Since the utility provided by revno's seems so minimal even in the
> case where they do work, Git simply doesn't bother with them. And
> "our" experience is that Git really does work well without them.
Yes. This really is what it boils down to.
The _only_ time you actually use revision numbers (as opposed to
branch-names or tag-names) is when you want a _stable_ number.
It's that simple. You never really need a revision number otherwise. In
other situations, you do things like
git log --since=2.days.ago
gitk v2.6.18..
git diff --stat --summary ORIG_HEAD..
or whatever. It's clearly not "stable", but it's also clearly not a
revision number from a UI perspective.
When you want a revision number is _exactly_ when you're moving things
between branches, or reporting a bug to somebody else, or similar. And
that's also _exactly_ when you want the number to be stable and meaningful
(ie the other end should be able to rely on the number).
And if you need refer to a central repository to do that, it's clearly not
distributed. Not needing such a central reference point is what the word
"distributed" _means_ in computer science for chrissake!
Linus
^ permalink raw reply
* Re: VCS comparison table
From: Linus Torvalds @ 2006-10-21 21:04 UTC (permalink / raw)
To: Erik Bågfors
Cc: Sean, Jan Hudec, bazaar-ng, git, Matthieu Moy, Jakub Narebski
In-Reply-To: <845b6e870610210919i6d086654g3881343e6a3c9f84@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1821 bytes --]
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 revision numbers are totally unstable in a distributed environment
_unless_ you use a certain work-flow. And that work-flow is definitely not
"distributed" it's much closer to "disconnected centralized".
Now, you could be truly distributed: BK used the same revision numbering
thing, but was distributed. But BK didn't even try to claim that their
revision numbers were "simple" and that fast-forwarding is sometimes the
wrong thing to do.
So BK always fast-forwarded, and the revision numbers were just randomly
changing numbers. They weren't stable, they weren't simple, and nobody
claimed they were.
So bzr can bite the bullet and say: "revision numbers are changing and
meaningless, and we should just fast-forward on merges", or you should
just admit that bzr is really more about "disconnected operation" than
truly distributed.
You can't have your cake and eat it too. Truly distributed _cannot_ be
done with a stable dotted numbering scheme (unless the "dotted numbering
scheme" is just a way to show a hash like git does - so the numbering has
no _sequential_ meaning).
Btw, this isn't just an "opinion". This is a _fact_. It's something they
teach in any good introductory course to distributed algorithms. Usually
it's talked about in the context of "global clock".
Anybody who thinks that there exists a globally ticking clock in the
system (and stably increasing dotted numbers are just one such thing) is
talking about some fantasy-world that doesn't exist, or a world that has
nothing to do with "distributed".
Linus
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-21 20:55 UTC (permalink / raw)
To: Carl Worth
Cc: Matthew D. Fuller, Aaron Bentley, Linus Torvalds,
Andreas Ericsson, bazaar-ng, git
In-Reply-To: <87ac3p1jn7.wl%cworth@cworth.org>
Carl Worth wrote:
> Also, since the git names are so predictable, git almost never emits
> them. It accepts them as names just fine, but it doesn't generate
> them, (log, and commit never show the branch-specific names). I think
> the only git command that even can emit such a name was a recently
> added git-name-rev which exists solely for the purpose of mapping a
> commit identifier to a local, branch-specific name which might have
> more intuitive meaning for the user.
git-show-branch also shows git-name-rev like names.
BTW. git-show-branch has somewhat strange, and different from other git
commands UI. You can think of it as text version of gitk/qgit history
viewer (although you can use tig for CLI (ncurses) graph).
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: VCS comparison table
From: Sean @ 2006-10-21 20:53 UTC (permalink / raw)
To: Aaron Bentley
Cc: bazaar-ng, Linus Torvalds, Andreas Ericsson, Carl Worth, git,
Jakub Narebski
In-Reply-To: <453A7D7E.8060105@utoronto.ca>
On Sat, 21 Oct 2006 16:05:18 -0400
Aaron Bentley <aaron.bentley@utoronto.ca> wrote:
> Our experience really is that it does work.
Of course it works as long as you accept the implicit requirements of
supporting them and ignore the cases where they change out from
underneath the user. But as soon as users want to embrace distributive
models where there isn't a central shared repo, at best revno's are
unhelpful and at worst they are counterproductive. The proof of this
is that if revno's were sufficient bzr wouldn't need revid's.
Since the utility provided by revno's seems so minimal even in the
case where they do work, Git simply doesn't bother with them. And
"our" experience is that Git really does work well without them.
Sean
^ permalink raw reply
* Re: VCS comparison table
From: Sean @ 2006-10-21 20:53 UTC (permalink / raw)
To: Aaron Bentley
Cc: Carl Worth, Linus Torvalds, Jakub Narebski, Andreas Ericsson,
bazaar-ng, git
In-Reply-To: <453A7D7E.8060105@utoronto.ca>
On Sat, 21 Oct 2006 16:05:18 -0400
Aaron Bentley <aaron.bentley@utoronto.ca> wrote:
> Our experience really is that it does work.
Of course it works as long as you accept the implicit requirements of
supporting them and ignore the cases where they change out from
underneath the user. But as soon as users want to embrace distributive
models where there isn't a central shared repo, at best revno's are
unhelpful and at worst they are counterproductive. The proof of this
is that if revno's were sufficient bzr wouldn't need revid's.
Since the utility provided by revno's seems so minimal even in the
case where they do work, Git simply doesn't bother with them. And
"our" experience is that Git really does work well without them.
Sean
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-21 20:48 UTC (permalink / raw)
To: Aaron Bentley
Cc: Carl Worth, Linus Torvalds, Andreas Ericsson, bazaar-ng, git
In-Reply-To: <453A7D7E.8060105@utoronto.ca>
Aaron Bentley wrote:
> Carl Worth wrote:
>> I'm noticing another terminology conflict here. The notion of "branch"
>> in bzr is obviously very different than in git. For example the bzr
>> man page has a sentence beginning with "if there is already a branch
>> at the location but it has no working tree". I'm still not sure
>> exactly what a bzr branch is, but it's clearly something different
>> from a git branch, (which is absolutely nothing more than a name
>> referencing a particular commit object).
>
> I got the impression there was also a local ordering of revisions. Is
> that wrong?
No, there is no such thing like local ordering of revisions.
Each revision (commit) has link to its parent(s). Branch technically
is just a reference to a particular commit object. The commit itself
gives us sub-DAG of DAG of whole history, the DAG of all parents of
said commit. Such lineage of commit pointed by branch is conceptually
a branch; i.e. branch is DAG of development (not line of development,
as there is no special meaning of first parent).
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.
> 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"?
We store configuration per repository, not per branch, although
there is some branch specific configuration.
[...]
> 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.
>> One, it intrudes on my branch namespace, (note that
>> in many commands above I have to use things like "../b" where I'd like
>> to just name my branch "b".
>
> 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.
>> Two, it prevents bzr from having any
>> notion of "all branches" in places where git takes advantage of it,
>> (such as git-clone and "gitk --all").
>
> No, it doesn't. Bazaar can easily list all the branches in a
> repository, just by starting with the repository root, and recursing
> through all the subdirectories, looking for branches.
Is there a command to list all branches in bzr? Is there a command
to copy (clone in SCM jargon) whole repository with all branches?
> That said, we do have mentality that branches, not repositories, are
> what's important to users in day-to-day use.
Thats opposite to git view. In git, working area is associated with
repository (clone of repository), not branch. We copy whole repositories
(sometimes only part of repository), not branches.
>>> What's nice is being able see the revno 753 and knowing that "diff -r
>>> 752..753" will show the changes it introduced. Checking the revo on a
>>> branch mirror and knowing how out-of-date it is.
>>
>> With git I get to see a revision number of b62710d4 and know that
>> "diff b62710d4^ b62710d4" will show its changes, though much more
>> likely just "show b62710d4". I really cannot fathom a place where
>> arithmetic on revision numbers does something useful that git revision
>> specifications don't do just as easily. Anybody have an example for
>> me?
>
> 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.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: VCS comparison table
From: Carl Worth @ 2006-10-21 20:47 UTC (permalink / raw)
To: Matthew D. Fuller
Cc: Aaron Bentley, Linus Torvalds, Andreas Ericsson, bazaar-ng, git,
Jakub Narebski
In-Reply-To: <20061021130111.GL75501@over-yonder.net>
[-- Attachment #1: Type: text/plain, Size: 8080 bytes --]
On Sat, 21 Oct 2006 08:01:11 -0500, "Matthew D. Fuller" wrote:
> I think we're getting into scratched-record-mode on this.
I apologize if I've come across as beating a dead horse on this. I've
really tried to only respond where I still confused, or there are
explicit indications that the reader hasn't understood what I was
saying, ("I don't understand how you've come to that conclusion",
etc.). I'll be even more careful about that below, labeling paragraphs
as "I'm missing something" or "Maybe I wasn't clear".
> G: So use revids everywhere.
>
> B: Revnos are handier tools for [situation] and [situation] for
> [reason] and [reason].
I'm missing something:
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).
> > It may be that the centralization bias
>
> I think it's more accurately describable as a branch-identity bias.
> The git claim seems to be that the two statements are identical, but I
> have some trouble swallowing that.
Maybe I wasn't clear:
There's no doubt that there has been semantic confusion over the term
branch that has been confounding communication on both sides. Here's
my attempt to describe the situation, (which only became this clear
recently as I started playing with bzr more). This is not an attempt
at a complete description, but is hopefully accurate, neutral, and
sufficient for the current discussion:
Abstract: In a distributed VCS we are using a distributed process to
create a DAG, (nodes are associated with revisions and point to parent
nodes). The distributed nature means that the collective DAG will have
multiple source nodes, (often termed heads or tips).
Git: A subset of the DAG is stored in a "repository". The DAG in the
repository may have many source nodes. A "branch" is a named reference
to a node (whether or not a source). Multiple local repositories may
share storage for common objects. There are inter-repository commands
for copying revisions and adjusting branch references, but basically
all other operations act within a single repository.
Bzr: A subset of the DAG is stored in a "branch". The DAG in the
branch has a single source node. Multiple local branches may share
storage for common objects through a "repository". Basically all
operations (where applicable) can act between branches.
Let me know if I botched any of that.
One concept that is really not introduced in the above is the
colloquial concept of a "branch" as a "line of development". In my
experience, this notion is a fundamentally short-lived thing. For
example, work happens on a feature branch for a while, and then it
gets merged into the mainline. After the merge, there's not that much
significance to the branch anymore. In a sense, it no longer exists
but for a few edges in the graph.
I imagine that both git and bzr users both use this short-lived aspect
in practice. After merging, git users drop their branch references and
bzr users drop their directories containing their branches. Anything
else would be unwieldy as the number of merged-in, "uninteresting"
branches would grow without bound and there wouldn't be any advantage
to keeping them around.
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.
But, here's a unifying point about git and bzr. Git also allows
branch-specific, unstable names for revisions. And they're even more
unstable than the ones bzr generates. But there are some important
differences between how they are used, (both by the tool and by
people).
To illustrate, yesterday I gave an example where performing a bzr
branch from a dotted-decimal revision would rewrite the numbers from
the originating branch (1.2.2, 1.2.1, and 1) to unrelated numbers in
the new branch (3, 2, 1). I was surprised at first, and couldn't
imagine any sane reason for the tool to go off and invent new names.
It prevents a user of the new branch from referencing any commits by
their original names. It also prevents the user from communicating
with anyone with these new names, (unless the user publishes the
branch, and any parties to the communication retain the new branch for
as long as said communication might be reference).
But then I realized why bzr is doing this. It's because, bzr users
don't just use the revision numbers for external communication, but
they also use them for lots of direct interaction with the tool. The
rewriting makes it easy to write something like "bzr diff -r1..3".
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.)
So there are two fundamentally different uses for names, (and Linus
recently talked about this in some length): 1. day-to-day working with
the tool and 2. externally communicating about specific revisions.
Both bzr and git allow for unstable, branch-specific names to be used
as a convenience in the case of the day-to-day working. Maybe some of
the people that dislike git's "ugly" names so much is that they
imagine that to compare two revisions a user of git must inspect the
logs, fish out the sha1sum for each, and then cut-and-paste to create
the command needed. I agree that if that were required, it would be
exceedingly painful. But that's not required, what the git user uses
is branch names and simple variations.
Now, there are some important difference in the unstable names that
git and bzr has. Most importantly, git's are even less stable, (with
respect to the association between a name and any specific
revision). With every commit, all of the git names effectively shift
as the branch moves, (HEAD points to the new commit, HEAD~1 points to
what HEAD previously pointed to). This is remarkably useful since it
provides stability in terms of what the user cares about, (the latest
commit and it's closest ancestors). This means that "diff from
grandparent to current commit" is always "git diff HEAD~1 HEAD" where
as in bzr it is "git diff -r<X-2>..<X>" and the user actually does
need to lookup X first, (unless there's more to the bzr revision
specification than I've seen).
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.
Also, since the git names are so predictable, git almost never emits
them. It accepts them as names just fine, but it doesn't generate
them, (log, and commit never show the branch-specific names). I think
the only git command that even can emit such a name was a recently
added git-name-rev which exists solely for the purpose of mapping a
commit identifier to a local, branch-specific name which might have
more intuitive meaning for the user.
So the fact that things like git-log doesn't print these names also
helps avoid any trap of users trying to communicate with something
unstable.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-21 20:19 UTC (permalink / raw)
To: Linus Torvalds
Cc: Jeff King, Matthew D. Fuller, bazaar-ng, Carl Worth,
Andreas Ericsson, git
In-Reply-To: <Pine.LNX.4.64.0610211237460.3962@g5.osdl.org>
Linus Torvalds wrote:
> - sometimes you have multiple branches in the same tree that have very
> _different_ sources. For example, you might start out cloning my tree,
> but if you _also_ want to track the stable tree, you just do so: you
> can just do
>
> git fetch <repo> <remote-branch-name>:<local-branch-name>
>
> at any time, and you now have a new branch that tracks a different
> repository entirely (to make it easier to keep track of them, you'd
> probably want to make note of this in your .config file or your remote
> tracking data, but that's a small "usability detail", not a real
> conceptual issue).
That for example allows of joining two initially separate projects
into one project. For example that was the case for gitk and gitweb
which are now in git.git repository. Most probably gitweb/gitk was
fetched into separate gitweb/gitk branch, then merged with the 'master'
branch of git (in case of gitweb we "resolved conflict" by moving
all gitweb files to gitweb/ subdirectory) then propagated to other
branches by merging with master.
For example git has 7 "initial" (parentless) commits. Two of them
are superficial 'html' and 'man' branches for automatic generation
of HTML and man version of git documentation, keeping it current.
There is 'todo' branch, [also] totally separate for notes. And there
are initial commits of git, git-tools, gitk and gitweb:
* Initial revision of "git", the information manager from hell
* Start of early patch applicator tools for git.
* Add initial version of gitk to the CVS repository
* first working version
[of gitweb: this commit message should be more descriptive]
$ git rev-list --parents --all | grep -v " " | xargs git -p show
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: VCS comparison table
From: Aaron Bentley @ 2006-10-21 20:05 UTC (permalink / raw)
To: Carl Worth
Cc: Linus Torvalds, Jakub Narebski, Andreas Ericsson, bazaar-ng, git
In-Reply-To: <87irie1wvv.wl%cworth@cworth.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Carl Worth wrote:
> On Thu, 19 Oct 2006 21:06:40 -0400, Aaron Bentley wrote:
>> I understand your argument now.
>> It's nothing to do with numbers per se,
>> and all about per-branch namespaces. Correct?
>
> The entire discussion is about how to name things in a distributed
> system. The premise that Linus has put forth in a very compelling way,
> is that attempting to use sequential numbers for names in a
> distributed system will break down. The breakdown could be that the
> names are not stable, or that the system is used in a centralized way
> to avoid the instability of the names.
So I'd say that revnos without the context of a location can only refer
to the current branch that the user is working on. They don't refer to
the mainline, which typically has its own numbers that don't match the
user's.
If you're saying that bzr is "centralized" in that the user's current
branch is special, then I'll say "guilty as charged".
> But it really is fundamental and unavoidable that sequential numbers
> don't work as names in a distributed version control system.
Right. You need something guaranteed to be unique. It's the revno +
url combo that is unique. That may not be permanent, but anyone can
create one of those names, so it is decentralized.
>> I meant that the active branch and a mirror of the abandoned branch
>> could be stored in the same repository, for ease of access.
>
> Granted, everything can be stored in one repository. But that still
> doesn't change what I was trying to say with my example. One of the
> repositories would "win" (the names it published during the fork would
> still be valid). And the other repository would "lose" (the names it
> published would be not valid anymore). Right?
No. It would be silly for the losing side to publish a mirror of the
winning branch at the same location where they had previously published
their own branch. So the old number + URL combination would remain valid.
If the losing faction decided to maintain their own branch after the
merge, they'd have two options
1. continue to develop against the losing "branch", without updating its
numbers from the "winning" branch. It would be hard to tell who had won
or lost in this case.
2. create a new mirror of the "winning" branch and develop against that.
I'm not sure what this point of this would be.
I think the most realistic thing in this scenario is that they leave the
"losing" branch exactly where it was, and develop against the "winning"
branch.
>> Bazaar encourages you to stick lots and lots of branches in your
>> repository. They don't even have to be related. For example, my repo
>> contains branches of bzr, bzrtools, Meld, and BazaarInspect.
>
> Git allows this just fine. And lots of branches belonging to a single
> project is definitely the common usage. It is not common (nor
> encouraged) for unrelated projects to share a repository, since a git
> clone will fetch every branch in the repository.
Right. This is a difference between Bazaar and Git that's I'd
characterize as being "branch-oriented" vs "repository-oriented". We'll
see more of this below.
> I'm noticing another terminology conflict here. The notion of "branch"
> in bzr is obviously very different than in git. For example the bzr
> man page has a sentence beginning with "if there is already a branch
> at the location but it has no working tree". I'm still not sure
> exactly what a bzr branch is, but it's clearly something different
> from a git branch, (which is absolutely nothing more than a name
> referencing a particular commit object).
I got the impression there was also a local ordering of revisions. Is
that wrong?
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
A Bazaar branch doesn't contain any commit objects ("revisions" in
Bazaar parlance). Those are retrieved from the containing repository.
It doesn't contain any working files, but a branch and a working tree
may coexist in the same directory. Similarly, a branch and a repository
may coexist in the same directory.
So this is one common layout:
Repository:
~/repo/
Branch:
~/repo/branch
Working Tree:
~/workingtee
This is another common layout:
Repository:
~/
Branch:
~/mybranch
Working Tree
~/mybranch
This layout is our default, a "standalone tree":
Repository:
~/mybranch
Branch:
~/mybranch
Working Tree:
~/mybranch
This layout is an imitation of Git, as I understand it:
Repository:
~/repo
Branches:
~/repo/origin
~/repo/master
Workingtree
~/repo
> Second, I'm not comfortable
> with any limit on usefulness of history. Would you willingly throw
> away commits, mailing list posts, or closed bug reports older than any
> given age for any projects that you care about?
I think the mailing list posts age the best, because they provide a
record of rationales for design decsions. But I'd throw away old
commits if there were a good reason, like lack of disk space. Not so
sure about bug reports.
> Second, I think that using the filesystem for separating branches is a
> really bad idea.
The canonical way to name branches in Bazaar is with URLs, though we
support file paths where possible. Part of the "simple namespace" thing
is that branches are simply URLs, so in order to retrieve a branch, all
you need is one URL.
> One, it intrudes on my branch namespace, (note that
> in many commands above I have to use things like "../b" where I'd like
> to just name my branch "b".
While "bzr merge ../b" is a minor inconvenience, I think that "bzr merge
http://bazaar-vcs.org/bzr/bzr.dev" is a big win.
> Two, it prevents bzr from having any
> notion of "all branches" in places where git takes advantage of it,
> (such as git-clone and "gitk --all").
No, it doesn't. Bazaar can easily list all the branches in a
repository, just by starting with the repository root, and recursing
through all the subdirectories, looking for branches.
That said, we do have mentality that branches, not repositories, are
what's important to users in day-to-day use.
> Three, it certainly encourages
> the storage problem I ran into above, (and I'd be interested to see a
> "corrected" version of the commands above to fix the storage
> inefficiencies).
$ bzr init-repo bzrtest --trees
$ bzr init bzrtest/master; cd bzrtest/master
$ touch a; bzr add a; bzr commit -m "Initial commit of a"
$ bzr branch . ../b; cd ../b
$ touch b; bzr add b; bzr commit -m "Commit b on b branch"
$ echo "change" > b; bzr commit -m "Change b on b branch"
$ bzr branch ../master ../c; cd ../c
$ touch c; bzr add c; bzr commit -m "Commit c on c branch"
$ echo "change" > c; bzr commit -m "Change c on c branch"
$ cd ../master
$ bzr merge ../b; bzr commit -m "Merge in b"
$ bzr merge ../c; bzr commit -m "Merge in c"
> I hadn't realized that the dotted decimal notation was so new that the
> community hadn't had a lot of experience with it yet. But, your
> description doesn't actually presume that notation. What you asked
> was:
>
> > When you create a new branch from scratch, the number starts at zero.
> > If you copy a branch, you copy its number, too.
> >
> > Every time you commit, the number is incremented. If you pull, your
> > numbers are adjusted to be identical to those of the branch you pulled from.
> >
> > Is that really complicated?
>
> And to answer. That description doesn't describe at all what happens
> to the "simple" numbers of commits that are merged.
Nothing happens to them, because they were never part of this branch, so
they didn't ever exist in this context.
> I still don't
> understand how people can avoid number changing, (since pull seems the
> only way to synch up without infinite new merge commits being added
> back and forth).
Why would anyone commit if the merge introduced no changes?
>> What's nice is being able see the revno 753 and knowing that "diff -r
>> 752..753" will show the changes it introduced. Checking the revo on a
>> branch mirror and knowing how out-of-date it is.
>
> With git I get to see a revision number of b62710d4 and know that
> "diff b62710d4^ b62710d4" will show its changes, though much more
> likely just "show b62710d4". I really cannot fathom a place where
> arithmetic on revision numbers does something useful that git revision
> specifications don't do just as easily. Anybody have an example for
> me?
My understanding is that ^ is treated as a special metacharacter by some
shells, which is why bzr revision specs are more long-winded.
> PS. The "bzr branch" of bzr.dev did eventually finish. I can see the
> dotted-decimal numbers in my example now, (1.1.1 and 1.2.2 for the
> commits that came from branch b; 1.2.1 and 1.2.2 for the commits that
> came from branch c). At 5 characters a piece these are well on their
> way to getting just as "ugly" as git names, (once it's all
> cut-and-paste the difference in ugliness is negligible).
Yeah, I'm not sure I like those dotted numbers, either.
> And now, I see it's not just pull that does number rewriting. If I use
> the following command (after the chunk of commands above):
>
> cd ..; bzr branch -r 1.2.2 master 1.2.2
It's not number rewriting, it's number writing. It doesn't change the
numbers in master, or any other existing branch. (Push also does number
rewriting, because it's mostly the inverse of pull).
> It appears to just create newly linearized revision numbers from whole
> cloth for the new branch (1, 2, and 3 corresponding to mainline 1,
> 1.2.1, and 1.2.2). That's totally surprising, very confusing, and
> would invalidate any use I wanted to make of published revision
> numbers for the mainline branch while I was working on this branch.
I think the intent of those numbers was for operations like "diff". I
never branch from a revision, always from a branch, which will preserve
numbers.
> See? This stuff really doesn't work.
Our experience really is that it does work.
> Is there even a way to say "show me the change introduced by what is
> named '1.2.1' in the source branch in this scenario" ?
The revno:branch notation ought to work, but I guess there's a bug. Not
surprising, since dotted revnos are new in this release.
> > Note: In #bzr I just learned that there is a way for me to do this
> _if_ I also happen to have a pull of the original branch somewhere on
> my machine.
This should work with any URL, not just locations on your machine.
> But with bzr if I find "1.2.1" somewhere I'm likely to type:
The problem here is the "somewhere". Since each branch has its own
revno namespace, you need to know where to use the revno effectively.
Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFOn190F+nu1YWqI0RAn1nAKCDqT8gbzm/xIMjbc3kTFCkpMbJvwCeJiWr
3fLtDo4uLwtAWi+pQOrgPLU=
=0GeT
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: VCS comparison table
From: Linus Torvalds @ 2006-10-21 19:55 UTC (permalink / raw)
To: Jakub Narebski
Cc: bazaar-ng, Matthew D. Fuller, Jeff King, Andreas Ericsson,
Carl Worth, git
In-Reply-To: <200610212130.31414.jnareb@gmail.com>
On Sat, 21 Oct 2006, Jakub Narebski wrote:
>
> That's good example of fully distributed approach. I can fetch directly
> (actually, I cannot) from Junio private repository, I can fetch from
> public git.git repository, either using git:// or http:// protocol,
> I can fetch from somebody else clone of git repository: intermixing
> those fetches, and revids (commit-ids) remain constant and unchanged.
This is nice for a couple of situations:
- if some particular machine is down, nobody really cares. It doesn't
really change the workflow at all if "master.kernel.org" were to be
off-line due to some trouble - it just happens to be a machine with
good bandwidth that a number of kernel (and git) developers have access
to, but if you want to sync with something else, go wild. We could just
sync directly between developers, although most people tend to have
firewalls (I certainly have a very anal one - not even ssh gets in)
making it usually easier to go through some - any - public place.
But in git, the "public place" really is just an intermediary. It has
nothing to do with anything history-wise, and it's revision ID's are a
non-issue. It's just a temporary staging area (although re-using the
same repo over and over for pushing things out obviously means you can
do just incremental updates, so most everybody does that)
- sometimes you have multiple branches in the same tree that have very
_different_ sources. For example, you might start out cloning my tree,
but if you _also_ want to track the stable tree, you just do so: you
can just do
git fetch <repo> <remote-branch-name>:<local-branch-name>
at any time, and you now have a new branch that tracks a different
repository entirely (to make it easier to keep track of them, you'd
probably want to make note of this in your .config file or your remote
tracking data, but that's a small "usability detail", not a real
conceptual issue).
- the same "multi-source" thing is true for pushing things out too, not
just fetching: I still have my personal git.git repository on
kernel.org for historical reasons, even though Junio maintains the
normal one. So when I did some experimental (and broken) stuff for "git
unpack-objects" in a local branch, and others were interested in fixing
it, I just pushed it out to my git repo as a new branch - one that
Junio doesn't have.
So now my kernel.org git repo not only tracks all of Junio's branches
(basically just a mirror of his tree), I also have a few stale branches
of my own that I did some work on separately. So it's kind of a
"frankensteins monster" of different branches from different sources.
And I think that's fairly common, actually (ie many kernel developers
that publicise their own git trees often have a "linus" branch that
tracks mine, along with their own "real" branches)
And note how in none of these situtations does it matter what the
"original" branch was. It might even be a way to just pre-populate the
tree. For a real-life example, a week or two ago, Jesper Juhl wanted to
download my kernel tree (which is about 140MB in size), but he's somewhere
in Europe, and apparently the connection to kernel.org was just _really_
slow.
So what I told him to do was:
Hmm. I suspect most mirrors avoid the /pub/scm directory, but there are a
few places that mirror git trees in general, eg
http://www.jur-linux.org/git/
might be closer to you.
Once you have _one_ kernel repo, you can clone another easily using
git clone --reference <mylocalrepo> <remotereponame> [localdir]
but you do need to have the thing in git format, not just a snapshot, to
do that.
and that's exactly what he did (and he could have just fetched into the
original archive entirely):
I could only get 2-3kb/sec from kernel.org and at that speed 140MB is
*HUGE*.
That was a lot better. got more than 200kb/sec from there.
so the point here is, "distributed" really is more than star-topology. If
you think outside the star, you can take useful shortcuts.
Now, I'm sure that bzr can probably do all the same things. This is likely
less an issue of "technology" than of "mindset". The "git way" tends to
make all of these things very trivial - the notion of tracking multiple
branches from multiple _different_ repositories in one local repo just
fits very naturally in the whole git mentality.
Linus
^ permalink raw reply
* Re: VCS comparison table
From: Jan Hudec @ 2006-10-21 19:47 UTC (permalink / raw)
To: Jakub Narebski
Cc: Jeff King, bazaar-ng, Matthew D. Fuller, Linus Torvalds,
Andreas Ericsson, Carl Worth, git
In-Reply-To: <200610212130.31414.jnareb@gmail.com>
On Sat, Oct 21, 2006 at 09:30:30PM +0200, Jakub Narebski wrote:
> Jeff King wrote:
>
> > The difference, I think, is that it's easier in git to move the upstream
> > around: you simply start fetching from a different place. I'm not clear
> > on how that works in bzr (if it invalidates revnos or has other side
> > effects).
Moving upstram around does not invalidate revnos. Switching to different
upstream (ie. the head revisions are different) does. And this may
happen by doing a merge with the previous mainline as non-first parent
-- revnos are simply short aliases for revids, not persistent unique
idenfiers.
> That's good example of fully distributed approach. I can fetch directly
> (actually, I cannot) from Junio private repository, I can fetch from
> public git.git repository, either using git:// or http:// protocol,
> I can fetch from somebody else clone of git repository: intermixing
> those fetches, and revids (commit-ids) remain constant and unchanged.
So they (revids) do in bzr.
--------------------------------------------------------------------------------
- Jan Hudec `Bulb' <bulb@ucw.cz>
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-21 19:41 UTC (permalink / raw)
To: Matthew D. Fuller
Cc: bazaar-ng, Linus Torvalds, Carl Worth, Andreas Ericsson, git
In-Reply-To: <20061021181149.GM75501@over-yonder.net>
Matthew D. Fuller wrote:
> On Sat, Oct 21, 2006 at 04:08:18PM +0200 I heard the voice of
> Jakub Narebski, and lo! it spake thus:
>> Dnia sobota 21. października 2006 15:01, Matthew D. Fuller napisał:
>> When two clones of the same repository (in git terminology), or two
>> "branches" (in bzr terminology), used by different people, cannot be
>> totally equivalent that is centralization bias.
>
> This is obviously some new meaning of "centralization" bearing no
> resemblance whatsoever to how I understand the word.
Perhaps I'd better use "star topology bias" instead of "centralization
bias".
> In git, apparently, you don't give a crap about a branch's identity
> (alternately expressible as "it has none"), and so you throw it away
> all the time. Given that, revnos even if git had them would never be
> of ANY use to you, so it's no wonder you have no use for the notion.
In git branches are lightweight. Branch names are local to repository.
Repositories have identity. Bzr "branch" is strange mix of one-branch
git repository and git branch.
Git main workflow is fully decentralized workflow. All clones of the
same repository are created equal. In bzr the suggested workflow
(with revnos) forces one (or more) branches to be mainline (use "merge",
get empty-merges, revnos don't change) and leaf (use "pull", revnos
change).
> I DO give a crap about my branchs' identities. I WANT them to retain
> them. If I have 8 branches, they have 8 identities. When I merge one
> into another, I don't WANT it to lose its identity. When I merge a
> branch that's a strict superset of second into that second, I don't
> WANT the second branch to turn into a copy of the first. If I wanted
> that, I'd just use the second branch, or make another copy of it. I
> don't WANT to copy it. I just want to merge the changes in, and keep
> on with my branch's current identity.
I don't understand. If I merge 'next' branch into 'master' in git, I
still have two branches: 'master' and 'next'.
And I don't understand why you are so hung on branch identities. Yes, if
somebody clones your 'repo' repository, he can have your 'master' branch
(refs/heads/master) named 'repo' (refs/heads/repo) or 'repo/master'
(refs/remotes/repo/master), but why that matters to you. It is _his_
(or her ;-) clone.
> Now, we can discuss THAT distinction. I'm not _opposed_ to git's
> model per se, and I can think of a lot of cases where it's be really
> handy. But those aren't most of my cases. And as long as we don't
> agree on branch identity, it's completely pointless to keep yakking
> about revnos, because they're a direct CONSEQUENCE of that difference
> in mental model. See? They're an EFFECT, not a CAUSE. If bzr didn't
> have revnos, I'd STILL want my branch to keep its identity. You could
> name the mainline revisions after COLORS if you wanted, and I'd still
> want my branch to keep its identity. Aren't we through rehashing the
> same discussion about the EFFECTS?
For revnos to work you MUST have one "branch" to be considered
special, the hub in star topology. This very much precludes fully
distributed development.
BTW. I get that you can use revids in revnos in bzr for fully
distributed and not star-topology geared development. But
Bazaar-NG revids are uglier that Git commit-ids.
[...]
>> And you say that bzr is not biased towards centralization? In git
>> you can just pull (fetch) to check if there were any changes, and if
>> there were not you don't get useless marker-merges.
>
> If I don't tell you my branch has something in it ready to grab, you
> shouldn't merge it. It probably won't work, and is quite likely to
> set your computer on fire, slaughter and fillet your pet goldfish, and
> make demons fly out of your nose. If you wanna get stuck with all my
> incomplete WIP, let's just use a CVS module and be done with it.
In git I can fetch your changes but I don't need to merge them. Take
for example Junio 'pu' (proposed updates) branch: this is the branch
you shouldn't merge as it's history is constantly being rewritten.
If you don't want for your WIP to be publicly available, you don't
publish it. For example as far as I understand Junio works on Git
in his private repository, with many, many feature branches, but
he does push to public [bare] repository only some subset of branches,
and we can fetch/pull only those.
But still, if I am impatient I can pull from Junio every hour, and
I don't get 24 totally useless empty merge messages if he took day
off and didn't publish any changes till day later.
>> 2. But the preferred git workflow is to have two branches in each of
>> two clones. The 'origin' branch where you fetch changes from other
>> repository (so called "tracking branch") and you don't commit your
>> changes to [...]
>
> Funny, since this reads to me EXACTLY like the bzr flow of "upstream
> branch I pull" and "my branch I merge from upstream" that's getting
> kvetched around...
But please, have you realized that in this workflow the two clones
of the same repository are totally symmetrical? One's 'master' is
another 'origin' and vice versa. After pull on one side, and pull
on the other side (without any changes in between) we have the same
contents, and the same revision names (commit-ids in git), even if
the changes (revisions) got to those clones in different order.
In bzr those two "branches" would get different revnos. No symmetry.
Full distributed vs star topology (one branch "central", hence
"centralized" - I don't mean need to access to one central repository,
although...)
--
Jakub Narebski
ShadeHawk on #git
Poland
^ permalink raw reply
* Re: [PATCH 2/2] Remove dead code after direct graph drawing
From: Marco Costalba @ 2006-10-21 19:33 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git
In-Reply-To: <200610211740.26128.Josef.Weidendorfer@gmx.de>
>
> On the first pass down, the memory increases by around 26 MB,
> which could by correct, as you do setupData() lazy (no idea what
> this function does...).
Populates the list view item and calculates (only calculation not
drawing) the graph of the item (see Git::updateLanes() )
> >
> > I'm not sure it depends on your patch though.
>
> Can you compare with/without my patch?
Yes. You are right, I have a memory increase also without your last patch.
>
> How did you check for leaks in the past?
> Did you try valgrind (memcheck or massif)?
>
I tried with valgrind but with little success due to a lot of noise
from qt libraries. Perhaps I was not using it right.
Sorry for the noise
Marco
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-21 19:30 UTC (permalink / raw)
To: Jeff King
Cc: Matthew D. Fuller, bazaar-ng, Linus Torvalds, Carl Worth,
Andreas Ericsson, git
In-Reply-To: <20061021191949.GA8096@coredump.intra.peff.net>
Jeff King wrote:
> The difference, I think, is that it's easier in git to move the upstream
> around: you simply start fetching from a different place. I'm not clear
> on how that works in bzr (if it invalidates revnos or has other side
> effects).
That's good example of fully distributed approach. I can fetch directly
(actually, I cannot) from Junio private repository, I can fetch from
public git.git repository, either using git:// or http:// protocol,
I can fetch from somebody else clone of git repository: intermixing
those fetches, and revids (commit-ids) remain constant and unchanged.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle
From: Jakub Narebski @ 2006-10-21 19:21 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jan Hudec, Jeff King, bazaar-ng, git
In-Reply-To: <Pine.LNX.4.64.0610211102250.3962@g5.osdl.org>
Linus Torvalds wrote:
> We've discussed adding a "--follow" flag to tell "git log" to consider the
> argument to not be a "pathname filter", but a "individual file" kind of
> thing, and I think there was even a patch for it, but I suspect it hasn't
> been a big issue, probably partly because you get rather used to the
> "pathname filter" approach fairly quickly.
If I remember correctly, the patch implementing --follow was fairly
intrusive, and was unfortunate in that it was posted during changes
in diffcore.
Lack of --follow is not a big issue because you can do this "by hand";
you can use git-diff-tree -M at the end of file history to check if
[git considers] it was moved from somewhere.
During discussion we have agreed that we would like to have both
--follow rename following limiter and static path limiter (and
that it would be nice to extend static path limiter to include globs).
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle
From: Jan Hudec @ 2006-10-21 19:20 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Jeff King, bazaar-ng, git
In-Reply-To: <200610211951.43495.jnareb@gmail.com>
On Sat, Oct 21, 2006 at 07:51:43PM +0200, Jakub Narebski wrote:
> Jan Hudec wrote:
>
> > Besides I start to think that it should be actually possible to solve
> > this case with the git-style approach. I have to state beforehand, that
> > I don't know how the most recent git algorithm works, but I imagine
> > there is some kind of 'brackets' saying the text is in a given file. Now
> > if those 'brackets' were not flat, but nested, ie. instead of saying
> > 'this is in foo/bar' it would say 'this is in bar is in foo', the
> > difference when renaming directory would only affect the 'outer bracket'
> > and therefore merge correctly with adding content inside it.
>
> You mean, to consider "contents" of a directory union of contents
> of files and directories it contains, and then use the same "rename
> detection" algorithm as for files?
Yes, something like that.
--------------------------------------------------------------------------------
- Jan Hudec `Bulb' <bulb@ucw.cz>
^ permalink raw reply
* Re: VCS comparison table
From: Jeff King @ 2006-10-21 19:19 UTC (permalink / raw)
To: Matthew D. Fuller
Cc: Jakub Narebski, bazaar-ng, Linus Torvalds, Carl Worth,
Andreas Ericsson, git
In-Reply-To: <20061021181149.GM75501@over-yonder.net>
On Sat, Oct 21, 2006 at 01:11:49PM -0500, Matthew D. Fuller wrote:
> Maybe that's what you mean by 'centralization'; each branch is central
> to itself. That seems a pretty useless definition, though. In my
> mind, actually, it's MORE distributed; my branch remains my branch,
> and your branch remains your branch, and the difference doesn't keep
> us from working together and moving changes back and forth. Forcing
> my branch to become your branch sounds a lot more "centralized" to me.
>
> Now, we can discuss THAT distinction. I'm not _opposed_ to git's
OK, let's discuss. :)
I think the concept of "my" branch doesn't make any sense in git.
Everyone is working collectively on a DAG of the history, and we all
have pointers into the DAG. Something is "my" branch in the sense that I
have a repository with a pointer into the DAG, but then again, so do N
other people. I control my pointer, but that's it.
So don't think of it as "git throws away branch identity" as much as
"git never cared about branch identity in the first place, and doesn't
think it's relevant."
Now, there are presumably advantages and disadvantages to these
approaches. I like the fact that I can prepare a repository from
scratch, import it from cvs, copy it, push it, or do whatever I like,
and the end result is always exactly the same (revids included). With
your model, on the other hand, it seems the advantages are that in many
cases you can do things like distributed revnos.
> agree on branch identity, it's completely pointless to keep yakking
> about revnos, because they're a direct CONSEQUENCE of that difference
> in mental model. See? They're an EFFECT, not a CAUSE. If bzr didn't
> have revnos, I'd STILL want my branch to keep its identity. You could
> name the mainline revisions after COLORS if you wanted, and I'd still
> want my branch to keep its identity. Aren't we through rehashing the
> same discussion about the EFFECTS?
I agree completely.
> > 2. But the preferred git workflow is to have two branches in each of
> > two clones. The 'origin' branch where you fetch changes from other
> > repository (so called "tracking branch") and you don't commit your
> > changes to [...]
>
> Funny, since this reads to me EXACTLY like the bzr flow of "upstream
> branch I pull" and "my branch I merge from upstream" that's getting
> kvetched around...
The difference, I think, is that it's easier in git to move the upstream
around: you simply start fetching from a different place. I'm not clear
on how that works in bzr (if it invalidates revnos or has other side
effects).
-Peff
^ permalink raw reply
* Re: VCS comparison table
From: Sean @ 2006-10-21 19:02 UTC (permalink / raw)
To: Jan Hudec; +Cc: Linus Torvalds, bazaar-ng, git, Jakub Narebski
In-Reply-To: <20061021185825.GC29927@artax.karlin.mff.cuni.cz>
On Sat, 21 Oct 2006 20:58:25 +0200
Jan Hudec <bulb@ucw.cz> wrote:
> In bzr this was already discussed and the storage supports so called
> "ghost" revisions, whose existence is known, but not their data. There
> are even repositories around that contain them (created by converting
> data from arch), but to my best knowledge there is no user interface to
> create branches or checkouts with partial data.
In Git the same functionality can be achieved with so called shallow-
clones. Unfortunately, they've only been discussed and not yet
implemented.
Sean
^ permalink raw reply
* Re: VCS comparison table
From: Sean @ 2006-10-21 19:02 UTC (permalink / raw)
To: Jan Hudec; +Cc: Aaron Bentley, Linus Torvalds, bazaar-ng, git, Jakub Narebski
In-Reply-To: <20061021185825.GC29927@artax.karlin.mff.cuni.cz>
On Sat, 21 Oct 2006 20:58:25 +0200
Jan Hudec <bulb@ucw.cz> wrote:
> In bzr this was already discussed and the storage supports so called
> "ghost" revisions, whose existence is known, but not their data. There
> are even repositories around that contain them (created by converting
> data from arch), but to my best knowledge there is no user interface to
> create branches or checkouts with partial data.
In Git the same functionality can be achieved with so called shallow-
clones. Unfortunately, they've only been discussed and not yet
implemented.
Sean
^ permalink raw reply
* Re: VCS comparison table
From: Jan Hudec @ 2006-10-21 18:58 UTC (permalink / raw)
To: Aaron Bentley; +Cc: Sean, Linus Torvalds, bazaar-ng, git, Jakub Narebski
In-Reply-To: <4535345C.6090905@utoronto.ca>
On Tue, Oct 17, 2006 at 03:51:56PM -0400, Aaron Bentley wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Sean wrote:
> > On Tue, 17 Oct 2006 00:24:15 -0400
> > Aaron Bentley <aaron.bentley@utoronto.ca> wrote:
> >>- - you can use a checkout to maintain a local mirror of a read-only
> >> branch (I do this with http://bazaar-vcs.com/bzr/bzr.dev).
> >
> >
> > I'm not sure what you mean here. A bzr checkout doesn't have any history
> > does it?
>
> By default, they do. You must use a flag to get a checkout with no history.
If I can add some clarification: There is a lightweight checkout and
heavyweight checkout. The former contains no history and does everything
(except status and I am not sure about diff) by accessing the remote
data. The later contains mirror of the history data and does
write-through on commit (and otherwise behaves like normal branch with
repository)
What would be really useful would be a checkout, or even a branch (ie.
with ability to commit locally), that would only contain history data
since some point. This would allow downloading very little data when
branching, but than working locally as with normal repository clone.
In bzr this was already discussed and the storage supports so called
"ghost" revisions, whose existence is known, but not their data. There
are even repositories around that contain them (created by converting
data from arch), but to my best knowledge there is no user interface to
create branches or checkouts with partial data.
--------------------------------------------------------------------------------
- Jan Hudec `Bulb' <bulb@ucw.cz>
^ permalink raw reply
* [PATCH] git-merge: show usage if run without arguments
From: Rene Scharfe @ 2006-10-21 18:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
diff --git a/git-merge.sh b/git-merge.sh
index 49c46d5..cb09438 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -93,6 +93,8 @@ finish () {
esac
}
+case "$#" in 0) usage ;; esac
+
rloga=
while case "$#" in 0) break ;; esac
do
^ permalink raw reply related
* Re: VCS comparison table
From: Sean @ 2006-10-21 18:47 UTC (permalink / raw)
To: Jan Hudec; +Cc: Linus Torvalds, bazaar-ng, Matthieu Moy, git, Jakub Narebski
In-Reply-To: <20061021183428.GB29927@artax.karlin.mff.cuni.cz>
On Sat, 21 Oct 2006 20:34:28 +0200
Jan Hudec <bulb@ucw.cz> wrote:
> For one think I, like others already expressed, think difference should
> be made between 'centralized' and 'star-topology'. Subversion is
> centralized -- I don't think bzr is biased towards that kind of
> centralization, though it provides tools (bound branches) to make it
> easy.
A star-topology assumes there is a central server from which the points
of the start emerge. It is very much a centralized model and one that
bzr is clearly optimized for. The difference between bzr and say
cvs is that bzr provides offline abilities where checkins to the
central server can be deferred by checking them in locally first.
The bzr bias towards this model is implicit in its affection for
revnos, which depend on a central repository to syncronize them for
all the points of the star.
[...]
> On the other hand git is biased away from centralized (as in subversion
> is centralized) in that it takes extra work to make sure you are always
> synchronized (while bzr has bound branches to do the checking for you).
> For open-source development, centralized is a wrong way to go, but
> people use version control tools for other purposes as well and for some
> of them staying synchronized is important.
Please reconsider this point, Git can be configured to push every commit
to a central server immediately. It's just that such a model is so inferior
in almost every way, that it's not typically done.
Sean
^ 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