* Re: VCS comparison table
From: Matthieu Moy @ 2006-10-17 14:19 UTC (permalink / raw)
To: bazaar-ng, git
In-Reply-To: <BAYC1-PASMTP10F617306F1477E66FA441AE0E0@CEZ.ICE>
Sean <seanlkml@sympatico.ca> writes:
> Ah, okay. Well Git can definitely manage this. Just means you have to
> rebase any local changes before pushing. This will keep the history
> linear and make sure that no merges are needed in the case you were asking
> about.
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 ;-).
> So far, it sounds to me like bazaar and git are more alike than they are
> different. Each have a few commands the other doesn't but all in all
> they sound very similar.
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)
> But i'm a Git fanboy so I aint switching now ;o)
Probably not going to switch either, but that might happen.
--
Matthieu
^ permalink raw reply
* Re: VCS comparison table
From: Olivier Galibert @ 2006-10-17 14:19 UTC (permalink / raw)
To: Matthieu Moy
Cc: Jakub Narebski, Aaron Bentley, Linus Torvalds, bazaar-ng, git
In-Reply-To: <vpqejt76vgz.fsf@ecrins.imag.fr>
On Tue, Oct 17, 2006 at 01:19:08PM +0200, Matthieu Moy wrote:
> 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.
You're not telling us bzr still follows the utterly stupid
update-before-commit model, right? Right?
OG.
^ permalink raw reply
* Re: VCS comparison table
From: Matthieu Moy @ 2006-10-17 14:08 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Linus Torvalds, Andreas Ericsson, bazaar-ng, git
In-Reply-To: <200610171555.56778.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> While email can be used to exchange patches (git-format-patch to
> generate patches, git-send-mail to send patches if you don't want to
> use ordinary email client, git-am to apply patches) it cannot be used
> to exchange all information (one cannot send for example tags, or merge
> commits).
In bzr, the "bundle" appears like a patch, but it actually contain the
same information as the revision(s) it contains (I believe this
applies to hg and Darcs too). A bundle can be used almost like a
branch. That's a key point, since revision identity is not based on
content's hash, so applying a patch is very different from merging a
bundle.
> It is very usefull tool to have for "accidental" developer.
That's the key point, but patch review for non-accidental developpers
is also good :-).
> BTW. git can provide binary patch for binary files (e.g. adding favicon
> for gitweb in git.git).
Bazaar's bundle use base64 encoding for binaries. I don't think that's
efficient binary diff (xdelta-like) though. Aaron has been fighting
quite a lot with MUA and MTA mixing up the patches (line ending in
particular) ...
^ permalink raw reply
* Re: VCS comparison table
From: Aaron Bentley @ 2006-10-17 14:05 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Linus Torvalds, Jakub Narebski, bazaar-ng, git
In-Reply-To: <45348B5E.8000404@op5.se>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Andreas Ericsson wrote:
> Aaron Bentley wrote:
>> When two people have copies of the same revision, it's usually because
>> they are each pulling from a common branch, and so the revision in that
>> branch can be named. Bazaar does use unique ids internally, but it's
>> extremely rare that the user needs to use them.
>>
>
> Well, if two people have the same revision in git, you *know* they have
> pulled from each other
No, you don't. They may have each pulled from a different repository.
Take revision 00aabbcc, created by Linus. Linus has it because he
committed it. I have it because I pulled Linus' repository. You have
it because Andrew Morton pulled Linus' repository, and you pulled Andrew
Morton's repository.
>> But tags have local meaning only, unless someone has access to your
>> repository, right?
>>
>
> I imagine the bazaar-names with url+number only has local meaning unless
> someone has access to your repository too.
Yes. That phrasing was from Linus' description of revnos.
> One of the great benefits of
> git is that each revision is *always exactly the same* no matter in
> which repository it appears. This includes file-content, filesystem
> layout and, last but also most important, history.
In Bazaar, a revision id always refers to the same logical entity, but
it may be stored in different formats in different repositories.
>> - - you can publish a repository without publishing its working tree,
>> possibly using standard mirroring tools like rsync.
>>
>
> Can't all scm's do this?
With most SCMs that store the repository in the root of the tree,
disentangling the tree and repository requires care. OTOH, this is just
as easy with Arch, CVS and SVN as it is with Bazaar.
>> - - 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).
>>
>
> Check. Well, actually, you just clone it as usual but with the --bare
> argument and it won't write out the working tree files.
No, I *want* the working tree files. I run bzr from a checkout of bzr.dev.
>> You can operate that way in bzr too, but I find it nicer to have one
>> checkout for each active branch, plus a checkout of bzr.dev. Our switch
>> command also rewrites only the changed part of the working tree.
>>
>
> Works in git as well, but each "checkout" (actually, locally referenced
> repository clone) gets a separate branch/tag namespace.
In our terminology, if it can diverge from the original, it's a branch,
not a checkout.
Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFFNOM10F+nu1YWqI0RAvNUAJwN/QviOs+sUuN9ep4Otyrgax9SmwCfSH7t
XdxOxo7smshNlzU3qoxq6Nw=
=nxsM
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [RFC/PATCH] git-fetch: Use already fetched branch with the --local flag.
From: Santi Béjar @ 2006-10-17 14:03 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <87ac3w8jl1.fsf@gmail.com>
Please, add this:
diff --git a/git-parse-remote.sh b/git-parse-remote.sh
index 617d022..a792323 100755
--- a/git-parse-remote.sh
+++ b/git-parse-remote.sh
@@ -260,7 +260,7 @@ get_ref_for_remote_branch (){
remotes)
ref=$(sed -ne '/^Pull: */{
s///p
- }' "$GIT_DIR/remotes/$1" | grep "$2:")
+ }' "$GIT_DIR/remotes/$1" | grep "^$2:")
expr "z$ref" : 'z[^:]*:\(.*\)'
;;
*)
^ permalink raw reply related
* Re: VCS comparison table
From: Sean @ 2006-10-17 14:01 UTC (permalink / raw)
To: Matthieu Moy
Cc: Jakub Narebski, Aaron Bentley, Linus Torvalds, bazaar-ng, git
In-Reply-To: <vpqejt73vln.fsf@ecrins.imag.fr>
On Tue, 17 Oct 2006 15:44:36 +0200
Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
> > How does bzr avoid a merge when you're pushing changes from 3
> > separate machines?
>
> Err, the same way people have been doing for years ;-). If you don't
> have local commits, "bzr update" will work in the same way as "cvs
> update", it keeps your local changes, without recording history. Like
> "git pull" does if you have uncommited changes I think.
Ah, okay. Well Git can definitely manage this. Just means you have to
rebase any local changes before pushing. This will keep the history
linear and make sure that no merges are needed in the case you were asking
about.
So far, it sounds to me like bazaar and git are more alike than they are
different. Each have a few commands the other doesn't but all in all
they sound very similar. But i'm a Git fanboy so I aint switching
now ;o)
Sean
^ permalink raw reply
* Re: VCS comparison table
From: Andreas Ericsson @ 2006-10-17 14:01 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Linus Torvalds, bazaar-ng, git, Jakub Narebski
In-Reply-To: <vpqlknf3wdz.fsf@ecrins.imag.fr>
Matthieu Moy wrote:
> Andreas Ericsson <ae@op5.se> writes:
>
>> What about
>>
>> 3) getting the repo with all the history while still not having to be
>> online to actually commit to *your* copy of the repo. When you later
>> get online, you can send all your changes in a big hunk, or let bazaar
>> email them to the maintainer as patches, or...
>
> Well, the discussion was about checkouts, so I was talking about
> checkouts ;-).
>
Differences in nomenclature is really messing this discussion up. In
git, a "checkout" is the act of pulling objects from the object database
into the working tree. I.e., the act of "clothing" a "bare" repository.
>> but the ability to commit to whatever branch I like in my local repo
>> and then just send the diffs by email or please-pull requests to
>> upstream authors is what makes git work so well for me.
>
> Sure. Once again, Bazaar does it this way too. There's an _additional
> feature_ called checkout which allows you to work in another way,
> though. As most "feature", it's not useful to everybody.
>
Now I'm really confused. Does bazaar have both "clone" (git-style
fetching a full repo and all the branches) and "checkout" (cvs-style
fetching only the working tree)?
>
>> Side-note 2: Three really great things that have made work a lot
>> easier and more enjoyable since we changed from cvs to git and that
>> aren't mentioned in the comparison table:
>
> Sure. And regarding this, hopufully, most modern VCS go in the same
> direction.
>
>> * Dependency/history graph display tools á la qgit/gitk
>
> http://bazaar-vcs.org/bzr-gtk
> http://samba.org/~jelmer/bzr/bzrk.png
>
>> * Bisection tool for finding bug introduction revisions.
>
> This took time to come in bzr, but that's the bisect plugin:
>
> http://bazaar-vcs.org/PluginRegistry
>
>> * Tools for sending commits as emails.
>
> (Surprisingly, I had added this in the table, but has been removed for
> some obscure reasons)
>
Merge-conflict with the webpage? ;-)
However, I know that bazaar has many of these features. I was merely
commenting on the absence of these killer-features in the table. It
might help people pick the right scm for their project, which is always
a Good Thing(tm).
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-17 13:55 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Linus Torvalds, Andreas Ericsson, bazaar-ng, git
In-Reply-To: <vpqlknf3wdz.fsf@ecrins.imag.fr>
Matthieu Moy wrote:
>> Side-note 2: Three really great things that have made work a lot
>> easier and more enjoyable since we changed from cvs to git and that
>> aren't mentioned in the comparison table:
>
> Sure. And regarding this, hopufully, most modern VCS go in the same
> direction.
>
> > * Dependency/history graph display tools á la qgit/gitk
>
> http://bazaar-vcs.org/bzr-gtk
> http://samba.org/~jelmer/bzr/bzrk.png
Hmmm... most of the tools look similar. Git has gitk (Tcl/Tk, now in
git.git repository), QGit (Qt), GitView (GTK+, in contrib/),
git-browser (JavaScript, uses High Performance JavaScript Graphics
Library by Walter Zorn, http://www.walterzorn.com, for graphics).
Tig (Text-mode Interface for Git, ncurses) also in it's git version has
a kind of history graph using ascii-art.
That is very important tool to have for any SCM which allows (and
encourages) nonlinear history development.
>> * Bisection tool for finding bug introduction revisions.
>
> This took time to come in bzr, but that's the bisect plugin:
>
> http://bazaar-vcs.org/PluginRegistry
Hmmm... I winder which SCM had it first.
>> * Tools for sending commits as emails.
>
> (Surprisingly, I had added this in the table, but has been removed for
> some obscure reasons)
While email can be used to exchange patches (git-format-patch to
generate patches, git-send-mail to send patches if you don't want to
use ordinary email client, git-am to apply patches) it cannot be used
to exchange all information (one cannot send for example tags, or merge
commits).
It is very usefull tool to have for "accidental" developer. You don't
have to have constant on-line presence in the form of web server or git
server somewhere for sending pull requests (although http://repo.or.cz
public git repo hosting can help with that), you don't have to have
access (ssh perhaps limited, or WebDAV one) to do push to somebody else
repository, you can just send email to some mailing list.
BTW. git can provide binary patch for binary files (e.g. adding favicon
for gitweb in git.git).
Other often and not-so-often used tools include:
* git-rerere - Reuse recorded resolve (of merge conflicts)
* reflog - Records where was given branch at given time (no UI yet)
* git-diff -S'text' aka. pickaxe - find commits which added or removed
given 'text'; and other revision limiters
^ permalink raw reply
* Re: VCS comparison table
From: Matthieu Moy @ 2006-10-17 13:44 UTC (permalink / raw)
To: Sean; +Cc: Linus Torvalds, bazaar-ng, git, Jakub Narebski
In-Reply-To: <BAYC1-PASMTP10E107E5EB0F7E69167F41AE0E0@CEZ.ICE>
Sean <seanlkml@sympatico.ca> writes:
>> 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?
The workflow is different.
If I commit broken changes on a repository shared by multiple
developers, they'll insult me, and they'll be right. While I find
nothing wrong in commiting broken changes to my ${HOME}/etc/ when
leaving the office, and fix it from home.
> How does bzr avoid a merge when you're pushing changes from 3
> separate machines?
Err, the same way people have been doing for years ;-). If you don't
have local commits, "bzr update" will work in the same way as "cvs
update", it keeps your local changes, without recording history. Like
"git pull" does if you have uncommited changes I think.
^ permalink raw reply
* Re: VCS comparison table
From: Aaron Bentley @ 2006-10-17 13:48 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Sean, bazaar-ng, git
In-Reply-To: <Pine.LNX.4.63.0610171229160.14200@wbgn013.biozentrum.uni-wuerzburg.de>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Johannes Schindelin wrote:
> On Tue, 17 Oct 2006, Sean wrote:
>>Aaron Bentley <aaron.bentley@utoronto.ca> wrote:
>>>- - you can have working trees on local systems while having the
>>> repository on a remote system. This makes it easy to work on one
>>> logical branch from multiple locations, without getting out of sync.
>>
>>That is a very nice feature. Git would be improved if it could
>>support that mode of operation as well.
>
>
> It would also make things slow as hell. How do you deal with something
> like annotate in such a setup?
For the particular case of annotate, bzr is designed to store
annotations at commit time. So annotate should require remote access to
a small amount of data from two files-- not a great cost.
But our default form of checkout contains a local copy of all history
data, so that readonly operations happen at local speed.
Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFFNN8Y0F+nu1YWqI0RAqXtAJ4qKGQ5ZwlMF795kz3udeuRTcRy6wCghr53
tjw9cNVxzrQ0XSUO2v52ZIo=
=W6q7
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: VCS comparison table
From: Matthieu Moy @ 2006-10-17 13:33 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Linus Torvalds, bazaar-ng, git
In-Reply-To: <200610171345.32313.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> But git has reverse check: it forbids (unless forced by user) to fetch
> into branch which has local changes (does not fast-forward).
Same as bzr then I believe. "bzr pull" will suggest you to use "merge"
in this situation, unless you say "pull --overwrite".
>> 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.
>
> Git is designed for distributed workflows, not for centralized one.
> All repositories are created equal :-)
Note that "bound branches" and "other branches" in bzr are not so
different. The "master" (the one you make a checkout of) doesn't have
to know it has checkouts, and the "checkout" just has one file
pointing to the "master", and you can switch from one flow to the
other with "bzr bind/unbind".
So, in Bazaar, all repositories are /almost/ created equal ;-).
--
Matthieu
^ permalink raw reply
* Re: VCS comparison table
From: Matthieu Moy @ 2006-10-17 13:27 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Linus Torvalds, bazaar-ng, git, Jakub Narebski
In-Reply-To: <4534C5CF.3000508@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> What about
>
> 3) getting the repo with all the history while still not having to be
> online to actually commit to *your* copy of the repo. When you later
> get online, you can send all your changes in a big hunk, or let bazaar
> email them to the maintainer as patches, or...
Well, the discussion was about checkouts, so I was talking about
checkouts ;-).
What you mention is the default behavior of Bazaar when you use
"bzr branch" or "bzr get". BTW, it's also possible to do this with a
heavy checkout, that's "commit --local".
> It appears we have different ideas of what's handy. Perhaps it's just
> a difference in workflow, or lack of "email-commits-as-patches" tools
> in bazaar,
You have "bzr bundle" in Bazaar, and there was work to have it
actually send the email ( http://bazaar-vcs.org/SubmitByMail ), but I
don't think it's finished yet.
And yes, this is a great feature, the first time I used it was with
Darcs, and I was impressed how easy I could submit a patch without any
setup and with a 5-lines tutorial. Even wiki seems complex after
that ;-).
> but the ability to commit to whatever branch I like in my local repo
> and then just send the diffs by email or please-pull requests to
> upstream authors is what makes git work so well for me.
Sure. Once again, Bazaar does it this way too. There's an _additional
feature_ called checkout which allows you to work in another way,
though. As most "feature", it's not useful to everybody.
And I repeat that I'm in no way arguing against the git model :-).
> Side-note 2: Three really great things that have made work a lot
> easier and more enjoyable since we changed from cvs to git and that
> aren't mentioned in the comparison table:
Sure. And regarding this, hopufully, most modern VCS go in the same
direction.
> * Dependency/history graph display tools á la qgit/gitk
http://bazaar-vcs.org/bzr-gtk
http://samba.org/~jelmer/bzr/bzrk.png
> * Bisection tool for finding bug introduction revisions.
This took time to come in bzr, but that's the bisect plugin:
http://bazaar-vcs.org/PluginRegistry
> * Tools for sending commits as emails.
(Surprisingly, I had added this in the table, but has been removed for
some obscure reasons)
--
Matthieu
^ permalink raw reply
* Re: VCS comparison table
From: Jon Smirl @ 2006-10-17 12:59 UTC (permalink / raw)
To: Sam Vilain; +Cc: Petr Baudis, Jakub Narebski, git
In-Reply-To: <45345362.8040902@vilain.net>
On 10/16/06, Sam Vilain <sam@vilain.net> wrote:
> Jon Smirl wrote:
> > cvsps works ok on small amounts of data, but it can't handle the full
> > Mozilla repo. The current idea is to convert the full repo with
> > cvs2git and build the ini file needed by cvsps to support incremental
> > imports. After that use cvsps.
> >
>
> Looking through the client.mk used to check out the sub-portions of the
> CVS repository, I have to ask;
>
> Why are you trying to import this big collection of projects into a
> single git repository?
All of Mozilla is in a single CVS repo, client.mk is checking out
directories from the mozilla project. This is how it has been
historically for over ten years. It also allows commits that
simultaneously go to all subcomponents when interfaces are changed.
Even if it was split into different git repos you still need to
download about 70% of them to build the browser.
I've been trying to simply translate the existing repo without
changing it's structure in any way. Changing structure is going to
require a lot of buy-in from all of the developers.
>
> View git's repositories not as a container for an entire community's
> code base, but more as object partitions. Currently you are quite happy
> to use per-file version control partitions inherent to CVS. Now you are
> looking at removing all of the partitions completely and hoping to end
> up with something managable. That it has been possible at all to fit it
> into the space less than the size of a CD is staggering, but surely a
> piecemeal approach would be a pragmatic solution to this problem.
>
> Sam.
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: VCS comparison table
From: Sean @ 2006-10-17 12:57 UTC (permalink / raw)
To: Matthieu Moy
Cc: Jakub Narebski, Aaron Bentley, Linus Torvalds, bazaar-ng, git
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: Jakub Narebski @ 2006-10-17 12:56 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Sean, Aaron Bentley, Linus Torvalds, bazaar-ng, git
In-Reply-To: <vpqbqob5euu.fsf@ecrins.imag.fr>
Matthieu Moy wrote:
>> 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.
>
> 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/).
Fast-forward doesn't result in merge.
If you have
1---2---3 <branch 1, or branch locally>
\
4---5 <branch 2, or branch at remote>
then this is fast-forward case. After pull (or push) you have
1---2---3---4---5 <branch 1>
without merge.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: VCS comparison table
From: Matthieu Moy @ 2006-10-17 12:03 UTC (permalink / raw)
To: Sean; +Cc: Jakub Narebski, Aaron Bentley, Linus Torvalds, bazaar-ng, git
In-Reply-To: <BAYC1-PASMTP02ADC5BEF688E61583283CAE0E0@CEZ.ICE>
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, 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).
>> 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.
I lied in my above description ;-).
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).
>> 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.
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.
>> 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.
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/).
But don't get me wrong, I also prefer the decentralized way in most
case. And I'm happy that bzr and git work like this by default. Just
that at least *I* have cases where a centralized approach suits me
better, and then I'm happy with that particular feature of bzr.
--
Matthieu
^ permalink raw reply
* Re: VCS comparison table
From: Sean @ 2006-10-17 12:07 UTC (permalink / raw)
To: Jakub Narebski
Cc: Matthieu Moy, Aaron Bentley, Linus Torvalds, bazaar-ng, git
In-Reply-To: <200610171345.32313.jnareb@gmail.com>
On Tue, 17 Oct 2006 13:45:31 +0200
Jakub Narebski <jnareb@gmail.com> wrote:
> Git cannot do that remotely (with exception of git-tar-tree/git-archive
> which has --remote option), yet. But you can get contents of a file
> (with "git cat-file -p [<revision>:|:<stage>:]<filename>"), list
> directory (with "git ls-tree <tree-ish>") and compare files or
> directories (git diff family of commands) without need for working
> directory.
Interesting, I didn't know about the --remote option. So in fact as long
as the remote has enabled upload-tar then anyone can do a "light checkout".
However, it appears that kernel.org for instance doesn't enable this feature.
Sean
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-17 12:02 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Aaron Bentley, Linus Torvalds, bazaar-ng, git
In-Reply-To: <200610171345.32313.jnareb@gmail.com>
Jakub Narebski wrote:
> In git by default in the top directory of working area you have .git
> directory which contains whole repository (object database, refs (i.e.
> branches and tags), information which branch is current, index aka.
> gitcache, configuration, etc.). You can share object database locally
> (which includes network filesystem).
>
> You can have .git (usually <project>.git then) directory without working
> area.
So called "bare" repository.
>
> And you can symlink (and in the future "symref"-link) .git directory.
And you can use GIT_DIR environmental variable or --git-dir option
to git wrapper.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: VCS comparison table
From: Andreas Ericsson @ 2006-10-17 12:00 UTC (permalink / raw)
To: Matthieu Moy
Cc: Jakub Narebski, Aaron Bentley, Linus Torvalds, bazaar-ng, git
In-Reply-To: <vpqejt76vgz.fsf@ecrins.imag.fr>
Matthieu Moy wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>>> - 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).
>> In git you can access contents _without_ checkout/working area.
>
> Bazaar can do this too. For example,
> "bzr cat http://something -r some-revision" gets the content of a file
> at a given revision. But that's not what Aaron was refering to.
>
> In Bazaar, checkouts can be two things:
>
> 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")
>
> 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")
>
What about
3) getting the repo with all the history while still not having to be
online to actually commit to *your* copy of the repo. When you later get
online, you can send all your changes in a big hunk, or let bazaar email
them to the maintainer as patches, or...
> 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.
>
It appears we have different ideas of what's handy. Perhaps it's just a
difference in workflow, or lack of "email-commits-as-patches" tools in
bazaar, but the ability to commit to whatever branch I like in my local
repo and then just send the diffs by email or please-pull requests to
upstream authors is what makes git work so well for me. I can ofcourse
also pull the changes to another branch, or cherrypick them one by one,
or...
OTOH, if by "commit" you mean "send your changes back to central
server", and bazaar'ish for "register my current set of changes in the
local clone of the repo" is called something else, it sounds very
similar to what git does.
>
> 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.
>
Centralized works in git too after a fashion. Most projects have a
master repo hidden somewhere that frequently gets pushed out for
publishing and which most (all?) contributors sync against from time to
time, but it's by no means a certainty. What *is* a certainty is that
the published branches are exactly identical to the ones in the master
repo, and all the downstream authors will get a history where they can
easily track master's development.
For git, I suppose Junio has the hidden master repo which he publishes
at kernel.org. Linus does the same with the Linux repo.
On a side-note, it sounds as though the "bound branch" scenario
encourages making a big change as one mega-diff, so long as it
implements one feature, whereas the git workflow with topic-branches
that eventually gets merged to master allows changes to sort of
accumulate up to a feature in the steps one actually has to take to make
the feature work.
Side-note 2: Three really great things that have made work a lot easier
and more enjoyable since we changed from cvs to git and that aren't
mentioned in the comparison table:
* Dependency/history graph display tools á la qgit/gitk
* Bisection tool for finding bug introduction revisions.
* Tools for sending commits as emails.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-17 11:45 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Aaron Bentley, Linus Torvalds, bazaar-ng, git
In-Reply-To: <vpqejt76vgz.fsf@ecrins.imag.fr>
Matthieu Moy wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>>> - 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).
>>
>> In git you can access contents _without_ checkout/working area.
>
> Bazaar can do this too. For example,
> "bzr cat http://something -r some-revision" gets the content of a file
> at a given revision. But that's not what Aaron was refering to.
Git cannot do that remotely (with exception of git-tar-tree/git-archive
which has --remote option), yet. But you can get contents of a file
(with "git cat-file -p [<revision>:|:<stage>:]<filename>"), list
directory (with "git ls-tree <tree-ish>") and compare files or
directories (git diff family of commands) without need for working
directory.
AFAICT working area is required _only_ to resolve conflicts during
merge.
> In Bazaar, checkouts can be two things:
>
> 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")
>
> 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")
In git by default in the top directory of working area you have .git
directory which contains whole repository (object database, refs (i.e.
branches and tags), information which branch is current, index aka.
gitcache, configuration, etc.). You can share object database locally
(which includes network filesystem).
You can have .git (usually <project>.git then) directory without working
area.
And you can symlink (and in the future "symref"-link) .git directory.
> 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.
There was proposal to allow for tracking branches to be marked
read-only, but it was not implemented yet.
But git has reverse check: it forbids (unless forced by user) to fetch
into branch which has local changes (does not fast-forward). This make
sure that no information is lost.
The idea is that you fetch changes into tracking branch (e.g. 'master'
branch of some parent remote repository into 'origin' or
'remotes/<repository name>/master' branch); you don't commit changes to
such branch. You do your own work either on 'master' branch, then merge
(typically using "git pull") corresponding 'origin' tracking branch, or
use separate private feature branch and use rebase after fetch.
[...]
> 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.
Git is designed for distributed workflows, not for centralized one.
All repositories are created equal :-)
--
Jakub Narebski
ShadeHawk on #git and #revctl
Poland
^ permalink raw reply
* Re: VCS comparison table
From: Sean @ 2006-10-17 11:38 UTC (permalink / raw)
To: Matthieu Moy
Cc: Jakub Narebski, Aaron Bentley, Linus Torvalds, bazaar-ng, git
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
* Re: VCS comparison table
From: Matthieu Moy @ 2006-10-17 11:19 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Aaron Bentley, Linus Torvalds, bazaar-ng, git
In-Reply-To: <200610171030.35854.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
>> - 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).
>
> In git you can access contents _without_ checkout/working area.
Bazaar can do this too. For example,
"bzr cat http://something -r some-revision" gets the content of a file
at a given revision. But that's not what Aaron was refering to.
In Bazaar, checkouts can be two things:
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")
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")
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.
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.
Once more, that's not fundamental, but handy.
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.
--
Matthieu
^ permalink raw reply
* Re: [PATCH] nice ftplugin for vim, that shows the commited diff in a split'ed buffer.
From: Pierre Habouzit @ 2006-10-17 11:04 UTC (permalink / raw)
To: Peter Baumann; +Cc: git, Jeff King
In-Reply-To: <802d21790610170359v3f17438dn8009ae9a55b2405c@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1412 bytes --]
Le mar 17 octobre 2006 12:59, Peter Baumann a écrit :
> 2006/10/17, Pierre Habouzit <madcoder@debian.org>:
> > because for me, wherever I'm from, the cwd is .git/ but it's maybe
> > due to the fact that I use autochdir, I don't know.
>
> Wouldn't it make sense to use something like 'git-rev-parse
> --git-dir' or 'git-rev-parse --show-cdup' to get to the root of the
> repository?
Yes it does, SungHyun Nam already sent a patch to me about that, that is
quite interesting. I've merged it partly, and will make that commit
plugin slightly better, so that people can:
1/ trig it by hand
2/ chose if the split is vertical or horizontal (I always have very big
terms with a lot of vertical splits in vim, so I like the latter,
other prefer the former)
3/ chose via a let g:gitcommit_diff_mode or sth like that in the vimrc
if that has to spawn automatically (0: none, 1: horiz split, 2: vert
split)
and that time, I'll send that to the git contrib/vim maintainer so that
I won't bother the list too much :)
a corrected version of the commit file wrt the cwd is on my site
already, with a bit of SungHyun changes[1].
[1] http://madism.org/~madcoder/dotfiles/vim/ftplugin/git.vim
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] nice ftplugin for vim, that shows the commited diff in a split'ed buffer.
From: Peter Baumann @ 2006-10-17 10:59 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git, Jeff King
In-Reply-To: <200610171238.04372.madcoder@debian.org>
2006/10/17, Pierre Habouzit <madcoder@debian.org>:
> Le mar 17 octobre 2006 10:22, Peter Baumann a écrit :
> > 2006/10/17, Pierre Habouzit <madcoder@debian.org>:
> > > Signed-off-by: Pierre Habouzit <madcoder@debian.org>
> > > ---
> > > contrib/vim/README | 6 ++++
> > > contrib/vim/ftplugin/gitcommit.vim | 61
> > > ++++++++++++++++++++++++++++++++++++ 2 files changed, 67
> > > insertions(+), 0 deletions(-)
> > >
> > > diff --git a/contrib/vim/README b/contrib/vim/README
> > > index 9e7881f..26c1682 100644
> > > --- a/contrib/vim/README
> > > +++ b/contrib/vim/README
> > > @@ -6,3 +6,9 @@ To syntax highlight git's commit message
> > > $ cat >>$HOME/.vimrc <<'EOF'
> > > autocmd BufNewFile,BufRead COMMIT_EDITMSG set
> > > filetype=gitcommit EOF
> > > +
> > > +To use the fancy split-view with the currently commited diff, you
> > > need to: + 1. Copy ftplugin/gitcommit.vim to vim's ftplugin
> > > directory: + $ mkdir -p $HOME/.vim/ftplugin
> > > + $ cp ftplugin/gitcommit.vim $HOME/.vim/ftplugin
> > > + 2. Auto-detect the editing of git commit files (see above).
> > > diff --git a/contrib/vim/ftplugin/gitcommit.vim
> > > b/contrib/vim/ftplugin/gitcommit.vim new file mode 100644
> > > index 0000000..f9efd59
> > > --- /dev/null
> > > +++ b/contrib/vim/ftplugin/gitcommit.vim
> > > @@ -0,0 +1,61 @@
> > > +if exists("b:did_ftplugin")
> > > + finish
> > > +endif
> > > +
> > > +let b:did_ftplugin = 1
> > > +
> > > +setlocal tw=74
> > > +setlocal nowarn nowb
> > > +
> > > +"{{{ function Git_diff_windows
> > > +
> > > +function! Git_diff_windows()
> > > + let i = 0
> > > + let list_of_files = ''
> > > +
> > > + " drop everything until '# (will commit)' and the next empty
> > > line + while i <= line('$')
> > > + let line = getline(i)
> > > + if line =~ '^#\s*(will commit)$'
> > > + let i = i + 2
> > > + break
> > > + endif
> > > +
> > > + let i = i + 1
> > > + endwhile
> > > +
> > > + " read file names until we have EOF or an empty line
> > > + while i <= line('$')
> > > + let line = getline(i)
> > > + if line =~ '^#\s*[a-z ]*:.*->.*$'
> > > + let file = substitute(line,
> > > '\v^#[^:]*:.*->\s*(.*)\s*$', '\1', '') + let
> > > list_of_files = list_of_files . ' '.file
> > > + let file = substitute(line,
> > > '\v^#[^:]*:\s*(.*)\s*->.*$', '\1', '') + let
> > > list_of_files = list_of_files . ' '.file
> > > + elseif line =~ '^#\s*[a-z ]*:'
> > > + let file = substitute(line, '\v^#[^:]*:\s*(.*)\s*$',
> > > '\1', '') + let list_of_files = list_of_files . ' '.file
> > > + elseif line =~ '^#\s*$'
> > > + break
> > > + endif
> > > +
> > > + let i = i + 1
> > > + endwhile
> > > +
> > > + if list_of_files == ""
> > > + return
> > > + endif
> > > +
> > > + rightbelow vnew
> >
> > I find it confusing that you split vertically, especially if I work
> > in small terminals.
> > I would prefere a horizontal split, thats why I changed it to the way
> > to the way it is
> > handled in the svn.vim commit case:
> >
> > below new
> >
> > > + silent! setlocal ft=diff previewwindow bufhidden=delete
> > > nobackup noswf nobuflisted nowrap buftype=nofile + exe 'normal
> > > :r!LANG=C cd ..; git diff HEAD -- ' . list_of_files . "\n1Gdd" +
> > > exe 'normal :r!LANG=C cd ..; git diff HEAD -- ' . list_of_files . "
> > > \| git apply --stat\no\<esc>1GddO\<esc>"
> >
> > Why changing directory? I had to remove the cd .. to make it work.
> > Otherwise git diff couldn't find the repository.
>
> because for me, wherever I'm from, the cwd is .git/ but it's maybe due
> to the fact that I use autochdir, I don't know.
>
Wouldn't it make sense to use something like 'git-rev-parse --git-dir' or
'git-rev-parse --show-cdup' to get to the root of the repository?
Greetings,
Peter
^ permalink raw reply
* Re: VCS comparison table
From: Matthieu Moy @ 2006-10-17 10:47 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Robert Collins, bazaar-ng, git, Jakub Narebski
In-Reply-To: <4534AB8B.8030505@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> Robert Collins wrote:
>> On Tue, 2006-10-17 at 11:20 +0200, Jakub Narebski wrote:
>>> ---- time --->
>>>
>>> --*--*--*--*--*--*--*--*--*-- <branch>
>>> \ /
>>> \-*--X--*--/
>>>
>>> The branch it used to be on is gone...
>>
>> In bzr 0.12 this is :
>> 2.1.2
>>
>
> Would it be a different number in a different version of bazaar?
I can't say for bzr 0.>12 which do not exist ;-)
For previous versions, it didn't have that "simple" number, and you
had to use the rev-id.
--
Matthieu
^ 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