* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-20 13:26 UTC (permalink / raw)
To: Petr Baudis
Cc: Matthieu Moy, Andreas Ericsson, Matthew D. Fuller, bazaar-ng,
Linus Torvalds, Carl Worth, git
In-Reply-To: <200610201350.12273.jnareb@gmail.com>
Jakub Narebski wrote:
> Second, git-diff with only one <commit-ish> generates diff to first
> parent. But you can always use '-c' or '-cc' combined diff format
> or '-m' with default diff format to compare to _all_ parents.
I stand corrected: git-diff refuses to show anything if provided
with only one commit, and commit has more than one parent. So it
does not reat first parent specially.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.4.3
From: Peter Eriksen @ 2006-10-20 13:26 UTC (permalink / raw)
To: git; +Cc: linux-kernel
In-Reply-To: <7vejt5xjt9.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> The latest feature release GIT 1.4.3 is available at the usual
> places:
...
> ----------------------------------------------------------------
>
> .gitignore | 10 +-
> Documentation/Makefile | 4 +-
> Documentation/asciidoc.conf | 1 +
> Documentation/config.txt | 34 +
...
> rename contrib/gitview/{gitview.txt => gitview.txt} (74%)
How does it come to the result, that this is a rename?
Peter
^ permalink raw reply
* Re: VCS comparison table
From: Petr Baudis @ 2006-10-20 13:36 UTC (permalink / raw)
To: Jakub Narebski
Cc: James Henstridge, bazaar-ng, Linus Torvalds, Carl Worth,
Andreas Ericsson, git
In-Reply-To: <200610201517.26702.jnareb@gmail.com>
Dear diary, on Fri, Oct 20, 2006 at 03:17:26PM CEST, I got a letter
where Jakub Narebski <jnareb@gmail.com> said that...
> But you can also clone _whole_ repository, _all_ published branches with
>
> $ cg clone git://git.kernel.org/pub/scm/git/git.git
Nope, cg clone will in this case clone the master branch (or whatever
the remote HEAD points at). cg clone -a is planned but not implemented
yet. Very soon now, hopefully. :-)
> In GIT to work on some repository you don't (like from what I understand
> in Bazaar-NG) "checkout" some branch (which would automatically copy some
> data in case of "heavy checkout" or just save some pointer to repository
> in "lightweight checkout" case). You clone whole repository; well you can
> select which branches to clone. "Checkout" in GIT terminology means to
> populate working area with given version (and change in repository which
> branch is current, usually).
You don't need to, you can switch your working tree between various
branches. I think Linus said he does that (or was it Junio?), and I do that
as well, as well as many others.
A good question would be "when to create another branch and when to
clone the repository". And I don't think there's any good answer, except
"when you are comfortable with it". :-) Both approaches have pros/cons.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* Re: VCS comparison table
From: Shawn Pearce @ 2006-10-20 13:36 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <eha926$uc$2@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> wrote:
> from discussion on #revctrl list on FreeNode), and in addition
> to existing GitSvnComparison page on GitWiki).
Oh, you mean that document that I orphaned when I got sidetracked
and forgot I hadn't quite finished it? :-)
--
Shawn.
^ permalink raw reply
* Re: VCS comparison table
From: Christian MICHON @ 2006-10-20 13:46 UTC (permalink / raw)
To: bazaar-ng, git
In-Reply-To: <200610201322.k9KDMKk0011370@laptop13.inf.utfsm.cl>
On 10/20/06, Horst H. von Brand <vonbrand@inf.utfsm.cl> wrote:
> Are you saying Bazaar is aimed at small(ish) projects (only)?
funny. I actually read another post from Linus, and when I
"merge" with your post (understand: bisect), the following
comes out:
- git is the fastest scm around
- git has the smallest scm footprint
- git is also aimed at small(ish) projects
my personal proof of concept on the last point is that I'm a
IC design engineer who threw away other scm in favor of git
since git-1.4.2 and regret now the years wasted on _other_
scm. But your mileage may vary.
--
Christian
^ permalink raw reply
* Re: VCS comparison table
From: Petr Baudis @ 2006-10-20 13:47 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Matthieu Moy, bazaar-ng, git
In-Reply-To: <200610201520.42799.jnareb@gmail.com>
Dear diary, on Fri, Oct 20, 2006 at 03:20:42PM CEST, I got a letter
where Jakub Narebski <jnareb@gmail.com> said that...
> Matthieu Moy wrote:
> > Jakub Narebski <jnareb@gmail.com> writes:
> >
> > >> If you're interested, it's called "Bugs Everywhere" and it's available here:
> > >> http://panoramicfeedback.com/opensource/
> > >>
> > >> New VCS backends are welcome :-D
> > >
> > > While SCM can (and should be usually) distributed, I think that bugtracker
> > > has to be centralized.
> >
> > Well, indeed, I think bug _reporting_ should be somehow centralized,
> > while bug _fixing_ can be decentralized: You fix a bug, you mark it as
> > fixed, and then the main branch gets the information that the bug is
> > fixed when the bugfix is merged.
>
> But you don't need much infrastructure for branch fixing. Fix it in
> repository, and write bug number (you have to have centralized bugtracker
> for numbers) or bug identifier in commit message. You write (or post-commit
> hook writes) in bugtracker that bug was fixed in commit <commit-id>.
> You tell mainline to pull from you. That's all.
Yes but noone did the infrastructure yet. :-) Also, we need a way to
make it worth smooth, e.g. so that you don't have to download any
special stuff after cloning a branch - thus the post-commit hook needs
to be cloned too, but you also need to deal with the security
implications reasonably. (We would very much like to have "hooks
cloning" in Git in our in-SUSE usage as well; I didn't get to it yet.)
On a somewhat related note, I was on Microsoft's presentation at my
university about their Team Foundation Server. And Microsoft's clearly
aware that SourceSafe was a horrible crap and the version control in TFS
is much more advanced and even shows some signs of distributiveness (but
I don't know how much, the presenter did not know details about how it
works).
But their selling point really is the tight integration with bug
tracking and autobuild system. And it indeed does look pretty nice (when
you watch it, you might get quite a different perspective when actually
*using* it ;).
You can read my brief notes from the presentation at
http://pasky.or.cz/~pasky/cp/tfs-lecture-notes.txt
It's a bit of bureaucracy for developers but managers will absolutely
*adore* it.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle
From: Aaron Bentley @ 2006-10-20 14:03 UTC (permalink / raw)
To: Sean; +Cc: Alexander Belchenko, bazaar-ng, git
In-Reply-To: <BAYC1-PASMTP061F10D0B5AF9F6608134CAE0C0@CEZ.ICE>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Sean wrote:
> Petr already mentioned that the data currently shown in the email
> text isn't really useful.
In Bazaar bundles, the text of the diff is an integral part of the data.
It is used to generate the text of all the files in the revision.
Bazaar bundles were designed to be used on mailing lists. So you can
review the changes from the diff, comment on them, and if it seems
suitable, merge them.
> Although that might just make the email bigger for not a lot of
> gain.
It's my understanding that most changes discussed on lkml are provided
as a series of patches. Bazaar bundles are intended as a direct
replacement for patches in that use case.
Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFFONck0F+nu1YWqI0RAgrHAJ0flmF1wCGYYUSk8f2iy8LuZnkaKQCdFSIo
JIaKi9S8TzUkhvaWpYYP5AA=
=MgZo
-----END PGP SIGNATURE-----
^ permalink raw reply
* problem with gitk --all on OSX, unknown option "-state"
From: Seth Falcon @ 2006-10-20 14:11 UTC (permalink / raw)
To: git
Hi,
On OSX (ppc 10.4.8), I'm unable to run gitk --all. Without arguments,
gitk seems to work fine. This is with git version 1.4.2.4.g3453.
There error message is surprising because the line before has:
.bar.view entryconf 2 -state normal
and there is no complaint there about -state being unknown...
ziti:~/proj/bioc-2.0-git$ gitk --all
Error in startup script: unknown option "-state"
while executing
".bar.view entryconf 3 -state normal"
invoked from within
"if {$cmdline_files ne {} || $revtreeargs ne {}} {
# create a view for the files/dirs specified on the command line
set curview 1
set selec..."
(file "/Users/seth/scm/bin/gitk" line 6283)
Thanks,
+ seth
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-20 14:12 UTC (permalink / raw)
To: Petr Baudis
Cc: James Henstridge, bazaar-ng, Linus Torvalds, Carl Worth,
Andreas Ericsson, git
In-Reply-To: <20061020133630.GH20017@pasky.or.cz>
Petr Baudis wrote:
> Dear diary, on Fri, Oct 20, 2006 at 03:17:26PM CEST, I got a letter
> where Jakub Narebski <jnareb@gmail.com> said that...
>> But you can also clone _whole_ repository, _all_ published branches with
>>
>> $ cg clone git://git.kernel.org/pub/scm/git/git.git
>
> Nope, cg clone will in this case clone the master branch (or whatever
> the remote HEAD points at). cg clone -a is planned but not implemented
> yet. Very soon now, hopefully. :-)
That's probably because Cogito still uses obsolete branches/
$ git clone git://git.kernel.org/pub/scm/git/git.git
clones _whole_ repository, all the branches and tags, and saves information
about the branches it cloned, and URL to repository in remotes/ file.
>> In GIT to work on some repository you don't (like from what I understand
>> in Bazaar-NG) "checkout" some branch (which would automatically copy some
>> data in case of "heavy checkout" or just save some pointer to repository
>> in "lightweight checkout" case). You clone whole repository; well you can
>> select which branches to clone. "Checkout" in GIT terminology means to
>> populate working area with given version (and change in repository which
>> branch is current, usually).
>
> You don't need to, you can switch your working tree between various
> branches. I think Linus said he does that (or was it Junio?), and I do that
> as well, as well as many others.
I should have said: bring working area to state given by some revision
(instead of "populate working area").
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: VCS comparison table
From: Jeff King @ 2006-10-20 14:12 UTC (permalink / raw)
To: Aaron Bentley
Cc: Carl Worth, Linus Torvalds, Jakub Narebski, Andreas Ericsson,
bazaar-ng, git
In-Reply-To: <45382120.9060702@utoronto.ca>
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
(Yes, I am capable of performing subtraction in my head, but I find that
a "parent-of" operator matches my cognitive model better, especially
when you get into things like d8a60^2~3).
Does bzr have a similar shorthand for mentioning relative commits?
-Peff
^ permalink raw reply
* (unknown)
From: andyparkins @ 2006-10-20 14:21 UTC (permalink / raw)
>From 0e3c0aefc3276bd271553d171ed9bcc52d85230e Mon Sep 17 00:00:00 2001
From: Andy Parkins <andyparkins@gmail.com>
Date: Fri, 20 Oct 2006 15:21:02 +0100
Subject: [PATCH] Use email address only for looking up signing key in git-tag
To: git@vger.kernel.org
MIME-Version: 1.0
X-TUID: 312298ab1a3cb74a
X-UID: 98
X-Length: 2046
Content-Type: Multipart/Mixed;
boundary="Boundary-00=_PtNOFMGj306NIAG"
Message-Id: <200610201521.03122.andyparkins@gmail.com>
This is a multi-part message in MIME format.
--Boundary-00=_PtNOFMGj306NIAG
Content-Type: text/plain;
charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
I did this:
$ git tag -s adp-sign-tag
gpg: skipped "Andy Parkins <andyparkins@gmail.com>": secret key not
available
gpg: signing failed: secret key not available
failed to sign the tag with GPG.
I believe the problem is that I have used the comment field in my key's UID
definition.
$ gpg --list-keys andy
pub 1024D/4F712F6D 2003-08-14
uid Andy Parkins (Google) <andyparkins@gmail.com>
So when git-tag looks for "Andy Parkins <andyparkins@gmail.com>"; it's not
found. The answer is (I think) to search only on the email address when
looking for a key.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
git-tag.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
--Boundary-00=_PtNOFMGj306NIAG
Content-Type: text/x-patch;
name="0e3c0aefc3276bd271553d171ed9bcc52d85230e.diff"
Content-Transfer-Encoding: 8bit
Content-Disposition: inline;
filename="0e3c0aefc3276bd271553d171ed9bcc52d85230e.diff"
diff --git a/git-tag.sh b/git-tag.sh
index a0afa25..6fd98e2 100755
--- a/git-tag.sh
+++ b/git-tag.sh
@@ -73,7 +73,7 @@ git-check-ref-format "tags/$name" ||
object=$(git-rev-parse --verify --default HEAD "$@") || exit 1
type=$(git-cat-file -t $object) || exit 1
tagger=$(git-var GIT_COMMITTER_IDENT) || exit 1
-: ${username:=$(expr "z$tagger" : 'z\(.*>\)')}
+: ${username:=$(expr "z$tagger" : 'z.*<\(.*\)>')}
trap 'rm -f "$GIT_DIR"/TAG_TMP* "$GIT_DIR"/TAG_FINALMSG "$GIT_DIR"/TAG_EDITMSG' 0
--Boundary-00=_PtNOFMGj306NIAG--
^ permalink raw reply related
* (unknown)
From: andyparkins @ 2006-10-20 14:24 UTC (permalink / raw)
>From 9c128bc4b9b85385b7b98ceae0c89283d70e5d45 Mon Sep 17 00:00:00 2001
From: Andy Parkins <andyparkins@gmail.com>
Date: Fri, 20 Oct 2006 15:24:22 +0100
Subject: [PATCH] Remove git-send-email references from documentation
MIME-Version: 1.0
X-TUID: 1fbae8e75caaf795
X-Length: 1933
To: git@vger.kernel.org
Content-Type: Multipart/Mixed;
boundary="Boundary-00=_WwNOFc8Re2ORHlu"
Message-Id: <200610201524.22493.andyparkins@gmail.com>
This is a multi-part message in MIME format.
--Boundary-00=_WwNOFc8Re2ORHlu
Content-Type: text/plain;
charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
git-send-email doesn't exist; so don't refer to it in the documentation.
Perhaps git-send-email.perl is meant to do this job? It runs with an error.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
Documentation/git-format-patch.txt | 2 +-
Documentation/git.txt | 3 ---
2 files changed, 1 insertions(+), 4 deletions(-)
--Boundary-00=_WwNOFc8Re2ORHlu
Content-Type: text/x-patch;
name="9c128bc4b9b85385b7b98ceae0c89283d70e5d45.diff"
Content-Transfer-Encoding: 8bit
Content-Disposition: inline;
filename="9c128bc4b9b85385b7b98ceae0c89283d70e5d45.diff"
diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
index 67425dc..9257030 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -112,7 +112,7 @@ git-format-patch -M -B origin::
See Also
--------
-gitlink:git-am[1], gitlink:git-send-email[1]
+gitlink:git-am[1]
Author
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 3af6fc6..1f60d3f 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -478,9 +478,6 @@ gitlink:git-request-pull[1]::
gitlink:git-rev-parse[1]::
Pick out and massage parameters.
-gitlink:git-send-email[1]::
- Send patch e-mails out of "format-patch --mbox" output.
-
gitlink:git-symbolic-ref[1]::
Read and modify symbolic refs.
--Boundary-00=_WwNOFc8Re2ORHlu--
^ permalink raw reply related
* (unknown)
From: andyparkins @ 2006-10-20 14:24 UTC (permalink / raw)
>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
MIME-Version: 1.0
X-TUID: 260426abfb2864ec
X-Length: 2046
To: git@vger.kernel.org
Content-Type: Multipart/Mixed;
boundary="Boundary-00=_owNOFStzYauRv42"
Message-Id: <200610201524.40525.andyparkins@gmail.com>
This is a multi-part message in MIME format.
--Boundary-00=_owNOFStzYauRv42
Content-Type: text/plain;
charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
I did this:
$ git tag -s adp-sign-tag
gpg: skipped "Andy Parkins <andyparkins@gmail.com>": secret key not
available
gpg: signing failed: secret key not available
failed to sign the tag with GPG.
I believe the problem is that I have used the comment field in my key's UID
definition.
$ gpg --list-keys andy
pub 1024D/4F712F6D 2003-08-14
uid Andy Parkins (Google) <andyparkins@gmail.com>
So when git-tag looks for "Andy Parkins <andyparkins@gmail.com>"; it's not
found. The answer is (I think) to search only on the email address when
looking for a key.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
git-tag.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
--Boundary-00=_owNOFStzYauRv42
Content-Type: text/x-patch;
name="0e3c0aefc3276bd271553d171ed9bcc52d85230e.diff"
Content-Transfer-Encoding: 8bit
Content-Disposition: inline;
filename="0e3c0aefc3276bd271553d171ed9bcc52d85230e.diff"
diff --git a/git-tag.sh b/git-tag.sh
index a0afa25..6fd98e2 100755
--- a/git-tag.sh
+++ b/git-tag.sh
@@ -73,7 +73,7 @@ git-check-ref-format "tags/$name" ||
object=$(git-rev-parse --verify --default HEAD "$@") || exit 1
type=$(git-cat-file -t $object) || exit 1
tagger=$(git-var GIT_COMMITTER_IDENT) || exit 1
-: ${username:=$(expr "z$tagger" : 'z\(.*>\)')}
+: ${username:=$(expr "z$tagger" : 'z.*<\(.*\)>')}
trap 'rm -f "$GIT_DIR"/TAG_TMP* "$GIT_DIR"/TAG_FINALMSG "$GIT_DIR"/TAG_EDITMSG' 0
--Boundary-00=_owNOFStzYauRv42--
^ permalink raw reply related
* Re: VCS comparison table
From: Jeff King @ 2006-10-20 14:31 UTC (permalink / raw)
To: J. Bruce Fields
Cc: Carl Worth, Aaron Bentley, Linus Torvalds, Jakub Narebski,
Andreas Ericsson, bazaar-ng, git
In-Reply-To: <20061019171409.GA31671@fieldses.org>
On Thu, Oct 19, 2006 at 01:14:09PM -0400, J. Bruce Fields wrote:
> > > In the second place, one must consider the "nuclear launch codes"
> > > scenario.
> > Sure. And git does provide tools that can do this.
>
> So in this case you can certainly lose the launch codes. But you have
> forever granted everyone a way to determine whether a given guess at the
> launch codes is correct. (Again, assuming some stuff about SHA1).
In what sense? Yes, you can make a guess if you have stored the SHA1
that contained the launch codes. But the point is that that particular
SHA1 is no longer part of the repository. Keeping that SHA1 is no easier
than just keeping the launch codes in the first place.
-Peff
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-20 14:40 UTC (permalink / raw)
To: Jeff King
Cc: Aaron Bentley, Carl Worth, Linus Torvalds, Andreas Ericsson,
bazaar-ng, git
In-Reply-To: <20061020141222.GA17497@coredump.intra.peff.net>
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
By the way "diff d8a60" also works (unless d8a60 is merge commit, in
which case you would need "diff -c d8a60" or "diff -m d8a60").
> (Yes, I am capable of performing subtraction in my head, but I find that
> a "parent-of" operator matches my cognitive model better, especially
> when you get into things like d8a60^2~3).
>
> Does bzr have a similar shorthand for mentioning relative commits?
By the way, git has the following extended SHA1 syntax for <commit-ish>
(documented in git-rev-parse(1)):
* full SHA1 (40-chars hexadecimal string) or abbreviation unique for
repository
* symbolic ref name. E.g. 'master' typically means commit object referenced
by $GIT_DIR/refs/heads/master; 'v1.4.1' means commit object referenced
[indirectly] by $GIT_DIR/refs/tags/v1.4.1. You can say 'heads/master'
and 'tags/master' if you have both head (branch) and tag named 'master',
but don't do that. HEAD means current branch (and is usually default).
* <ref>@{<date>} or <ref>@{<n>} to specify value of <ref> (usually branch)
at given point of time, or n changes to ref back. Available only if you
have reflog for given ref.
* <commit-ish>^<n> means n-th parent of given revision. <commit-ish>^0
means commit itself. <commit-ish>^ is a shortcut for <commit-ish>^1.
<commit-ish>~<n> is shortcut for <commit-ish>^^..^ with n*'^', for
example rev~3 is equivalent to rev^^^, which in turn is equivalent
to rev^1^1^1
Additionally it has following undocumented extended SHA1 syntax to refer
to trees (directories) and blobs (file contents)
* <revision>:<filename> gives SHA1 of tree or blob at given revision
* :<stage>:<filename> (I think for blobs only) gives SHA1 for different
versions of file during unresolved merge conflict.
I'm not enumerating here all the ways to specify part of DAG of history,
except that it includes "A ^B" meaning "all from A", "exclude all from B",
"B..A" meaning "^B A", "A...B" meaning "A B --not $(git merge-base A B)",
and of course "A -- path" meaning "all from A", "limit to changes in path".
What about _your_ SMC? ;-)
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle
From: Jeff King @ 2006-10-20 14:41 UTC (permalink / raw)
To: Linus Torvalds, Junio C Hamano, git
In-Reply-To: <20061020002032.GA7162@delft.aura.cs.cmu.edu>
On Thu, Oct 19, 2006 at 08:20:32PM -0400, Jan Harkes wrote:
> It looks like you were really close. When we cannot resolve a delta, we
> just write it to the packfile and we don't queue it. If it can be
> resolved we write it as a full object.
If I understand correctly, if we see an unresolvable delta, we are just
making the assumption that its base has arrived (or will arrive) in the
same pack (without checking). This means that we could end up with a
corrupted repository if the sender gives us a bad pack. I believe that
git's network interaction has been designed specifically to avoid such
possibilities (e.g., verifying completeness and integrity of downloaded
objects).
-Peff
^ permalink raw reply
* Re: your mail
From: Johannes Schindelin @ 2006-10-20 14:42 UTC (permalink / raw)
To: andyparkins; +Cc: git
In-Reply-To: <E1GavIN-0007Vi-00@dvr.360vision.com>
Hi,
your email is horridly mixed here. I get an empty subject here, and the
complete email header at the beginning of the email:
On Fri, 20 Oct 2006, andyparkins@gmail.com wrote:
> >From 9c128bc4b9b85385b7b98ceae0c89283d70e5d45 Mon Sep 17 00:00:00 2001
> From: Andy Parkins <andyparkins@gmail.com>
> [... complete email header including MIME header ...]
> Content-Disposition: inline
>
> git-send-email doesn't exist; so don't refer to it in the documentation.
But it does! I just removed it, and "make" remade it. I don't even see in
the Makefile why it should _not_ be made...
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Remove git-send-email references from documentation
From: Jakub Narebski @ 2006-10-20 14:46 UTC (permalink / raw)
To: git
In-Reply-To: <E1GavIN-0007Vi-00@dvr.360vision.com>
Please configure your mailer to _not_ send emails in Multipart/Mixed form!
For example it screws up GMane news<->email interface.
andyparkins@gmail.com wrote:
> git-send-email doesn't exist; so don't refer to it in the documentation.
>
> Perhaps git-send-email.perl is meant to do this job? It runs with an
> error.
Which git version do you use?
1063:jnareb@roke:~/git> which git-send-email
/usr/bin/git-send-email
1064:jnareb@roke:~/git> rpm -qf /usr/bin/git-send-email
git-email-1.4.2.1-1
1065:jnareb@roke:~/git> git --version
git version 1.4.2.1
git-send-email is created from git-send-email.perl during instalation
(by make install). And it works.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: VCS comparison table
From: Johannes Schindelin @ 2006-10-20 14:52 UTC (permalink / raw)
To: Jakub Narebski
Cc: Jeff King, Aaron Bentley, Carl Worth, Linus Torvalds,
Andreas Ericsson, bazaar-ng, git
In-Reply-To: <200610201640.36640.jnareb@gmail.com>
Hi,
On Fri, 20 Oct 2006, Jakub Narebski wrote:
> Jeff King wrote:
> >
> > 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
>
> By the way "diff d8a60" also works (unless d8a60 is merge commit, in
> which case you would need "diff -c d8a60" or "diff -m d8a60").
I could be wrong, but I have the impression (even after actually testing
it) that "git diff d8a60" is equivalent to "git diff d8a60..HEAD", _not_
"git diff d8a60^..d8a60".
IIRC we had a "-p" flag to denote "parent" once upon a time, but that no
longer works...
"git-show" is definitely what you want.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Remove git-send-email references from documentation
From: Andy Parkins @ 2006-10-20 14:56 UTC (permalink / raw)
To: git
In-Reply-To: <200610201425.48598.andyparkins@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 348 bytes --]
On Friday 2006 October 20 14:25, Andy Parkins wrote:
> git-send-email doesn't exist; so don't refer to it in the documentation.
Please ignore. I'm a muppet. I'm using the debian packages for git; and
git-send-email is packaged separately in the git-email package.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
andyparkins@gmail.com
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle
From: Jakub Narebski @ 2006-10-20 14:56 UTC (permalink / raw)
To: git; +Cc: bazaar-ng
In-Reply-To: <4538D724.5040508@utoronto.ca>
Aaron Bentley wrote:
> Sean wrote:
>
>> Petr already mentioned that the data currently shown in the email
>> text isn't really useful.
>
> In Bazaar bundles, the text of the diff is an integral part of the data.
> It is used to generate the text of all the files in the revision.
I thought that the diff was combined diff of changes.
> Bazaar bundles were designed to be used on mailing lists. So you can
> review the changes from the diff, comment on them, and if it seems
> suitable, merge them.
If you have only mega-diff, you can comment only on this mega-diff.
It is more usefull for changes which have natural mult-commit history,
to review and comment on each of commits/patches in series _separately_.
>> Although that might just make the email bigger for not a lot of
>> gain.
>
> It's my understanding that most changes discussed on lkml are provided
> as a series of patches. Bazaar bundles are intended as a direct
> replacement for patches in that use case.
As _series_ of patches. You have git-format-patch + git-send-email
to format and send them, git-am to apply them (as patches, not as branch).
I was under an impression that user sees only mega-patch of all the
revisions in bundle together, and rest is for machine consumption only.
cg-bundle doesn't have this "mega-diff", but has shortlog (does bzr
bundle has shortlog/log of changes contained therein?) and diffstat
was planned.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: VCS comparison table
From: James Henstridge @ 2006-10-20 14:59 UTC (permalink / raw)
To: Jakub Narebski
Cc: bazaar-ng, Linus Torvalds, Carl Worth, Andreas Ericsson, git
In-Reply-To: <200610201517.26702.jnareb@gmail.com>
On 20/10/06, Jakub Narebski <jnareb@gmail.com> wrote:
> James Henstridge wrote:
> > With the above layout, I would just type:
> > bzr branch http://server/repo/branch1
>
> With Cogito (you can think of it either as alternate Git UI, or as SCM
> built on top of Git) you would use
>
> $ cg clone http://server/repo#branch
>
> for example
>
> $ cg clone git://git.kernel.org/pub/scm/git/git.git#next
>
> to clone _single_ branch (in bzr terminology, "heavy checkout" of branch).
My understanding of git is that this would be equivalent to the "bzr
branch" command. A checkout (heavy or lightweight) has the property
that commits are made to the original branch.
> But you can also clone _whole_ repository, _all_ published branches with
>
> $ cg clone git://git.kernel.org/pub/scm/git/git.git
I suppose that'd be useful if you want a copy of all the branches at
once. There is no builtin command in Bazaar to do that at present.
> With core Git it is the same, but we don't have the above shortcut
> for checking only one branch; branches to checkout are in separate
> arguments to git-clone.
>
> In bzr it seems that you cannot distinguish (at least not only
> from URL) where repository ends and branch begins.
I guess this highlights that the two tools optimise for different workflows.
> > This command behaves identically whether the repository data is in
> > /repo or in /repo/branch1. Someone pulling from the branch doesn't
> > have to care what the repository structure is. Having a separate
> > namespace for branch names only really makes sense if the user needs
> > to care about it.
> >
> > As for hierarchical names, there is nothing stopping you from using
> > deaper directory structures with Bazaar too. Bazaar just checks each
> > successive parent directory til it finds a repository for the branch.
> >
> >> The idea of "branches (and tags) as directories" was if I understand
> >> it correctly introduced by Subversion, and from what can be seen from
> >> troubles with git-svn (stemming from the fact that division between
> >> project name and branch name is the matter of _convention_) at least
> >> slightly brain-damaged.
> >
> > I think you are a bit confused about how Bazaar works here. A Bazaar
> > repository is a store of trees and revision metadata. A Bazaar branch
> > is just a pointer to a head revision in the repository. As you can
> > probably guess, the data for the branch is a lot smaller than the data
> > for the repository.
> >
> > You can store the repository and branch in the same directory to get a
> > standalone branch. The layout I described above has a repository in a
> > parent directory, shared by multiple branches.
> >
> > If you are comparing Subversion and Bazaar, a Bazaar branch shares
> > more properties with a full Subversion repository rather than a
> > Subversion branch.
>
> Oh, that explained yet another difference between Bazaar-NG (and other
> SCM which uses similar model) and Git.
>
> In Git branch is just a pointer to head (top) commit (hence they are stored
> under .git/refs/heads/) in given line of development. Git also stores
> information (in .git/HEAD) about which branch we are currently on, which
> means on which branch git puts new commits. Nothing more (well, there
> can be log of changes to head in .git/logs/refs/heads/ but that is optional
> and purely local information). In Bazaar-NG you have to store (if I
> understand it correctly) mapping from revnos to revisions.
>
> By default (it means for example default behavior of git-clone, if we don't
> use --bare option) git repository is _embedded_ in working area. We have
Two points:
(1) if we are publishing branches, we wouldn't include working trees
-- they are not needed to pull or merge from such a branch.
(2) if we did have working trees, they'd be rooted at /repo/branch1
and /repo/branch2 -- not at /repo (since /repo is not a branch).
In case (2) there is a potential for conflicts if you nest branches,
but people don't generally trigger this problem with the way they use
Bazaar.
> So repo/branch wouldn't work, because 'branch' would conflict with working
> area files. GIT doesn't follow the CVS model of separate storage area
> (CVSROOT) and having only pointer to said area (files in CVS/
> subdirectories) in working directory.
That is fairly similar to the default mode of operation with Bazaar:
you have a repository, branch and working tree all rooted in the same
directory. If you have separated working trees and branches, then
that is because you specifically asked for it.
> In GIT to work on some repository you don't (like from what I understand
> in Bazaar-NG) "checkout" some branch (which would automatically copy some
> data in case of "heavy checkout" or just save some pointer to repository
> in "lightweight checkout" case). You clone whole repository; well you can
> select which branches to clone. "Checkout" in GIT terminology means to
> populate working area with given version (and change in repository which
> branch is current, usually).
I think you have a slight misunderstanding of what a Bazaar checkout is.
>
> How checked out working area looks like in Bazaar-NG?
The layout of a standalone branch would be:
.bzr/repository/ -- storage of trees and metadata
.bzr/branch/ -- branch metadagta (e.g. pointer to the head revision)
.bzr/checkout/ -- working tree book-keeping files
source code
If we use a shared repository, the contained branches would lack the
.bzr/repository/ directory. The parent directory would instead have a
.bzr/repository/, but usually wouldn't have .bzr/branch/ (unless there
is a branch rooted at the base of the repository).
if we are publishing a branch to a web server, we'd skip the working
tree, so the source code and .bzr/checkout/ directory would be
missing.
In the case of a checkout, the .bzr/branch/ directory has a special
format and acts as a pointer to the original branch. If the checkout
is lightweight, the .bzr/repository/ directory would be missing, and
bzr would need to contact the original branch for the data.
> >>> For similar reasons, the cost of publishing 20 related Bazaar branches
> >>> on my web server is generally not 20 times the cost of publishing a
> >>> single branch.
> >>>
> >>> I understand that you get similar benefits by a GIT repository with
> >>> multiple head revisions.
> >>
> >> You can get similar benefits by a GIT repository with shared object
> >> database using alternates mechanism. And that is usually preferred
> >> over storing unrelated branches, i.e. branches pointing to disconnected
> >> DAG (separate trees in BK terminology) of revision, if that you mean by
> >> multiple head revisions (because in GIT there is no notion of "mainline"
> >> branch, only of current (HEAD) branch).
> >
> > I may have got the git terminology wrong. I was trying to draw
> > parallels between the .git/refs/... files in a git repository and the
> > way multiple branches can be stored in a Bazaar repository.
>
> Yes, but using Git that way has serious disadvantages. For example
> there is only one current branch pointer and only one index (dircache)
> per git repository.
Okay. So using Bazaar terminology, this seems to be an issue of the
working tree being associated with the repository rather than the
branch?
[...]
> But I agree that saving "old fork" info as separate branch doesn't lead
> to that much inefficiency as might be thought.
>
> But after saving "old fork" as a branch revno based revision identifiers
> change from http://old.host/old/repo:127 to http://host/repo/old.fork:127
> That is maybe minimal change, but this is change!
Well, a branch can easily have multiple URLs even if there is only one
copy of it. I might write to it via local file access or sftp (which
would be a file: or sftp: URL).
Mirrors of branches don't usually confuse users (and remember that the
revision numbers are primarily intended for users -- if I am writing a
Bazaar plugin, I'd work in terms of revision IDs).
James.
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-20 15:05 UTC (permalink / raw)
To: git; +Cc: bazaar-ng
In-Reply-To: <46d6db660610200646r502d01d5kb84cc218c24e42ce@mail.gmail.com>
Christian MICHON wrote:
> - git is the fastest scm around
Mercurial also claims that. It probably depends on the benchmark, though.
But Mercurial (hg) lacks from what I understand persistent branches, and
has only partial support for renames. YMMV.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: VCS comparison table
From: Johannes Schindelin @ 2006-10-20 15:16 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, bazaar-ng
In-Reply-To: <ehaojp$2qv$2@sea.gmane.org>
Hi,
On Fri, 20 Oct 2006, Jakub Narebski wrote:
> Christian MICHON wrote:
>
> > - git is the fastest scm around
>
> Mercurial also claims that.
Funny. When you type in "mercurial" and "benchmark" into Google, the
_first_ hit is into "git Archives: Mercurial 0.4b vs git patchbomb
benchmark". Performed by the good Mercurial people.
Leaving git as winner.
Ciao,
Dscho
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-20 15:28 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, bazaar-ng
In-Reply-To: <Pine.LNX.4.63.0610201715040.14200@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> On Fri, 20 Oct 2006, Jakub Narebski wrote:
>
>> Christian MICHON wrote:
>>
>>> - git is the fastest scm around
>>
>> Mercurial also claims that.
>
> Funny. When you type in "mercurial" and "benchmark" into Google, the
> _first_ hit is into "git Archives: Mercurial 0.4b vs git patchbomb
> benchmark". Performed by the good Mercurial people.
>
> Leaving git as winner.
Check out http://git.or.cz/gitwiki/GitBenchmarks section "Quilt import
comparison of Git and Mercurial" for the latest (OLS2006) benchmark
by Mercurial. Probably not indexed by Google, or doesn't have high
pagerank because it is in PDF and fairly new (therefore has low
"citations" number).
--
Jakub Narebski
Poland
^ 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