* Re: Tags
From: Petr Baudis @ 2005-07-02 22:14 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Linus Torvalds, Eric W. Biederman, Daniel Barkalow,
Git Mailing List, Junio C Hamano, ftpadmin
In-Reply-To: <42C70A5B.9070606@zytor.com>
Dear diary, on Sat, Jul 02, 2005 at 11:42:51PM CEST, I got a letter
where "H. Peter Anvin" <hpa@zytor.com> told me that...
> Linus Torvalds wrote:
> >
> >Note that the fact that you use a common object store does not mean that
> >everything should be common.
\o/ Finally I have some hope that we don't end up with something
braindead w.r.t. the tags... ;-)
..snip..
> OK, so let me retell what I think I hear you say:
>
> - Store all the tags in the object store; they may conflict.
They may have the same "human-readable name", but they will have a
different hash.
> - Let each source user have a set of refs, and provide a method for the
> end user to select which refs to get.
>
> In other words, the only way (other than knowing what GPG keys to trust)
> to distinguish between your "v2.6.12" and J. Random Hacker's "v2.6.12"
> is that the former is referenced by *your* refs as opposed to JRH's
> refs.
After all, this is the best way to distinguish it, isn't it? Just "tag
name" without a name of the branch the tag concerns makes no sense -
that's the point I'm trying to get along. JRH's v2.6.12 wouldn't make
much sense to you if you use Linus' v2.6.12, since the object JRH's
v2.6.12 references simply may not be in the branch you use. Yes, JRH
could tag it somewhere in the common past, but that's kind of strange
and is likely some private JRH's stuff. If Linus merged JRH, he will
take his v2.6.12 if it makes sense in his branch - so the decision
is then up to the one who merges, which makes some sense too.
FYI, I'll teach Cogito about the refs/tags/<branch>/<tag> later today
(and totally offtopic, it already has some trivial cg-push now).
It will still fall back to refs/tags/<tag>.
> This also means the refs cannot be uniquely rebuilt from the
> object storage.
Why should they be, after all.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
<Espy> be careful, some twit might quote you out of context..
^ permalink raw reply
* Re: Tags
From: Linus Torvalds @ 2005-07-02 22:17 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Eric W. Biederman, Daniel Barkalow, Git Mailing List,
Junio C Hamano, ftpadmin
In-Reply-To: <42C70A5B.9070606@zytor.com>
On Sat, 2 Jul 2005, H. Peter Anvin wrote:
>
> OK, so let me retell what I think I hear you say:
>
> - Store all the tags in the object store; they may conflict.
No. They cannot conflict.
A git "tag object" cannmot conflict in any way. It is just a generic
"pointer object", and like all other objects, it is defined by its
contents, and there are no "conflicts". If two people have exactly the
same pointer, they'll just have the same object - that's not a conflict,
that's just a fact of life with content-addressable filesystems.
The git "tag object" contains a suggested symbolic name, but that actually
has no meaning except as being informational. So for example:
[torvalds@g5 linux]$ git-cat-file tag v2.6.12
object 9ee1c939d1cb936b1f98e8d81aeffab57bae46ab
type commit
tag v2.6.12
This is the final 2.6.12 release
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQBCsykyF3YsRnbiHLsRAvPNAJ482tCZwuxp/bJRz7Q98MHlN83TpACdHr37
o6X/3T+vm8K3bf3driRr34c=
=sBHn
-----END PGP SIGNATURE-----
here the "symbolic name" is "v2.6.12", but that's purely informational,
and nothing at all cares if a million people have made their own tags that
have that same tag-name. The git _object_ is:
[torvalds@g5 linux]$ git-rev-parse v2.6.12
26791a8bcf0e6d33f43aef7682bdb555236d56de
and that object name is going to be unique (modulo hash collissions)
> - Let each source user have a set of refs, and provide a method for the
> end user to select which refs to get.
Right. Let users have any damn refs they want. They may be refs to tags
objects, but they may just be direct refs to the commit. The tag object
really has no meaning to git, except it allows signing. That's really the
_only_ thing a tag object does: it introduces trust. There's no other
reason to ever use one, really.
And a "tag ref" thing is really nothing more (and nothing less) than a
branch. It's a 41-byte filename, although if you actually were to have a
"gitforge" deamon, it could also be just the raw 20-byte SHA1 in a
database. Let people have their own refs, and have some good way to create
them and delete them, and copy them from others (and refer to other
peoples refs - one common usage might be "I want to merge with that other
users ref 'xyzzy'".
Note that the .git/refs/tags/xxx files are _literally_ treated exactly the
same as the same files under "heads". Or under "mydir". Git really doesn't
care, it's purely syntactic sugar. To git, a ref is a ref is a ref. It
just refers to an object, and it's nothing more than a way to specify some
random SHA1 at any time.
> In other words, the only way (other than knowing what GPG keys to trust)
> to distinguish between your "v2.6.12" and J. Random Hacker's "v2.6.12"
> is that the former is referenced by *your* refs as opposed to JRH's
> refs. This also means the refs cannot be uniquely rebuilt from the
> object storage.
Right. All the refs are personal and "fleeting" - some refs are actively
changed all the time (branch refs - aka "heads" - get updated when you
update the branch). Tags are really the same way in all technical ways,
and the only real difference between a "branch ref" and a "tag ref" is
your _expectation_ of them - one you expect to be mostly stable, the other
you expect to be updated with development. _Technically_ there's no
difference between the two, though.
(And you might also change tag contents occasionally. One reason might be
a bug and you decide to re-tag something else. But a more common reason
might be because you want to have tags like "latest" that don't actually
update with development, but they update with some other event, like a
release event or some automated test cycle completion or something like
that. So tags aren't _immutable_ even from an expectation standpoint,
it's just that they tend to change _less_).
Now, from tag _objects_ (as opposed to tag refs) you _can_ build them if
somebody created a tag object, and you have the signature so that you can
re-associate the tag-name with the person. But you should consider that a
pretty heavy and unusual case. The normal case is that you just want to
back up peoples refs. They're like a part of a personal ".gitrc": you
could equally well think of them as "these are my shorthands, because I
don't want to talk about 40-digit hex numbers all the time". It's nothing
more than a personal address book, really.
Linus
^ permalink raw reply
* Re: Tags
From: Linus Torvalds @ 2005-07-02 22:20 UTC (permalink / raw)
To: A Large Angry SCM
Cc: Git Mailing List, H. Peter Anvin, Eric W. Biederman,
Daniel Barkalow, Junio C Hamano, ftpadmin
In-Reply-To: <42C70EEF.6050207@gmail.com>
On Sat, 2 Jul 2005, A Large Angry SCM wrote:
>
> Why have tag objects at all?
Trust.
None of git itself normally has any "trust". The SHA1 means that the
_integrity_ of the archive is ensured, but for some things (notably
releases), you want to have something else. That's the "tag object".
And I really should probably have called them something else. _I_
personally tend to want to have a 1:1 relationship between my "tag
references" (ie the 20-byte SHA1 pointer) and my "tag objects", but that's
because my releases are things that I envision people may actually want to
verify are mine.
In many cases, you'd never use a "tag object", and the "tag reference"
would just point directly to a commit, with no extra indirect object.
Linus
^ permalink raw reply
* Re: Tags
From: Jan Harkes @ 2005-07-02 22:32 UTC (permalink / raw)
To: Git Mailing List
Cc: H. Peter Anvin, Eric W. Biederman, Linus Torvalds,
Daniel Barkalow, Junio C Hamano, ftpadmin
In-Reply-To: <20050702203805.GB19206@delft.aura.cs.cmu.edu>
On Sat, Jul 02, 2005 at 04:38:06PM -0400, Jan Harkes wrote:
> - Then you run the following script (untested)
Ok, I tested it and it was pretty broken, I assumed that git-fetch-script
accepted the same arguments as git-pull-script.
Here is one that actually seems to work.
Jan
#!/bin/sh
#
# combine per-user private trees into a single repository.
# assumes that user repositories are stored as "$repos/<user>/<tree>.git"
#
global=global.git
repos=/path/to/user/repositories
export GIT_DIR="$global"
# create global repository if it doesn't exist
git-init-db
for tree in $(cd "$repos" && find . -name '*.git' -prune | sed 'sX./XX')
do
root="$repos/$tree"
for ref in $(cd "$root" && find refs -type f) ; do
echo Synchronizing $tree
git fetch "$root" "$ref"
type=$(echo "$ref" | sed -ne 'sX^refs/\([^/]*\)/.*$X\1Xp')
name=$(echo "$ref" | sed -ne 'sX^refs/[^/]*/\(.*\)$X\1Xp')
dest="$GIT_DIR/refs/$type/$tree/$name"
mkdir -p $(dirname "$dest")
cat "$GIT_DIR/FETCH_HEAD" > "$dest"
done
done
^ permalink raw reply
* Re: Tags
From: A Large Angry SCM @ 2005-07-02 23:49 UTC (permalink / raw)
To: Linus Torvalds
Cc: Git Mailing List, H. Peter Anvin, Eric W. Biederman,
Daniel Barkalow, Junio C Hamano, ftpadmin
In-Reply-To: <Pine.LNX.4.58.0507021517220.8247@g5.osdl.org>
Linus Torvalds wrote:
>
> On Sat, 2 Jul 2005, A Large Angry SCM wrote:
>>Why have tag objects at all?
>
> Trust.
>
> None of git itself normally has any "trust". The SHA1 means that the
> _integrity_ of the archive is ensured, but for some things (notably
> releases), you want to have something else. That's the "tag object".
>
But can't the commit object do this just as well by signing the commit text?
> And I really should probably have called them something else. _I_
> personally tend to want to have a 1:1 relationship between my "tag
> references" (ie the 20-byte SHA1 pointer) and my "tag objects", but that's
> because my releases are things that I envision people may actually want to
> verify are mine.
>
Your tendency is to use tag objects as a permanent, public label of some
state. Signing the commit text or the email stating that commit
${COMMIT_SHA} would work just as well for verification purposes. Or even
a blob object containing the signed text "${COMMIT_SHA} is vX.X.X.X".
Either way, you'd still need some kind of external reference to find the
object.
> In many cases, you'd never use a "tag object", and the "tag reference"
> would just point directly to a commit, with no extra indirect object.
Tag refs, like head refs and branches, are all just (temporary)
notational shorthand to make using the tools easier.
The problem with the Borg repository is not the objects but the object
refs. Isn't that just a namespace problem?
^ permalink raw reply
* Re: Tags
From: Dan Holmsand @ 2005-07-03 0:04 UTC (permalink / raw)
To: Linus Torvalds
Cc: H. Peter Anvin, Eric W. Biederman, Daniel Barkalow,
Git Mailing List, Junio C Hamano, ftpadmin
In-Reply-To: <Pine.LNX.4.58.0507021501450.8247@g5.osdl.org>
Linus Torvalds wrote:
> And a "tag ref" thing is really nothing more (and nothing less) than a
> branch.
I'm guessing that this is the root of the confusion here. To you, and to
git, a tag is just a another branch. And a tag object is pretty much a
specialized commit object, that can't have children and only one parent.
But people seem to *expect* tags to be connected somehow to a specific
repository. Or, rather, to a specific branch.
That's why people want e.g. cogito to get "all the tags" from
torvalds/linux-2.6.git when they cg-pull.
From git's point of view, that doesn't really make any sense; it's like
saying that you should pull all the branches from a specific branch. But
from a practical point of view, it *does* make sense if you hold the
view that tags are connected to a branch, and that you should be able to
diff against v2.6.12 as soon as you've pulled the latest head.
So why not add tags to the branch itself?
It should be pretty straightforward: just make git look for tag refs in,
say, a .gittags tree in the current HEAD. The whole thing would pretty
much as if you've symlinked .git/refs/tags to .gittags in the current
working tree, except that tag refs would have to be read directly from
the repository.
That way, tag refs could be handled pretty much just like any other
git-managed file: they can be added, deleted, changed, merged,
committed, etc. We could track their history, and see who tagged what
and when.
And tags could easily be signed and contain arbitrary text, just like
the present day tag objects, as long as they start with a sha1 ref.
This way, a git branch could have public, shared tags, with a minimum of
hassle. No special-casing needed for storage or transfer.
And there would be no room for conflicting tag names (but you could
easily use the same name in different branches, just as any file can
differ in content between two branches).
It might be useful, though, to add some syntax for "tag in a specific
branch", say <branch-name>@<tag-name>.
The present tagging mechanism should be kept. It is useful for private
tagging, and may be useful for signalling that "this is a branch that is
unlikely to change".
So, am I missing something obvious here?
/dan
^ permalink raw reply
* Re: Tags
From: Linus Torvalds @ 2005-07-03 0:17 UTC (permalink / raw)
To: A Large Angry SCM
Cc: Git Mailing List, H. Peter Anvin, Eric W. Biederman,
Daniel Barkalow, Junio C Hamano, ftpadmin
In-Reply-To: <42C727FC.3030900@gmail.com>
On Sat, 2 Jul 2005, A Large Angry SCM wrote:
>
> Linus Torvalds wrote:
> >
> > None of git itself normally has any "trust". The SHA1 means that the
> > _integrity_ of the archive is ensured, but for some things (notably
> > releases), you want to have something else. That's the "tag object".
> >
>
> But can't the commit object do this just as well by signing the commit text?
Yes and no.
Technically yes, absolutely, you could add a signature to the commit text.
However, that's just wrong for several reasons:
First off, the signing is not necessarily done by the person committing
something. Think of any paperwork: the person that signs the paperwork is
not necessarily the same person that _wrote_ the paperwork. A signature is
a "witness".
For an example of this, look at the signatures that we've had for a long
time on kernel.org: check out the files like "patch-2.6.8.1.sign". That's
a signature, but it's not a signature by _me_. It's kernel.org signing the
thing so that downstream people can verify things.
And it would be not only wrong, but literally _impossible_ for me to do it
in the commit. I don't have (or want to have) the kernel.org private key.
That's not what the signature is about. kernel.org is signing that "this
is what I got, and what I passed on". It's not signing that "this is what
I wrote".
In a lot of systems, you tag something good after it has passed a
regression test. Ie the _tag_ may happen days or even weeks after the
commit has been done.
So any system that signs commits directly is doing something _wrong_.
Secondly, you can say that you trust other things. In git, you can tag
individual blobs, and you can tag individual trees. For an example of
where it makes sense to tag (sign) individual file versions, we've
actually had things like ISDN drivers (or firmware) that passed some telco
verification suite, and in certain countries it used to be that you
weren't legally supposed to use hadrware that hadn't passed that suite. In
cases like that, you could sign the particular version of the driver, and
say "this one is good".
(Yeah, those laws are happily going away, but I think the ISDN people in
germany actually ended up doing exactly that, except they obviously didn't
use git signatures. I think they had a list of file+md5sum).
Finally, it's a tools issue. It's wrong to mix up the notion of committing
and signing in the same thing, because that just complicates a tool that
has to be able to do both. Now you can have a nice graphical commit tool,
and it doesn't need to know about public keys etc to be useful - you can
use another tool to do the signing.
Small is beautiful, but "independent" is even more so.
> Your tendency is to use tag objects as a permanent, public label of some
> state. Signing the commit text or the email stating that commit
> ${COMMIT_SHA} would work just as well for verification purposes.
Well, according to that logic, you'd never need signatures at all - you
can always keep them totally outside the system.
But if they are totally outside the system, then you have to have some
other mechanism to track them, and you can never trust a git archive on
its own. My goal with the tag objects was that you can just get my git
archive, and the archive is _inherently_ trustworthy, because if you care,
you can verify it without any external input at all (except you need to
know my public key, of course, but that's not a tools issue any more,
that's about how signatures work).
So by having tag objects, I can just have refs to them, and anything that
can fetch a ref (which implies _any_ kind of "pull" functionality) can get
it. No special cases. No crap.
Do one thing, and do it well. Git does objects with relationships. That's
really what git is all about, and the "tag object" fits very well into
that mentality.
Linus
^ permalink raw reply
* Re: kernel.org and GIT tree rebuilding
From: linux @ 2005-07-03 2:51 UTC (permalink / raw)
To: git, torvalds
> unsigned long size;
> unsigned char c;
>
> c = *pack++;
> size = c & 15;
> type = (c >> 4) & 7;
> while (c & 0x80) {
> c = *pack++;
> size = (size << 7) + (c & 0x7f);
> }
>
> or something. That's even denser.
If you're going for density, you missed something. Try:
c = *pack++;
size = c & 15;
type = (c >> 4) & 7;
while (c & 0x80) {
c = *pack++;
size = (size << 7) + (c & 0x7f) + 16;
}
Encoding is most easily done in little-endian order, such as:
static unsigned
encode(unsigned char *p, unsigned long x)
{
unsigned char *q = p;
unsigned char buf[5];
unsigned char *b = buf;
while (x > 15) {
assert(b < buf+5);
x -= 16;
*b++ = x & 0x7f;
x >>= 7;
}
*b = x;
while (b != buf)
*q++ = *b-- | 0x80;
*q++ = *b;
return (unsigned)(q - p);
}
(You'll probably want to rewrite the above, but it's abandoned to the
public domain in any case. Go nuts.)
^ permalink raw reply
* [PATCH] Cogito: Use git-rev-parse instead of cg-Xnormid.
From: Brian Gerst @ 2005-07-03 5:59 UTC (permalink / raw)
To: pasky; +Cc: git
[-- Attachment #1: Type: text/plain, Size: 152 bytes --]
Use git-rev-parse instead of cg-Xnormid. This allows Cogito to work
properly with packed objects.
Signed off by: Brian Gerst <bgerst@didntduck.org>
[-- Attachment #2: cg-rev-parse --]
[-- Type: text/plain, Size: 3735 bytes --]
Use git-rev-parse instead of cg-Xnormid. This allows Cogito to work properly with packed objects.
Signed off by: Brian Gerst <bgerst@didntduck.org>
---
commit 32c6125190d7d183110790b556a8e1128f29c52d
tree 0e53bc37eb8ad12f093cfb0e903689ef95c54ece
parent 266e27c48ba20c1af33f6a3eb966e8cd0d3c8b65
author Brian Gerst <bgerst@didntduck.org> Sun, 03 Jul 2005 01:53:22 -0400
committer Brian Gerst <bgerst@didntduck.org> Sun, 03 Jul 2005 01:53:22 -0400
Makefile | 2 +-
cg-Xnormid | 63 ------------------------------------------------------------
commit-id | 12 +----------
parent-id | 4 +---
tree-id | 4 ++--
5 files changed, 5 insertions(+), 80 deletions(-)
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -67,7 +67,7 @@ SCRIPT= commit-id tree-id parent-id cg-a
cg-pull cg-restore cg-rm cg-seek cg-status cg-tag cg-tag-ls cg-update \
cg cg-admin-ls cg-push cg-branch-chg
-LIB_SCRIPT=cg-Xlib cg-Xmergefile cg-Xnormid
+LIB_SCRIPT=cg-Xlib cg-Xmergefile
GEN_SCRIPT= cg-version
diff --git a/cg-Xnormid b/cg-Xnormid
deleted file mode 100755
--- a/cg-Xnormid
+++ /dev/null
@@ -1,63 +0,0 @@
-#!/usr/bin/env bash
-#
-# Normalize an ID to an SHA1 hash value.
-# Copyright (c) Petr Baudis, 2005
-# Copyright (c) Philip Pokorny, 2005
-#
-# Strings resolve in this order:
-# NULL, this, HEAD => .git/HEAD
-# <tags>
-# <heads>
-# short SHA1 (4 or more hex digits)
-#
-# Takes the ID to normalize and returns the normalized ID.
-
-. ${COGITO_LIB}cg-Xlib
-
-id="$1"
-
-if [ ! "$id" ] || [ "$id" = "this" ] || [ "$id" = "HEAD" ]; then
- read id < "$_git/HEAD"
-
-elif [ -r "$_git/refs/tags/$id" ]; then
- read id < "$_git/refs/tags/$id"
-
-elif [ -r "$_git/refs/heads/$id" ]; then
- read id < "$_git/refs/heads/$id"
-
-# Short id's must be lower case and at least 4 digits.
-elif [[ "$id" == [0-9a-z][0-9a-z][0-9a-z][0-9a-z]* ]]; then
- idpref=${id:0:2}
- idpost=${id:2}
-
- # Assign array elements to matching names
- idmatch=($_git_objects/$idpref/$idpost*)
-
- if [ ${#idmatch[*]} -eq 1 ] && [ -r "$idmatch" ]; then
- id=$idpref${idmatch#$_git_objects/$idpref/}
- elif [ ${#idmatch[*]} -gt 1 ]; then
- echo "Ambiguous id: $id" >&2
- exit 1
- fi
-fi
-
-if ([ "$id" ] && [ "$id" != " " ]) && ([ ${#id} -ne 40 ] || [ ! -f .git/objects/${id:0:2}/${id:2} ]); then
- reqsecs=$(date --date="$id" +'%s' 2>/dev/null)
-
- if [ "$reqsecs" ]; then
- id=$(git-rev-list --min-age=$reqsecs --max-count=1 HEAD)
- fi
-fi
-
-# If we don't have a 40-char ID by now, it's an error
-if [ ${#id} -ne 40 ] || [ ! -f $_git_objects/${id:0:2}/${id:2} ]; then
- echo "Invalid id: $id" >&2
- exit 1
-fi
-
-if [ "$(git-cat-file -t "$id")" = "tag" ]; then
- id=$(git-cat-file tag "$id" | head -n 1)
- id="${id#object }"
-fi
-
-echo $id
diff --git a/commit-id b/commit-id
--- a/commit-id
+++ b/commit-id
@@ -5,14 +5,4 @@
#
# Takes the appropriate ID, defaults to HEAD.
-. ${COGITO_LIB}cg-Xlib
-
-id="$1"
-normid=$(${COGITO_LIB}cg-Xnormid "$id") || exit 1
-
-if [ "$(git-cat-file -t "$normid")" != "commit" ]; then
- echo "Invalid commit id: $id" >&2
- exit 1
-fi
-
-echo $normid
+git-rev-parse "${1:-HEAD}"
diff --git a/parent-id b/parent-id
--- a/parent-id
+++ b/parent-id
@@ -7,6 +7,4 @@
#
# NOTE: Will return multiple SHA1s if ID is a commit with multiple parents.
-id=$(commit-id "$1") || exit 1
-
-git-cat-file commit $id | awk '/^parent/{print $2};/^$/{exit}'
+git-rev-parse "${1:-HEAD}^"
diff --git a/tree-id b/tree-id
--- a/tree-id
+++ b/tree-id
@@ -5,8 +5,8 @@
#
# Takes ID of the appropriate commit, defaults to HEAD.
-id="$1"
-normid=$(${COGITO_LIB}cg-Xnormid "$id") || exit 1
+id="${1:-HEAD}"
+normid=$(git-rev-parse "$id")
type=$(git-cat-file -t "$normid")
if [ "$type" = "commit" ]; then
^ permalink raw reply
* Re: [PATCH] Cogito: Use git-rev-parse instead of cg-Xnormid.
From: Petr Baudis @ 2005-07-03 6:59 UTC (permalink / raw)
To: Brian Gerst; +Cc: git
In-Reply-To: <42C77ECE.2080903@didntduck.org>
Dear diary, on Sun, Jul 03, 2005 at 07:59:42AM CEST, I got a letter
where Brian Gerst <bgerst@didntduck.org> told me that...
> Use git-rev-parse instead of cg-Xnormid. This allows Cogito to work
> properly with packed objects.
>
> Signed off by: Brian Gerst <bgerst@didntduck.org>
But git-rev-parse sucks. It won't detect invalid IDs (--revs-only?), and
does not support short object IDs (that's a must, it's tremendously
useful). You need to add that for it to be useful first.
> diff --git a/tree-id b/tree-id
> --- a/tree-id
> +++ b/tree-id
> @@ -5,8 +5,8 @@
> #
> # Takes ID of the appropriate commit, defaults to HEAD.
>
> -id="$1"
> -normid=$(${COGITO_LIB}cg-Xnormid "$id") || exit 1
> +id="${1:-HEAD}"
> +normid=$(git-rev-parse "$id")
> type=$(git-cat-file -t "$normid")
>
> if [ "$type" = "commit" ]; then
This is broken too. You need to be able to pass _tree_ ID to tree-id too,
not just commit ID. Hmm, or is git-rev-parse able to process any ids?
Then it's terribly misnamed too. :-) A comment would be useful in that
case. (Or better a patch to rename it.)
Thanks,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
<Espy> be careful, some twit might quote you out of context..
^ permalink raw reply
* Re: Stacked GIT 0.3 (now more Quilt-like)
From: Peter Osterlund @ 2005-07-03 8:38 UTC (permalink / raw)
To: Catalin Marinas; +Cc: GIT
In-Reply-To: <1119994003.9631.6.camel@localhost.localdomain>
Catalin Marinas <catalin.marinas@gmail.com> writes:
> A new StGIT release is available from http://procode.org/stgit/
>
> What's new in version 0.3:
> * closer to the Quilt functionality
> * there is only one commit object per patch which can be
> indefinitely modified using the 'refresh' command. The commit
> objects are stacked on top of the base and can also be accessed
> via standard GIT commands
> * no 'commit' command. Use 'refresh' instead
>
> StGIT is a Python application providing similar functionality to Quilt
> (i.e. pushing/popping patches to/from a stack) on top of GIT. These
> operations are performed using GIT commands and the patches are stored
> as GIT commit objects, allowing easy merging of the StGIT patches into
> other repositories using standard GIT functionality.
This is good stuff and the 3-way merge really simplifies things.
However, if there is a merge conflict, you will basically be stuck
with a 2-way merge when resolving manually. It's usually much easier
if you can see all three version, so I think it's better to use -A
instead of -E in the diff3 command.
--- stgit-0.3/gitmergeonefile.py~ 2005-06-28 14:15:22.000000000 +0200
+++ stgit-0.3/gitmergeonefile.py 2005-07-03 02:33:13.000000000 +0200
@@ -108,7 +108,7 @@
# 3-way merge
else:
merge_ok = os.system('diff3 -L local -L older -L remote '
- '-m -E %s %s %s > %s'
+ '-m -A %s %s %s > %s'
% (src1, orig, src2, path)) == 0
if merge_ok:
--
Peter Osterlund - petero2@telia.com
http://web.telia.com/~u89404340
^ permalink raw reply
* Re: Stacked GIT 0.3 (now more Quilt-like)
From: Catalin Marinas @ 2005-07-03 10:08 UTC (permalink / raw)
To: Peter Osterlund; +Cc: GIT
In-Reply-To: <m3ekagp9mk.fsf@telia.com>
Hi Peter,
Thanks for trying this tool.
On Sun, 2005-07-03 at 10:38 +0200, Peter Osterlund wrote:
> This is good stuff and the 3-way merge really simplifies things.
> However, if there is a merge conflict, you will basically be stuck
> with a 2-way merge when resolving manually. It's usually much easier
> if you can see all three version, so I think it's better to use -A
> instead of -E in the diff3 command.
I know that using -A gives a more detailed output in case of a conflict.
The problem is that you will get a conflict even if the changes are
identical, making it impossible to detect when a patch was merged
upstream.
For example:
ancestor: aaa
branch1: aaa
bbb
branch2: aaa
bbb
diff3 -E: aaa
bbb
diff3 -A: aaa
<<<<<<< ancestor
=======
bbb
>>>>>>> branch2
In version 0.3, in case of a conflict, StGIT leaves 3 files in the tree:
file.older, file.local and file.remote so that one can use a graphical
tool to do the merge. I think these names are a bit misleading, .remote
extension means the file in the patch and .local is the one in the tree
before pushing the patch. Anyway, it might be invoking a graphical tool
directly from gitmergeonefile.py.
Speaking of detecting upstream merges, the latest StGIT snapshot shows a
'0' in front of a patch if it is empty, when 'stg series' is invoked.
When pushing, if all the changes are the same, it notifies you that the
patch is empty so that it can be safely removed.
--
Catalin
^ permalink raw reply
* Re: cvsimport: rewritten in Perl
From: Sven Verdoolaege @ 2005-07-03 10:35 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: git
In-Reply-To: <pan.2005.07.01.09.43.24.106822@smurf.noris.de>
On Fri, Jul 01, 2005 at 11:43:34AM +0200, Matthias Urlichs wrote:
> Personally, I'd prefer merging.
>
Pull this one then:
http://www.liacs.nl/~sverdool/git.git#cvs2git
skimo
^ permalink raw reply
* [PATCH] Make specification of CVS module to convert optional.
From: Sven Verdoolaege @ 2005-07-03 10:36 UTC (permalink / raw)
To: Matthias Urlichs, git
In-Reply-To: <20050703103517.GJ5992MdfPADPa@garage.linux.student.kuleuven.ac.be>
Make specification of CVS module to convert optional.
If we're inside a checked out CVS repository, there is
no need to explicitly specify the module as it is
available in CVS/Repository.
Also read CVS/Root if it's available and -d is not specified.
Finally, explicitly pass root to cvsps as CVS/Root takes
precedence over CVSROOT.
Signed-off-by: Sven Verdoolaege <skimo@kotnet.org>
---
commit f9714a4a0cd4ed0ccca3833743d98ea874a2232d
tree de5d7bba63538f29b8ea2b801d932b7679289b96
parent 1cd3674add10d1e511446f3034a1d233a3da7eab
author Sven Verdoolaege <skimo@kotnet.org> Sun, 03 Jul 2005 11:34:59 +0200
committer Sven Verdoolaege <skimo@kotnet.org> Sun, 03 Jul 2005 11:40:44 +0200
Documentation/git-cvsimport-script.txt | 2 +-
git-cvsimport-script | 34 ++++++++++++++++++++++++--------
2 files changed, 27 insertions(+), 9 deletions(-)
diff --git a/Documentation/git-cvsimport-script.txt b/Documentation/git-cvsimport-script.txt
--- a/Documentation/git-cvsimport-script.txt
+++ b/Documentation/git-cvsimport-script.txt
@@ -11,7 +11,7 @@ SYNOPSIS
--------
'git-cvsimport-script' [ -o <branch-for-HEAD> ] [ -h ] [ -v ]
[ -d <CVSROOT> ] [ -p <options-for-cvsps> ]
- <CVS_module> [ <GIT_repository> ]
+ [ -C <GIT_repository> ] [ <CVS_module> ]
DESCRIPTION
diff --git a/git-cvsimport-script b/git-cvsimport-script
--- a/git-cvsimport-script
+++ b/git-cvsimport-script
@@ -26,35 +26,53 @@ use POSIX qw(strftime dup2);
$SIG{'PIPE'}="IGNORE";
$ENV{'TZ'}="UTC";
-our($opt_h,$opt_o,$opt_v,$opt_d,$opt_p);
+our($opt_h,$opt_o,$opt_v,$opt_d,$opt_p,$opt_C);
sub usage() {
print STDERR <<END;
Usage: ${\basename $0} # fetch/update GIT from CVS
[ -o branch-for-HEAD ] [ -h ] [ -v ] [ -d CVSROOT ]
- [ -p opts-for-cvsps ]
- CVS_module [ GIT_repository ]
+ [ -p opts-for-cvsps ] [ -C GIT_repository ]
+ [ CVS_module ]
END
exit(1);
}
-getopts("hqvo:d:p:") or usage();
+getopts("hqvo:d:p:C:") or usage();
usage if $opt_h;
-@ARGV == 1 or @ARGV == 2 or usage();
-
-my($cvs_tree, $git_tree) = @ARGV;
+@ARGV <= 1 or usage();
if($opt_d) {
$ENV{"CVSROOT"} = $opt_d;
+} elsif(-f 'CVS/Root') {
+ open my $f, '<', 'CVS/Root' or die 'Failed to open CVS/Root';
+ $opt_d = <$f>;
+ chomp $opt_d;
+ close $f;
+ $ENV{"CVSROOT"} = $opt_d;
} elsif($ENV{"CVSROOT"}) {
$opt_d = $ENV{"CVSROOT"};
} else {
die "CVSROOT needs to be set";
}
$opt_o ||= "origin";
+my $git_tree = $opt_C;
$git_tree ||= ".";
+my $cvs_tree;
+if ($#ARGV == 0) {
+ $cvs_tree = $ARGV[0];
+} elsif (-f 'CVS/Repository') {
+ open my $f, '<', 'CVS/Repository' or
+ die 'Failed to open CVS/Repository';
+ $cvs_tree = <$f>;
+ chomp $cvs_tree;
+ close $f
+} else {
+ usage();
+}
+
select(STDERR); $|=1; select(STDOUT);
@@ -378,7 +396,7 @@ die "Cannot fork: $!\n" unless defined $
unless($pid) {
my @opt;
@opt = split(/,/,$opt_p) if defined $opt_p;
- exec("cvsps",@opt,"-x","-A","--cvs-direct",$cvs_tree);
+ exec("cvsps",@opt,"-x","-A","--cvs-direct",'--root',$opt_d,$cvs_tree);
die "Could not start cvsps: $!\n";
}
^ permalink raw reply
* git-cvsimport-script: clean up documentation
From: Sven Verdoolaege @ 2005-07-03 10:37 UTC (permalink / raw)
To: Matthias Urlichs, git
In-Reply-To: <20050703103517.GJ5992MdfPADPa@garage.linux.student.kuleuven.ac.be>
git-cvsimport-script: clean up documentation
Remove documentation of irrelevant "type" option.
Signed-off-by: Sven Verdoolaege <skimo@kotnet.org>
---
commit a92bebe6978edaea2885a627e7bef6f7f8b208c2
tree 25e9a3324ac489b7987be562923fd8e81a5de358
parent f9714a4a0cd4ed0ccca3833743d98ea874a2232d
author Sven Verdoolaege <skimo@kotnet.org> Sun, 03 Jul 2005 11:38:06 +0200
committer Sven Verdoolaege <skimo@kotnet.org> Sun, 03 Jul 2005 11:40:45 +0200
Documentation/git-cvsimport-script.txt | 8 --------
1 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/Documentation/git-cvsimport-script.txt b/Documentation/git-cvsimport-script.txt
--- a/Documentation/git-cvsimport-script.txt
+++ b/Documentation/git-cvsimport-script.txt
@@ -48,14 +48,6 @@ OPTIONS
<CVS_module>::
The CVS module you want to import. Relative to <CVSROOT>.
-<type>::
- Typically this matches the real type of <object> but asking
- for a type that can trivially dereferenced from the given
- <object> is also permitted. An example is to ask for a
- "tree" with <object> being a commit object that contains it,
- or to ask for a "blob" with <object> being a tag object that
- points at it.
-
-h::
Print a short usage message and exit.
^ permalink raw reply
* rsync access method deprecated in latest Cogito
From: Petr Baudis @ 2005-07-03 11:17 UTC (permalink / raw)
To: git
Hi,
just a heads-up, I deprecated the rsync access method in the latest
Cogito. For all kernel.org trees, just using HTTP instead should do,
and most of the other GIT repository URLs I noticed use HTTP as well.
rsync is evil and with packs likely doubly so for general GIT access.
I will probably remove rsync access support altogether after another
one or two Cogito releases to give this some transition time; in the
meantime, cg-pull (cg-update, subsequently) will shout a warning.
The only big advantage of rsync is that it is probably (I didn't
measure it, but it feels so) faster especially for smaller repositories,
larger updates and higher latency links. Hopefully we (I hope Daniel
gets to it, but I will do it in foreseeable future if he doesn't)
improve this too.
Does anyone have anything on mind what rsync can do and the git-*-pull
tools can't (or can but a lot worse)?
Have a nice localtime.timeofday,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
<Espy> be careful, some twit might quote you out of context..
^ permalink raw reply
* git-cvsimport-script: Honour CVS_SERVER.
From: Sven Verdoolaege @ 2005-07-03 11:37 UTC (permalink / raw)
To: Matthias Urlichs, git
In-Reply-To: <20050703103517.GJ5992MdfPADPa@garage.linux.student.kuleuven.ac.be>
Honour CVS_SERVER.
---
commit 8d0ea3117597933610e02907d14b443f8996ca3b
tree 8a8aba2772a770082e7d6bd47abd42c3e239ed2c
parent a92bebe6978edaea2885a627e7bef6f7f8b208c2
author Sven Verdoolaege <skimo@kotnet.org> Sun, 03 Jul 2005 12:26:51 +0200
committer Sven Verdoolaege <skimo@kotnet.org> Sun, 03 Jul 2005 12:26:51 +0200
git-cvsimport-script | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/git-cvsimport-script b/git-cvsimport-script
--- a/git-cvsimport-script
+++ b/git-cvsimport-script
@@ -148,6 +148,8 @@ sub conn {
my $pw = IO::Pipe->new();
my $pid = fork();
die "Fork: $!\n" unless defined $pid;
+ my $cvs = 'cvs';
+ $cvs = $ENV{CVS_SERVER} if exists $ENV{CVS_SERVER};
unless($pid) {
$pr->writer();
$pw->reader();
@@ -155,7 +157,7 @@ sub conn {
dup2($pr->fileno(),1);
$pr->close();
$pw->close();
- exec("cvs","server");
+ exec($cvs,"server");
}
$pw->writer();
$pr->reader();
^ permalink raw reply
* [PATCH] git-cvsimport-script: Support :ext: access method.
From: Sven Verdoolaege @ 2005-07-03 11:38 UTC (permalink / raw)
To: Matthias Urlichs, git
In-Reply-To: <20050703103517.GJ5992MdfPADPa@garage.linux.student.kuleuven.ac.be>
Support :ext: access method.
---
commit 34155390a576d8124e0adc864aaf2f11bbf5168b
tree 4918235816314f1d9981456cb05e395b6030c035
parent 8d0ea3117597933610e02907d14b443f8996ca3b
author Sven Verdoolaege <skimo@kotnet.org> Sun, 03 Jul 2005 13:02:06 +0200
committer Sven Verdoolaege <skimo@kotnet.org> Sun, 03 Jul 2005 13:02:06 +0200
Documentation/git-cvsimport-script.txt | 3 ++-
git-cvsimport-script | 23 +++++++++++++++++++++--
2 files changed, 23 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-cvsimport-script.txt b/Documentation/git-cvsimport-script.txt
--- a/Documentation/git-cvsimport-script.txt
+++ b/Documentation/git-cvsimport-script.txt
@@ -26,7 +26,8 @@ OPTIONS
-------
-d <CVSROOT>::
The root of the CVS archive. May be local (a simple path) or remote;
- currently, only the :pserver: access method is supported.
+ currently, only the :local:, :ext: and :pserver: access methods
+ are supported.
-o <branch-for-HEAD>::
The 'HEAD' branch from CVS is imported to the 'origin' branch within
diff --git a/git-cvsimport-script b/git-cvsimport-script
--- a/git-cvsimport-script
+++ b/git-cvsimport-script
@@ -143,13 +143,32 @@ sub conn {
}
$self->{'socketo'} = $s;
$self->{'socketi'} = $s;
- } else { # local: Fork off our own cvs server.
+ } else { # local or ext: Fork off our own cvs server.
my $pr = IO::Pipe->new();
my $pw = IO::Pipe->new();
my $pid = fork();
die "Fork: $!\n" unless defined $pid;
my $cvs = 'cvs';
$cvs = $ENV{CVS_SERVER} if exists $ENV{CVS_SERVER};
+ my $rsh = 'rsh';
+ $rsh = $ENV{CVS_RSH} if exists $ENV{CVS_RSH};
+
+ my @cvs = ($cvs, 'server');
+ my ($local, $user, $host);
+ $local = $repo =~ s/:local://;
+ if (!$local) {
+ $repo =~ s/:ext://;
+ $local = !($repo =~ s/^(?:([^\@:]+)\@)?([^:]+)://);
+ ($user, $host) = ($1, $2);
+ }
+ if (!$local) {
+ if ($user) {
+ unshift @cvs, $rsh, '-l', $user, $host;
+ } else {
+ unshift @cvs, $rsh, $host;
+ }
+ }
+
unless($pid) {
$pr->writer();
$pw->reader();
@@ -157,7 +176,7 @@ sub conn {
dup2($pr->fileno(),1);
$pr->close();
$pw->close();
- exec($cvs,"server");
+ exec(@cvs);
}
$pw->writer();
$pr->reader();
^ permalink raw reply
* Re: [PATCH] Cogito: Use git-rev-parse instead of cg-Xnormid.
From: Brian Gerst @ 2005-07-03 12:25 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050703065920.GA11765@pasky.ji.cz>
Petr Baudis wrote:
> Dear diary, on Sun, Jul 03, 2005 at 07:59:42AM CEST, I got a letter
> where Brian Gerst <bgerst@didntduck.org> told me that...
>
>>Use git-rev-parse instead of cg-Xnormid. This allows Cogito to work
>>properly with packed objects.
>>
>>Signed off by: Brian Gerst <bgerst@didntduck.org>
>
>
> But git-rev-parse sucks. It won't detect invalid IDs (--revs-only?), and
> does not support short object IDs (that's a must, it's tremendously
> useful). You need to add that for it to be useful first.
cg-Xnormid is terminally broken in the presence of packed files, since
it cannot look into them to find objects. Moreover, many uses of
commit-id in the scripts can be eliminated because the underlying git
commands can already understand tags directly, and will check for
invalid ids then. The only thing missing is the short id matching.
>
>
>>diff --git a/tree-id b/tree-id
>>--- a/tree-id
>>+++ b/tree-id
>>@@ -5,8 +5,8 @@
>> #
>> # Takes ID of the appropriate commit, defaults to HEAD.
>>
>>-id="$1"
>>-normid=$(${COGITO_LIB}cg-Xnormid "$id") || exit 1
>>+id="${1:-HEAD}"
>>+normid=$(git-rev-parse "$id")
>> type=$(git-cat-file -t "$normid")
>>
>> if [ "$type" = "commit" ]; then
>
>
> This is broken too. You need to be able to pass _tree_ ID to tree-id too,
> not just commit ID. Hmm, or is git-rev-parse able to process any ids?
> Then it's terribly misnamed too. :-) A comment would be useful in that
> case. (Or better a patch to rename it.)
Yes you can still pass in the tree id.
--
Brian Gerst
^ permalink raw reply
* Re: cvsimport: rewritten in Perl
From: Sven Verdoolaege @ 2005-07-03 12:21 UTC (permalink / raw)
To: Matthias Urlichs, git
In-Reply-To: <20050703103517.GJ5992MdfPADPa@garage.linux.student.kuleuven.ac.be>
On Sun, Jul 03, 2005 at 12:35:17PM +0200, Sven Verdoolaege wrote:
> On Fri, Jul 01, 2005 at 11:43:34AM +0200, Matthias Urlichs wrote:
> > Personally, I'd prefer merging.
> >
> Pull this one then:
>
> http://www.liacs.nl/~sverdool/git.git#cvs2git
That was a cogito branch, btw.
In git you'd say:
git-http-pull -c -v -t -a heads/cvs2git http://www.liacs.nl/~sverdool/git.git/
skimo
^ permalink raw reply
* Re: Stacked GIT 0.3 (now more Quilt-like)
From: Peter Osterlund @ 2005-07-03 12:38 UTC (permalink / raw)
To: Catalin Marinas; +Cc: GIT
In-Reply-To: <1120385280.6845.12.camel@localhost.localdomain>
Catalin Marinas <catalin.marinas@gmail.com> writes:
> Hi Peter,
>
> Thanks for trying this tool.
>
> On Sun, 2005-07-03 at 10:38 +0200, Peter Osterlund wrote:
> > This is good stuff and the 3-way merge really simplifies things.
> > However, if there is a merge conflict, you will basically be stuck
> > with a 2-way merge when resolving manually. It's usually much easier
> > if you can see all three version, so I think it's better to use -A
> > instead of -E in the diff3 command.
>
> I know that using -A gives a more detailed output in case of a conflict.
> The problem is that you will get a conflict even if the changes are
> identical, making it impossible to detect when a patch was merged
> upstream.
OK, I see. How about using wiggle instead?
http://cgi.cse.unsw.edu.au/~neilb/source/wiggle/
That's what patch-utils uses if you run "pushpatch -m". wiggle is also
a lot smarter than diff3, so there will be fewer cases that result in
a conflict. Maybe a parameter to "stg push" could enable wiggle mode.
Another nice thing from patch-utils is that if applying the patch
would have failed, nothing will be done by "pushpatch". You then have
the option to rerun it with -m (merge) or -f (force, create .rej
files), or decide that you don't want to push the patch at all. The
last part is quite useful if you try to reorder a patch series, find
out that you would get a thousand conflicts, and want to reconsider.
Is there a way in StGIT to undo a push that results in a large mess of
conflicts?
> Speaking of detecting upstream merges, the latest StGIT snapshot shows a
> '0' in front of a patch if it is empty, when 'stg series' is invoked.
> When pushing, if all the changes are the same, it notifies you that the
> patch is empty so that it can be safely removed.
That's a useful feature. With patch-utils, I used to drop patches
manually, but that could lose information if the patch applied
upstream is not exactly the same as the one I had locally.
--
Peter Osterlund - petero2@telia.com
http://web.telia.com/~u89404340
^ permalink raw reply
* Re: cvsimport: rewritten in Perl
From: Matthias Urlichs @ 2005-07-03 13:44 UTC (permalink / raw)
To: git
In-Reply-To: <20050703122110.GC18608MdfPADPa@garage.linux.student.kuleuven.ac.be>
Hi, Sven Verdoolaege wrote:
>> http://www.liacs.nl/~sverdool/git.git#cvs2git
>
> That was a cogito branch, btw.
> In git you'd say:
>
> git-http-pull -c -v -t -a heads/cvs2git http://www.liacs.nl/~sverdool/git.git/
>
Your patches make sense -- thanks; imported.
Linus: Please grab http://netz.smurf.noris.de/git/git.git/#cvs2git.
(A very git-ty URL, that.)
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Quantum Mechanics is God's version of "Trust me."
^ permalink raw reply
* Re: [PATCH] Cogito: Use git-rev-parse instead of cg-Xnormid.
From: Petr Baudis @ 2005-07-03 15:41 UTC (permalink / raw)
To: Brian Gerst; +Cc: git
In-Reply-To: <42C7D925.2070007@didntduck.org>
Dear diary, on Sun, Jul 03, 2005 at 02:25:09PM CEST, I got a letter
where Brian Gerst <bgerst@didntduck.org> told me that...
> Petr Baudis wrote:
> >Dear diary, on Sun, Jul 03, 2005 at 07:59:42AM CEST, I got a letter
> >where Brian Gerst <bgerst@didntduck.org> told me that...
> >
> >>Use git-rev-parse instead of cg-Xnormid. This allows Cogito to work
> >>properly with packed objects.
> >>
> >>Signed off by: Brian Gerst <bgerst@didntduck.org>
> >
> >
> >But git-rev-parse sucks. It won't detect invalid IDs (--revs-only?), and
> >does not support short object IDs (that's a must, it's tremendously
> >useful). You need to add that for it to be useful first.
>
> cg-Xnormid is terminally broken in the presence of packed files, since
> it cannot look into them to find objects.
That's right. Well, for everything but the short id matching we could
just check the ID validity by git-rev-parse instead of peeking into
the object store - I just did that. If I'm not missing anything, that
will just make the short id matching for packed objects impossible, but
works fine otherwise...?
> Moreover, many uses of commit-id in the scripts can be eliminated because
> the underlying git commands can already understand tags directly, and will
> check for invalid ids then.
I feel reserved about that. I want to have custom error handling here to
give the user less confusing output (no core GIT command name, since
that confuses users), and as I said, Cogito's rev resolving is more
powerful than Core Git's.
> The only thing missing is the short id matching.
Yes, but as I said, I think it's very important to have. BTW, another
cool thing cg-Xnormid does and git-rev-parse does not: time specifiers.
E.g. you could specify revisions as "2 days ago" or so, very useful for
cg-log, cg-diff and such.
Thanks for pointing this out, BTW.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
<Espy> be careful, some twit might quote you out of context..
^ permalink raw reply
* Re: [PATCH] Cogito: Use git-rev-parse instead of cg-Xnormid.
From: Sven Verdoolaege @ 2005-07-03 15:40 UTC (permalink / raw)
To: Petr Baudis; +Cc: Brian Gerst, git
In-Reply-To: <20050703154127.GA31848@pasky.ji.cz>
On Sun, Jul 03, 2005 at 05:41:27PM +0200, Petr Baudis wrote:
> That's right. Well, for everything but the short id matching we could
> just check the ID validity by git-rev-parse instead of peeking into
> the object store - I just did that.
Why not use it to actually resolve ids ?
I really miss the '^' parent notation in cogito.
skimo
^ permalink raw reply
* [PATCH] git: fix gcc4 warnings
From: Mika Kukkonen @ 2005-07-03 20:32 UTC (permalink / raw)
To: torvalds; +Cc: git
Here is a few trivial fixes to git about things that gcc4 complains about.
Signed-off-by: Mika Kukkonen <mikukkon@iki.fi>
diffstat:
git/send-pack.c | 2 +-
git/sha1_file.c | 4 ++++----
2 files changed, 5 insertions(+), 5 deletions(-)
Index: git/send-pack.c
===================================================================
--- git.orig/send-pack.c
+++ git/send-pack.c
@@ -93,7 +93,7 @@ static void rev_list(int fd, struct ref
exec_rev_list(refs);
}
-static int pack_objects(int fd, struct ref *refs)
+static void pack_objects(int fd, struct ref *refs)
{
pid_t rev_list_pid;
Index: git/sha1_file.c
===================================================================
--- git.orig/sha1_file.c
+++ git/sha1_file.c
@@ -384,8 +384,8 @@ struct packed_git *add_packed_git(char *
{
struct stat st;
struct packed_git *p;
- unsigned long idx_size;
- void *idx_map;
+ unsigned long idx_size = 0;
+ void *idx_map = NULL;
if (check_packed_git_idx(path, &idx_size, &idx_map))
return NULL;
@@ -857,7 +857,7 @@ static void *unpack_non_delta_entry(unsi
{
int st;
z_stream stream;
- char *buffer;
+ unsigned char *buffer;
buffer = xmalloc(size + 1);
buffer[size] = 0;
@@ -949,7 +949,7 @@ int nth_packed_object_sha1(const struct
int find_pack_entry_one(const unsigned char *sha1,
struct pack_entry *e, struct packed_git *p)
{
- int *level1_ofs = p->index_base;
+ unsigned int *level1_ofs = p->index_base;
int hi = ntohl(level1_ofs[*sha1]);
int lo = ((*sha1 == 0x0) ? 0 : ntohl(level1_ofs[*sha1 - 1]));
void *index = p->index_base + 256;
^ 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