* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-20 10:40 UTC (permalink / raw)
To: git; +Cc: bazaar-ng
In-Reply-To: <45373E27.3050209@op5.se>
Andreas Ericsson wrote:
> Christian MICHON wrote:
>
>> close to 200 post on bzr-git war!
>> is this the right place (git mailing list) to discuss about future
>> features of bzr ?
>>
>
> Perhaps not, but the tone is friendly (mostly), the patience of the
> bazaar people seems infinite and lots of people seem to be having fun
> while at the same time learning a thing or two about a different SCM.
> Best case scenario, both git and bazaar come out of the discussion as
> better tools. If there would never be any cross-pollination, git
> wouldn't have half the features it has today.
And it certainly helps to explain user-visible differences between
Bazaar-NG and GIT; I'd like to put ComparisonWithBazaarNG page on
GitWiki (http://git.or.cz/gitwiki/) some time soon, in addition
to ComparisonWithMercurial I meant to add from some time (stemming
from discussion on #revctrl list on FreeNode), and in addition
to existing GitSvnComparison page on GitWiki).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-20 10:32 UTC (permalink / raw)
To: git
In-Reply-To: <loom.20061019T205327-196@post.gmane.org>
Nathaniel Smith wrote:
> Aaron Bentley <aaron.bentley <at> utoronto.ca> writes:
>
>> Bazaar also supports multiple unrelated branches in a repository, as
>> does CVS, SVN (depending how you squint), Arch, and probably Monotone.
>
> It's quite common in Monotone. You could probably do it in Mercurial as well,
> though I don't know that anyone does. SVK definitely does it (since each user
> has a single repo that's shared by all the projects they work on).
I think that GIT separation of root, repository, and branches
namespaces is why there are so many calls for adding subproject
support to GIT; people want to change to GIT literally, for example
putting everything in one large repository.
In GIT there is no concept of root, like in CVS or SVN. You can
put repository anywhere. By default GIT looks for repository
in current directory or one of its parents; otherwise you have to
provide location of repository either by using GIT_DIR environment
variable, or by using --git-dir option to git wrapper.
And the branch namespace is totally separate. There are some
restrictions on branch names (caused by notation GIT uses, for
example <branch>^ means [first] parent of commit given by <branch>),
but really few. Branch names can be hierarchical, like "jc/diff".
So there is no "store everything in URL/path" of
/root/repo/branch
notation in GIT.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-20 10:19 UTC (permalink / raw)
To: James Henstridge; +Cc: Sean, Aaron Bentley, Linus Torvalds, bazaar-ng, git
In-Reply-To: <a7e835d40610200126y5edc2ad0v8ca0a95655b2e029@mail.gmail.com>
James Henstridge wrote:
> On 17/10/06, Sean <seanlkml@sympatico.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? So it's not a mirror of a branch, but just a checkout of the
> > branch head?
>
> There are two forms of checkout: a normal checkout which contains the
> complete history of the branch, and a lightweight checkout, which just
> has a pointer back to the original location of the history.
>
> In both cases, a "bzr commit" invocation will commit changes to the
> remote location. In general, you only want to use a lightweight
> checkout when there is a fast reliably connection to the branch (e.g.
> if it is on the local file system, or local network).
So the "lightweight checkout" is equivalent of "lazy clone" we have
much discussed on git mailing list about (without any resulting code,
unfortunately). The point of problem was how to do this fast, without
need for fast reliable connection to the repository it was cloned from.
For example if to leave fetched objects in some kind of cache, or even
in "lightweight checkout"/"lazy clone" repository database.
If repository we do "lightweight checkout"/"lazy clone" from is on
local file system (perhaps network file system), then we can use
alternates mechanism (git clone -l -s). That's why "lazy clone" was
sometimes named "remote alternates".
> Aaron would be talking about a normal (heavyweight) checkout here.
> With a heavyweight checkout, you can do pretty much anything without
> access to the branch. In contrast, almost all operations on a
> lightweight checkout need access to the branch.
We have terminology conflict here. Bazaar-NG "pull" and "merge" vs.
GIT "fetch", "pull" and "merge"; Bazaar-NG "checkout" vs. GIT "clone"
and "checkout".
In GIT "clone" is what is used to copy whole repository, "checkout"
is what is used to extract given/current branch to [given] working area.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: VCS comparison table
From: Petr Baudis @ 2006-10-20 10:16 UTC (permalink / raw)
To: Lachlan Patrick; +Cc: bazaar-ng, git
In-Reply-To: <45387F04.5010101@research.canon.com.au>
Dear diary, on Fri, Oct 20, 2006 at 09:47:16AM CEST, I got a letter
where Lachlan Patrick <loki@research.canon.com.au> said that...
> I think git has an alternative way to name revisions
> (can someone please explain it in more detail, I've seen <ref>~<n>
> mentioned only in passing in this thread).
This is just a notion that lets you point to revisions relative to a
given id. <id>~<n> means n-th ancestor of the given commit.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* Re: VCS comparison table
From: Petr Baudis @ 2006-10-20 10:13 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: bazaar-ng, git
In-Reply-To: <Pine.LNX.4.63.0610201034170.14200@wbgn013.biozentrum.uni-wuerzburg.de>
Hi,
Dear diary, on Fri, Oct 20, 2006 at 10:38:48AM CEST, I got a letter
where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> On Fri, 20 Oct 2006, Lachlan Patrick wrote:
>
> > How does git disambiguate SHA1 hash collisions?
>
> It does not. You can fully expect the universe to go down before that
> happens.
>
> The only reasonable worry is about SHA-1 being broken some time in future,
> i.e. being able to construct a malign version of some source code _which
> has the same hash_. There were plenty of discussions about that; Please
> search the mailing list. (The consent was that those do not matter,
> because an existing object will _never_ be overwritten by a fetch, so you
> would not get that invalid object anyway.)
well, that's somewhat a bold statement, since when you have a way to
fabricate malicious objects, you probably can socially engineer to have
it distributed to a large portion of repositories if you try hard
enough. Or you hack kernel.org and replace the object. Who knows.
But the thing is that noone has come any closer to this kind of attack
at all. Currently known attacks are that you can relatively fast (which
doesn't mean "5 minutes"; I think that in case of SHA1 the complexity is
still huge, just smaller than intended, but I may remember wrong; you
can get a MD5 collision of this kind within one minute on a standard
notebook) create a _pair_ of objects sharing the same hash, where both
objects contain a big binary blob. So you would first have to engineer
to have one of those objects accepted officially, then engineer the
malicious one getting in. Generating an object that hashes to a
predetermined value is much harder problem and AFAIK there's no much
progress in breaking this.
^ permalink raw reply
* Re: VCS comparison table
From: Matthieu Moy @ 2006-10-20 10:02 UTC (permalink / raw)
To: Jakub Narebski
Cc: bazaar-ng, Linus Torvalds, Andreas Ericsson, Carl Worth, git
In-Reply-To: <200610201157.22348.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Huh? If you want what changes have been introduced by commit
> c3424aebbf722c1f204931bf1c843e8a103ee143, you just do
>
> # git diff c3424aebbf722c1f204931bf1c843e8a103ee143
How does git chose which ancestor to use if this revision has more
than one in this case?
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-20 9:57 UTC (permalink / raw)
To: Aaron Bentley
Cc: Carl Worth, Linus Torvalds, Andreas Ericsson, bazaar-ng, git
In-Reply-To: <45382120.9060702@utoronto.ca>
Aaron Bentley wrote:
>> The naming in git really is beautiful and beautifully simple.
>
> Well, you've got to admit that those names are at least superficially
> ugly.
If you want pretty name, you tag it. Tags are exchanged during
fetch/push operation. And you can have pretty names of revisions
like v1.4.3
>> It's not monotonically increasing from one revision to the next, but
>> I've never found that to be an issue. Of course, we do still use our
>> own "simple" names for versioning the releases and snapshots of
>> software we manage with git, and that's where being able to easily
>> determine "newer" or "older" by simple numerical examination is
>> important. I've honestly never encountered a situation where I was
>> handed two git sha1 sums and wished that I could do the same thing.
>
> 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.
Huh? If you want what changes have been introduced by commit
c3424aebbf722c1f204931bf1c843e8a103ee143, you just do
# git diff c3424aebbf722c1f204931bf1c843e8a103ee143
(or better "git show" instead of "git diff" or "git diff-tree").
If you give only one commit (only one revision) git automatically
gives diff to its parent(s).
By the way, is referring to revision by it's revno _fast_?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-20 9:51 UTC (permalink / raw)
To: James Henstridge
Cc: bazaar-ng, Linus Torvalds, Carl Worth, Andreas Ericsson, git
In-Reply-To: <a7e835d40610191953i467ce853k4b4740bbfdd92936@mail.gmail.com>
James Henstridge wrote:
> On 20/10/06, Carl Worth <cworth@cworth.org> wrote:
>> On Thu, 19 Oct 2006 19:01:58 -0400, Aaron Bentley wrote:
>>> Additionally, the new mainline can keep a mirror of the
>>> abandoned mainline in its repository, because there are virtually no
>>> additional storage requirements to doing so.
>>
>> And this part I don't understand. I can understand the mainline
>> storing the revisions, but I don't understand how it could make them
>> accessible by the published revision numbers of the "abandoned"
>> line. And that's the problem.
>
> With this sort of setup, I would publish my branches in a directory
> tree like this:
>
> /repo
> /branch1
> /branch2
>
> I make "/repo" a Bazaar repository so that it stores the revision data
> for all branches contained in the directory (the tree contents,
> revision meta data, etc).
And here we have a feature which is as far as I see unique to git,
namely to have persistent branches with _separate namespace_. It means
that we can have hierarchical branch names (including names like
"remotes/<remotename>/<branch of remote>", or "jc/diff"), and we don't
have to guess where repository name ends and branch name begins.
The idea of "branches (and tags) as directories" was if I understand
it correctly introduced by Subversion, and from what can be seen from
troubles with git-svn (stemming from the fact that division between
project name and branch name is the matter of _convention_) at least
slightly brain-damaged.
> The "/repo/branch1" essentially just contains a list of mainline
> revision IDs that identify the branch. This could probably be just
> store the head revision ID, but there are some optimisations that make
> use of the linear history here.
>
> If the ancestry of "/repo/branch2" is a subset of branch1 (as it might
> be if the in the case of forked then merged projects), then all its
> revision data will already be in the repository when branch1 was
> imported. The only cost of keeping the branch around (and publishing
> it) is the list of revision IDs in its mainline history.
>
> For similar reasons, the cost of publishing 20 related Bazaar branches
> on my web server is generally not 20 times the cost of publishing a
> single branch.
>
> I understand that you get similar benefits by a GIT repository with
> multiple head revisions.
You can get similar benefits by a GIT repository with shared object
database using alternates mechanism. And that is usually preferred
over storing unrelated branches, i.e. branches pointing to disconnected
DAG (separate trees in BK terminology) of revision, if that you mean by
multiple head revisions (because in GIT there is no notion of "mainline"
branch, only of current (HEAD) branch).
>>>> But for these communications, revision numbers will not provide
>>>> historically stable values that can be used.
>>>
>>> They certainly can.
>>>
>>> The coder says "I've put up a branch at http://example.com/bzr/feature.
>>> In revision 5, I started work on feature A. I finished work in
>>> revision 6. But then I had to fix a related bug in revision 7."
>>
>> "I've put this branch up" isn't historically stable...
>
> With the repository structure mentioned above, the cost of publishing
> multiple branches is quite low. If I continue to work on the project,
> then there is no particular bandwidth or disk space reasons for me to
> cut off access to my old branches.
>
> For similar reasons, it doesn't cost me much to mirror other people's
> related branches if I really care about them.
But the revision number in this case _changes_. It is from 7 to
branch:7 but still it changes somewhat.
[...]
>> The naming in git really is beautiful and beautifully simple.
>
> I don't think anyone is saying that universally unique names are bad.
> But I also don't see a problem with using shorter names that only have
> meaning in a local scope.
>
> I've noticed some people using abbreviated SHA1 sums with GIT. Isn't
> that also a case of trading potential global uniqueness for
> convenience when working in a local scope?
Emphasisis on _potential_. SHA1 id abbreviated to 6 characters might
be not unique in larger project, but for example the chance that
SHA1 id abbreviated to 7 or 8 characters is not unique is really low.
Yet another analogy:
SHA1 identifiers of commits (and not only commits) can be compared
to Message-Ids of Usenet messages, while revision numbers can be compared
to Xref number of Usenet message which if I understand correctly is unique
only for given news server. But Message-Ids cannot be shortened
meaningfully like SHA1 ids can; newertheless they are used in communication
without any problems. Even if namespace is not simple ;-)
^ permalink raw reply
* Re: VCS comparison table
From: Matthieu Moy @ 2006-10-20 9:43 UTC (permalink / raw)
To: Sean; +Cc: Andreas Ericsson, bazaar-ng, git, Jakub Narebski
In-Reply-To: <BAYC1-PASMTP07AB11A64250AAF683424DAE0E0@CEZ.ICE>
Sean <seanlkml@sympatico.ca> writes:
> On Tue, 17 Oct 2006 17:27:44 -0400
> Aaron Bentley <aaron.bentley@utoronto.ca> wrote:
>
>> Bzr has plugin autoloading, Protocol plugins, Repository format plugins,
>> and more. Because Python supports monkey-patching, a plugin can change
>> absolutely anything.
>
> But really why does any of that matter? This is the open source world.
> We don't need plugins to extend features, we just add the feature to
> the source. The example I asked about earlier is a case in point.
> Apparently in bzr "bisect" was implemented as a plugin, yet in Git it
> was implemented as a command without any issue at all,
The plugin Vs core feature is not a technical problem. The code for a
plugin and for a core functionality will roughly be the same, but in a
different file.
There can be many reasons why you want to implement something as a
plugin:
* This is project-specific, upstream is not interested (for example,
bzr has a plugin to submit a merge request to a robot, it will
probably never come in the core).
* The feature is not matured enough, so you don't want to merge it in
upstream, but you want to make it available to people without
patching (for example, "bzr uncommit" was once in the bzrtools
plugin, and finally landed in upstream).
* The feature you're adding are only of use to a small subset of
users. You don't want to pollute, in particular "bzr help commands"
with it, especially not to disturb beginners. I've been arguing in
favor of a configuration option to hide commands from "bzr help
commands" instead, but nobody seemed interested.
* Explicit divergent points of view between the implementor of the
plugin and upstream. That avoids a fork. I don't remember any such
case with bzr.
I'd compare bzr's plugins to Firefox extensions. Geeks used to like
the big Mozilla-with-tons-of-config-options, but
Firefox-with-only-the-most-relevant-features is the one which allowed
a wide adoption by non-geeks. Still, geeks can customize their
browser, and add features without having to wait for Mozilla Fundation
to incorporate it in upstream.
Now, I don't know git enough to know whether the way it is extensible
allow all of the above, but bzr's plugin system it quite good at that.
At the time git was almost exclusively used by the kernel, you didn't
have all those problems since you targeted only one community, but I
guess you already had some needs for flexibility.
^ permalink raw reply
* Re: VCS comparison table
From: Sean @ 2006-10-17 15:06 UTC (permalink / raw)
To: Matthieu Moy; +Cc: bazaar-ng, git
In-Reply-To: <vpqlknf10u5.fsf@ecrins.imag.fr>
On Tue, 17 Oct 2006 16:19:46 +0200
Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
> Sure. As I said before, the little add-on of checkouts is that you say
> once "I don't want to do local commit here", and bzr reminds you this
> each time you commit. Well, where it can make a difference is that it
> does it in a transactional way, that is, you don't have that little
> window between the time you pull and the time you push your next
> commit. But this would really be bad luck ;-).
Yeah, it would be bad luck, but Git wouldn't actually let the push
succeed if someone had changed the upstream repo in that small window.
It would complain that your push wasn't a fast forward and ask you
to update before pushing.
> Sure. And at least, if you want to prove that your decentralized SCM
> is the best, you'd better look at features other than the ability to
> commit on a local branch ;-). If you want a _real_ flamewar, better
> talk about rename management or revision identity.
>
> The thing is that most people migrated from CVS/svn, so they found
> their new SCM to be incredibly better the existing. But it's generally
> not _so_ much better than the other modern alternatives ;-). (and
> don't forget to thank Darcs and Monotone who brought most of the good
> ideas you and I are using)
Heh, true enough. And the fact is they're all "borrowing" the
best ideas from one another. All of a sudden the others are all
getting git-like bisect and gitk guis. And of course Linus has
said that he got quite a bit of inspiration from Monotone
originally.
Beyond the distributed offline nature of using Git, the killer
"feature" for me is its raw speed and flexibility[1]. It's
really nice to be able to branch in under a second and try
out a line of development etc. Maybe this is just as easy
in Bazaar but it's not true of say Mercurial. Honestly, I
just can't imagine any other SCM meeting my needs better than
Git. So I have a hard time taking complaints about rename
management or revision identity seriously.
While they don't affect my usage, IMHO the two biggest failings
of Git are its lack of a shallow clone and its reliance on shell
and other scripting languages so there is no native Windows version.
I'm sure both of these areas are handled better by Bazaar and/or
some of the other new SCMs where they'd be a better choice than
Git.
Sean
[1] As an aside, I don't understand why bazaar pushes the idea
of "plugins". For instance someone mentioned that bazaar has
a bisect "plugin". Well Git was able to add a bisect "command"
without needing a plugin architecture.. so i'm at a loss as
to why plugins are seen as an advantage.
^ permalink raw reply
* Re: VCS comparison table
From: Sean @ 2006-10-17 22:00 UTC (permalink / raw)
To: Aaron Bentley; +Cc: Andreas Ericsson, bazaar-ng, git, Jakub Narebski
In-Reply-To: <45354AD0.1020107@utoronto.ca>
On Tue, 17 Oct 2006 17:27:44 -0400
Aaron Bentley <aaron.bentley@utoronto.ca> wrote:
> Bzr has plugin autoloading, Protocol plugins, Repository format plugins,
> and more. Because Python supports monkey-patching, a plugin can change
> absolutely anything.
But really why does any of that matter? This is the open source world.
We don't need plugins to extend features, we just add the feature to
the source. The example I asked about earlier is a case in point.
Apparently in bzr "bisect" was implemented as a plugin, yet in Git it
was implemented as a command without any issue at all, no plugins
needed, and its compiled and runs at machine speed.
Sean
^ permalink raw reply
* Re: VCS comparison table
From: Erik Bågfors @ 2006-10-20 8:56 UTC (permalink / raw)
To: Sean; +Cc: Linus Torvalds, bazaar-ng, git, Jakub Narebski
In-Reply-To: <BAYC1-PASMTP08A746E5FA6B87BC65BD37AE0E0@CEZ.ICE>
> > - - 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? So it's not a mirror of a branch, but just a checkout of the
> branch head?
In bzr there are two different kind of checkouts. One is a called a
lightweight checkout and that's really a "normal" checkout in the way
svn for example does it. In this mode, you have the branch remotely
and only the working tree locally. So it's just a checkout of the
branch head (of any other revision if using -r when doing the
checkout).
Then there are none lightweight checkouts, heavyweight checkouts.
These are the default type. A heavyweight checkout is in fact a full
branch locally, but it is "bound" to the remote branch. What this
means is that all commands such as diff/status/log/etc can be done
locally. So it's really quick.
It acts the same as a lightweight checkout in most regards, so when I
run "bzr update" it actually pulls from the remove branch, and when I
run "bzr commit" it commits the same revision in both the remote
branch and the local branch. It does this in one transaction so one
can't work and the other fail (they would both fail in that case).
What this also gives you is that when you want to clone the branch,
you don't need to go the the remote branch to get the revisions and
also, when being offline, you can commit locally.
Committing locally is a very cool feature in my mind. If you work in
a centralized manner with checkouts, you normally commit directly to
the central branch, but when you are offline, that will fail (of
course :) ). So what you can do then is to run "bzr commit --local"
to commit only to your local checkout branch, then when you get online
again you can run "bzr update". In this case the update will take any
new commits that has been done while you were away, pull them into
your local branch, and make your local commits into something that has
been merged into the "checkout".
I find this REALLY useful.
Don't know if that made sense, here it is in commands.
$ bzr checkout t p
$ cd p
$ echo hej >> hosts
$ bzr commit --local -m 'offline'
$ echo hej >> hosts
$ bzr commit --local -m 'offline 2'
Now I get back, someone has committed new stuff... I run bzr update
$ bzr update
All changes applied successfully.
Updated to revision 2.
Your local commits will now show as pending merges with 'bzr status',
and can be committed with 'bzr commit'.
$ bzr status
modified:
hosts
pending merges:
Erik Bågfors 2006-10-20 offline 2
Erik Bågfors 2006-10-20 offline
$ bzr commit -m 'my offline stuff'
modified hosts
Committed revision 3.
$ bzr log -r-1
------------------------------------------------------------
revno: 3
committer: Erik Bågfors <erik@bagfors.nu>
branch nick: p
timestamp: Fri 2006-10-20 10:51:08 +0200
message:
my offline stuff
------------------------------------------------------------
merged: erik@bagfors.nu-20061020084949-8bc43db8f5cd449b
committer: Erik Bågfors <erik@bagfors.nu>
branch nick: p
timestamp: Fri 2006-10-20 10:49:49 +0200
message:
offline 2
------------------------------------------------------------
merged: erik@bagfors.nu-20061020084945-13e5093f98c0c380
committer: Erik Bågfors <erik@bagfors.nu>
branch nick: p
timestamp: Fri 2006-10-20 10:49:45 +0200
message:
offline
I think that bzr really allows you to work well in a centralized
environment as well as a distrubuted, which is one of the things I
like best about bzr.
Regards,
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: Sean @ 2006-10-18 13:02 UTC (permalink / raw)
To: Matthew D. Fuller
Cc: bazaar-ng, Linus Torvalds, Andreas Ericsson, Carl Worth, git,
Jakub Narebski
In-Reply-To: <20061018124320.GT75501@over-yonder.net>
On Wed, 18 Oct 2006 07:43:20 -0500
"Matthew D. Fuller" <fullermd@over-yonder.net> wrote:
> The difference is that bzr ALSO chooses to support and optimize for a
> different case in the default UI presentation, because We[0] consider
> that far and away the common case on the one hand, and that people
> trying to use the more complex case are ipso facto more able to use a
> behavior differing from the norm on the other.
>
> [0] Note how adroitly I again speak for other people. Practice,
> practice!
Just to be clear here, Git is also able to supports this model if
you so choose. It's quite easy for a server to generate Git tags
for every commit it gets.
It's just that this is basically a non issue in the Git world. People
who use Git aren't crying out for salvation from sha1 numbers. So I
think this entire discussion is a bit overblown.
But just to be clear, there is nothing in the Git model that prohibits
tagging every commit with something you find less objectionable than
sha1's. They can appear in the log listings and in gitk etc, and
everyone who pulls from the central server will get them. In fact,
for some imports of other VCS into Git, exactly that is done; so every
commit can be referenced by its sha1 _or_ the "friendly" number it was
known by in its original VCS.
Sean
^ permalink raw reply
* Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle
From: Sean @ 2006-10-19 10:40 UTC (permalink / raw)
To: Alexander Belchenko; +Cc: bazaar-ng, git
In-Reply-To: <eh76np$trg$1@sea.gmane.org>
On Thu, 19 Oct 2006 09:46:32 +0300
Alexander Belchenko <bialix@ukr.net> wrote:
> You probably miss main idea of bzr bundles. It's not just the way to
> send via e-mail or other appropriate transport the part of repository.
> It primarily was designed to be human readable as usual diff (i.e.
> patch). It was designed to solve 2 thing simultaneously:
>
> - be informative for human as usual patch
> - be consistent for machine.
Petr already mentioned that the data currently shown in the email
text isn't really useful. But it's simple to make it an attachment
and show a combined diff instead.
Although that might just make the email bigger for not a lot of
gain. It's easy to use the git command line and gui tools to inspect
the bundle after importing it into your repository. And just as
easy to expunge the bundle afterward if it isn't up to grade.
Sean
^ permalink raw reply
* Re: VCS comparison table
From: Sean @ 2006-10-17 11:38 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Linus Torvalds, bazaar-ng, git, Jakub Narebski
In-Reply-To: <vpqejt76vgz.fsf@ecrins.imag.fr>
On Tue, 17 Oct 2006 13:19:08 +0200
Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
> 1) a working tree without any history information, pointing to some
> other location for the history itself (a la svn/CVS/...).
> (this is "light checkout")
Git can do this from a local repository, it just can't do it from
a remote repo (at least over the git native protocol). However,
over gitweb you can grab and unpack a tarball from a remote repo.
In practice this is probably enough support for such a feature.
> 2) a bound branch. It's not _very_ different from a normal branch, but
> mostly "commit" behaves differently:
> - it commits both on the local and the remote branch (equivalent to
> "commit" + "push", but in a transactional way).
> - it refuses to commit if you're out of date with the branch you're
> bound to.
> (this is "heavy checkout")
This doesn't sound right, at least in the spirit of git. Git really
wants to have a local commit which you may or may not push to a
remote repo at a later time. There is no upside to forcing it all to
happen in one step, and a lot of downsides. Gits focus is to support
distributed offline development, not requiring a remote repo to be
available at commit time.
> In both cases, this has the side effect that you can't commit if the
> "upstream" branch is read-only. That's not fundamental, but handy.
Again this seems really anti-git. There is no reason for your local
branch to be marked read only just because some upstream branch is
so marked.
> I use it for example to have several "checkouts" of the same branch on
> different machines. When I commit, bzr tells me "hey, boss, you're out
> of date, why don't you update first" if I'm out of date. And if commit
> succeeds, I'm sure it is already commited to the main branch. I'm sure
> I won't pollute my history with merges which would only be the result
> of forgetting to update.
This is exactly the same in Git. You really only ever push upstream
when your local changes fast forward the remote, (ie. you're up to date).
Git will warn you if your changes don't fast forward the remote.
> The more fundamental thing I suppose is that it allows people to work
> in a centralized way (checkout/commit/update/...), and Bazaar was
> designed to allow several different workflows, including the
> centralized one.
While Git really isn't meant to work in a centralized way there's nothing
preventing such a work flow. It just requires the use of some surrounding
infrastructure.
Sean
^ permalink raw reply
* Signed git-tag doesn't find default key
From: Andy Parkins @ 2006-10-20 9:04 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 913 bytes --]
Hello,
I did this:
$ git tag -s adp-sign-tag
gpg: skipped "Andy Parkins <andyparkins@gmail.com>": secret key not available
gpg: signing failed: secret key not available
failed to sign the tag with GPG.
I believe the problem is that I have used the comment field in my key's UID
definition.
$ gpg --list-keys andy
pub 1024D/4F712F6D 2003-08-14
uid Andy Parkins (Google) <andyparkins@gmail.com>
So when git-tag looks for "Andy Parkins <andyparkins@gmail.com>"; it's not
found. The answer is (I think) to search only on the email address when
looking for a key. I've simply changed git-tag to have
username=$(git-repo-config user.email)
However, this is clearly wrong as what it actually wants is the committer
email. Am I safe to simply process the $tagger variable to extract it?
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
andyparkins@gmail.com
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: VCS comparison table
From: Sean @ 2006-10-17 12:57 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Linus Torvalds, bazaar-ng, git, Jakub Narebski
In-Reply-To: <vpqbqob5euu.fsf@ecrins.imag.fr>
On Tue, 17 Oct 2006 14:03:21 +0200
Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
> Anyway, given the price of disk space today, this only makes sense if
> you have a fast access to the repository (otherwise, you consider your
> local repository as a cache, and you're ready to pay the disk space
> price to save your bandwidth). In this case, it's often in your
> filesystem (local or NFS).
This is most likely the reason that people using Git don't clammor
more for the ability to work without a local repository. Disk is cheap
and it just makes sense the vast majority of the time to have a complete
copy of the repository yourself. There are a lot of powerful things
you can do once you have all that information in your repo. Not the least
of which is performing any and all operations while flying on a plane
or sitting on a park bench.
> I should have said "by default" ... but you have "commit --local" if
> you want to have a local commit on a bound branch (at this point, I
> should remind that not all branches are "bound branches". "bzr branch"
> creates branches similar to git ones).
Well, with Git the default is to only commit locally. Of course, you
could set your post commit hook to always push it to a remote if
you wanted to.
> Will, take the example of my bzr setup.
>
> I have one repository, say, $repo.
>
> In it, I have one branch "$repo/bzr.dev" which is an exact mirror of
> http://bazaar-vcs.org's branch.
>
> I also have branches for patches (occasional in my case) that I'll
> send to upstream. Say $repo/feature1, $repo/feature2, ...
>
> If, by mistake, I start hacking on bzr.dev itself, I'll be warned at
> commit time, create a branch, and commit in this new branch. I believe
> git manages this in a different way, allowing you to commit in this
> branch, and creating the branch next time you pull. But you know this
> better than I ;-), I never got time to give a real try to git.
Well, it's just a slight difference in perspective rather than any
big issue here. Git treats all repositories as peers, so it would never
assume that just because one other particular repo has a branch marked
as read only that it should be marked read only locally. It lets you
commit to it, and then push to say a third and fourth repo that are
writable as well. In practice this doesn't really cause any
insurmountable problems.
> Yes, but you will have to do a merge at some point, right ? While I'm
> keeping a purely linear history (not that it is good in the general
> case, but for "projects" on which I'm the only developper, I find it
> good. For example, my ${HOME}/etc/).
Well if you're committing changes from multiple different machines,
how is that different from having say 3 different developers committing
changes to the central repo? How does bzr avoid a merge when you're
pushing changes from 3 separate machines?
You mentioned that if you try to push and you're not up to date you'll
be prompted to update (ie. pull from the upstream repo). When you do such
a pull do your local changes get rebased on top or is there a merge? By
your comments I guess you're saying they're rebased rather than merged, and
this is how you keep a linear history. Git can do this easily, but it's
not done by default.
Sean
^ permalink raw reply
* Re: VCS comparison table
From: Sean @ 2006-10-17 22:56 UTC (permalink / raw)
To: Aaron Bentley; +Cc: Andreas Ericsson, bazaar-ng, git, Jakub Narebski
In-Reply-To: <45355CBB.80108@utoronto.ca>
On Tue, 17 Oct 2006 18:44:11 -0400
Aaron Bentley <aaron.bentley@utoronto.ca> wrote:
> That can lead to feature bloat. Some plugins are not useful to
> everyone, e.g. Mercurial repository support. Some plugins introduce
> additional dependencies that we don't want to have in the core (e.g. the
> rsync, baz-import and graph-ancestry commands).
Shrug, it's really not that tough to do in regular ole source code.
On Fedora for instance you have your choice of which rpms you want
to install to get the features of Git you want.
> Plugins also don't have a Bazaar's rigid release cycle, testing
> requirements and coding conventions, so they are a convenient way to try
> out an idea, before committing to the effort of getting it merged into
> the core.
Hmm.. It's pretty easy to test out Git ideas too. People do it all
the time, and without plugins. Junio maintains several such trees
for instance. Dunno.. I just think plugs _sounds_ good to developers
without much real benefit to users over regular ole source code.
> The bisect plugin is just as performant as any other bzr command. (The
> whole VCS is in Python.) Most people don't use it, so we don't ship it
> as part of the base install, but anyone who wants it can have it.
Sure, and anyone who wants to use StGit on top of Git can download and
use it as well.
Sean
^ permalink raw reply
* Re: VCS comparison table
From: Sean @ 2006-10-17 23:18 UTC (permalink / raw)
To: Robert Collins; +Cc: Linus Torvalds, bazaar-ng, git, Jakub Narebski
In-Reply-To: <1161124078.9020.88.camel@localhost.localdomain>
On Wed, 18 Oct 2006 08:27:58 +1000
Robert Collins <robertc@robertcollins.net> wrote:
> Be as blunt as you want. You're expressing an opinion, and thats fine. I
> happen to think that we're right : users appear to really appreciate
> this bit of the UI, and I've not yet seen any evidence of confusion
> about it - though I will admit there is the possibility of that
> occurring.
Yeah, but it's an opinion that is based on a huge real world project with
hundreds of developers. If Bazaar is ever used in a project of that
size it may just see the same type of issues as Bk. As has been mentioned
elsewhere, Git users really appreciate the short forms it provides for
referencing commits, so much so that there is no reason to invent a
new (unstable) numbering system or attempt to hide the true underlying
commit identities.
Just out of curiosity is there a Bazaar repo of the Linux kernel available
somewhere?
Sean
^ permalink raw reply
* Re: VCS comparison table
From: linux @ 2006-10-20 8:43 UTC (permalink / raw)
To: loki; +Cc: git, linux
> I've been following the git-vs-bzr discussion, and I'd like to ask a
> question (being new to both bzr and git). How does git disambiguate SHA1
> hash collisions? I think git has an alternative way to name revisions
> (can someone please explain it in more detail, I've seen <ref>~<n>
> mentioned only in passing in this thread). It seems to me collisions are
> a good argument in favour of having two independent naming schemes, so
> that you're not solely relying on hashes being unique.
>
> A strong argument is that a global namespace based on hashes of data is
> ideal because the names are generated from the data being named, and
> therefore are immutable. Same data => same name for that data, always
> and forever, which is desirable when merging named data from many
> sources. But the converse isn't true: one name does not necessarily map
> to only that data. Have I misunderstood? Is this a problem?
Git avoids the problem by using a very large gryptographic hash.
While recent cryptographic advances mean that it will soon be barely
possible to deliberately construct two files with the same SHA hash,
absent massivecomputational investment, it can be considered a truly
random hash function.
That means that, given N objects in the repository, there are N * (N-1)
/ 2 pairs, each of which is a chance to collide. The probability of
having a collision is thus roughly N * (N-1) / 2^161. Which doesn't
reach 1/2 until N == 2^80.
Suppose a git repository has 100 objects added per second, continuously,
until the Sun turns into a red giant and swallows the Earth in 5-6
billion years' time (thus halting development).
That will generate 2^64 objects in the repository, and the probability
of there being a collison at that time is 2^128/2^161 = 2^-33, or 1 in
8 billion, small enough to be negligible.
For slightly more plausible repository sizes, the odds of having a
problem are even more miniscule.
And the benefits gained from having a completely deterministic
data => name mapping are considerable, well worth running such
a minisule risk of major problems.
(There is a road map for conversion to the even larger SHA-256 if
that ever proves necessary, but it's not likely to.)
As for the <ref>~<n> syntax, see "man git-rev-parse". The parent of <rev>
is <rev>^. If it has multiple parents, the othersare <rev>^2, <rev>^3, etc.
<rev>^^^^ is the great-great-grandparent of the named rev, and may also
be written <rev>~4.
^ permalink raw reply
* Re: VCS comparison table
From: Sean @ 2006-10-18 21:29 UTC (permalink / raw)
To: Charles Duffy; +Cc: bazaar-ng, git
In-Reply-To: <eh64tk$rug$2@sea.gmane.org>
On Wed, 18 Oct 2006 16:04:52 -0500
Charles Duffy <cduffy@spamcop.net> wrote:
> Example time!
>
> There's a plugin for Bzr which adds support for Cygwin-compatible
> symlink support on Windows. (IIRC, this involves monkey-patching some of
> the Python standard library bits).
>
> Now, this is something which is *proposed* as a feature to be merged
> into upstream bzr, and it may happen at some point. That said, when I
> have a Windows-using coworker who wants to check out a repository that
> has symlinks in it (with his win32-native, no-cygwin-required bzr
> upstream binary), I don't need to tell him to go download and build bzr
> from a third party; instead, I just need to tell him to run a single
> command to check out the plugin in question into the bzr plugins folder.
>
> From an end-user convenience perspective, it's a pretty significant win.
You'll need a better example than that. Git has supported a version
of Cygwin-compatible symlink support on Windows for quite some time.
And no plugins were needed.
Sean
^ permalink raw reply
* Re: VCS comparison table
From: Johannes Schindelin @ 2006-10-20 8:38 UTC (permalink / raw)
To: Lachlan Patrick; +Cc: bazaar-ng, git
In-Reply-To: <45387F04.5010101@research.canon.com.au>
Hi,
On Fri, 20 Oct 2006, Lachlan Patrick wrote:
> How does git disambiguate SHA1 hash collisions?
It does not. You can fully expect the universe to go down before that
happens.
The only reasonable worry is about SHA-1 being broken some time in future,
i.e. being able to construct a malign version of some source code _which
has the same hash_. There were plenty of discussions about that; Please
search the mailing list. (The consent was that those do not matter,
because an existing object will _never_ be overwritten by a fetch, so you
would not get that invalid object anyway.)
Hth,
Dscho
^ permalink raw reply
* Re: VCS comparison table
From: James Henstridge @ 2006-10-20 8:26 UTC (permalink / raw)
To: Sean; +Cc: Aaron Bentley, Linus Torvalds, bazaar-ng, git, Jakub Narebski
In-Reply-To: <BAYC1-PASMTP08A746E5FA6B87BC65BD37AE0E0@CEZ.ICE>
On 17/10/06, Sean <seanlkml@sympatico.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? So it's not a mirror of a branch, but just a checkout of the
> branch head?
There are two forms of checkout: a normal checkout which contains the
complete history of the branch, and a lightweight checkout, which just
has a pointer back to the original location of the history.
In both cases, a "bzr commit" invocation will commit changes to the
remote location. In general, you only want to use a lightweight
checkout when there is a fast reliably connection to the branch (e.g.
if it is on the local file system, or local network).
Aaron would be talking about a normal (heavyweight) checkout here.
With a heavyweight checkout, you can do pretty much anything without
access to the branch. In contrast, almost all operations on a
lightweight checkout need access to the branch.
James.
^ permalink raw reply
* Re: VCS comparison table
From: Sean @ 2006-10-17 10:35 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: bazaar-ng, git
In-Reply-To: <Pine.LNX.4.63.0610171229160.14200@wbgn013.biozentrum.uni-wuerzburg.de>
On Tue, 17 Oct 2006 12:30:27 +0200 (CEST)
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> It would also make things slow as hell. How do you deal with something
> like annotate in such a setup?
Some commands like annotate might not make any sense in such a set up.
But one way to get the same (perhaps even better) feature into git
would be to support shallow clones, in which case even annotate would
continue to work even if somewhat crippled by the lack of a complete
history.
Sean
^ permalink raw reply
* Re: VCS comparison table
From: Sean @ 2006-10-17 10:23 UTC (permalink / raw)
To: Aaron Bentley; +Cc: bazaar-ng, git, Johannes Schindelin, Jakub Narebski
In-Reply-To: <4534656B.7080105@utoronto.ca>
On Tue, 17 Oct 2006 01:08:59 -0400
Aaron Bentley <aaron.bentley@utoronto.ca> wrote:
> I can use the 'bzr missing' command to check whether my branch is in
> sync with a remote branch. Or I can use the 'pull' command to update my
> branch to a given revno in a remote branch.
The "bzr missing" command sounds like a handy one.
Someone on the xorg mailing list was recently lamenting that git does not
have an easy way to compare a local branch to a remote one. While this
turns out to not be a big problem in git, it might be nice to have such
a command.
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