* Re: VCS comparison table
From: Erik Bågfors @ 2006-10-21 16:31 UTC (permalink / raw)
To: Jakub Narebski
Cc: Matthew D. Fuller, bazaar-ng, Linus Torvalds, Carl Worth,
Andreas Ericsson, git
In-Reply-To: <200610211608.18895.jnareb@gmail.com>
> There _are_ terminology conflicts. For example bzr "branch" is roughly
> equivalent to one-branch git "repository";
Agreed.
> bzr "repository" is just
> collection of branches sharing common storage,
Agreed
> which is similar to set
> of git "repositories" with .git/objects/ linked to common object
> repository (storage area) or appropriately set alternates file
> (although that is not common usage in git, and for example you would
> have to be carefull with running git-prune); bzr "lightweight checkout"
> is equivalent to nonexistent "lazy clone"/"remote alternates" discussed
> on git mailing list but not implemented because of performance
> concerns; bzr "normal checkout" is I think similar to git "shared
> clone" (but shared clone is limited to repositories on the same
> filesystem); bzr "heavyweight checkout" is roughly equivalent to
> one-branch-only "clone" in git or cg (cg = Cogito).
This is wrong. There are two kinds of checkouts
lightweight.. and "normal/heavyweight".
I think you are getting this alittle wrong, and I think the reason is
that you are thinking of repositories, while in bzr you normally think
of branches.
For example, I think (correct me if I'm wrong) that if I have a git
repository of a upstream linux-repo (Linus' for example). I guess
I'll use "pull" to keep my copy up to date with the upstream repo? If
I then would like to hack something special, I would "clone" the repo
and get a new repo and that's where I do my work. Is that correct?
In bzr you never (well...) clone a full repository, but you clone one
line-of-development (a branch). So "bzr branch" is always a
"one-branch-only "clone" in git or cg".
"bzr checkout" is a "bzr branch" followed by a setting saying
"whenever you commit here, commit in the master branch also".
"bzr checkout --lightweight" is a way to get only a snapshot of the
working tree out of a branch. Whenever you commit, it's done in the
remote branch.
/Erik
^ permalink raw reply
* Re: VCS comparison table
From: Erik Bågfors @ 2006-10-21 16:35 UTC (permalink / raw)
To: Sean
Cc: Jan Hudec, Linus Torvalds, bazaar-ng, git, Matthieu Moy,
Jakub Narebski
In-Reply-To: <BAYC1-PASMTP01706CD2FCBE923333A0CBAE020@CEZ.ICE>
On 10/21/06, Sean <seanlkml@sympatico.ca> wrote:
> On Sat, 21 Oct 2006 18:19:54 +0200
> "Erik Bågfors" <zindar@gmail.com> wrote:
>
> > This is just plain wrong.
> >
> > bzr is a fully decentralized VCS. I've read this thread for quite some
> > time now and I really cannot understand why people come to this
> > conclusion.
> >
> > However, if you do want to work centralized, bzr has commands that
> > fits that workflow really good.
>
> Have you been reading this thread at all?
Yes.
> Even the bzr people have now
> stated rather firmly that the revno scheme doesn't work very well in
> a number of situations. Numerous examples have been given where the
> revno will be useless, or worse misleading when bzr is used without
> a central server. The answer from the bzr folks has been then don't
> use the revno in those situations. However, it's quite clear from the
> bzr UI that there is a _bias_ towards using revno's.
>
> So yes, clearly you can use bzr without a central server; but it's just
> as clearly biased against such usage.
So... I do agree that revnos might not fit perfectly in at all times.
But that they automatically mean that bzr is not a decentralized VCS,
I strongly disagree with. They are just one part of the equation.
/Erik
--
google talk/jabber. zindar@gmail.com
SIP-phones: sip:erik_bagfors@gizmoproject.com
sip:17476714687@proxy01.sipphone.com
^ permalink raw reply
* Re: less -F ubuntu dapper.
From: A Large Angry SCM @ 2006-10-21 16:47 UTC (permalink / raw)
To: Git Mailing List; +Cc: Sergey Vlasov, Aneesh Kumar
In-Reply-To: <20061021200110.6aef96a4.vsu@altlinux.ru>
Sergey Vlasov wrote:
> On Sat, 21 Oct 2006 18:53:35 +0530 Aneesh Kumar wrote:
>
>> -F option for less in ubuntu Dapper is broken. It doesn't display
>> anyting if the file can be displayed in one page.
>
> Same here in ALT Linux (less-382-alt2). The problem appears only
> when the terminal supports alternate screen, and less uses it.
Suse 9.3 has the same problem.
^ permalink raw reply
* git-imap-send and "From "
From: Andy Parkins @ 2006-10-21 16:51 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1804 bytes --]
Hello,
I've been playing around with git; made some simple patches for git and
thought I would forward them to the mailing list. I did this using
git-format-patch --stdout --signoff -M -B | git-imap-send
With the following in .gitconfig and courier-imap as the IMAP server.
[imap]
Folder = "INBOX.Drafts"
Tunnel = "ssh -q mailhost /usr/bin/imapd ./Maildir 2> /dev/null"
This appeared to work as expected. A nicely formatted patch appeared in my
drafts mailbox for checking and sending; which I did. However, those emails
caused a few problems; like:
"Can you please not send your emails to "unlisted recipients?" It
breaks my mail filtering and your mails don't end up going to my "git"
folder."
As far as I knew, I hadn't done this. The email looked fine when I checked it
in KMail. So, I went back and had a look at the raw source of the patch
email that I'd sent and found this:
From 0e3c0aefc3276bd271553d171ed9bcc52d85230e Mon Sep 17 00:00:00 2001
From: Andy Parkins <andyparkins@gmail.com>
Date: Fri, 20 Oct 2006 15:24:40 +0100
Subject: [PATCH] Use email address only for looking up signing key in git-tag
It's that first line that's the problem. It was generated by git-format-patch
of course, however, I assume that it was intended to be stripped on the way
to the IMAP server. So,
* Courier's /usr/bin/imapd should have stripped it and didn't
* git-imap-send shouldn't have sent it
Can anyone help me out with which it should be? Or point me at the relevant
RFC?
While I was poking around I found that git is hard coded with
printf("From %s Mon Sep 17 00:00:00 2001\n", sha1);
Was it intentional that the date be hard coded like that?
Andy
--
Dr Andrew Parkins, M Eng (Hons), AMIEE
andyparkins@gmail.com
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: VCS comparison table
From: Aaron Bentley @ 2006-10-21 16:56 UTC (permalink / raw)
To: Jakub Narebski; +Cc: bazaar-ng, git
In-Reply-To: <ehd5u7$c5g$1@sea.gmane.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jakub Narebski wrote:
> Jan Hudec wrote:
>
>> On Fri, Oct 20, 2006 at 12:05:35AM -0400, Aaron Bentley wrote:
>>> Tim Webster wrote:
>>>> Also svn does not allow files in the same directory to live in
>>>> multiple repos
>>> It would surprise me if many SCMs that support atomic commit also
>>> support intermixing files from multiple repos in the same directory.
>> In fact I think svk would. You would have to switch them by setting
>> an environment variable, but it's probably doable. That is because
>> unlike other version control systems, it does not store the information
>> about checkout in the checkout, but in the central directory and that
>> can be set. I don't know git well enough to tell whether git could do
>> the same by setting GIT_DIR.
>
> You can very simply embed one "clothed" repository into another in GIT,
> like shown below
>
> project/.git
> project/subdir/
> project/subdir/file
> project/subproject/
> project/subproject/.git
> project/subproject/file
> ...
>
> It depends on circumstances if one wants files belonging to subdirectory
> be ignored by top repository. You would want to ignore .git/ directory,
> though.
Any SCM worth its salt should support that. AIUI, that's not what Tim
wants. He wants to intermix files from different repos in the same
directory.
i.e.
project/file-1
project/file-2
project/.git-1
project/.git-2
So file-1 would be in the .git-1 repository, but file-2 would be in the
.git-2 repository.
Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFOlE70F+nu1YWqI0RAvNcAJ0Rd6ovGoBNtKxcPNOrMH1yc+bzWQCfQlqT
hREsUmCBAW8mIYzfzdnqZqU=
=unGE
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-21 16:59 UTC (permalink / raw)
To: Erik Bågfors
Cc: Matthew D. Fuller, bazaar-ng, Linus Torvalds, Carl Worth,
Andreas Ericsson, git
In-Reply-To: <845b6e870610210931r19aaaac3y3dfd0d9c4af8ed40@mail.gmail.com>
Erik Bågfors wrote:
> Jakub Narebski wrote:
>>
>> There _are_ terminology conflicts. For example bzr "branch" is roughly
>> equivalent to one-branch git "repository";
>
> Agreed.
>
>> bzr "repository" is just
>> collection of branches sharing common storage,
>
> Agreed
What is worse (in comparing git with bzr) that there are no exact
equivalents. For example bzr "branch" is something between git
repository (clone of repository) and git branch. Bazaar-NG "repository"
is something like multi-branch git repository, but also like collection
of git repositories sharing object database.
>> which is similar to set
>> of git "repositories" with .git/objects/ linked to common object
>> repository (storage area) or appropriately set alternates file
>> (although that is not common usage in git, and for example you would
>> have to be carefull with running git-prune); bzr "lightweight checkout"
>> is equivalent to nonexistent "lazy clone"/"remote alternates" discussed
>> on git mailing list but not implemented because of performance
>> concerns; bzr "normal checkout" is I think similar to git "shared
>> clone" (but shared clone is limited to repositories on the same
>> filesystem); bzr "heavyweight checkout" is roughly equivalent to
>> one-branch-only "clone" in git or cg (cg = Cogito).
>
> This is wrong. There are two kinds of checkouts
> lightweight.. and "normal/heavyweight".
>
> I think you are getting this a little wrong, and I think the reason is
> that you are thinking of repositories, while in bzr you normally think
> of branches.
As I said: conflict of concepts. And perhaps philosophies.
> For example, I think (correct me if I'm wrong) that if I have a git
> repository of a upstream linux-repo (Linus' for example). I guess
> I'll use "pull" to keep my copy up to date with the upstream repo? If
> I then would like to hack something special, I would "clone" the repo
> and get a new repo and that's where I do my work. Is that correct?
Not exactly.
To work for example on Linus' version of Linux kernel you clone upstream
linux-repo git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Working area is associated with repository in Git, not with "branch" like
in Bazaar-NG. In default configuration 'master' (main) branch of cloned
repository (in the case of Linus' public repo it is the only branch)
corresponds to 'origin' branch in your repository.
Now you can work on 'master' branch, putting your changes there. git-fetch
will update 'origin' branch to the current version of 'master' branch of
cloned repo; git-pull will additionally merge into 'master', i.e. merge
new changes into your work.
Now if you want to hack something special, that you prefer to use separate
branch for, you don't need to clone repository anew (although you could,
using --local --shared to reduce cost of cloning) but it is enough to
create new branch in your repository. You can very easily switch between
branches using the same working area (in bzr it would probably mean
"branch checkout" to the same directory).
> In bzr you never (well...) clone a full repository, but you clone one
It's a pity... for example you usually want to have access to both
stable ('master') and development ('next') branches, perhaps
also to fixes ('maint') and beta stage development ('pu') branches.
In bzr it is a bit work (to correctly setup "repository"), in git
it is one command.
> line-of-development (a branch). So "bzr branch" is always a
> "one-branch-only "clone" in git or cg".
More or less.
> "bzr checkout" is a "bzr branch" followed by a setting saying
> "whenever you commit here, commit in the master branch also".
Git doesn't have exact equivalent here. For "bzr checkout" on
the same system, it is similar to setting common object repository;
for remote "bzr checkout" it might be approximated by hooks which
would push changes to remote repository (although we would have
to implement some transaction/journal framework).
> "bzr checkout --lightweight" is a way to get only a snapshot of the
> working tree out of a branch. Whenever you commit, it's done in the
> remote branch.
Yes, but with "bzr checkout --lightweight" you get also pointer
to remote branch where to commit changes. Git doesn't have something
like that, at least not for remote remote branch; mostly because of
poor performance or need for fast and constant network connection
to source branch.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-21 17:03 UTC (permalink / raw)
To: Aaron Bentley; +Cc: bazaar-ng, git
In-Reply-To: <453A513B.1070006@utoronto.ca>
Aaron Bentley wrote:
> AIUI, that's not what Tim wants. He wants to intermix files from
> different repos in the same directory.
>
> i.e.
>
> project/file-1
> project/file-2
> project/.git-1
> project/.git-2
>
> So file-1 would be in the .git-1 repository, but file-2 would be
> in the .git-2 repository.
Possible (as I said), although it would screw up automatic repository
detection. So you would have to say "git --git-dir=.git-1 commit -a"
or "GIT_DIR=.git-2 git log -p; git diff; ...", i.e. specify repo
for each command.
Of course you would have to hide repositories from each other,
and probably it would be better to hide files provided by other
repository.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [RFC] separate .git from working directory
From: Nguyen Thai Ngoc Duy @ 2006-10-21 17:08 UTC (permalink / raw)
To: git
In-Reply-To: <fcaeb9bf0610110623q365d3ffcw9ba9e11936d03a9d@mail.gmail.com>
Hi,
After reading a post in VCS comparison thread mentioning /etc example.
I think some of my patches might be useful for some users. They are
two patches, tp/gitlink~1 and tp/gitlink~2 in git-pclouds.git on
repo.or.cz.
The implementation is a bit differerent from what I proposed. The
.gitdir file (I named it .gitlink though) contains an alternative
name for .git dir. It would be more obvious with the following
example:
The standard layout:
a/.git
a/file
a/b/.git
a/b/file
The new layout:
a/.git
a/.git-b (it is actually a/b/.git)
a/file
a/b/.gitlink (whose content is ".git-b")
a/b/file
With this I can move all .git directories to the top directory (or
just parent directories). In /etc example, it can create a less
cluttered directory structure. I do not submit these patches to git.
It needs more work IMO.
--
Duy
^ permalink raw reply
* Re: VCS comparison table
From: Linus Torvalds @ 2006-10-21 17:31 UTC (permalink / raw)
To: Aaron Bentley; +Cc: bazaar-ng, git, Jakub Narebski
In-Reply-To: <453A513B.1070006@utoronto.ca>
On Sat, 21 Oct 2006, Aaron Bentley wrote:
>
> Any SCM worth its salt should support that. AIUI, that's not what Tim
> wants. He wants to intermix files from different repos in the same
> directory.
>
> i.e.
>
> project/file-1
> project/file-2
> project/.git-1
> project/.git-2
Ok, that's just insane.
It's going to always result in problems (ie some files are going to be
considered "untracked" depending on which repository you're looking at
right then and there).
That said, if you _really_ want this, you can do it. Here's now:
# Create insane repository layout
mkdir I-am-insane
cd I-am-insane
# Tell people we want to work with ".git-1"
export GIT_DIR=.git-1
git init-db
echo "This is file 1 in repo 1" > file-1
git add file-1
git commit -m "Silly commit"
# Now we switch repos
export GIT_DIR=.git-2
git init-db
echo "This is another file in repo 2" > file-2
git add file-2
git commit -m "Silly commit in another repo"
and now you literally have two repositories in the same subdirectory, and
they don't know about each other, and you can switch your "attention"
between them by simply doing
export GIT_DIR=.git-1
(or .git-2). Then you can just do "git diff" etc normally, and work in the
repo totally ignoring the other one in the same directory structure.
Of course, things like "git status" that show untracked files will always
then show the "other" repository files as untracked - the two things will
really be _totally_ independent, they don't at any point know about each
others files, although they can actually _share_ checked-out files if you
want to:
echo "This is a shared file" > file-shared
export GIT_DIR=.git-1
git add file-shared
git commit -m "Add shared file to repo 1"
export GIT_DIR=.git-2
git add file-shared
git commit -m "Add shared file to repo 2"
and now if you change that file, both repositories will see it as being
changed.
INSANE. And probably totally useless. But you can do it. If you really
want to.
The git directories don't even have to be in the same subdirectory
structure. You could have done
export GIT_DIR=~/insane-git-setup/dir1
instead, and the git information for that thing would have been put in
that subdirectory.
Note: the above literally creates two different repositories. You can do
the same thing with a single object repository (so that any actual shared
data shows up in a shared database) by still using different GIT_DIR
variables, but using GIT_OBJECT_DIRECTORY to point to a shared database
directory (which again could be anywhere - it could be under ".git-1", or
it could be in a separate place in your home directory).
Or you could do it even _more_ differently by actually having just a
single repository, and having two different branches in that repository,
and just tracking them separately: in that case you would keep the same
GIT_DIR/GIT_OBJECT_DIRECTORY (or keep them unset, which just means that
they default to ".git" and ".git/objects" as normal), and then just switch
the "index" file and the HEAD files around. That would mean that to switch
from one "view" to the other, you'd do something like
export GIT_INDEX_FILE=.git/index1
git symbolic-ref HEAD refs/heads/branch1
to set your view to "branch1".
Anyway, I would strongly discourage people from actually doing anything
like this. It should _work_, but quite frankly, if you actually want to do
this, you have serious mental problems.
What's probably much better is to have two separate development
repositories, and then perhaps mixing the end _result_ somewhere else. For
example, you can use the
git checkout-index -a -f --prefix=/usr/shared/result/
in both (separate) repositories, and you'll end up with basically a
snapshot of the "union" in /usr/shared/result.
(Not that I see why you'd want to do that _either_, but hey, at least
you're not going to be _totally_ confused by the end result).
Anyway. Git certainly allows you to do some really insane things. The
above is just the beginning - it's not even talking about alternate object
directories where you can share databases _partially_ between two
otherwise totally independent repositories etc.
Linus
^ permalink raw reply
* Re: VCS comparison table
From: Erik Bågfors @ 2006-10-21 17:33 UTC (permalink / raw)
To: Sean
Cc: Matthieu Moy, bazaar-ng, Linus Torvalds, Jan Hudec, git,
Jakub Narebski
In-Reply-To: <BAYC1-PASMTP04FAD1FBB91BA4C07A5E79AE020@CEZ.ICE>
On 10/21/06, Sean <seanlkml@sympatico.ca> wrote:
> On Sat, 21 Oct 2006 18:35:18 +0200
> "Erik Bågfors" <zindar@gmail.com> wrote:
>
>
> > So... I do agree that revnos might not fit perfectly in at all times.
> > But that they automatically mean that bzr is not a decentralized VCS,
> > I strongly disagree with. They are just one part of the equation.
>
> Whoe are you strongly disagreeing with? Nobody said it wasn't a
> decentralized VCS. But there is a _clear_ bias towards using it
> with a central server.
Ok, I take that back :)
When I think "centralized" I think "everyone must commit to a central
repository"... which is not what we are talking about here...
/Erik
ps. Sean, your mailer does something wierd with my last name in the
to-field, so I can't just hit "reply" without removing my name
first...
/Erik
--
google talk/jabber. zindar@gmail.com
SIP-phones: sip:erik_bagfors@gizmoproject.com
sip:17476714687@proxy01.sipphone.com
^ permalink raw reply
* Re: VCS comparison table
From: Linus Torvalds @ 2006-10-21 17:38 UTC (permalink / raw)
To: Aaron Bentley; +Cc: Jakub Narebski, bazaar-ng, git
In-Reply-To: <Pine.LNX.4.64.0610211007320.3962@g5.osdl.org>
On Sat, 21 Oct 2006, Linus Torvalds wrote:
>
> # Tell people we want to work with ".git-1"
> export GIT_DIR=.git-1
Actually, I think Jakub's approach is better: you'd be better off doing
this as
alias git-1="git --git-dir=.git-1"
alias git-2="git --git-dir=.git-2"
and now you should be able to just do
git-1 diff
(or any other git command) and
git-2 diff
and can happily share the same directory and mix git commands without
changing an environment variable all the time.
That would still be insane, but it wouldn't likely be _quite_ as confusing
(or error-prone in case you forgot to switch the variable).
Linus
PS. I'd still _not_ suggest doing this. It should _work_, but I mean -
really..
^ permalink raw reply
* Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle
From: Jan Hudec @ 2006-10-21 17:40 UTC (permalink / raw)
To: Jeff King; +Cc: bazaar-ng, git, Jakub Narebski
In-Reply-To: <20061020225917.GA30584@coredump.intra.peff.net>
On Fri, Oct 20, 2006 at 06:59:17PM -0400, Jeff King wrote:
> On Fri, Oct 20, 2006 at 08:12:10PM +0200, Jan Hudec wrote:
>
> > At this point, I expect the tree to look like this:
> > A$ ls -R
> > .:
> > data/
> > data:
> > hello.txt
> > A$ cat data/hello.txt
> > Hello World!
>
> Git does what you expect here.
>
> > A$ VCT mv data greetings
> > A$ VCT commit -m "Renamed the data directory to greetings"
> > B$ echo "Goodbye World!" > data/goodbye.txt
> > B$ VCT add data/goodbye.txt
> > B$ VCT commit -m "Added goodbye message."
> > A$ VCT merge B
> >
> > And now I expect to have tree looking like this:
> >
> > A$ ls -R
> > .:
> > greetings/
> > greetings:
> > hello.txt
> > goodbye.txt
>
> Git does not do what you expect here. It notes that files moved, but it
> does not have a concept of directories moving. Git could, even without
> file-ids or special patch types, figure out what happened by noting that
> every file in data/ was renamed to its analogue in greetings/, and infer
> that previously non-existant files in data/ should also be moved to
> greetings/.
>
> However, I'm not sure that I personally would prefer that behavior. In
> some cases you might actually WANT data/goodbye.txt, and in some other
> cases a conflict might be more appropriate. In any case, I would rather
> the SCM do the simple and predictable thing (which I consider to be
> creating data/goodbye.txt) rather than be clever and wrong (even if it's
> only wrong a small percentage of the time).
>
> In short, git doesn't do what you expect, but I'm not convinced that
> it's a bug or lack of feature, and not simply a difference in desired
> behavior.
I still consider it a bug, but different problems of the file-id
solution have already been described in this thread that I consider bugs
as well.
Besides I start to think that it should be actually possible to solve
this case with the git-style approach. I have to state beforehand, that
I don't know how the most recent git algorithm works, but I imagine
there is some kind of 'brackets' saying the text is in a given file. Now
if those 'brackets' were not flat, but nested, ie. instead of saying
'this is in foo/bar' it would say 'this is in bar is in foo', the
difference when renaming directory would only affect the 'outer bracket'
and therefore merge correctly with adding content inside it.
--------------------------------------------------------------------------------
- Jan Hudec `Bulb' <bulb@ucw.cz>
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-21 17:41 UTC (permalink / raw)
To: Erik Bågfors
Cc: Matthew D. Fuller, bazaar-ng, Carl Worth, Andreas Ericsson, git
In-Reply-To: <200610211859.03420.jnareb@gmail.com>
Note: instead of symlinking .git/objects/ objects database,
you can simply set and export GIT_OBJECT_DIRECTORY environment
variable.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle
From: Jakub Narebski @ 2006-10-21 17:51 UTC (permalink / raw)
To: Jan Hudec; +Cc: Jeff King, bazaar-ng, git
In-Reply-To: <20061021174056.GA29927@artax.karlin.mff.cuni.cz>
Jan Hudec wrote:
> Besides I start to think that it should be actually possible to solve
> this case with the git-style approach. I have to state beforehand, that
> I don't know how the most recent git algorithm works, but I imagine
> there is some kind of 'brackets' saying the text is in a given file. Now
> if those 'brackets' were not flat, but nested, ie. instead of saying
> 'this is in foo/bar' it would say 'this is in bar is in foo', the
> difference when renaming directory would only affect the 'outer bracket'
> and therefore merge correctly with adding content inside it.
You mean, to consider "contents" of a directory union of contents
of files and directories it contains, and then use the same "rename
detection" algorithm as for files?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: git-imap-send and "From "
From: Jeff King @ 2006-10-21 17:55 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200610211751.21581.andyparkins@gmail.com>
On Sat, Oct 21, 2006 at 05:51:17PM +0100, Andy Parkins wrote:
> From 0e3c0aefc3276bd271553d171ed9bcc52d85230e Mon Sep 17 00:00:00 2001
> From: Andy Parkins <andyparkins@gmail.com>
> Date: Fri, 20 Oct 2006 15:24:40 +0100
> Subject: [PATCH] Use email address only for looking up signing key in git-tag
>
> It's that first line that's the problem. It was generated by
> git-format-patch of course, however, I assume that it was intended to
> be stripped on the way to the IMAP server. So,
That makes sense; git-format-patch generates an mbox, not a raw message.
> * Courier's /usr/bin/imapd should have stripped it and didn't
> * git-imap-send shouldn't have sent it
git-imap-send shouldn't be sending it. The IMAP protocol works with
RFC822 messages, not mboxes.
> Can anyone help me out with which it should be? Or point me at the relevant
> RFC?
RFC2060, section 6.3.11 (APPEND).
-Peff
^ permalink raw reply
* Re: VCS comparison table
From: Aaron Bentley @ 2006-10-21 17:57 UTC (permalink / raw)
To: Jeff King
Cc: Carl Worth, Linus Torvalds, Jakub Narebski, Andreas Ericsson,
bazaar-ng, git
In-Reply-To: <20061020141222.GA17497@coredump.intra.peff.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jeff King wrote:
> On Thu, Oct 19, 2006 at 09:06:40PM -0400, Aaron Bentley wrote:
>
>> What's nice is being able see the revno 753 and knowing that "diff -r
>> 752..753" will show the changes it introduced. Checking the revo on a
>> branch mirror and knowing how out-of-date it is.
>
> I was accustomed to doing such things in CVS, but I find the git way
> much more pleasant, since I don't have to do any arithmetic:
> diff d8a60^..d8a60
> Does bzr have a similar shorthand for mentioning relative commits?
Yes, you could e.g. do:
bzr diff -r before:753..753
Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFOl9s0F+nu1YWqI0RAhW7AJ4vi4kgen/8h6j2AgueU+kcsmLrPwCeKry9
pp68K4rAmXjjkPvK32LvmPk=
=qDn2
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: git-imap-send and "From "
From: Jeff King @ 2006-10-21 18:01 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <20061021175519.GA7432@coredump.intra.peff.net>
On Sat, Oct 21, 2006 at 01:55:19PM -0400, Jeff King wrote:
> git-imap-send shouldn't be sending it. The IMAP protocol works with
> RFC822 messages, not mboxes.
FWIW, I just checked and git-imap-send does the right thing; it strips
the 'From ' line before sending to the imap server.
-Peff
^ permalink raw reply
* Re: VCS comparison table
From: Matthew D. Fuller @ 2006-10-21 18:11 UTC (permalink / raw)
To: Jakub Narebski
Cc: bazaar-ng, Linus Torvalds, Carl Worth, Andreas Ericsson, git
In-Reply-To: <200610211608.18895.jnareb@gmail.com>
On Sat, Oct 21, 2006 at 04:08:18PM +0200 I heard the voice of
Jakub Narebski, and lo! it spake thus:
> Dnia sobota 21. października 2006 15:01, Matthew D. Fuller napisał:
> >
> > I think we're getting into scratched-record-mode on this.
>
> [....]
Thank you for demonstrating my point 8-}
> When two clones of the same repository (in git terminology), or two
> "branches" (in bzr terminology), used by different people, cannot be
> totally equivalent that is centralization bias.
This is obviously some new meaning of "centralization" bearing no
resemblance whatsoever to how I understand the word.
In git, apparently, you don't give a crap about a branch's identity
(alternately expressible as "it has none"), and so you throw it away
all the time. Given that, revnos even if git had them would never be
of ANY use to you, so it's no wonder you have no use for the notion.
I DO give a crap about my branchs' identities. I WANT them to retain
them. If I have 8 branches, they have 8 identities. When I merge one
into another, I don't WANT it to lose its identity. When I merge a
branch that's a strict superset of second into that second, I don't
WANT the second branch to turn into a copy of the first. If I wanted
that, I'd just use the second branch, or make another copy of it. I
don't WANT to copy it. I just want to merge the changes in, and keep
on with my branch's current identity.
Maybe that's what you mean by 'centralization'; each branch is central
to itself. That seems a pretty useless definition, though. In my
mind, actually, it's MORE distributed; my branch remains my branch,
and your branch remains your branch, and the difference doesn't keep
us from working together and moving changes back and forth. Forcing
my branch to become your branch sounds a lot more "centralized" to me.
Now, we can discuss THAT distinction. I'm not _opposed_ to git's
model per se, and I can think of a lot of cases where it's be really
handy. But those aren't most of my cases. And as long as we don't
agree on branch identity, it's completely pointless to keep yakking
about revnos, because they're a direct CONSEQUENCE of that difference
in mental model. See? They're an EFFECT, not a CAUSE. If bzr didn't
have revnos, I'd STILL want my branch to keep its identity. You could
name the mainline revisions after COLORS if you wanted, and I'd still
want my branch to keep its identity. Aren't we through rehashing the
same discussion about the EFFECTS?
> > It refers both to the conceptual entity ("a line of development"
> > roughly, much like what 'branch' means in git and VCS in general),
> > and to the physical location (directory, URL)
>
> I'd rather use other name then. Perhaps "forks" for physical
> "branch", i.e. branch metadata (like revno to revid mapping) +
> object repository or pointer to it + optionally working area/working
> files.
It's the same name in bzr because branches are their location, not
their 'name'. Every branch always has a location, and every location
refers to a branch (well, as long as it's a location that's meaningful
to bzr; "/etc/passwd" is a location, but it's nothing to do with bzr,
so it's not a branch. Don't dawdle in irrelevancies).
> And you say that bzr is not biased towards centralization? In git
> you can just pull (fetch) to check if there were any changes, and if
> there were not you don't get useless marker-merges.
If I don't tell you my branch has something in it ready to grab, you
shouldn't merge it. It probably won't work, and is quite likely to
set your computer on fire, slaughter and fillet your pet goldfish, and
make demons fly out of your nose. If you wanna get stuck with all my
incomplete WIP, let's just use a CVS module and be done with it.
> 2. But the preferred git workflow is to have two branches in each of
> two clones. The 'origin' branch where you fetch changes from other
> repository (so called "tracking branch") and you don't commit your
> changes to [...]
Funny, since this reads to me EXACTLY like the bzr flow of "upstream
branch I pull" and "my branch I merge from upstream" that's getting
kvetched around...
--
Matthew Fuller (MF4839) | fullermd@over-yonder.net
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
On the Internet, nobody can hear you scream.
^ permalink raw reply
* Re: git-imap-send and "From "
From: Andy Parkins @ 2006-10-21 18:11 UTC (permalink / raw)
To: git
In-Reply-To: <20061021175519.GA7432@coredump.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 478 bytes --]
On Saturday 2006, October 21 18:55, Jeff King wrote:
> git-imap-send shouldn't be sending it. The IMAP protocol works with
> RFC822 messages, not mboxes.
I grabbed the latest git; and started looking at fixing it. It looks fixed to
me; a quick "git log imap-send.c" found me commit
e0b0830726286287744cc9e1a629a534bbe75452; which already fixes this problem.
Goodness I love git :-)
Andy
--
Dr Andrew Parkins, M Eng (Hons), AMIEE
andyparkins@gmail.com
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-21 18:20 UTC (permalink / raw)
To: Aaron Bentley
Cc: Jeff King, Carl Worth, Linus Torvalds, Andreas Ericsson,
bazaar-ng, git
In-Reply-To: <453A5F6D.7020306@utoronto.ca>
Aaron Bentley wrote:
> Jeff King wrote:
>> On Thu, Oct 19, 2006 at 09:06:40PM -0400, Aaron Bentley wrote:
>>
>>> What's nice is being able see the revno 753 and knowing that "diff -r
>>> 752..753" will show the changes it introduced. Checking the revo on a
>>> branch mirror and knowing how out-of-date it is.
>>
>> I was accustomed to doing such things in CVS, but I find the git way
>> much more pleasant, since I don't have to do any arithmetic:
>> diff d8a60^..d8a60
>
>> Does bzr have a similar shorthand for mentioning relative commits?
>
> Yes, you could e.g. do:
>
> bzr diff -r before:753..753
What about grandparent of commit (d8a60^^ or d8a60~2 in git),
or choosing one of the parents in merge commit (d8a60^2 is second
parent of a commit)? before:before:753 ?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: VCS comparison table
From: Jan Hudec @ 2006-10-21 18:34 UTC (permalink / raw)
To: Sean; +Cc: Linus Torvalds, bazaar-ng, git, Matthieu Moy, Jakub Narebski
In-Reply-To: <20061021102346.9cd3abce.seanlkml@sympatico.ca>
On Sat, Oct 21, 2006 at 10:23:46AM -0400, Sean wrote:
> On Sat, 21 Oct 2006 16:13:28 +0200
> Jan Hudec <bulb@ucw.cz> wrote:
>
> > Bzr is meant to be used in both ways, depending on user's choice.
> > Therefore it comes with that infrastructure and you can choose whether
> > you want to use it or not.
>
> >From what we've read on this thread, bzr appears to be biased towards
> working with a central repo. That is the model that supports the use of
> revnos etc that the bzr folks are so fond of. However Git is perfectly
> capable of being used in any number of models, including centralized.
> Git just doesn't make the mistake of training new users into using
> features that are only stable in a limited number of those models.
For one think I, like others already expressed, think difference should
be made between 'centralized' and 'star-topology'. Subversion is
centralized -- I don't think bzr is biased towards that kind of
centralization, though it provides tools (bound branches) to make it
easy.
I would agree it IS biased towards viewing branches as organized in a
hierarchy, while git strictly treats them as equal peers, which I'd call
star-topology (and I don't think it is because it _has_ revnos, but
because the user interface strongly favors them over revids).
On the other hand git is biased away from centralized (as in subversion
is centralized) in that it takes extra work to make sure you are always
synchronized (while bzr has bound branches to do the checking for you).
For open-source development, centralized is a wrong way to go, but
people use version control tools for other purposes as well and for some
of them staying synchronized is important.
--------------------------------------------------------------------------------
- Jan Hudec `Bulb' <bulb@ucw.cz>
^ permalink raw reply
* New software uploaded by Melissa on Oct 21 22:20:00 MSK 2006
From: Adobe Software @ 2006-10-21 18:36 UTC (permalink / raw)
To: git
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit, Size: 6726 bytes --]
Melissa has uploaded some new software for you!
Click here to view available updated software:
http://update.eroemka.com/?Melissa
booting a diskless workstation from Ethernet. You can include other
RSA Data Security, Inc., MD4 secure hash function) iteration-count
might be a good way to cleanly shut down the running system, sync()
``wd'' for ``sd'' appropriately. You otherwise mount extended
High-speed modems, like V.32, V.32bis, and V.34 modems, need to use
When you are using the parallel interface, you can choose whether
18.2.5.9. Package Names
One important note - the actual UART chips for the Boca 16 are in the
FreeBSD will also add subnet routes for the local subnet (10.20.30.255
The stock GENERIC kernel does not have this enabled by default, so you
drive size. It is useful to note that 32 * 64 / 2 = the size of your
Here is the /etc/printcap file with an entry for a printer using the
subscription request for a local mailing list (note: this is more
#!/bin/sh -
everybody forgets to remove the terminators from the controller. The
was based on DES, the Data Encryption Standard. This causes only
initialization devices (/dev/ttyid? and /dev/cuai0?) and locking
c. Use ftp. The source tree for FreeBSD-stable is always
9. The X-Window System
QIC
X.X.X.X is the IP address of the client. The contents of this file
TCP/IP connectivity, CTM was made for you. You will need to transfer
o An actual bug report should be filed by using the send-pr(1)
Digital Equipment DC21040 PCI Ethernet adapter
<freebsd-portsFreeBSD>if you are not sure what to do.
In my case, the controller could not handle this number of sectors. It
This guide was originally written for SLIP Server services on a
For as many `DISTS' you wish to install from MS-DOS (and you have free
Restoring a damaged filesystem requires the most recent full backup
If you have a poor quality ethernet card which suffers from very slow
it." Even in small desktop configurations, SCSI often makes more
Enable the queue for a printer. Users can submit jobs but the
place of 10.0.0.1.
computer. We're using `port' here to mean the result of `porting' a
o FreeBSD is a 32-bit operating system and was designed as such from
Newer stuff uses 15 Mbits/second.
signals to itself on behalf of LPD.
make three megabytes (which is 6144 disk blocks) the amount of free
By default this part is similar to the NS16550A, but an extended
18.2.5.7.11. Subdirectories
o ftp.jp.FreeBSD/pub/FreeBSD
One obvious way to get header pages is to have every conversion filter
Most ESDI controllers offer the possibility to remap bad sectors.
teak|hp|laserjet|Hewlett Packard LaserJet 3Si:\
unlikely that FreeBSD would have gotten as far, as fast, as it has
Bit 3 Framing Error (FE)
The st(4) driver provides support for 8mm (Exabyte), 4mm (DAT: Digital
Add an entry to the firewall/accounting rule list
quota utilities do not seem to handle this properly.
in Matches if the packet is on the way in.
terms permitting, of course!) and so on.
:sh:
lines as your ISP provides nameservers.
o If the printer does not support any flow control, use some
devices have single-character buffers. The 16550 device provides a
16.2. Who needs FreeBSD-stable?
6.2.1. Secure connection initialization
example of how a machine may be made aware of multiple realms. You may
By using the sc capability, we prevent the use of lpr -#, but that
reading this port.
______________________________________________________________________
missing device special files.
device eg0 at isa? port 0x310 net irq 5 vector egintr
``Header Page Options'' for more lpr options.
<dysonFreeBSD>
# /etc/printcap for host rose - added spooling directories
<freebsd-docFreeBSD>The latest version of this document is
Kerberos is a network add-on system/protocol that allows users to
files, header pages, printing across networks, and restricting and
# the parameters:
If you have a poor quality ethernet card which suffers from very slow
If your machine is already running MS-DOS and has little or no free
configuration'' for more information on creating custom kernels.
receive FIFO that the host may read.
Information Protocol), which figures out routes to local hosts based
EISA, and PCI busses are assumed to be bridged from ISA. This is
you have general FTP access to the Internet then the following FTP
listed by clicking on their names. If no coordinator has been
popular with us due to the amount of extra effort demanded of
are created/deleted during the backup and more. She presented the
Enter Kerberos master key:
technical discussions mailing list <freebsd-hackersFreeBSD>
copies of each file in the job. Whether this is a good thing is up to
transmitter may still be transmitting
lrwxr-xr-x 1 bin bin 15 Sep 5 12:50 libcrypt_p.a -> libdescrypt_p.a
exit 0;
10.4.5.7.7.
the new data lies in a band surrounded on both sides by the previous
o ftp2.de.FreeBSD/pub/FreeBSD
16450, and may not make effective use of the extra buffering present
+0x07 write/read Scratch Register (SCR)
# psif - Print PostScript or plain text on a PostScript printer
Before explaining how to generate one-time passwords, we should go
hostname=myname.my.domain
ST16650
`CATEGORIES' states what kind of program this is.
Master key entered. BEWARE!
# Simply copies stdin to stdout. Ignores all filter arguments.
contains the programs that normally use DES. The auxiliary packages
through all your floppies, packing as many files as will fit on each
spooling directory, not the remote. It is still useful, though.
By default this part behaves similar to the NS16550A, but an
to reflect your configuration or the changes you have made to
Firmware revisions prior to "25462 -011" are bug ridden and will not
57:(kgdb) up
64 (0-63). When you combine the 1024 cylinder limit with the 16 head
current interrupt must be resolved before
If you are using telnet or rlogin exit with no password and use keyinit -s.
slakware/x6/oldlibs/tgz
www.adaptec) and answered NO to the question whether the disk
routes), then the system checks to see if it can connect along that
Bug reports
kernel is finally started with %cs 0x08 and %ds/%es/%ss 0x10, which
The FreeBSD Documentation Project
Reflects the state of the CTS line on
Netboot will try to find a supported Ethernet card, and use
o orgchem.weizmann.ac.il/pub/FreeBSD
18.2.5.7.12. ldconfig
of printer in use, the formats being printed, and your requirements in
the option of suppressing the header pages with lpr -h, they will
appears in the entry for a locally-attached printer, LPD will
|| die "Can't create TCP/IP stream socket: $!";
of SCSI" (First book along with a one-hour video and tutorial
^ permalink raw reply
* Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle
From: Linus Torvalds @ 2006-10-21 18:42 UTC (permalink / raw)
To: Jan Hudec; +Cc: Jeff King, bazaar-ng, git, Jakub Narebski
In-Reply-To: <20061021174056.GA29927@artax.karlin.mff.cuni.cz>
On Sat, 21 Oct 2006, Jan Hudec wrote:
>
> [ On not moving files that weren't moved originally, but whose
> directories were moved ]
>
> I still consider it a bug, but different problems of the file-id
> solution have already been described in this thread that I consider bugs
> as well.
>
> Besides I start to think that it should be actually possible to solve
> this case with the git-style approach.
It's certainly _possible_ to figure out, but one reason git does what it
does is that it's just simpler (ie just ignore the whole "directory move"
situation entirely, and just consider it to be "many files moved").
Another reason is that this really is an ambigious case. When the
directory was moved, the file in question really didn't exist. So when it
was created independently of the move, it really _is_ somewhat ambiguous
whether the intention was to move it with the other files or whether the
new creation point is the right one.
I think that for a human, the details would likely be obvious (and I
suspect that in most cases it would indeed move with the directory). But
it really isn't totally clear: what does moving a directory imply for the
future? Does it imply that the directory should never exist in the future,
or does it just imply that the _current_ contents move?
Git "tends to" have a policy of not caring about directories at all. For
example, git will not track an empty directory by default. You _can_ make
it track one in your commits (the data structures support it), but you're
really just better of just thinking of git as tracking individual files,
and nor really directories. So as far as git is concerned, "directories"
mostly don't really have any existence on their own, they only exist as
paths to reach files.
In that kind of mindset, renaming a directory really is about renaming the
files that are in that directory, and that explains the git behaviour. It
may not necessarily be what you expect, but it _is_ consistent, and it's
not really "wrong" either. It's just another way of looking at the thing.
Also, I'd like to point out that people worry way too much about merges.
There are much harder merge conflicts to fix up. If you notice that things
didn't go the way you expected in a merge, even if it was done
automatically, you can just do a
git mv unexpected/directory/file expected/directory/file
git commit --amend
which basically "fixes up" the automatic merge (that's what the "--amend"
means: it means "re-do the last commit with _this_ state instead).
(Of course, you could also just make a separate commit to move the file,
but I think the "manual fixup of the merge" is just cleaner - just add a
note in the commit message to say you fixed it up by hand. When you do
your "git commit --amend", it will automatically just give you an editor
to edit up the commit message too while you're at it).
So again: merges are certainly fairly "hard" from a SCM standpoint, but
from a user standpoint, they tend to be not at all as important. I would
again argue that more important than the merge itself (which you can
trivially just fix up to match your expectations) is to make it easy to
later _show_ what happened, ie if you examine the file later, you should
be able to see where it came from.
(And again, with git, things like "git pickaxe" - think of it as just a
"better annotate" - will indeed pick up the similarity, regardless of
whether the rename was done manually or automatically as part of the
merge - exactly because git only really cares about actual contents).
Btw, just to be honest: git _mostly_ thinks in terms of "constant
pathname patterns" as opposed to "individual paths that move around".
That's at least partly because of how I work. I actually fairly seldom
look at an individual file, and tend to much more often look at a group of
files, and then it's a _lot_ more convenient to do
gitk drivers/usb include/linux/usb*
where those argument pathnames are _not_ a set of filenames that we track,
but really somethign more generic, namely a "repository pathname subset"
which is constant. The above will show the _subset_ of the kernel
repository history that is relevant for all the named pathnames, but the
pathnames are _fixed_. It won't follow files that move out of the
subdirectories: it will show the history as seen from the viewpoint of a
certain subset of pathnames.
This also extends to things like "git log". So when you do
git log kernel/sched.c
if you have a "file ID" mentality, you expect the above to follow renames.
It doesn't - even though git -can- follow renames, what the above actually
_means_ is "show the log for the fixed pathname set that only includes one
single path".
So if "kernel/sched.c" had originally been called something else, the
above wouldn't show the rename at all. It would just show that "oh, this
pathname suddenly was created as a new file", because from the viewpoint
of that fixed pathname, that's _exactly_ what happens.
We've discussed adding a "--follow" flag to tell "git log" to consider the
argument to not be a "pathname filter", but a "individual file" kind of
thing, and I think there was even a patch for it, but I suspect it hasn't
been a big issue, probably partly because you get rather used to the
"pathname filter" approach fairly quickly. If you knew what the old
pathname was, for example, you could get git to _tell_ you about the
rename by doing
git log -M -- <set-of-all-pathnames-we're-interested-in-old-included>
and git would happily see the renames that happen _within_ that pathname
filter (the "-M" is there because by default "git log" doesn't show any
patches at all, of course, so if you want to see the rename, you need to
tell git so).
As a particular example of this behaviour, if you do
git log -M kernel/
you'll always see any renames that happen _within_ that subdirectory, but
any files that are moved into (or out of) the subdirectory will be
considered to be "create" or "delete" events - because you've literally
told git to ignore all history that is not relevant to the kernel/
subdirectory (so they really _are_ "create/delete" events as far as that
subdirectory is concerned).
Is this different from other SCM's? Hell yes. git does a lot of things
differently. Is it useful? Again, hell yes. Especially for a maintainer,
the ability to talk about pathname _patterns_ is generally much more
important than talking about any particular file.
[ The pathname thing also means that it's trivial to ask questions like
"ok, so what happened to file xyz that I _know_ we used to have, but
clearly don't have any more?".
You just do "git log -- xyz", and you'll see exactly what you wanted to
see. The "--" here (and in a previous example) is because to avoid
ambiguity, git requires that if you name files that don't actually
exist, you make it clear that they are filenames, not just mistyped
revision ID's or something else. ]
In general, git gives you the best of both worlds. It knows how to follow
individual files if you want to, but by default it uses this much more
generic concept of "pathname filters". The default is definitely
influenced both by my usage, and my (obviously very strong) opinions on
what is more important (and thus the git "mental model").
Linus
^ permalink raw reply
* Re: VCS comparison table
From: Sean @ 2006-10-21 18:47 UTC (permalink / raw)
To: Jan Hudec; +Cc: Linus Torvalds, bazaar-ng, git, Matthieu Moy, Jakub Narebski
In-Reply-To: <20061021183428.GB29927@artax.karlin.mff.cuni.cz>
On Sat, 21 Oct 2006 20:34:28 +0200
Jan Hudec <bulb@ucw.cz> wrote:
> For one think I, like others already expressed, think difference should
> be made between 'centralized' and 'star-topology'. Subversion is
> centralized -- I don't think bzr is biased towards that kind of
> centralization, though it provides tools (bound branches) to make it
> easy.
A star-topology assumes there is a central server from which the points
of the start emerge. It is very much a centralized model and one that
bzr is clearly optimized for. The difference between bzr and say
cvs is that bzr provides offline abilities where checkins to the
central server can be deferred by checking them in locally first.
The bzr bias towards this model is implicit in its affection for
revnos, which depend on a central repository to syncronize them for
all the points of the star.
[...]
> On the other hand git is biased away from centralized (as in subversion
> is centralized) in that it takes extra work to make sure you are always
> synchronized (while bzr has bound branches to do the checking for you).
> For open-source development, centralized is a wrong way to go, but
> people use version control tools for other purposes as well and for some
> of them staying synchronized is important.
Please reconsider this point, Git can be configured to push every commit
to a central server immediately. It's just that such a model is so inferior
in almost every way, that it's not typically done.
Sean
^ permalink raw reply
* Re: VCS comparison table
From: Sean @ 2006-10-21 18:47 UTC (permalink / raw)
To: Jan Hudec; +Cc: Linus Torvalds, bazaar-ng, Matthieu Moy, git, Jakub Narebski
In-Reply-To: <20061021183428.GB29927@artax.karlin.mff.cuni.cz>
On Sat, 21 Oct 2006 20:34:28 +0200
Jan Hudec <bulb@ucw.cz> wrote:
> For one think I, like others already expressed, think difference should
> be made between 'centralized' and 'star-topology'. Subversion is
> centralized -- I don't think bzr is biased towards that kind of
> centralization, though it provides tools (bound branches) to make it
> easy.
A star-topology assumes there is a central server from which the points
of the start emerge. It is very much a centralized model and one that
bzr is clearly optimized for. The difference between bzr and say
cvs is that bzr provides offline abilities where checkins to the
central server can be deferred by checking them in locally first.
The bzr bias towards this model is implicit in its affection for
revnos, which depend on a central repository to syncronize them for
all the points of the star.
[...]
> On the other hand git is biased away from centralized (as in subversion
> is centralized) in that it takes extra work to make sure you are always
> synchronized (while bzr has bound branches to do the checking for you).
> For open-source development, centralized is a wrong way to go, but
> people use version control tools for other purposes as well and for some
> of them staying synchronized is important.
Please reconsider this point, Git can be configured to push every commit
to a central server immediately. It's just that such a model is so inferior
in almost every way, that it's not typically done.
Sean
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox