* p4 + svn + git
From: Benjamin Sergeant @ 2007-06-08 4:45 UTC (permalink / raw)
To: git
That might be too much, but let's ask anyway...
My company uses perforce.
I took a snapshot of some code checked out from perforce (a single
branch), that I imported into subversion, a while ago, and started
working with svn only. I have different Unix machines checking in /
out code code from the subversion server (with svn), and I'd like to
keep it this way (if possible).
I'm wondering if I could use git as a gateway between both systems, to
merge code in both direction (svn <-> perforce).
Is this possible, with the help of git-p4import, git-svn, and using
several branches ?
Thanks,
Benjamin.
^ permalink raw reply
* Re: [PATCH/RFC] filter-branch: support skipping of commits more easily
From: Johannes Schindelin @ 2007-06-08 4:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7iqfnuo3.fsf@assigned-by-dhcp.cox.net>
Hi,
On Thu, 7 Jun 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > When commit-filter echoes just "skip", just skip that commit by mapping
> > its object name to the same (possibly rewritten) object name(s) its
> > parent(s) are mapped to.
> >
> > IOW, given A-B-C, if commit-filter says "skip" upon B, the rewritten
> > branch will look like this: A'-C'.
> >
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> > ---
> >
> > Of course, if you think of "patchsets", this behaviour might
> > be unexpected, since the children will still contain everything
> > which was changed in the skipped revisions, and not changed in
> > _them_.
>
> I think that is fine; in effect, by saying "skip" B, you are
> squashing B-C into C'.
>
> Does this mean that, given
>
> C---D---E
> / /
> A---B
>
> and if commit-filter says "skip" on D, the written history would
> look like this?
>
> C'------E'
> / /
> A'--B'--'
>
> The new commit E' would become an evil merge that has difference
> between D and E in the original history?
>
> I am not objecting; just trying to get a mental picture.
Yeah, but you called it "squash" instead of "skip". So, maybe it should
accept "squash" to do that operation instead?
Ciao,
Dscho
^ permalink raw reply
* mingw Git 1.5.2.1
From: Han-Wen Nienhuys @ 2007-06-08 3:44 UTC (permalink / raw)
To: git
The tip of the repo.or.cz (5f09ee750771252e02fb0cc994f9ca15dbb333e4)
is now available as
http://lilypond.org/git/binaries/mingw/git-1.5.2.1-1.mingw.exe
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* Problems importing branches and tags
From: Jean-Marc Valin @ 2007-06-08 2:35 UTC (permalink / raw)
To: git
Hi,
I've been trying to pull the Speex svn into Git with tags and branches.
Unfortunately, every time I try that, I end up pulling the history of
every other project in the repository as well. The command line I use is:
% git-svn clone http://svn.xiph.org/ -T trunk/speex -b
branches/speex-branches -t tags/speex-tags
For some reason, the most recent tags (that were created with svn) get
pulled fine. However, when the older ones (created with CVS and
converted to SVN) get pulled, they end up pulling all the other projects
in the repository (vorbis, mgm, ...).
As you can see from the repository above, the branches/speex-branches
and tags/speex-tags directories only contain Speex stuff, so I can't
understand where the problem comes from. Can anyone help?
Jean-Marc
^ permalink raw reply
* Re: [PATCH] fsck: do not crash on tag objects which do not contain an empty line
From: Johan Herland @ 2007-06-08 2:14 UTC (permalink / raw)
To: git; +Cc: Nicolas Pitre, Johannes Schindelin, gitster
In-Reply-To: <alpine.LFD.0.99.0706072158160.12885@xanadu.home>
On Friday 08 June 2007, Nicolas Pitre wrote:
> On Fri, 8 Jun 2007, Johan Herland wrote:
>
> > I agree that we should fail gracefully, and my code is clearly not doing
> > that in this case. My bad.
> >
> > But the code should also detect invalid tag objects, and in this case I'm
> > not yet convinced that the tag object causing the failure is in fact valid.
> > If someone can convince me that the blank line after headers is optional,
> > then I'll gladly fix the code.
>
> That's irrelevant.
>
> Because you are fed invalid data is no excuse for crashing.
>
> Especially in a tool like fsck, you should _expect_ and cope with
> invalid data. That's why it exists in the first place: to identify such
> data.
Of course. If you read my first sentence in the quote above, you will see
that I agree with you 100%.
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [PATCH/RFC] filter-branch: support skipping of commits more easily
From: linux @ 2007-06-08 2:11 UTC (permalink / raw)
To: git, gitster, Johannes.Schindelin
> I think that is fine; in effect, by saying "skip" B, you are
> squashing B-C into C'.
>
> Does this mean that, given
>
> C---D---E
> / /
> A---B
>
> and if commit-filter says "skip" on D, the written history would
> look like this?
>
> C'------E'
> / /
> A'--B'--'
>
> The new commit E' would become an evil merge that has difference
> between D and E in the original history?
>
> I am not objecting; just trying to get a mental picture.
I think, for compatibility with the existing git path limiter,
it should delete D from the history only if:
1) Told to skip D, and
2) Told to skip B or C (or both).
So you could get A--B--E' or A--C--E' or even A--E', but D would only
be deleted if it wasn't needed as a merge marker.
That's probably a little more complex to implement, but it feels like
The Right Thing.
^ permalink raw reply
* Re: [PATCH] fsck: do not crash on tag objects which do not contain an empty line
From: Nicolas Pitre @ 2007-06-08 2:04 UTC (permalink / raw)
To: Johan Herland; +Cc: git, Johannes Schindelin, gitster
In-Reply-To: <200706080128.48637.johan@herland.net>
On Fri, 8 Jun 2007, Johan Herland wrote:
> I agree that we should fail gracefully, and my code is clearly not doing
> that in this case. My bad.
>
> But the code should also detect invalid tag objects, and in this case I'm
> not yet convinced that the tag object causing the failure is in fact valid.
> If someone can convince me that the blank line after headers is optional,
> then I'll gladly fix the code.
That's irrelevant.
Because you are fed invalid data is no excuse for crashing.
Especially in a tool like fsck, you should _expect_ and cope with
invalid data. That's why it exists in the first place: to identify such
data.
Nicolas
^ permalink raw reply
* Re: [PATCH] Teach filter-branch about subdirectory filtering
From: Junio C Hamano @ 2007-06-08 0:57 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0706080130000.4046@racer.site>
Good thing you folded git-split into this, which is an obviously
right thing to do.
But it makes me wonder, if it is common to want to split a
combined project into two (or more) sets, taking more than one
directories at a time. Contents of directory A and B (without
hoisting them up) are filtered into one history and remaining
bits (again without hoisting them up) are filtered into another.
I do not think that is common, and you can easily do that with
the index filter, I think, so it probably is pointless to make
this new filter to try supporting that mode of operation.
We might however want to make sure that we detect an attempt to
give more than one --subdirectory-filter parameter.
^ permalink raw reply
* Re: [PATCH/RFC] filter-branch: support skipping of commits more easily
From: Junio C Hamano @ 2007-06-08 0:42 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0706080058160.4046@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> When commit-filter echoes just "skip", just skip that commit by mapping
> its object name to the same (possibly rewritten) object name(s) its
> parent(s) are mapped to.
>
> IOW, given A-B-C, if commit-filter says "skip" upon B, the rewritten
> branch will look like this: A'-C'.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
>
> Of course, if you think of "patchsets", this behaviour might
> be unexpected, since the children will still contain everything
> which was changed in the skipped revisions, and not changed in
> _them_.
I think that is fine; in effect, by saying "skip" B, you are
squashing B-C into C'.
Does this mean that, given
C---D---E
/ /
A---B
and if commit-filter says "skip" on D, the written history would
look like this?
C'------E'
/ /
A'--B'--'
The new commit E' would become an evil merge that has difference
between D and E in the original history?
I am not objecting; just trying to get a mental picture.
^ permalink raw reply
* [PATCH] Teach filter-branch about subdirectory filtering
From: Johannes Schindelin @ 2007-06-08 0:30 UTC (permalink / raw)
To: git, gitster
With git-filter-branch --subdirectory-filter <subdirectory> you can
get at the history, as seen by a certain subdirectory. The history
of the rewritten branch will only contain commits that touched that
subdirectory, and the subdirectory will be rewritten to be the new
project root.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
git-filter-branch.sh | 33 ++++++++++++++++++++++++++++++---
t/t7003-filter-branch.sh | 24 ++++++++++++++++++++++++
2 files changed, 54 insertions(+), 3 deletions(-)
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index e6ed7b9..4990729 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -122,6 +122,10 @@
# attached, the rewritten tag won't have it. Sorry. (It is by
# definition impossible to preserve signatures at any rate, though.)
#
+# --subdirectory-filter DIRECTORY:: Only regard the history, as seen by
+# the given subdirectory. The result will contain that directory as
+# its project root.
+#
# EXAMPLE USAGE
# -------------
# Suppose you want to remove a file (containing confidential information
@@ -227,7 +231,13 @@ set_ident () {
# list all parent's object names for a given commit
get_parents () {
- git-rev-list -1 --parents "$1" | sed "s/^[0-9a-f]*//"
+ case "$filter_subdir" in
+ "")
+ git-rev-list -1 --parents "$1"
+ ;;
+ *)
+ git-rev-list -1 --parents "$1" -- "$filter_subdir"
+ esac | sed "s/^[0-9a-f]*//"
}
tempdir=.git-rewrite
@@ -238,6 +248,7 @@ filter_parent=
filter_msg=cat
filter_commit='git-commit-tree "$@"'
filter_tag_name=
+filter_subdir=
while case "$#" in 0) usage;; esac
do
case "$1" in
@@ -283,6 +294,9 @@ do
--tag-name-filter)
filter_tag_name="$OPTARG"
;;
+ --subdirectory-filter)
+ filter_subdir="$OPTARG"
+ ;;
*)
usage
;;
@@ -316,7 +330,14 @@ ret=0
mkdir ../map # map old->new commit ids for rewriting parents
-git-rev-list --reverse --topo-order --default HEAD "$@" >../revs
+case "$filter_subdir" in
+"")
+ git-rev-list --reverse --topo-order --default HEAD "$@"
+ ;;
+*)
+ git-rev-list --reverse --topo-order --default HEAD "$@" \
+ -- "$filter_subdir"
+esac > ../revs
commits=$(cat ../revs | wc -l | tr -d " ")
test $commits -eq 0 && die "Found nothing to rewrite"
@@ -326,7 +347,13 @@ while read commit; do
i=$(($i+1))
printf "\rRewriting commits... ($i/$commits)"
- git-read-tree -i -m $commit
+ case "$filter_subdir" in
+ "")
+ git-read-tree -i -m $commit
+ ;;
+ *)
+ git-read-tree -i -m $commit:"$filter_subdir"
+ esac
export GIT_COMMIT=$commit
git-cat-file commit "$commit" >../commit
diff --git a/t/t7003-filter-branch.sh b/t/t7003-filter-branch.sh
index 3739cb1..292b837 100755
--- a/t/t7003-filter-branch.sh
+++ b/t/t7003-filter-branch.sh
@@ -54,4 +54,28 @@ test_expect_success 'common ancestor is still common (unchanged)' '
test "$(git-merge-base modD D)" = "$(git-rev-parse B)"
'
+test_expect_success 'filter subdirectory only' '
+ mkdir subdir &&
+ touch subdir/new &&
+ git add subdir/new &&
+ test_tick &&
+ git commit -m "subdir" &&
+ echo H > a &&
+ test_tick &&
+ git commit -m "not subdir" a &&
+ echo A > subdir/new &&
+ test_tick &&
+ git commit -m "again subdir" subdir/new &&
+ git rm a &&
+ test_tick &&
+ git commit -m "again not subdir" &&
+ git-filter-branch --subdirectory-filter subdir sub
+'
+
+test_expect_success 'subdirectory filter result looks okay' '
+ test 2 = $(git-rev-list sub | wc -l) &&
+ git show sub:new &&
+ ! git show sub:subdir
+'
+
test_done
--
1.5.2.1.2689.gaf768-dirty
^ permalink raw reply related
* Re: git-stash
From: Bill Lear @ 2007-06-08 0:26 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0706072328000.4046@racer.site>
On Thursday, June 7, 2007 at 23:28:33 (+0100) Johannes Schindelin writes:
>Hi,
>
>I just was in the need for git-stash (for the 1e6th time this year), but
>instead of writing a script, I though I'd try the "!" convention for
>aliases. Works quite well for me:
Excellent work. I do this sort of stuff all the time. I called my
lame version "shelf", but this works for me ...
Bill
^ permalink raw reply
* Spec file for StGIT (or equivalent)
From: Jakub Narebski @ 2007-06-08 0:24 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
I can see that stgit repository contains some helper files to build deb
package. How to build rpm package from current version of stgit? Is
here main version planned to be released soon?
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH] Fix failed tag parsing when tag object has no body/message (and thus ends with a single '\n')
From: Johan Herland @ 2007-06-08 0:08 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin
In-Reply-To: <200706080147.50207.johan@herland.net>
Thanks to Johannes Schindelin <Johannes.Schindelin@gmx.de> for
discovering this.
Also add a testcase for this condition.
Signed-off-by: Johan Herland <johan@herland.net>
---
This patch should hopefully fix your problem.
...Johan
t/t3800-mktag.sh | 15 +++++++++++++++
tag.c | 9 ++-------
2 files changed, 17 insertions(+), 7 deletions(-)
diff --git a/t/t3800-mktag.sh b/t/t3800-mktag.sh
index ac9008a..ac7cbbc 100755
--- a/t/t3800-mktag.sh
+++ b/t/t3800-mktag.sh
@@ -399,5 +399,20 @@ test_expect_success \
'create valid tag #4' \
'git-mktag <tag.sig >.git/refs/tags/mytag 2>message'
+############################################################
+# 24. create valid tag #4 (with empty message)
+
+cat >tag.sig <<EOF
+object $head
+type commit
+tag mytag
+keywords note
+tagger a
+EOF
+
+test_expect_success \
+ 'create valid tag #4' \
+ 'git-mktag <tag.sig >.git/refs/tags/mytag 2>message'
+
test_done
diff --git a/tag.c b/tag.c
index e371179..875145b 100644
--- a/tag.c
+++ b/tag.c
@@ -131,10 +131,6 @@ int parse_and_verify_tag_buffer(struct tag *item, const char *data, const unsign
header_end = memchr(tagger_line, '\n', end - tagger_line);
if (!header_end++)
return error("char" PD_FMT ": could not find \"\\n\" after \"tagger\"", tagger_line - data);
- if (end - header_end < 1)
- return error("char" PD_FMT ": premature end of data", header_end - data);
- if (*header_end != '\n') /* header must end with "\n\n" */
- return error("char" PD_FMT ": could not find blank line after header section", header_end - data);
}
else {
/* Treat tagger line as optional */
@@ -148,9 +144,8 @@ int parse_and_verify_tag_buffer(struct tag *item, const char *data, const unsign
header_end = tagger_line;
}
- if (end - header_end < 1)
- return error("char" PD_FMT ": premature end of data", header_end - data);
- if (*header_end != '\n') /* header must end with "\n\n" */
+ /* header must end with "\n\n", but "\n" is acceptable if at EOF */
+ if (header_end < end - 1 && *header_end != '\n') /* not at EOF, and next char is not '\n' */
return error("char" PD_FMT ": could not find blank line after header section", header_end - data);
/*
--
1.5.2
^ permalink raw reply related
* [PATCH/RFC] filter-branch: support skipping of commits more easily
From: Johannes Schindelin @ 2007-06-07 23:59 UTC (permalink / raw)
To: git, gitster
When commit-filter echoes just "skip", just skip that commit by mapping
its object name to the same (possibly rewritten) object name(s) its
parent(s) are mapped to.
IOW, given A-B-C, if commit-filter says "skip" upon B, the rewritten
branch will look like this: A'-C'.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Of course, if you think of "patchsets", this behaviour might
be unexpected, since the children will still contain everything
which was changed in the skipped revisions, and not changed in
_them_.
git-filter-branch.sh | 15 ++++++++++++---
1 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index 9d61b7f..e6ed7b9 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -102,6 +102,9 @@
# multiple commit ids; in that case, all of them will be used
# as parents instead of the original commit in further commits.
#
+# For the common case, that this commit should be skipped, just
+# output a single "skip".
+#
# --tag-name-filter COMMAND:: The filter for rewriting tag names.
# If this filter is passed, it will be called for every tag ref
# that points to a rewritten object (or to a tag object which
@@ -321,7 +324,7 @@ test $commits -eq 0 && die "Found nothing to rewrite"
i=0
while read commit; do
i=$(($i+1))
- printf "$commit ($i/$commits) "
+ printf "\rRewriting commits... ($i/$commits)"
git-read-tree -i -m $commit
@@ -358,8 +361,14 @@ while read commit; do
sed -e '1,/^$/d' <../commit | \
eval "$filter_msg" | \
- sh -c "$filter_commit" git-commit-tree $(git-write-tree) $parentstr | \
- tee ../map/$commit
+ sh -c "$filter_commit" \
+ git-commit-tree $(git-write-tree) $parentstr \
+ > ../map/$commit
+
+ test skip = "$(cat ../map/$commit)" &&
+ for parent in $(get_parents $commit); do
+ map "$parent"
+ done > ../map/$commit
done <../revs
src_head=$(tail -n 1 ../revs)
--
1.5.2.1.2689.gaf768-dirty
^ permalink raw reply related
* Re: error: char103: premature end of data
From: Johannes Schindelin @ 2007-06-07 23:55 UTC (permalink / raw)
To: Johan Herland; +Cc: git
In-Reply-To: <200706080147.50207.johan@herland.net>
Hi,
On Fri, 8 Jun 2007, Johan Herland wrote:
> If I'm pulling from a corrupt repo, I'd sure as hell want git to tell me
> when I first fetched, and not a couple of weeks later when I'd try to
> use the corrupt data, or call fsck, or whatever.
We don't check that the object names match the object contents on pull.
With your argument, we should do that, too. And of course, get rid of
git-fsck, because it is of no more use, then.
Ciao,
Dscho
^ permalink raw reply
* Re: error: char103: premature end of data
From: Johan Herland @ 2007-06-07 23:47 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin
In-Reply-To: <Pine.LNX.4.64.0706080023450.4046@racer.site>
On Friday 08 June 2007, Johannes Schindelin wrote:
> Hi,
>
> On Fri, 8 Jun 2007, Johan Herland wrote:
>
> > On Friday 08 June 2007, Johannes Schindelin wrote:
> >
> > > I just tried to fetch from one of my repos which was perfectly usable
> > > (and fetchable) before, and got this error message:
> > >
> > > error: char103: premature end of data
> >
> > Sorry about that. Do you have an idea of which tag object caused the
> > failure? If so, could you send the output of "git-cat-file tag <name>"
> > on it?
>
> Yes, I know what causes it. A tag with an empty message.
Of course. Although if one uses git-tag -a to create an annotated tag object
I have a hard time seeing why one wouldn't supply a message. But it's of
course entirly valid not to supply a message.
> And I even know why it does that. It's easy. Look into git-tag.sh, and you
> will find that it does a git-stripspace on the final message. If that was
> empty, then the tag will just be the tag header.
You're right. I'll fix my code to handle this case. I'll also try to split
that first patch in my series into more manageable chunks.
> > git-fsck on the repo should report the same error. If you run with -v
> > (verbose) you should also get some hints as to which tag object causes
> > this.
>
> Yes, it finds the error. And crashes. And costs me time.
>
> Why do we have to parse _everything_ in the tag to begin with? It's not
> like I will show the information of the darn thing when I just fetch it
> from repo A into repo B.
We parse the tag completely in order to detect corruption/invalid tags as
early as possible. If I'm pulling from a corrupt repo, I'd sure as hell
want git to tell me when I first fetched, and not a couple of weeks later
when I'd try to use the corrupt data, or call fsck, or whatever.
Again, I'm sorry for your problems.
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* [PATCH] Fix push with refspecs containing wildcards
From: Alex Riesen @ 2007-06-07 23:43 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Johannes Schindelin
In-Reply-To: <20070607225302.GA10633@steel.home>
Otherwise
git push 'remote-name' 'refs/heads/*:refs/remotes/other/*'
will consider references in "refs/heads" of the remote repository
"remote-name", instead of the ones in "refs/remotes/other", which
the given refspec clearly means.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
Alex Riesen, Fri, Jun 08, 2007 00:53:02 +0200:
> Try something like this:
>
> git-send-pack --remote=origin --thin /some/other/repo \
> 'refs/heads/*:refs/remotes/child/*'
>
> The result looks broken: the sent reference are created not in
> refs/remotes/child/ but just in refs/heads/ of /some/other/repo.
>
And as usual, I'm not sure if it is the right fix. Johannes has a
point: why the hell does send-pack parse the wildcards at all?!
remote.c | 39 +++++++++++++++++++++++++++------------
1 files changed, 27 insertions(+), 12 deletions(-)
diff --git a/remote.c b/remote.c
index d904616..33c8e50 100644
--- a/remote.c
+++ b/remote.c
@@ -501,16 +501,16 @@ static struct ref *find_ref_by_name(struct ref *list, const char *name)
return NULL;
}
-static int check_pattern_match(struct refspec *rs, int rs_nr, struct ref *src)
+static const struct refspec *check_pattern_match(const struct refspec *rs,
+ int rs_nr,
+ const struct ref *src)
{
int i;
- if (!rs_nr)
- return 1;
for (i = 0; i < rs_nr; i++) {
if (rs[i].pattern && !prefixcmp(src->name, rs[i].src))
- return 1;
+ return rs + i;
}
- return 0;
+ return NULL;
}
int match_refs(struct ref *src, struct ref *dst, struct ref ***dst_tail,
@@ -525,29 +525,44 @@ int match_refs(struct ref *src, struct ref *dst, struct ref ***dst_tail,
/* pick the remainder */
for ( ; src; src = src->next) {
struct ref *dst_peer;
+ const struct refspec *pat = NULL;
+ char *dst_name;
if (src->peer_ref)
continue;
- if (!check_pattern_match(rs, nr_refspec, src))
- continue;
+ if (nr_refspec) {
+ pat = check_pattern_match(rs, nr_refspec, src);
+ if (!pat)
+ continue;
+ }
- dst_peer = find_ref_by_name(dst, src->name);
+ if (pat) {
+ dst_name = xmalloc(strlen(pat->dst) +
+ strlen(src->name) -
+ strlen(pat->src) + 2);
+ strcpy(dst_name, pat->dst);
+ strcat(dst_name, src->name + strlen(pat->src));
+ } else
+ dst_name = strdup(src->name);
+ dst_peer = find_ref_by_name(dst, dst_name);
if (dst_peer && dst_peer->peer_ref)
/* We're already sending something to this ref. */
- continue;
+ goto free_name;
if (!dst_peer && !nr_refspec && !all)
/* Remote doesn't have it, and we have no
* explicit pattern, and we don't have
* --all. */
- continue;
+ goto free_name;
if (!dst_peer) {
/* Create a new one and link it */
- int len = strlen(src->name) + 1;
+ int len = strlen(dst_name) + 1;
dst_peer = xcalloc(1, sizeof(*dst_peer) + len);
- memcpy(dst_peer->name, src->name, len);
+ memcpy(dst_peer->name, dst_name, len);
hashcpy(dst_peer->new_sha1, src->new_sha1);
link_dst_tail(dst_peer, dst_tail);
}
dst_peer->peer_ref = src;
+ free_name:
+ free(dst_name);
}
return 0;
}
--
1.5.2.1.147.g7c82d
^ permalink raw reply related
* Re: [PATCH] fsck: do not crash on tag objects which do not contain an empty line
From: Johannes Schindelin @ 2007-06-07 23:38 UTC (permalink / raw)
To: Johan Herland; +Cc: git, gitster
In-Reply-To: <200706080128.48637.johan@herland.net>
Hi,
On Fri, 8 Jun 2007, Johan Herland wrote:
> On Friday 08 June 2007, Johannes Schindelin wrote:
> >
> > On Fri, 8 Jun 2007, Johan Herland wrote:
> >
> > > On Friday 08 June 2007, Johannes Schindelin wrote:
> > > >
> > > > The first empty line in a tag object separates the header from the
> > > > message. If the tag object has no empty line, do not crash, but
> > > > complain loudly instead.
> > >
> > > Aren't tag objects _required_ to have an empty line separating the
> > > headers from the body? At least I wrote the new tag code with that
> > > assumption in mind.
> >
> > Yes, evidently you did.
> >
> > But even then, isn't it always better to not rely on such assumptions, but
> > fail gracefully? The rest of Git's source code seems to be nicer to
> > failures as this one, IMHO.
>
> I agree that we should fail gracefully, and my code is clearly not doing
> that in this case. My bad.
>
> But the code should also detect invalid tag objects, and in this case I'm
> not yet convinced that the tag object causing the failure is in fact valid.
IT BROKE GIT IN A REPO THAT WAS PERFECTLY VALID BEFORE, AND I COULD NOT DO
ANYTHING AFTER THAT CHANGE.
Thank you very much again.
> If someone can convince me that the blank line after headers is optional,
> then I'll gladly fix the code.
Convincing enough?
> > > Could this be related to the "error: char103: premature end of data"
> > > you're seeing?
> >
> > Definitely. It breaks even _fetching_.
>
> Sorry again. Still, if I could get a look at the object that'd help me alot
> in debugging.
object f90084c7b53b1c2fb4606acafd84ef8a748a7d78
type commit
tag start
tagger me <me>
But I have to say that I am unlikely to review any fix you make, if that
fix is as unreadable as those mega long lines with funny spaces in the
middle of the line in that mega patch that unfortunately was already
applied in next.
I need a beer,
Dscho
^ permalink raw reply
* Re: git-stash
From: Lars Hjemli @ 2007-06-07 23:38 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0706072328000.4046@racer.site>
On 6/8/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> I just was in the need for git-stash (for the 1e6th time this year), but
> instead of writing a script, I though I'd try the "!" convention for
> aliases.
Fwiw, here's a very simple unstash:
git config alias.unstash '!git diff --binary stash^ stash | git-apply -'
--
larsh
^ permalink raw reply
* Re: error: char103: premature end of data
From: Johannes Schindelin @ 2007-06-07 23:28 UTC (permalink / raw)
To: Johan Herland; +Cc: git
In-Reply-To: <200706080105.28102.johan@herland.net>
Hi,
On Fri, 8 Jun 2007, Johan Herland wrote:
> On Friday 08 June 2007, Johannes Schindelin wrote:
>
> > I just tried to fetch from one of my repos which was perfectly usable
> > (and fetchable) before, and got this error message:
> >
> > error: char103: premature end of data
>
> Sorry about that. Do you have an idea of which tag object caused the
> failure? If so, could you send the output of "git-cat-file tag <name>"
> on it?
Yes, I know what causes it. A tag with an empty message.
And I even know why it does that. It's easy. Look into git-tag.sh, and you
will find that it does a git-stripspace on the final message. If that was
empty, then the tag will just be the tag header.
> git-fsck on the repo should report the same error. If you run with -v
> (verbose) you should also get some hints as to which tag object causes
> this.
Yes, it finds the error. And crashes. And costs me time.
Why do we have to parse _everything_ in the tag to begin with? It's not
like I will show the information of the darn thing when I just fetch it
from repo A into repo B.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] fsck: do not crash on tag objects which do not contain an empty line
From: Johan Herland @ 2007-06-07 23:28 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin, gitster
In-Reply-To: <Pine.LNX.4.64.0706080011430.4046@racer.site>
On Friday 08 June 2007, Johannes Schindelin wrote:
> Hi,
>
> On Fri, 8 Jun 2007, Johan Herland wrote:
>
> > On Friday 08 June 2007, Johannes Schindelin wrote:
> > >
> > > The first empty line in a tag object separates the header from the
> > > message. If the tag object has no empty line, do not crash, but
> > > complain loudly instead.
> >
> > Aren't tag objects _required_ to have an empty line separating the
> > headers from the body? At least I wrote the new tag code with that
> > assumption in mind.
>
> Yes, evidently you did.
>
> But even then, isn't it always better to not rely on such assumptions, but
> fail gracefully? The rest of Git's source code seems to be nicer to
> failures as this one, IMHO.
I agree that we should fail gracefully, and my code is clearly not doing
that in this case. My bad.
But the code should also detect invalid tag objects, and in this case I'm
not yet convinced that the tag object causing the failure is in fact valid.
If someone can convince me that the blank line after headers is optional,
then I'll gladly fix the code.
> > Could this be related to the "error: char103: premature end of data"
> > you're seeing?
>
> Definitely. It breaks even _fetching_.
Sorry again. Still, if I could get a look at the object that'd help me alot
in debugging.
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [PATCH] fsck: do not crash on tag objects which do not contain an empty line
From: Johannes Schindelin @ 2007-06-07 23:13 UTC (permalink / raw)
To: Johan Herland; +Cc: git, gitster
In-Reply-To: <200706080108.50042.johan@herland.net>
Hi,
On Fri, 8 Jun 2007, Johan Herland wrote:
> On Friday 08 June 2007, Johannes Schindelin wrote:
> >
> > The first empty line in a tag object separates the header from the
> > message. If the tag object has no empty line, do not crash, but
> > complain loudly instead.
>
> Aren't tag objects _required_ to have an empty line separating the
> headers from the body? At least I wrote the new tag code with that
> assumption in mind.
Yes, evidently you did.
But even then, isn't it always better to not rely on such assumptions, but
fail gracefully? The rest of Git's source code seems to be nicer to
failures as this one, IMHO.
> Could this be related to the "error: char103: premature end of data"
> you're seeing?
Definitely. It breaks even _fetching_.
Ciao,
Dscho
^ permalink raw reply
* Re: error: char103: premature end of data
From: Johannes Schindelin @ 2007-06-07 23:11 UTC (permalink / raw)
To: git, Johan Herland
In-Reply-To: <Pine.LNX.4.64.0706072348110.4046@racer.site>
Hi,
On Thu, 7 Jun 2007, Johannes Schindelin wrote:
> I somehow suspect that this has something to do with the recent work on
> the tag objects. If so, NACK on that patch series from me.
Okay. Instead of doing the work I have to do, which I cannot, because
a vital part of git stopped working for me, I tracked down that it is
indeed that monster commit v1.5.2.1-134-gc7de6eb AKA ':/Refactor git tag
objects;'
I have to repeat my NACK on it. I did not have time to review it, when
you sent it, so I tried to find what is wrong now (when I don't have
time for it to begin with).
But it is really intrusive, introduces problems, is less than readable,
and it is not at all clear what problems it solves, while it looks like it
could be broken down to easily-reviewable fixes, cleanups, and changes, so
please fix it while I recover from my troubles.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] fsck: do not crash on tag objects which do not contain an empty line
From: Johan Herland @ 2007-06-07 23:08 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin, gitster
In-Reply-To: <Pine.LNX.4.64.0706072338260.4046@racer.site>
On Friday 08 June 2007, Johannes Schindelin wrote:
>
> The first empty line in a tag object separates the header from the
> message. If the tag object has no empty line, do not crash, but
> complain loudly instead.
Aren't tag objects _required_ to have an empty line separating the headers
from the body? At least I wrote the new tag code with that assumption in
mind.
Could this be related to the "error: char103: premature end of data" you're
seeing?
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: error: char103: premature end of data
From: Johan Herland @ 2007-06-07 23:05 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0706072348110.4046@racer.site>
On Friday 08 June 2007, Johannes Schindelin wrote:
> Hi,
>
> I just tried to fetch from one of my repos which was perfectly usable (and
> fetchable) before, and got this error message:
>
> error: char103: premature end of data
Sorry about that. Do you have an idea of which tag object caused the
failure? If so, could you send the output of "git-cat-file tag <name>" on
it?
git-fsck on the repo should report the same error. If you run with -v
(verbose) you should also get some hints as to which tag object causes
this.
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ 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