* Re: VCS comparison table
From: Petr Baudis @ 2006-10-18 0:39 UTC (permalink / raw)
To: Aaron Bentley
Cc: Jakub Narebski, Linus Torvalds, Andreas Ericsson, bazaar-ng, git,
Matthieu Moy
In-Reply-To: <45357596.8050702@utoronto.ca>
Dear diary, on Wed, Oct 18, 2006 at 02:30:14AM CEST, I got a letter
where Aaron Bentley <aaron.bentley@utoronto.ca> said that...
> Petr Baudis wrote:
> > Another aspect of this is that Git (Linus ;) is very focused on getting
> > the history right, nice and clean (though it does not _mandate_ it and
> > you can just wildly do one commit after another; it just provides tools
> > to easily do it).
>
> Yes, rebasing is very uncommon in the bzr community. We would rather
> evaluate the complete change than walk through its history. (Bundles
> only show the changes you made, not the changes you merged from the
> mainline.)
>
> In an earlier form, bundles contained a patch for every revision, and
> people *hated* reading them. So there's definitely a cultural
> difference there.
BTW, I think what describes the Git's (kernel's) stance very nicely is
what I call the Al Viro's "homework problem":
http://lkml.org/lkml/2005/4/7/176
If I understand you right, the bzr approach is what's described as "the
dumbest kind" there? (No offense meant!)
--
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: Aaron Bentley @ 2006-10-18 0:38 UTC (permalink / raw)
To: Petr Baudis
Cc: Matthieu Moy, Sean, Jakub Narebski, Linus Torvalds, bazaar-ng,
git
In-Reply-To: <20061018002523.GJ20017@pasky.or.cz>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Petr Baudis wrote:
>> 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).
>
> So how is the light checkout actually implemented? Do you grab the
> complete new snapshot each time the remote repository is updated?
No, the lightweight checkouts store very little. They have
- - a copy of tree shape (filenames, paths, sha1 sums) from the last
commit.
- - a copy of tree shape for the current working directory
- - a map from stat values to sha-1 hashes
> Do all
> the (at least read-only, like "log" and "diff", perhaps "status")
> commands work on such a light checkout?
Yes. And if you check out from a read-write branch, all write commands,
work, too.
Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFNXeN0F+nu1YWqI0RAsdrAJ0bUj4swxm5sod9WnsbPZ9yIQ7FVQCdE4UB
8x0ddFkbr5cPISTihw96d8c=
=/XAr
-----END PGP SIGNATURE-----
^ permalink raw reply
* contrib/vim patches, replace the previous set
From: Pierre Habouzit @ 2006-10-18 0:38 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <7vodsbmlkr.fsf@assigned-by-dhcp.cox.net>
here is a brand new set of patches, the same update on the syntax
file, and an enhanced ftplugin that is very configureable.
Those two patches replace the two previous ones.
^ permalink raw reply
* Re: VCS comparison table
From: Aaron Bentley @ 2006-10-18 0:30 UTC (permalink / raw)
To: Petr Baudis
Cc: Jakub Narebski, Linus Torvalds, Andreas Ericsson, bazaar-ng, git,
Matthieu Moy
In-Reply-To: <20061018000026.GH20017@pasky.or.cz>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Petr Baudis wrote:
> How frequently are the bundles used in practice?
Many times each day. Most submission to the bzr mainline are done with
bundles.
> Another aspect of this is that Git (Linus ;) is very focused on getting
> the history right, nice and clean (though it does not _mandate_ it and
> you can just wildly do one commit after another; it just provides tools
> to easily do it).
Yes, rebasing is very uncommon in the bzr community. We would rather
evaluate the complete change than walk through its history. (Bundles
only show the changes you made, not the changes you merged from the
mainline.)
In an earlier form, bundles contained a patch for every revision, and
people *hated* reading them. So there's definitely a cultural
difference there.
Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFNXWW0F+nu1YWqI0RAuRnAJ9aZVLo4T1sfmyGC2t364UyHX+6wACff7sM
peal5rAdk/T515RGeKXkWlo=
=O61J
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: VCS comparison table
From: Petr Baudis @ 2006-10-18 0:25 UTC (permalink / raw)
To: Matthieu Moy
Cc: Sean, Jakub Narebski, Aaron Bentley, Linus Torvalds, bazaar-ng,
git
In-Reply-To: <vpqbqob5euu.fsf@ecrins.imag.fr>
Dear diary, on Tue, Oct 17, 2006 at 02:03:21PM CEST, I got a letter
where Matthieu Moy <Matthieu.Moy@imag.fr> said that...
> Sean <seanlkml@sympatico.ca> writes:
>
> > 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.
>
> Anyway, given the price of disk space today,
(In rich countries. This may still be very different in poorer
countries. E.g. some actual mplayer developer(s) from Turkey opposed
transition to a distributed version control system simply because they
have trouble affording the required additional diskspace for the full
history. SVN is already very space-hungry for them. (It stores
basically two complete checkouts in parallel.))
But the much bigger practical problem is bandwidth, plenty of people
still have internet connections where downloading several tens/hundreds
of megabytes of the complete history is quite a big thing, and the
servers ain't gonna be happy from that either, nor those paying the
bandwidth bills. ;-) And this is one of the big problems the Mozilla
guys have - having everyone download 450M worth of the full CVS-imported
history (and I'll bet no other VCS will beat that size) seems to be not
an option at all.
> 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).
So how is the light checkout actually implemented? Do you grab the
complete new snapshot each time the remote repository is updated? Do all
the (at least read-only, like "log" and "diff", perhaps "status")
commands work on such a light checkout?
This is something sorely missing in Git but if it's really only "we just
provide bandwidth-expensive way to keep your tree up-to-date and that's
all," that would not be hard at all to implement in Git too, using
git-archive --remote.
--
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: Aaron Bentley @ 2006-10-18 0:24 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Andreas Ericsson, Linus Torvalds, bazaar-ng, git
In-Reply-To: <200610180139.41647.jnareb@gmail.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jakub Narebski wrote:
> Aaron Bentley wrote:
>>> This clears things up immensely. bazaar checkout != git checkout.
>>> I still fail to see how a local copy you can't commit to is useful
>> My bzr is run from a local copy I can't commit to. To get the latest
>> changes from http://bazaar-vcs.org, I can run "bzr update ~/bzr/dev".
>> To merge the latest changes into my branch, I can run
>> "bzr merge ~/bzr/dev". It's also convenient for applying other peoples'
>> patches to.
>
> Can you do "bzr log" in 'checkout', without need to specify "~/bzr/dev"?
Sure.
Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFNXRU0F+nu1YWqI0RAptIAJ0btflKFEjF9a7Kt/qVZufK003DpACeK7Dc
leW4ICG1LbOC9DGrAd5ztlY=
=JGvL
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: VCS comparison table
From: Aaron Bentley @ 2006-10-18 0:23 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jakub Narebski, Andreas Ericsson, bazaar-ng, git
In-Reply-To: <Pine.LNX.4.64.0610171605440.3962@g5.osdl.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Linus Torvalds wrote:
>
> On Tue, 17 Oct 2006, Aaron Bentley wrote:
>>> Excuse me? What does that "throws away your local commit ordering" mean?
>> Say this is the ordering in branch A:
>>
>> a
>> |
>> b
>> |
>> c
>>
>> Say this is the ordering in branch B:
>>
>> a
>> |
>> b
>> |\
>> d c
>> |/
>> e
>>
>> When A pulls B, it gets the same ordering as B has. If B did not have e
>> and c, the pull would fail.
>
> Sure. But that doesn't throw away any local commit ordering. The original
> order (a->b->c) is still very much there.
After the pull, it's no longer the mainline ordering for the branch. c
is represented a revision that was merged into the branch, while d is
represented as a commit on the mainline of the branch.
> The fact that there was a branch
> off 'b' and there is also (a->b->d) and a merge of the two at 'e' doesn't
> take away anything from the original local commit ordering.
It means the the order that revisions are shown in log commands changes,
and the revision numbers can change.
> But that's a totally specious "record". It has no meaning in a distributed
> SCM. There is absolutely zero semantic information in it.
It records the committer, the date, the commit message, the parent
revisions.
> The fact that you _locally_ want to remember where you were is a total
> non-issue for a true distributed system. You shouldn't force everybody
> else to see your local view - since it has no relevance to them, and
> doesn't add any information.
Nobody is forced to use your local view.
> In other words, the empty merge is totally semantically empty even in the
> bazaar world. Why does it exist?
It exists because it is useful. Because it makes the behavior of bzr
merge uniform. Because in some workflows, commits show that a person
has signed off on a change.
It's not something special-- it's just another commit, like regular
commits, and merge commits. It would be harder to forbid than it is to
permit.
Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFNXQQ0F+nu1YWqI0RAnxDAJ4hbuLkEK1eBlyoEOz7NAlqLVth9gCfed4w
nfeiR2KVvN+N9zdSrC8MKcY=
=et73
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: heads-up: git-index-pack in "next" is broken
From: Nicolas Pitre @ 2006-10-18 0:20 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Sergey Vlasov, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0610171440080.3962@g5.osdl.org>
On Tue, 17 Oct 2006, Linus Torvalds wrote:
>
>
> On Tue, 17 Oct 2006, Nicolas Pitre wrote:
> >
> > Because offsets into packs are expressed as unsigned long everywhere
> > else (except in the current pack index on-disk format).
>
> Until your work, that "unsigned long" was totally just an internal thing
> that didn't actually bleed into anything else.
And would you please explain how my work changes that state of affairs?
Sorry but I don't follow you here. Still _I_ wrote that code.
> > > For some structure like this, it sounds positively wrong. Pack-files
> > > should be architecture-neutral, which means that they shouldn't depend on
> > > word-size, and they should be in some neutral byte-order.
> >
> > But they do. Please consider this code:
>
> Right. The pack-file itself. But the code that actually _generates_ it
> mixes things in alarming ways.
???
> > > In contrast, the new union introduced in "next" is just horrid. There's
> > > not even any way to know which member to use, except apparently that it
> > > expects that a SHA1 is never zero in the last 12 bytes. Which is probably
> > > true, but still - that's some ugly stuff.
> >
> > This union should be looked at just like a sortable hash pointing to a
> > base object so that deltas with the same base object can be sorted
> > together.
>
> .. and it sorts _differently_ on a big-endian vs little-endian thing,
> doesn't it?
Sure. But who cares? The sorting is just there to 1) perform binary
searches on the list of deltas based from a given object, and 2) find a
list of all deltas with the same base object.
> So now the sort order depends on endianness and/or wordsize. That just
> sounds really really wrong.
Again, who cares? That ordering doesn't influence any data produced by
the tool. It is an internal and private strategy to speed up the
_local_ _searching_ process. It could be replaced by a dumb linear
list walk if you wish and the end result i.e.
the produced pack index would be exactly the same (with a significant
slowdown notwitstanding).
So let me summarize:
- the union is a hash.
- the hash is either an offset value or a sha1 digest.
- this hash is used for fast object lookup _only_.
- it does sort differently on big vs little endian machines.
- but we don't care at all because
- it is a private algorithmic thing that doesn't "bleed" into any
_real_ data structure, and
- it doesn't have any influence on the format of the end result.
- it is only a runtime abstraction and nothing else.
- It never gets into the pack nor the pack index themselves.
Do you still have issues with that?
Nicolas
^ permalink raw reply
* Re: VCS comparison table
From: Petr Baudis @ 2006-10-18 0:14 UTC (permalink / raw)
To: Sean; +Cc: Matthieu Moy, bazaar-ng, git
In-Reply-To: <20061017110655.f7bcf3f1.seanlkml@sympatico.ca>
Dear diary, on Tue, Oct 17, 2006 at 05:06:55PM CEST, I got a letter
where Sean <seanlkml@sympatico.ca> said that...
> [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.
Greater flexibility, you can "provide this great Git addon that will
let you push over FTP" without requiring users to patch their Git
installations or wait for new Git version that might include it.
Especially important if you want a lot of users test out your
experimental feature or if it's something project-specific etc.
BTW, I'm thinking about implementing some plugin functionality for
gitweb so that you can add your own views, so that git-browser can
integrate to it more reasonably. (Currently it has completely different
UI and you have to patch gitweb in order to get the proper links at
proper places.) Sure, git-browser might get fully integrated to gitweb
later but that needs to be done sensitively so that people are not
scared by the horrible javascript blobs, etc.; currently git-browser is
very experimental, and adding it would be quite intrusive.
--
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: Jakub Narebski @ 2006-10-17 23:39 UTC (permalink / raw)
To: Aaron Bentley; +Cc: Andreas Ericsson, Linus Torvalds, bazaar-ng, git
In-Reply-To: <453532A5.6060701@utoronto.ca>
Aaron Bentley wrote:
>> This clears things up immensely. bazaar checkout != git checkout.
>> I still fail to see how a local copy you can't commit to is useful
>
> My bzr is run from a local copy I can't commit to. To get the latest
> changes from http://bazaar-vcs.org, I can run "bzr update ~/bzr/dev".
> To merge the latest changes into my branch, I can run
> "bzr merge ~/bzr/dev". It's also convenient for applying other peoples'
> patches to.
Can you do "bzr log" in 'checkout', without need to specify "~/bzr/dev"?
If not, how this differs from checking out (in git terminology) outside
default working area, and requiring providing GIT_DIR or --git-dir for
stuff?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: VCS comparison table
From: Petr Baudis @ 2006-10-17 23:33 UTC (permalink / raw)
To: Sean; +Cc: Robert Collins, Linus Torvalds, bazaar-ng, git, Jakub Narebski
In-Reply-To: <20061017191838.1c36499b.seanlkml@sympatico.ca>
Dear diary, on Wed, Oct 18, 2006 at 01:18:38AM CEST, I got a letter
where Sean <seanlkml@sympatico.ca> said that...
> 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.
BTW, I think it's fine to build a system optimized for small-scale
projects (if that's the intent), simplifying some things in favour of
mostly straight histories instead of more complicated merge situations
(although I tend to agree with Linus that if you don't behave in the way
the users are used to in 100% cases, the more frequently you behave so
the worse it comes back to bite in the rare cases you do). Just as RCS
is fine when maintaining individual files for personal usage (I still
actually occassionaly use it for few files).
--
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: Aaron Bentley @ 2006-10-17 23:33 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Andreas Ericsson, bazaar-ng, git
In-Reply-To: <200610180057.25411.jnareb@gmail.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jakub Narebski wrote:
> Aaron Bentley wrote:
> By the way, are bzr "bundles" compatibile with ordinary patch?
> git-format-patch patches are. They have additional metainfo,
> but they are patches in heart.
Yes, they are.
>> I'm not sure what you think Bazaar does. In Bazaar, a repository format
>> plugin implements the same API that a native repository format does.
>>
>> This is how bzr supports Subversion, Mercurial and Git repositories.
>
> But if I remember correctly Subversion does not remember merge points
> (merge commits), so how can you provide full Bazaar-NG compatibility
> with Subversion repository as backend? Some repository formats lack
> some features.
That's true. We support merge points in a way that's compatible with
svk. Subversion allows revisions to have arbitrary properties, and svk
sets a property to indicate merges.
> In git we have import tools (most of them capable of incremental import),
> a few exchange tools like git-cvsexportcommit, git-cvsserver, and
> Tailor-like git-svn.
Bzr's subversion support is quite nice. You can commit, merge, run
history viewers.
There are screenshots and stuff here:
http://bazaar-vcs.org/BzrForeignBranches/Subversion
Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFNWhc0F+nu1YWqI0RAkH7AJ4/S648shA8IKg42xcGWdjnjmA+PgCdEDhg
Af/mcG+XTy3Tsb9b1x3rYcg=
=xnjF
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: VCS comparison table
From: Linus Torvalds @ 2006-10-17 23:50 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Aaron Bentley, Andreas Ericsson, bazaar-ng, git
In-Reply-To: <200610180124.28048.jnareb@gmail.com>
On Wed, 18 Oct 2006, Jakub Narebski wrote:
>
> Merge commit in fast-forward case is only marking "here we did a pull"
> (here we downloaded from other repository). It is just a marker which
> place is in reflog, not in history. It is only cluttering history.
For non-git people (and maybe even git people who didn't follow some of
the "reflog" work):
- git does actually have "local view" support, but it is very much
_defined_ to be local. It does not pollute any history as seen by
anybody else. It's called "reflog" (where "ref" is just the git name
for any reference into a tree, and the "log" part is hopefully obvious)
So each git repository can have (if you enable it) a full log of all the
changes to each branch. But it's not in the core git datastructures that
get replicated - because the local view of how the branches have changed
really _is_ just a local view. It's just a local log to each repository
(actually, one per branch).
It's what allows a git person to say
git diff "master@{5.hours.ago}"
because while "5 hours ago" is _not_ well-defined in a distributed
environment (five hours ago for _whom_?) it's perfectly well-defined in a
purely _local_ sense of one particular branch.
So there's no need for a fakey "merge" that isn't a real merge and that
doesn't make sense for anybody else because it doesn't actually add any
real knowledge about the _history_ of the tree (only about a single
repository). If you want to see how the history of a particular repository
has evolved, you can just look at the reflog (although admittedly, common
tools like "gitk" don't even show it - the data is there if they would
want to, but the most common usage is the above kind of "show me what
happened in the last five hours in my current branch".
Linus
^ permalink raw reply
* Re: VCS comparison table
From: Petr Baudis @ 2006-10-18 0:00 UTC (permalink / raw)
To: Jakub Narebski
Cc: Matthieu Moy, Linus Torvalds, Andreas Ericsson, bazaar-ng, git
In-Reply-To: <200610171641.04455.jnareb@gmail.com>
Dear diary, on Tue, Oct 17, 2006 at 04:41:02PM CEST, I got a letter
where Jakub Narebski <jnareb@gmail.com> said that...
> "Bundle" equivalent, although binary in nature, would be thin pack.
It should be noted that there's no user interface for sending/receiving
that and I suspect no reasonably usable user interface for creating it.
How frequently are the bundles used in practice?
It's a cultural difference, I suspect. Git comes from an environment
based on intensive exchanges of patches and patch series and an
environment not mandating developers to use any tool besides diff/patch,
so Git is very focused at good support for applying patches and there
simply has been no big conscious demand for bundles support given this.
Another aspect of this is that Git (Linus ;) is very focused on getting
the history right, nice and clean (though it does not _mandate_ it and
you can just wildly do one commit after another; it just provides tools
to easily do it). This means that the downstream maintainers have to
rebase patches, possibly reorder them, and update the changesets with
bugfixes instead of stacking the bugfixes upon them in separate changes
- then Linus merges the patches and only at that point they are "etched"
forever. This means that the history will contain neatly laid out way
of how $FEATURE was achieved, but of course also more work for
downstream maintainers.
--
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: Jakub Narebski @ 2006-10-17 23:35 UTC (permalink / raw)
To: Aaron Bentley; +Cc: Andreas Ericsson, bazaar-ng, git
In-Reply-To: <200610172301.27101.jnareb@gmail.com>
Dnia wtorek 17. października 2006 23:01, Jakub Narebski napisał:
> Aaron Bentley wrote:
> > Andreas Ericsson wrote:
> >> Aaron Bentley wrote:
> >>> Ah. Bazaar uses negative numbers to refer to <n>th parents, and
> >>> positive numbers to refer to the number of commits that have been made
> >>> since the branch was initialized.
> >>>
> >>
> >> What do you do once a branch has been thrown away, or has had 20 other
> >> branches merged into it? Does the offset-number change for the revision
> >> then, or do you track branch-points explicitly?
> >
> > We always track the number of parents since the initial commit in the
> > project. Sorry, I don't think I said that clearly before.
>
> While this I think is quite reliable (there was idea to store "generation
> number" with each commit, e.g. using not implemented "note" header, or
> commit-id to generation number "database" as a better heuristic than
> timestamp for revision ordering in git-rev-list output), and probably
> independent on repository (it is global property of commit history,
> and commit history is included in sha1 of its parents), numbering branching
> points is unreliable, as is relying on branch names.
Take for example the following situation:
In the following we had
A--B--C--D - repository A
we have cloned repository
A--B--C--D - repository B
Then, in parallel/independently we branched off C in repository A, and
branched off B in repository B
-x
/
A--B--C--D - repository A
A--B--C--D - repository B
\
-y
If we then fetch changes from B into A, and fetch changes from A into B,
we will have that in repository A branch off C appeared earlier, and
in repository B branch off C appeared later.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: VCS comparison table
From: Petr Baudis @ 2006-10-17 23:28 UTC (permalink / raw)
To: Aaron Bentley
Cc: Linus Torvalds, Andreas Ericsson, bazaar-ng, git, Jakub Narebski
In-Reply-To: <453532A5.6060701@utoronto.ca>
Dear diary, on Tue, Oct 17, 2006 at 09:44:37PM CEST, I got a letter
where Aaron Bentley <aaron.bentley@utoronto.ca> said that...
> Andreas Ericsson wrote:
> >> In our terminology, if it can diverge from the original, it's a branch,
> >> not a checkout.
> >>
> >
> > This clears things up immensely. bazaar checkout != git checkout.
> > I still fail to see how a local copy you can't commit to is useful
>
> My bzr is run from a local copy I can't commit to. To get the latest
> changes from http://bazaar-vcs.org, I can run "bzr update ~/bzr/dev".
> To merge the latest changes into my branch, I can run
> "bzr merge ~/bzr/dev". It's also convenient for applying other peoples'
> patches to.
The question is, why is it useful to enforce the "no commit" rule? Git
can work exactly the same, it just doesn't _enforce_ the rule. And is
the capability of enforcing such a rule important enough to warrant its
own column in the comparison table?
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-17 23:24 UTC (permalink / raw)
To: Aaron Bentley; +Cc: Linus Torvalds, Andreas Ericsson, bazaar-ng, git
In-Reply-To: <45355EEE.3060105@utoronto.ca>
Aaron Bentley wrote:
[...]
>> So generating an extra "merge" commit would be actively wrong, and adds
>> "history" that is not history at all.
>
> It's not a tree change, but it records the fact that one branch merged
> the other.
>
>> It also means that if people merge back and forth from each other, you get
>> into an endless loop of useless merge commits.
>
> You can pull if you don't want that. We haven't found that people are
> very fussed about it.
>
>> There's no reason _ever_ to not just fast-forward if one repository is a
>> strict superset of the other.
>
> Maybe not in Git.
Think what the existence of merge commit is for. It is a place where
we can record how we resolved conflicts. It means: we _merged_ (joined)
two (or more: does bzr support octopus merge?) lines of development.
Merge commit in fast-forward case is only marking "here we did a pull"
(here we downloaded from other repository). It is just a marker which
place is in reflog, not in history. It is only cluttering history.
Besides one of canonical workflows used and encouraged by git is:
* repository A stores does it's own work on branch 'master',
and fetches changes from 'master' branch of repository B
into branch 'origin'. "git pull origin" when on branch 'master'
fetches changes from 'master' branch of repository B (requiring
usually that it fast-forwards) into branch 'origin', then
merges branch 'origin' into branch 'master', automatically
creating merge commit message.
* repository B does it's own work on branch 'master',
and fetches changes from 'master' branch of repository A
into [tracking] branch 'origin'. (...)
Instead of pull/fetch, we could use push.
--
Jakub Narebski
Poland
^ 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: Linus Torvalds @ 2006-10-17 23:16 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Andreas Ericsson, bazaar-ng, git
In-Reply-To: <200610180057.25411.jnareb@gmail.com>
On Wed, 18 Oct 2006, Jakub Narebski wrote:
>
> Perhaps it would be nice to have "bundles" in git too. As of now
> we can save arbitrary part of history in a pack, but it is binary
> not textual representation.
>
> Some of git workflow stems from old, pre-SCM Linux kernel workflow
> of sending _patches_ via email.
Actually, the reason to _not_ have bundles very much stems from the fact
that BK did have bundles, and they were pretty horrid.
It would be easy to send the exact same data as the native git protocol
sends over ssh (or the git port) as an email encoding. We did that a few
times with BK (there it's called "bk send" and "bk receive" to pack and
unpack those things), and after doing it about five times, I absolutely
refused to ever do it again. There's just no point, except to make your
mailbox grow without bounds, and it was really annoying.
So sending things as patches is just a lot more convenient if you want
emails. And if you want to sync two repos directly, I think we've gotten
sufficiently past the old UUCP days when you want to use email as a
packetization medium.
That said, "bundles" certainly wouldn't be _hard_ to do. And as long as
nobody tries to send _me_ any of them, I won't mind ;)
Linus
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-17 23:11 UTC (permalink / raw)
To: Sean; +Cc: Andreas Ericsson, bazaar-ng, git
In-Reply-To: <BAYC1-PASMTP01369CD694D75CB61ACCC7AE0E0@CEZ.ICE>
/me too post ;-)
Sean wrote:
> 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.
git-core, git-email, git-arch, git-cvs, git-svn, gitk
(and git-debuginfo).
gitk and gitweb were developed in its own repositories, but some time
ago got incorporated into git repository. We have contrib/ area.
QGit, Cogito, StGit are developed separately.
> > 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.
Thanks to many low lewel (plumbing in git-speak) commands it is very
easy to prototype (write actually) new command in language suitable
for fast prototyping, i.e. shell or Perl (or Python, too). Then if it is
performance critical, or if it get troublesome to manage shell script
version, it gets rewritten in C as builtin command.
^ permalink raw reply
* Re: VCS comparison table
From: Linus Torvalds @ 2006-10-17 23:09 UTC (permalink / raw)
To: Aaron Bentley; +Cc: Jakub Narebski, Andreas Ericsson, bazaar-ng, git
In-Reply-To: <45355EEE.3060105@utoronto.ca>
On Tue, 17 Oct 2006, Aaron Bentley wrote:
> >
> > Excuse me? What does that "throws away your local commit ordering" mean?
>
> Say this is the ordering in branch A:
>
> a
> |
> b
> |
> c
>
> Say this is the ordering in branch B:
>
> a
> |
> b
> |\
> d c
> |/
> e
>
> When A pulls B, it gets the same ordering as B has. If B did not have e
> and c, the pull would fail.
Sure. But that doesn't throw away any local commit ordering. The original
order (a->b->c) is still very much there. The fact that there was a branch
off 'b' and there is also (a->b->d) and a merge of the two at 'e' doesn't
take away anything from the original local commit ordering.
> > So generating an extra "merge" commit would be actively wrong, and adds
> > "history" that is not history at all.
>
> It's not a tree change, but it records the fact that one branch merged
> the other.
But that's a totally specious "record". It has no meaning in a distributed
SCM. There is absolutely zero semantic information in it.
The fact that you _locally_ want to remember where you were is a total
non-issue for a true distributed system. You shouldn't force everybody
else to see your local view - since it has no relevance to them, and
doesn't add any information.
> Maybe not in Git.
I don't think there is any in bzr either. Can you explain?
In other words, the empty merge is totally semantically empty even in the
bazaar world. Why does it exist?
Linus
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-17 22:59 UTC (permalink / raw)
To: Aaron Bentley; +Cc: Andreas Ericsson, bazaar-ng, git
In-Reply-To: <200610180057.25411.jnareb@gmail.com>
Jakub Narebski wrote:
> Git has read-only access over git:// protocol (served by git-daemon on
> port 9418), read-write access over git+ssh:// protocol (you can limit
> exposition using git-shell), read-only access via HTTP, HTTPS, FTP "dumb"
> protocols, read-write access via WebDAV "dumb" protocol.
And deprecated read-only (I think), deprecated, suggested to use only
for cloning, rsync:// "dumb" protocol.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-17 22:57 UTC (permalink / raw)
To: Aaron Bentley; +Cc: Andreas Ericsson, bazaar-ng, git
In-Reply-To: <4535590C.4000004@utoronto.ca>
Aaron Bentley wrote:
> Jakub Narebski wrote:
>> Aaron Bentley wrote:
>
>>> What is the bad side of using merge in this situation?
>>
>> We want linear history, not polluted by merges. For example you cannot
>> send merge commit via email.
>
> Oh. Bazaar supports sending merge commits by email.
>
>> Another problem is that you want to
>> send _series_ of patches, string of commits (revisions), creating feature
>> part by part, with clean history; with merge you get _final result_
>> which will apply cleanly, with rebase you would get that series
>> of patches will apply cleanly.
>
> Yes, that's something that I'd heard about the kernel development
> methodology-- that a series of small patches is preferred to one patch
> that makes the whole change.
>
> That's not the way we operate. We like to review all the changes at
> once. But because bundles are applied with a 'merge' command, not a
> 'patch' command, an old bundle will tend to apply more cleanly than an
> old patch would.
Perhaps it would be nice to have "bundles" in git too. As of now
we can save arbitrary part of history in a pack, but it is binary
not textual representation.
Some of git workflow stems from old, pre-SCM Linux kernel workflow
of sending _patches_ via email.
By the way, are bzr "bundles" compatibile with ordinary patch?
git-format-patch patches are. They have additional metainfo,
but they are patches in heart.
>>> and more. Because Python supports monkey-patching, a plugin can change
>>> absolutely anything.
>>
>> Which is _not_ a good idea. Git is created in such way, that the repository
>> is abstracted away (introduction of pack format, and improving pack format
>> can and was done "behind the scenes", not changing any porcelanish (user)
>> commands), but we don't want any chage that would change this abstraction.
>
> I'm not sure what you think Bazaar does. In Bazaar, a repository format
> plugin implements the same API that a native repository format does.
>
> This is how bzr supports Subversion, Mercurial and Git repositories.
But if I remember correctly Subversion does not remember merge points
(merge commits), so how can you provide full Bazaar-NG compatibility
with Subversion repository as backend? Some repository formats lack
some features. Besides, as I said repository database and stuff is
quite well abstracted away.
In git we have import tools (most of them capable of incremental import),
a few exchange tools like git-cvsexportcommit, git-cvsserver, and
Tailor-like git-svn.
>> Changing repository format is not a good idea for "dumb" protocols;
>
> I can't parse this. Repository formats and protocols are different
> things, right?
"Dumb" protocols in git are protocols for which server provides access
to contents git repository plus some additional info (usually generated
using hooks). The client (be it git-fetch or git-push) discovers which
files to download or what to upload, but it only can download repository
"as is". So if server repository was created with repository format plugin,
and client doesn't have said plugin, you are out of luck.
>> native protocol is quite extensible
>
> I was meaning dumb protocol extension. I can't say how extensible the
> bzr native protocol is.
Native git protocol (git:// and git+ssh://) does feature discovery, then
negotiates what contents has to be send, and finally tries to send minimal
number of objects.
>> Adding
>> cURL based FTP read-only support to existing HTTP support was a matter
>> of few lines, if I remember correctly.
>
> We support read and write over native, ftp and WebDAV (a plugin). We
> also have readonly http support.
Git has read-only access over git:// protocol (served by git-daemon on
port 9418), read-write access over git+ssh:// protocol (you can limit
exposition using git-shell), read-only access via HTTP, HTTPS, FTP "dumb"
protocols, read-write access via WebDAV "dumb" protocol.
Git is open-source, we don't need plugins ;-)
--
Jakub Narebski
ShadeHawk on #git
Poland
^ permalink raw reply
* Re: VCS comparison table
From: Sean @ 2006-10-17 22:56 UTC (permalink / raw)
To: Aaron Bentley; +Cc: Jakub Narebski, Andreas Ericsson, bazaar-ng, git
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: Aaron Bentley @ 2006-10-17 22:53 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jakub Narebski, Andreas Ericsson, bazaar-ng, git
In-Reply-To: <Pine.LNX.4.64.0610171448150.3962@g5.osdl.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Linus Torvalds wrote:
>
> On Tue, 17 Oct 2006, Aaron Bentley wrote:
>>>> Interesting. We don't do 'fast-forward' in that case.
>>> Fast-forward is a really good idea. Perhaps you could implement it,
>>> if it is not hidden under different name?
>> We support it as 'pull', but merge doesn't do it automatically, because
>> we'd rather have merge behave the same all the time, and because 'pull'
>> throws away your local commit ordering.
>
> Excuse me? What does that "throws away your local commit ordering" mean?
Say this is the ordering in branch A:
a
|
b
|
c
Say this is the ordering in branch B:
a
|
b
|\
d c
|/
e
When A pulls B, it gets the same ordering as B has. If B did not have e
and c, the pull would fail.
> So generating an extra "merge" commit would be actively wrong, and adds
> "history" that is not history at all.
It's not a tree change, but it records the fact that one branch merged
the other.
> It also means that if people merge back and forth from each other, you get
> into an endless loop of useless merge commits.
You can pull if you don't want that. We haven't found that people are
very fussed about it.
> There's no reason _ever_ to not just fast-forward if one repository is a
> strict superset of the other.
Maybe not in Git.
Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFNV7u0F+nu1YWqI0RAhGtAJwOlWpl088pbl63EHyF04qQCYlXBgCfW0Tm
cfXuE0vqeWelfFbpzffiCNI=
=McQ2
-----END PGP SIGNATURE-----
^ 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