[PATCH] NUL terminate the object data in patch_delta()
At least pretty_print_commit() expects to get NUL-terminated commit data to
work properly. unpack_sha1_rest(), which reads objects from separate files,
and unpack_non_delta_entry(), which reads non-delta-compressed objects from
pack files, already add the NUL byte after the object data, but patch_delta()
did not do it, which caused problems with, e.g., git-rev-list --pretty when
there are delta-compressed commit objects.
Signed-off-by: Sergey Vlasov [EMAIL PROTECTED]
---
Actually I noticed the problem when trying to do git log ^v2.6.12
v2.6.13 on the linux-2.6 repository - the output was not identical to
the original ChangeLog-2.6.13; some commits had garbage at the end of
message.
Valgrind catches this problem with messages like:
==22513== 6 errors in context 6 of 7:
==22513== Invalid read of size 1
==22513==at 0x804E148: pretty_print_commit (commit.c:382)
==22513==by 0x8049A00: process_commit (rev-list.c:73)
==22513==by 0x804A1E6: main (rev-list.c:168)
==22513== Address 0x1BF2EC23 is 8 bytes after a block of size 459 alloc'd
==22513==at 0x1B8FFAD8: malloc (vg_replace_malloc.c:130)
==22513==by 0x804F9B6: patch_delta (patch-delta.c:37)
==22513==by 0x804BFE7: unpack_entry_gently (sha1_file.c:941)
==22513==by 0x804C2FA: read_packed_sha1 (sha1_file.c:987)
==22513==by 0x804C378: read_sha1_file (sha1_file.c:1147)
==22513==by 0x804DD91: parse_commit (commit.c:257)
==22513==by 0x804DF1A: pop_most_recent_commit (commit.c:329)
==22513==by 0x804A07D: main (rev-list.c:378)
==22513==
==22513== 260 errors in context 7 of 7:
==22513== Invalid read of size 1
==22513==at 0x804E050: pretty_print_commit (commit.c:347)
==22513==by 0x8049A00: process_commit (rev-list.c:73)
==22513==by 0x804A1E6: main (rev-list.c:168)
==22513== Address 0x1BC30C46 is 0 bytes after a block of size 430 alloc'd
==22513==at 0x1B8FFAD8: malloc (vg_replace_malloc.c:130)
==22513==by 0x804F9B6: patch_delta (patch-delta.c:37)
==22513==by 0x804BFE7: unpack_entry_gently (sha1_file.c:941)
==22513==by 0x804C2FA: read_packed_sha1 (sha1_file.c:987)
==22513==by 0x804C378: read_sha1_file (sha1_file.c:1147)
==22513==by 0x804DD91: parse_commit (commit.c:257)
==22513==by 0x804DF1A: pop_most_recent_commit (commit.c:329)
==22513==by 0x804A07D: main (rev-list.c:378)
patch-delta.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
121db224f0f2595067e3bf7daed6c6a903d7532b
diff --git a/patch-delta.c b/patch-delta.c
--- a/patch-delta.c
+++ b/patch-delta.c
@@ -34,9 +34,10 @@ void *patch_delta(void *src_buf, unsigne
/* now the result size */
size = get_delta_hdr_size(data);
- dst_buf = malloc(size);
+ dst_buf = malloc(size + 1);
if (!dst_buf)
return NULL;
+ dst_buf[size] = 0;
out = dst_buf;
while (data top) {
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Could not interpret heads/dbrt-test as something to pull
On 9/4/05, Kalle Valo [EMAIL PROTECTED] wrote: I was trying to clone the git repository this morning and it fails every time: got 15891f81e0fa99333ad81e9271df5b2a72ba368e error: Couldn't get http://www.kernel.org/pub/scm/git/git.git/refs/heads/dbrt-test for heads/dbrt-test Tried to repro, but takes ageson my puny cablemodem. Cloning via rsync seems to work well though. cheers, martin - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] archimport: avoid committing on an Arch tag
Arch tags are full commits (without any changed files) as well. Trust Arch
to have put an unchanged tree in place (which seems to do reliably), and
just add a tag new branch. Speeds up Arch imports significantly, and leaves
history in a much saner state.
Signed-off-by: Martin Langhoff [EMAIL PROTECTED]
---
git-archimport-script |8
1 files changed, 8 insertions(+), 0 deletions(-)
55f05e4d4ab662caff10437bdd4de7e8b87f30e0
diff --git a/git-archimport-script b/git-archimport-script
--- a/git-archimport-script
+++ b/git-archimport-script
@@ -227,6 +227,14 @@ foreach my $ps (@psets) {
# find where we are supposed to branch from
`git checkout -b $ps-{branch} $branchpoint`;
+
+# If we trust Arch with the fact that this is just
+# a tag, and it does not affect the state of the tree
+# then we just tag and move on
+tag($ps-{id}, $branchpoint);
+ptag($ps-{id}, $branchpoint);
+print * Tagged $ps-{id} at $branchpoint\n;
+next;
}
die $! if $?;
}
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] archimport autodetects import status, supports incremental imports
If there is no GIT directory, archimport will assume it is an initial import.
It now also supports incremental imports, skipping seen commits. You can
now run it repeatedly to pull new commits from the Arch repository.
Signed-off-by: Martin Langhoff [EMAIL PROTECTED]
---
git-archimport-script | 37 -
1 files changed, 20 insertions(+), 17 deletions(-)
cc93bff516ed5f460f4d5b0eeb6157ede88d21c1
diff --git a/git-archimport-script b/git-archimport-script
--- a/git-archimport-script
+++ b/git-archimport-script
@@ -49,12 +49,12 @@ $SIG{'PIPE'}=IGNORE;
$ENV{'TZ'}=UTC;
our($opt_h,$opt_v, $opt_T,
-$opt_C,$opt_t, $opt_i);
+$opt_C,$opt_t);
sub usage() {
print STDERR END;
Usage: ${\basename $0} # fetch/update GIT from Arch
- [ -h ] [ -v ] [ -i ] [ -T ]
+ [ -h ] [ -v ] [ -T ]
[ -C GIT_repository ] [ -t tempdir ]
repository/arch-branch [ repository/arch-branch] ...
END
@@ -173,21 +173,19 @@ foreach my $root (@arch_roots) {
## TODO cleanup irrelevant patches
## and put an initial import
## or a full tag
-
-if ($opt_i) { # initial import
+my $import = 0;
+unless (-d '.git') { # initial import
if ($psets[0]{type} eq 'i' || $psets[0]{type} eq 't') {
print Starting import from $psets[0]{id}\n;
+ `git-init-db`;
+ die $! if $?;
+ $import = 1;
} else {
die Need to start from an import or a tag -- cannot use
$psets[0]{id};
}
-`git-init-db`;
-die $! if $?;
}
-# process
-my $lastbranch = branchname($psets[0]{id}); # only good for initial import
-my $importseen = $opt_i ? 0 : 1; # start at 1 if opt_i
-
+# process patchsets
foreach my $ps (@psets) {
$ps-{branch} = branchname($ps-{id});
@@ -201,14 +199,22 @@ foreach my $ps (@psets) {
}
die $! if $?;
+#
+# skip commits already in repo
+#
+if (ptag($ps-{id})) {
+ $opt_v print Skipping already imported: $ps-{id}\n;
+ next;
+}
+
#
# create the branch if needed
#
-if ($ps-{type} eq 'i' $importseen) {
-die Should not have more than one 'Initial import' per GIT import;
+if ($ps-{type} eq 'i' !$import) {
+die Should not have more than one 'Initial import' per GIT import:
$ps-{id};
}
-unless ($opt_i !$importseen) { # skip for first commit
+unless ($import) { # skip for import
if ( -e .git/refs/heads/$ps-{branch}) {
# we know about this branch
`git checkout$ps-{branch}`;
@@ -225,13 +231,12 @@ foreach my $ps (@psets) {
die $! if $?;
}
-
#
# Apply the import/changeset/merge into the working tree
#
if ($ps-{type} eq 'i' || $ps-{type} eq 't') {
-$importseen = 1;
apply_import($ps) or die $!;
+$import=0;
} elsif ($ps-{type} eq 's') {
apply_cset($ps);
}
@@ -577,8 +582,6 @@ sub ptag {
} else {# read
# if the tag isn't there, return 0
unless ( -s .git/archimport/tags/$tag) {
-warn Could not find tag $tag -- perhaps it isn't in the repos we
have?\n
-if $opt_v;
return 0;
}
open(C,.git/archimport/tags/$tag)
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: empty patch-2.6.13-git? patches on ftp.kernel.org
On Sun, 2005-09-04 at 17:31 +0200, Jan Dittmer wrote: David Woodhouse wrote: On Fri, 2005-09-02 at 02:00 -0700, Linus Torvalds wrote: Ahh. Please change that to rm -rf tmp-empty-tree mkdir tmp-empty-tree cd tmp-empty-tree git-init-db because otherwise you'll almost certainly hit something else later on.. OK, done. -git4 is again empty Hm, yes. + rm -rf tmp-empty-tree + mkdir tmp-empty-tree + cd tmp-empty-tree + git-init-db /pub/scm/linux/kernel/git/torvalds/linux-2.6.git/branches/: Permission denied + unset GIT_DIR + git-read-tree f505380ba7b98ec97bf25300c2a58aeae903530b fatal: unable to create new cachefile Fixed now; thanks. -- dwmw2 - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Could not interpret heads/dbrt-test as something to pull
Kalle Valo [EMAIL PROTECTED] writes: Rsync works for me also. But HTTP is still broken. Sorry, a broken repo. Fix made on master should percolate through soonish. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Could not interpret heads/dbrt-test as something to pull
Junio C Hamano [EMAIL PROTECTED] writes: Rsync works for me also. But HTTP is still broken. Sorry, a broken repo. Fix made on master should percolate through soonish. HTTP clone works now, thanks. -- Kalle Valo - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Make sure the diff machinery outputs \ No newline ... in english
In non-english locales diff(1) do sometimes output \ No newline at end of file in some other language. Set LC_ALL to C before execing diff to avoid this behaviour. Signed-off-by: Fredrik Kuivinen [EMAIL PROTECTED] --- diff.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) eb6261334d65c3134d9dd822fd64e33ed8ad2dfc diff --git a/diff.c b/diff.c --- a/diff.c +++ b/diff.c @@ -207,6 +207,7 @@ static void builtin_diff(const char *nam } } fflush(NULL); + putenv(LC_ALL=C); execlp(/bin/sh,sh, -c, cmd, NULL); } - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Moved files and merges
On Sun, 4 Sep 2005, Junio C Hamano wrote: Sam Ravnborg [EMAIL PROTECTED] writes: If the problem is not fully understood it can be difficult to come up with the proper solution. And with the example above the problem should be really easy to understand. Then we have the tree as used by hpa with a few more mergers in it. But the above is what was initial tried to do with the added complexity of a few more renames etc. All true. Let's redraw that simplified scenario, and see if what I said still holds. It may be interesting to store my previous message and this one and run diff between them. I suspect that the main difference to come out would be the the problem description part and the merge machinery part would not be all that different. I'm not quite so convinced, because I think that the actual situation is a bit more natural, and therefore our expectations at the end should be closer to right with less attention to detail. But I think the actual situation is more interesting, anyway, because it's more likely to happen and we're more likely to be able to help. This is a simplified scenario of klibc vs klibc-kbuild HPA had trouble with, to help us think of a way to solve this interesting merge problem. #1 - #3 - #5 - #7 // / #0 - #2 - #4 - #6 There are two lines of developments. #0-#1 renames F to G and introduces K. #0-#2 keeps F as F and does not introduce K. At commit #3, #2 is merged into #1. The changes made to the file contents of F between #0 and #2 are appreciated, but we would also want to keep our decision to rename F to G and our new file K. So commit #3 has the resulting merge contents in G and has K, inherited from #1. This _might_ be different from what we traditionally consider a 'merge', but from the use case point of view it is a valid thing one would want to do. I think this is actually quite a regular merge, and I think we should be able to offer some assistance. The situation with K is normal: case #3ALT. If someone introduces a file and there's no file or directory with that name in other trees, we assume that the merge should include it. F/G is trickier, and I don't think we can actually do much about it with the current structure of read-tree/merge-cache/etc, but, theoretically, we should recognize that #0-#1 is a rename plus content changes, and #0-#2 is content changes, so the total should be the rename plus contents changes; I think we want to additionally signal a conflict, because there's a reasonable chance that the rename will interfere with the #0-#2 changes, and need intervention. Most likely, this just means that we should not commit automatically, but have the user test the result first. For now, of course, we don't get renames at any point in the merging procedure, so our code can't tell, and sees it as a big conflict that the user has to deal with. But we can agree on what the result is if the user includes all the changes from the other branch (and see the situation you reported first as cherry-picking the content and leaving the structural changes). Commit #4 is a continued development from #2; changes are made to F, and there is no K. Commit #5 similarly is a continued development from #3; its changes are made to G and K also has further changes. We are about to merge #6 into #5 to create #7. We should be able to take advantage of what the user did when the merge #3 was made; namely, we should be able to infer that the line of development that flows #0 .. #3 .. #7 prefers to rename F to G, and also wants the newly introduced K. We should be able to tell it by looking at what the merge #3 did. Again, K should be unexceptional, because we're keeping a file that was added to one side but not the other. (In the other situation, it still works; relative to the common ancestor, we're in #8ALT, since #5 doesn't have K, which was in #2 and #6; we see the rejection in a merge as a removal, which is effectively the same.) Now, how can we use git to figure that out? First off, it should handle K automatically, because we're still including a file added by one side without interference from the other side. First, given our current head (#5) and the other head we are about to merge (#6), we need a way to tell if we merged from them before (i.e. the existence of #3) and if so the latest of such merge (i.e. #3). The merge base between #5 and #6 is #2. We can look at commits between us (#5) and the merge base (#2), find a merge (#3), which has two parents. One of the parents is #2 which is reachable from #6, and the other is #1 which is not reachable from #6 but is reachable from #5. Can we say that this reliably tells us that #2 is on their side and #1 is on our side? Does the fact that #3 is the commit topologically closest to #5 tell us that #3 is the one we want to look deeper? This is still handwaving, but
Re: [PATCH] Make git-apply understand \ No newline at end of file in non-english locales
The message \ No newline at end of file which sometimes is produced by diff(1) is locale dependent. We can't assume more than that it begins with \ . Signed-off-by: Fredrik Kuivinen [EMAIL PROTECTED] --- The previous patch wasn't doing the right thing. Hopefully I have managed to get it right this time. apply.c | 10 +++--- 1 files changed, 7 insertions(+), 3 deletions(-) b94e5e845c241fff14334001aa5d418d22cd115e diff --git a/apply.c b/apply.c --- a/apply.c +++ b/apply.c @@ -672,9 +672,13 @@ static int parse_fragment(char *line, un added++; newlines--; break; - /* We allow \ No newline at end of file */ + + /* We allow \ No newline at end of file. Depending +* on locale settings when the patch was produced we +* don't know what this line looks like. The only +* thing we do know is that it begins with \ . */ case '\\': - if (len 12 || memcmp(line, \\ No newline, 12)) + if (len 2 || line[1] != ' ') return -1; break; } @@ -683,7 +687,7 @@ static int parse_fragment(char *line, un * it in the above loop because we hit oldlines == newlines == 0 * before seeing it. */ - if (12 size !memcmp(line, \\ No newline, 12)) + if (2 size !memcmp(line, \\ , 2)) offset += linelen(line, size); patch-lines_added += added; - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Make sure the diff machinery outputs \ No newline ... in english
Fredrik Kuivinen [EMAIL PROTECTED] writes: In non-english locales diff(1) do sometimes output \ No newline at end of file in some other language. Set LC_ALL to C before execing diff to avoid this behaviour. Signed-off-by: Fredrik Kuivinen [EMAIL PROTECTED] I was thinking about this when I was examining your other patch. What else, other than the incomplete line marker (and timestamp output it uses by default, which we disable by passing explicit -L flags), are affected by locale in diff output? Especially, if the diff output is more readable for human consumers (i.e. reviewers) without making it harder to use to machine consumers (i.e. patch or git-apply) when generated under a locale that is 'native' to the data, this patch robs from users the possibility of doing so. IOW, in a Swedes-only project that tracks a document in Swedish, it _might_ be friendlier and more useful to the users if allowed generating diffs under sv_SE locale, as long as such a diff does not make the processing by patch and git-apply more difficult (which your other patch already solved for git-apply). - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Moved files and merges
Daniel Barkalow [EMAIL PROTECTED] writes: I think this is actually quite a regular merge, and I think we should be able to offer some assistance. The situation with K is normal: case #3ALT. If someone introduces a file and there's no file or directory with that name in other trees, we assume that the merge should include it. I was not particularly interested in discussing the initial merge, which is a perfectly regular merge as you said. I was more focusing on reusing the tree-structure change information we _could_ find in merge #3 when we make later merges, because that merge is something the user did in the past and would be a good guide for guessing what the user wants to happen to this round. There is no question about K in 'keeping addition' case. It gets interesting only when the first merge prefered 'reject addition by them' and we would want to reuse that preference in the second merge. But as I tried to clarify in the a couple of things worth mentioning message, there is no fundamental reason to treat removal and addition any differently. It is just a way to reduce unnecessary conflicts. Most likely, this just means that we should not commit automatically, but have the user test the result first. No question about it again. Of course, read-tree is in flux at the moment, so making more structural changes to it at the same time is awkward. Doing this in read-tree is a bit premature. I'd prefer a scripted solution first to see what we want and how well it works in practice. 1 / \ 0-2-3-5-7 \ / 4-6 It shouldn't matter to the merge at 7 if the 2-3 reorganization was done locally, by applying a patch, or by merging. There was another problem in my message that treated #3 specially. I did it that way primarily because I wanted to have an algorithm that needs to look only limited (namely, one) number of commits, more than what we currently look at. The problem is that the trail #0..#1..#3 (in the example in second message, whose rename probably happened between #0 and #1) may change the contents of the renamed file so drastically that diff between #2 and #3 may not look like rename anymore, while we could still detect it if we followed the whole trail and looked for renames between each commit on it. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Make git-apply understand \ No newline at end of file in non-english locales
Fredrik Kuivinen [EMAIL PROTECTED] writes: The message \ No newline at end of file which sometimes is produced by diff(1) is locale dependent. We can't assume more than that it begins with \ . Signed-off-by: Fredrik Kuivinen [EMAIL PROTECTED] --- The previous patch wasn't doing the right thing. Hopefully I have managed to get it right this time. I noticed that you left 12 in the previous patch, and thought it was a sane safety measure to make sure that the incomplete line marker is of reasonably length, not just any line that starts with '\ ' (i.e. \ foobar\n, which is a tad short). - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Tool renames? was Re: First stab at glossary
Junio C Hamano [EMAIL PROTECTED] wrote: I said: I'll draw up a strawman tonight unless somebody else does it first. [...] 3. Non-binaries are called '*-scripts'. In earlier discussions some people seem to like the distinction between *-script and others; I did not particularly like it, but I am throwing this in for discussion. I for one think this makes the command name dependent on a non-essential implementation detail, so -script should go. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Tool renames? was Re: First stab at glossary
Horst von Brand [EMAIL PROTECTED] writes:
3. Non-binaries are called '*-scripts'.
In earlier discussions some people seem to like the
distinction between *-script and others; I did not
particularly like it, but I am throwing this in for
discussion.
I for one think this makes the command name dependent on a non-essential
implementation detail, so -script should go.
I had the same opinion. The counter-argument people raised when
this topic came up on the list was that it would help grepping
in the source tree.
I'm tempted to suggest doing something along these lines:
- Rename things that are implemented in shell from *-script to
*.sh, and perl to *.perl in the source tree;
- Install them without .{sh,perl} suffix.
Once this is done, the users nor the 'git' wrapper do not have
to deal with *-script.
Comments?
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Tool renames? was Re: First stab at glossary
Peter Williams [EMAIL PROTECTED] writes: *.pl is what is usually used for perl scripts. My recollection may be faulty, but '*.pl' was meant to be used for older Perl libraries back in perl4 days, and the standalone scripts are to be named '*.perl' but many people made the mistake of naming them '*.pl'. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Reorganize read-tree
Daniel Barkalow [EMAIL PROTECTED] writes:
I got mostly done with this before Linus mentioned the possibility of
having multiple index entries in the same stage for a single path. I
finished it anyway, but I'm not sure that we won't want to know which of
the common ancestors contributed which, and, if some of them don't have a
path, we wouldn't be able to tell. The other advantages I see to this
approach are:
I've finished reading your patch, after beating it reasonably
heavily by feeding combinations of nonsense trees to make sure
it produces the same result as the original implementation. I
have not found any regression from the read-tree in master
branch, after you fixed the path ordering issues.
There are various potential refinements, plus removing a bunch of memory
leaks, still to do, but I think this is sufficiently close to review.
I am not so worried about the leaks right now; they are
something that could be fixed before it hits the master
branch.
I like your approach of reading the input trees, along with the
existing index contents, and re-populating the index one path at
a time. It probably is more readable.
I further think that you can get the best of both worlds, by
inventing a convention that mode=0 entry means 'this path does
not exist in this tree'. This would allow you to have multiple
entries at the same stage and still tell which one came from
which tree. Instead of calling fn in unpack_trees(), you could
make it only unpack the tree into the index, and then after
unpacking is done, call fn() repeatedly to resolve the resulting
index. Of course the semantics of merge_fn_t needs to change
but if you feed N trees, the caller of a merge_fn_t function
needs to pick up the first N entries (because you use mode=0
entry to mean 'missing from this tree', each path will always
have N entries) and feed them to the merge function in one call,
then pick up the next N entries and feed them in the next call,
and so on. I think that would simplify that part of the code
even further.
So if you are making an octopus of 4 trees (one being our
current branch) using 2 merge bases, your intermediate index
would look like:
mode SHA1 stage path
100644 X 0 foo from original index
00 0{40} 1 foo merge base #1 did not have foo
100644 Z 1 foo merge base #2 has it
100644 X 2 foo our current head
100644 Z 3 foo other head #1 being merged into us
100644 Y 3 foo other head #2 being merged into us
100644 Z 3 foo other head #3 being merged into us
We cannot write something like this out without breaking
backward compatibility, but I personally think this breakage is
OK, because what is being broken is the index file format, not
tree object format, and the index file is by definition local to
a repository. IOW, it is not too much to ask people not to use
old tools to read new index file they created using new tools.
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] Update documentation of --compose to git-send-email-script.txt
Signed-off-by: Ryan Anderson [EMAIL PROTECTED] --- Documentation/git-send-email-script.txt | 13 + 1 files changed, 9 insertions(+), 4 deletions(-) 60765e20aa12da748f43204e25cb582f88fb16c8 diff --git a/Documentation/git-send-email-script.txt b/Documentation/git-send-email-script.txt --- a/Documentation/git-send-email-script.txt +++ b/Documentation/git-send-email-script.txt @@ -33,16 +33,21 @@ The options available are: the value GIT_COMMITTER_IDENT, as returned by git-var -l. The user will still be prompted to confirm this entry. + --compose + Use \$EDITOR to edit an introductory message for the + patch series. + --subject Specify the initial subject of the email thread. + Only necessary if --compose is also set. If --compose + is not set, this will be prompted for. --in-reply-to Specify the contents of the first In-Reply-To header. Subsequent emails will refer to the previous email - instead of this. - When overriding on the command line, it may be necessary - to set this to a space. For example - --in-reply-to= + instead of this if --chain-reply-to is set (the default) + Only necessary if --compose is also set. If --compose + is not set, this will be prompted for. --chain-reply-to, --no-chain-reply-to If this is set, each email will be sent as a reply to the previous - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Make git-apply understand \ No newline at end of file in non-english locales
On Sun, Sep 04, 2005 at 12:25:16PM -0700, Junio C Hamano wrote: Fredrik Kuivinen [EMAIL PROTECTED] writes: The message \ No newline at end of file which sometimes is produced by diff(1) is locale dependent. We can't assume more than that it begins with \ . Signed-off-by: Fredrik Kuivinen [EMAIL PROTECTED] --- The previous patch wasn't doing the right thing. Hopefully I have managed to get it right this time. I noticed that you left 12 in the previous patch, and thought it was a sane safety measure to make sure that the incomplete line marker is of reasonably length, not just any line that starts with '\ ' (i.e. \ foobar\n, which is a tad short). Maybe the first patch wasn't that bad after all :) In the current diffutils package the Swedish translation is one of the shortest ones, so 12 is ok for now at least. - Fredrik - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] Support multiple ancestors in read-tree
Various messages have already described this series. There's still a memory leak that should get resolved, but otherwise it should work. I'm not entirely sure that all directory-file conflict cases are handled properly, and some undefined cases behave differently. Also, I was a bit careless with preparing the patches. -Daniel *This .sig left intentionally blank* - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
