* Re: [PATCH] introduce inline is_same_sha1
From: Alex Riesen @ 2006-08-17 20:50 UTC (permalink / raw)
To: David Rientjes; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0608171152110.22819@chino.corp.google.com>
On 8/17/06, David Rientjes <rientjes@google.com> wrote:
> Introduces global inline:
> hashcmp(const unsigned char *sha1, const unsigned char *sha2)
>
> Uses memcmp for comparison and returns the result based on the length of
> the hash name (a future runtime decision).
>
> Signed-off-by: David Rientjes <rientjes@google.com>
Acked-by: Alex Riesen <raa.lkml@gmail.com>
^ permalink raw reply
* [PATCH] gitweb: bugfix: commitdiff regression
From: Luben Tuikov @ 2006-08-17 20:52 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 230 bytes --]
Fix regression in git_commitdiff() introduced
by commit 756d2f064b2419fcdf9cd9c851f352e2a4f75103.
Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
---
gitweb/gitweb.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
[-- Attachment #2: 2038685703-px.patch --]
[-- Type: application/octet-stream, Size: 690 bytes --]
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index bb77b55..b97342f 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2414,7 +2414,7 @@ sub git_commitdiff {
$cgi->a({-href => href(action=>"blob", hash=>$from_id, hash_base=>$hash_parent, file_name=>$file)}, $from_id) .
" -> " .
file_type($to_mode) . ":" .
- $cgi->a({-href => href(action=>"blob", hash=>$to_id, hash_base=>$hash, file_name=>$file)}, $to_id) .
+ $cgi->a({-href => href(action=>"blob", hash=>$to_id, hash_base=>$hash, file_name=>$file)}, $to_id);
print "</div>\n";
git_diff_print($from_id, "a/$file", $to_id, "b/$file");
}
--
1.4.2.g75c01
^ permalink raw reply related
* [PATCH] gitweb: bugfix: commitdiff regression
From: Luben Tuikov @ 2006-08-17 22:00 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 231 bytes --]
Fix regression in git_commitdiff() introduced
by commit 756d2f064b2419fcdf9cd9c851f352e2a4f75103.
Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
---
gitweb/gitweb.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
[-- Attachment #2: pat387950892 --]
[-- Type: application/octet-stream, Size: 690 bytes --]
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index bb77b55..b97342f 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2414,7 +2414,7 @@ sub git_commitdiff {
$cgi->a({-href => href(action=>"blob", hash=>$from_id, hash_base=>$hash_parent, file_name=>$file)}, $from_id) .
" -> " .
file_type($to_mode) . ":" .
- $cgi->a({-href => href(action=>"blob", hash=>$to_id, hash_base=>$hash, file_name=>$file)}, $to_id) .
+ $cgi->a({-href => href(action=>"blob", hash=>$to_id, hash_base=>$hash, file_name=>$file)}, $to_id);
print "</div>\n";
git_diff_print($from_id, "a/$file", $to_id, "b/$file");
}
--
1.4.2.g75c01
^ permalink raw reply related
* Re: [PATCH] gitweb: bugfix: commitdiff regression
From: Jakub Narebski @ 2006-08-17 22:11 UTC (permalink / raw)
To: git
In-Reply-To: <20060817220037.22377.qmail@web31812.mail.mud.yahoo.com>
Luben Tuikov wrote:
> Fix regression in git_commitdiff() introduced
> by commit 756d2f064b2419fcdf9cd9c851f352e2a4f75103.
>
> Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
> ---
> gitweb/gitweb.perl | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
Could you please attach patches inline, and if it is not possible due to
whitespace munging, at least attach them as text/plain with 8bit encoding,
not base64 encoding?
TIA
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Compression and dictionaries
From: linux @ 2006-08-17 22:33 UTC (permalink / raw)
To: Johannes.Schindelin, jonsmirl; +Cc: git, jcrigby, linux
In-Reply-To: <Pine.LNX.4.63.0608160832320.28360@wbgn013.biozentrum.uni-wuerzburg.de>
Just a note: there are index structures that support regular expression
searching. In particular, a PAT tree, usually represented implicitly as
a PAT array, can be walked by a finite automaton to find all the places
it matches.
However, there's a lot of code complexity associated with that. And a
PAT array assumes efficient random access to the text being indexed,
as it does not keep a copy of the text.
Perhaps most importantly, this would be a big change to "git grep", as
it would search every object in the database, not a particular commit.
And mapping objects back to filenames in trees and commits requires
another index.
Compression dictionaries and indexes have some opposing points. In a
compression dictionary, you prefer common words that appear in many places.
For an index, you prefer rare words that identify a small set of files.
^ permalink raw reply
* Re: Huge win, compressing a window of delta runs as a unit
From: Nicolas Pitre @ 2006-08-18 4:03 UTC (permalink / raw)
To: Jon Smirl; +Cc: Shawn Pearce, git
In-Reply-To: <9e4733910608161020s6855140bs68aaab6e1bbd3bad@mail.gmail.com>
On Wed, 16 Aug 2006, Jon Smirl wrote:
> Shawn put together a new version of his import utility that packs all
> of the deltas from a run into a single blob instead of one blob per
> delta. The idea is to put 10 or more deltas into each delta entry
> instead of one. The index format would map the 10 sha1's to a single
> packed delta entry which would be expanded when needed. Note that you
> probably needed multiple entries out of the delta pack to generate the
> revision you were looking for so this is no real loss on extraction.
>
> I ran it overnight on mozcvs. If his delta pack code is correct this
> is a huge win.
>
> One entry per delta - 845,42,0150
> Packed deltas - 295,018,474
> 65% smaller
Well, I have to state that I don't believe those results to be right.
Not that I question the results you obtained, but rather that Shawn's
pack generation is most probably broken.
Since I was highly suspicious looking at the above size difference (it
is just too good to be true), I did a quick hack to pack-objects.c to
produce packs with all deltas depending on the same root object into the
same zlib stream. In effect I implemented exactly what Shawn pretends
to have done but directly in pack-objects.c so git-repack could be used
with existing repositories like the linux kernel in order to validate
the concept.
Results:
One entry per delta - 122,103,455
Packed (or grouped) deltas : 108,479,014
Only 11% smaller.
I was really enthousiastic at first when I saw the result you obtained,
but I no longer believe it can be right.
Furthermore, such a pack organization has many disadvantages: it
prevents trivial delta data reuse for incremental push/pull operations
which is a huge performance penalty (bad for servers), as well as making
random object extraction from such a pack somewhat more complex. Those
disadvantages greatly outweight the 11% size saving IMHO.
A better way to get such a size saving is to increase the window and
depth parameters. For example, a window of 20 and depth of 20 can
usually provide a pack size saving greater than 11% with none of the
disadvantages mentioned above.
I therefore don't think this idea should be pursued any further.
For completeness you can find my changes to pack-objects below. Beware
that this produces packs that cannot be read back so backup your
repository first before playing with this.
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 448461b..bfae892 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -227,7 +227,7 @@ static int encode_header(enum object_typ
int n = 1;
unsigned char c;
- if (type < OBJ_COMMIT || type > OBJ_DELTA)
+ if (type < 0 || type > OBJ_DELTA)
die("bad type %d", type);
c = (type << 4) | (size & 15);
@@ -332,6 +332,8 @@ static unsigned long write_object(struct
return hdrlen + datalen;
}
+#if 0
+
static unsigned long write_one(struct sha1file *f,
struct object_entry *e,
unsigned long offset)
@@ -349,6 +351,107 @@ static unsigned long write_one(struct sh
return offset;
}
+#else
+
+static unsigned count_delta_childs(struct object_entry *e, unsigned long o)
+{
+ unsigned count = 0;
+ struct object_entry *child = e->delta_child;
+ while (child) {
+ count += 1 + count_delta_childs(child, o);
+ if (child->offset)
+ die("object already seen???");
+ child->offset = o;
+ child = child->delta_sibling;
+ }
+ return count;
+}
+
+static unsigned long write_delta_headers(struct sha1file *f, struct object_entry *e, unsigned long *size)
+{
+ unsigned long offset = 0;
+ struct object_entry *child = e->delta_child;
+ while (child) {
+ unsigned char header[10];
+ unsigned hdrlen;
+ hdrlen = encode_header(OBJ_DELTA, child->delta_size, header);
+ *size += child->delta_size;
+ sha1write(f, header, hdrlen);
+ sha1write(f, child->delta, 20);
+ offset += hdrlen + 20;
+ offset += write_delta_headers(f, child, size);
+ child = child->delta_sibling;
+ }
+ return offset;
+}
+
+static void * concat_delta_data(struct object_entry *e, void *buf)
+{
+ struct object_entry *child = e->delta_child;
+ while (child) {
+ char type[10];
+ unsigned long size;
+ void *data = read_sha1_file(child->sha1, type, &size);
+ if (!data)
+ die("unable to read %s", sha1_to_hex(child->sha1));
+ data = delta_against(data, size, child);
+ memcpy(buf, data, child->delta_size);
+ buf += child->delta_size;
+ free(data);
+ written++;
+ written_delta++;
+ buf = concat_delta_data(child, buf);
+ child = child->delta_sibling;
+ }
+ return buf;
+}
+
+static unsigned long write_one(struct sha1file *f,
+ struct object_entry *e,
+ unsigned long offset)
+{
+ unsigned char header[10];
+ unsigned count, hdrlen;
+ unsigned long size;
+ void *buf, *p;
+
+ if (e->offset)
+ /* offset starts from header size and cannot be zero
+ * if it is written already.
+ */
+ return offset;
+ if (!e->delta) {
+ e->offset = offset;
+ return offset + write_object(f, e);
+ }
+
+ /* find delta root object */
+ while (e->delta)
+ e = e->delta;
+
+ /* count how many deltas depend on it */
+ count = count_delta_childs(e, offset);
+
+ /* write header for object group */
+ hdrlen = encode_header(0, count, header);
+ sha1write(f, header, hdrlen);
+ offset += hdrlen;
+
+ /* write each object's header and find total data size */
+ size = 0;
+ offset += write_delta_headers(f, e, &size);
+
+ /* write concatenated object data buffer */
+ buf = xmalloc(size);
+ p = concat_delta_data(e, buf);
+ offset += sha1write_compressed(f, buf, p-buf);
+ free(buf);
+
+ return offset;
+}
+
+#endif
+
static void write_pack_file(void)
{
int i;
Nicolas
^ permalink raw reply related
* Re: [PATCH] gitweb: bugfix: commitdiff regression
From: Junio C Hamano @ 2006-08-18 4:09 UTC (permalink / raw)
To: Luben Tuikov; +Cc: git
In-Reply-To: <20060817205209.98624.qmail@web31801.mail.mud.yahoo.com>
Well spotted; thanks.
^ permalink raw reply
* Unresolved issues #3
From: Junio C Hamano @ 2006-08-18 4:09 UTC (permalink / raw)
To: git
As everybody has probably noticed already, I am terrible at
maintaining "the current issues" list. The most recent issue of
this series was done when? Back on May 4th this year.
Shame on me.
Here is a list of topics in the recent git traffic that I feel
inadequately addressed, in no particular order. I've commented
on some of them to give people a feel for what my priorities
are. Somebody might want to rehash the ones low on my priority
list to conclusion with a concrete proposal if they cared about
them enough.
* Mozilla import team seems to be making an interesting set of
discoveries around the area of scalability, although I haven't
personally looked at any of the tools they are using so far.
Continued discussion is encouraged, and I am looking forward
to see the fruits of this effort. Very much appreciated.
* Eric W Biederman outlined an alternative workflow to track
history of the tip of a branch that does not use ref-log
facility.
Message-ID: <m1mzakpam8.fsf@ebiederm.dsl.xmission.com>
I think this sort-of makes sense when everybody involved does
not misuse the fake parallel branch for purposes other than
tracking the tip of the other, "true", branch, but I fear it
would confuse people quite a bit. Eric talks about making
rewinding and rebasing in distributed manner possible, but I
do not know what merging between the fake branches would mean,
for example.
* Matthias Lederhofer's helper for stand alone gitweb test looked
very promising:
Message-ID: <20060806165151.GB9548@moooo.ath.cx>
With the recent flurry of gitweb changes, we really need a
test suite to catch obvious breakages in the t/ hierarchy, and
something like this patch would help.
I'd like to apply this patch, if somebody wants to add gitweb
tests.
* Jeff King sent a patch to color git-status output
Message-ID: <20060805031418.GA11102@coredump.intra.peff.net>
But later he started working on rewriting one core function
from git-status in C, which I think makes a lot of sense.
That would make this patch unnecessary. A thread related to
this effort is this:
Message-ID: <20060810082455.GA30739@coredump.intra.peff.net>
Hoping to see the C implementation of run_status but I am in
no rush myself.
I vaguely recall there was a companion patch to add vim
colorizer for the current git-status output, meant for
contrib/vim, but I lost it. If somebody cares deeply enough
please send it over.
* Alex Riesen still has problems with Git.pm/Git.xs on Windows
with ActiveState Perl.
Message-ID: <81b0412b0608020702q2fd4ec83ga43714c15538f7ad@mail.gmail.com>
There was a workaround patch by Alex to disable certain
commands that happen to use Git.pm:
Message-ID: <81b0412b0608040640s44c0d84et94871bce0271b047@mail.gmail.com>
But I sense this would make us think twice before using Git.pm
in new programs (i.e. "Can Alex live without this new nice
program? If not maybe we should write it without Git.pm"),
which feels backwards and I would like to avoid it if we can.
I am not sure what the resolution of this should be.
* Michael S. Tsirkin discovered that we have trouble dealing
with the same remote ref tracked by multiple tracking
branches.
Message-ID: <20060807125116.GA28658@mellanox.co.il>
Since I do not see a valid use case that _must_ use more than
one local tracking branch to track one remote ref, I think it
is Ok to declare it an error to do so. However, at least, we
would need a better error message even then.
* Jeff Garzik reports that the summary page of gitweb does not
look at anything other than "master" which is not appropriate
for his tree.
Message-ID: <44D874F0.6000907@garzik.org>
I probably should bug gitweb gang (Jakub, Luben, Martin Waitz,
Aneesh) about this.
* gitk bottom-left pane layout is reported to be broken for some
people.
Message-ID: <20060802192922.GA30539@prophet.net-ronin.org>
"carbonated beverage" tried some random hacks to work it
around but I do not think we have gotten anywhere, and the
discussion fizzled out.
I vaguely recall paulus saying it was a Tk bug but do not
recall hearing nor understanding any details myself.
* "A Large Angry SCM" wrote a nice summary, "Git files data
formats documentation".
Message-ID: <44D51D47.9090700@gmail.com>
With one final update by Nico yesterday, I think it is ready
for inclusion.
Does somebody care to make a patch out of it to add it to
Documentation/technical/, maybe removing pack-format.txt there
after making sure all it talks about is covered by the new
documentation?
I do not have enough "virginity" to spot omissions in the
description anymore, so comments from somebody new to the
system are very much appreciated.
* Martin Langhoff proposed git-xxdiff as a helper after a failed
merge.
Message-ID: <11546492331601-git-send-email-martin@catalyst.net.nz>
I like the general idea of this a lot, but am having a bit of
trouble envisioning how we can integrate this while making
sure mergers other than xxdiff can be added easily without
disrupting the end user experience.
* Shawn Pearce noticed that fsck-objects do not fully check some
fields in commits:
Message-ID: <20060814062830.GF18667@spearce.org>
* Although "annotate" had some big fixes just before 1.4.2, Ryan
seems to feel "blame" has already won.
Message-ID: <20060807194539.GD15477@h4x0r5.com>
Is there still an area "annotate" shines more than "blame -c"?
* "Michael barra_cuda" noticed that an option "--no" is
ambiguous to git-revert:
Message-ID: <200608031742.23170.barra_cuda@katamail.com>
I need to fix this.
* Cherry-pick should not require -r to suppress "cherry-picked
from" message.
Message-ID: <Pine.LNX.4.64.0607120834200.5623@g5.osdl.org>
This was requested by Linus, which I haven't done anything
about yet. Maybe making -r a no-op, defaulting not to add the
message, and introducing --record-original flag to add it
would be a way to go? My fingers are trained to automatically
type -r when doing cherry-pick which is a very good indication
that the flag was a mistake.
* Martin Waitz has a patch to accept "end-of-cover-letter"
marker in patch messages.
Message-ID: <20060723214524.GC20068@admingilde.org>
I did not take the patch, primarily because I do not want to
encourage "cover letter then log then patch" format, and also
the proposed marker "+++" looked somewhat ugly (see Message-ID:
<20060801193408.GF16364@admingilde.org> for an example).
If somebody wants to rehash this I am still open to reconsider
it, but I sense a veto from Linus coming...
^ permalink raw reply
* [PATCH] revert/cherry-pick: two minor fixes
From: Junio C Hamano @ 2006-08-18 4:09 UTC (permalink / raw)
To: git
Earlier it was noticed that revert has two seemingly overlapping
options, --no-commit and --no-edit. An ambiguious option,
e.g. "--no", is interpreted as --no-commit. It was consistent
because the documentation did not advertise the abbreviated
form, --no-edit, anyway, but that did not change the fact that
the case arm to handle --no-edit contained useless choices.
Linus asked to change cherry-pick's default not to record the
original commit object name (i.e. make -r the default). This
patch introduces a new option, --record-original, for people who
might prefer the command to record it.
Sometime in the near future, we would change the default not to
record the original commit, but not yet.
Update the documentation to match the above change.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Documentation/git-cherry-pick.txt | 18 +++++++++++-------
git-revert.sh | 8 ++++++--
2 files changed, 17 insertions(+), 9 deletions(-)
diff --git a/Documentation/git-cherry-pick.txt b/Documentation/git-cherry-pick.txt
index bfa950c..c2a2c27 100644
--- a/Documentation/git-cherry-pick.txt
+++ b/Documentation/git-cherry-pick.txt
@@ -7,7 +7,7 @@ git-cherry-pick - Apply the change intro
SYNOPSIS
--------
-'git-cherry-pick' [--edit] [-n] [-r] <commit>
+'git-cherry-pick' [--edit] [-n] [--record-original] [-r] <commit>
DESCRIPTION
-----------
@@ -24,13 +24,17 @@ OPTIONS
With this option, `git-cherry-pick` will let you edit the commit
message prior committing.
--r|--replay::
- Usually the command appends which commit was
+--record-original::
+ With this option, the command appends which commit was
cherry-picked after the original commit message when
- making a commit. This option, '--replay', causes it to
- use the original commit message intact. This is useful
- when you are reordering the patches in your private tree
- before publishing.
+ making a commit.
++
+This behaviour is still the default, and another option, `-r`,
+is used to turn it off. The plan is to make `-r` the default in
+the near future.
+
+-r|--replay::
+ See `--record-original`.
-n|--no-commit::
Usually the command automatically creates a commit with
diff --git a/git-revert.sh b/git-revert.sh
index 2bf35d1..179135b 100755
--- a/git-revert.sh
+++ b/git-revert.sh
@@ -12,7 +12,8 @@ case "$0" in
*-cherry-pick* )
edit=
me=cherry-pick
- USAGE='[--edit] [-n] [-r] <commit-ish>' ;;
+ replay=
+ USAGE='[--edit] [-n] [--record-original] <commit-ish>' ;;
* )
die "What are you talking about?" ;;
esac
@@ -29,12 +30,15 @@ do
-e|--e|--ed|--edi|--edit)
edit=-e
;;
- --n|--no|--no-|--no-e|--no-ed|--no-edi|--no-edit)
+ --no-e|--no-ed|--no-edi|--no-edit)
edit=
;;
-r|--r|--re|--rep|--repl|--repla|--replay)
replay=t
;;
+ --record-original)
+ replay=
+ ;;
-*)
usage
;;
--
1.4.2.gb0ae
^ permalink raw reply related
* Re: [PATCH] introduce inline is_same_sha1
From: Junio C Hamano @ 2006-08-18 4:09 UTC (permalink / raw)
To: David Rientjes; +Cc: git, Alex Riesen
In-Reply-To: <Pine.LNX.4.63.0608171152110.22819@chino.corp.google.com>
David Rientjes <rientjes@google.com> writes:
> On Thu, 17 Aug 2006, Alex Riesen wrote:
>
>> Why not just sha1cmp? And if you're aiming at hash-type independence,
>> why not hashcmp?
>
> hashcmp is a very good suggestion.
>
> David
> ---
> Introduces global inline:
> hashcmp(const unsigned char *sha1, const unsigned char *sha2)
>
> Uses memcmp for comparison and returns the result based on the length of
> the hash name (a future runtime decision).
>
> Signed-off-by: David Rientjes <rientjes@google.com>
Looks very very good. Much cleaner.
Also, I retract my previous comment that the parameters should
be (void*). Looking at the call sites that need casts, they
would need either (unsigned char*) or (char*) cast regardless of
the type of the argument hashcmp() function takes anyway.
Thanks. Will apply.
Oh, by the way, two minor procedural requests.
Pick a good one-line description of the patch; as it was sent,
the commit would have shown (in "git shortlog" output):
Introduces global inline:
which does not make much sense to the first time readers.
Please use something other than '---' as the delimiter after the
cover letter, if you write one _before_ the commit log message.
E-mailed patch acceptance tools consider anything after '---' is
patch and does not contribute to the commit log, so it is lost
from the resulting commit.
A short cover letter like this is better placed _after_ the real
separator '---' that comes after your commit log message, like
this:
From: David Rientjes <rientjes@google.com>
Subject: Do not use memcmp(sha1_1, sha1_2, 20) with hardcoded length.
Introduces global inline:
hashcmp(const unsigned char *sha1, const unsigned char *sha2)
Uses memcmp for comparison and returns the result based on the length of
the hash name (a future runtime decision).
Signed-off-by: David Rientjes <rientjes@google.com>
---
On Thu, 17 Aug 2006, Alex Riesen wrote:
> Why not just sha1cmp? And if you're aiming at hash-type independence,
> why not hashcmp?
hashcmp is a very good suggestion. Please ack the following.
builtin-commit-tree.c | 2 +-
builtin-diff-stages.c | 2 +-
...
^ permalink raw reply
* Re: [RFC diff-tree -c with copy/rename]
From: Junio C Hamano @ 2006-08-18 4:09 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
In-Reply-To: <e5bfff550608170402w25b9eaeaqe69665bdddaead3c@mail.gmail.com>
"Marco Costalba" <mcostalba@gmail.com> writes:
> As example
>
> 'R093MM checkout-index.c builtin-checkout-index.c'
>
> instead of current
>
> 'RM builtin-checkout-index.c'
I am not particularly opposed to have an option to do this. I
originally did not show this because I did not particularly find
it interesting (and I still don't). The output would become a
very long line, not for human consumption, though.
But it should not be too involved if you want to do this. We
already compute all the information necessary to do so before
combine-diff.c::intersect_paths() converts the usual <from,to>
representation (struct diff_filepair) into <result, list of
parents' blobs> representation (struct combine_diff_path), which
is used by combine-diff.c routines.
We currently do not retain that information when this conversion
happens to be used for the output. You would need to add a few
fields to record the preimage filename, similarity score and
status in struct combine_diff_parent and populate them in
intersect_paths() and adjust the output routines.
^ permalink raw reply
* Re: recur status on linux-2.6
From: Junio C Hamano @ 2006-08-18 4:09 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0608132221030.10541@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Sun, 13 Aug 2006, Junio C Hamano wrote:
>
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>
>> > I fail to see how this is worse than -recursive...
>>
>> These are what I got. ls-files -u output followed by git diff.
>
> I am a little confused here: I thought it would be enough to compare the
> outputs of "git-ls-files --stage". But that seems wrong.
>
> What are the stages for, again?
I do not offhand remember what git-merge-recursive and
git-merge-recur store in stage #1 when they recurse to create a
virtual common ancestor. I expected it would contain the blob
used as the base for the final file-level three-way merge
(i.e. the blob in the virtual common ancestor), and if that is
the case, i.e. if the blob matches the second argument for
"merge" (from RCS), it should be enough to check that the stages
match to verify two implementations do the same thing.
But in practice, stage #1 is not very interesting nor useful
after a conflicted merge (git diff --ours and git diff --theirs
are more useful, so is git log -p --merge), so it is possible
that merge-recursive is leaving the blob from one of the true
common ancestors there while using the blob from the virtual
common ancestor to produce the final result in the working tree
and nobody has noticed. I dunno.
^ permalink raw reply
* Re: [Possible bug] diff-tree --stat info does not count copies
From: Junio C Hamano @ 2006-08-18 4:09 UTC (permalink / raw)
To: Marco Costalba; +Cc: Junio C Hamano, git
In-Reply-To: <e5bfff550608170354i45104458h3b7e2ec8c668fb9c@mail.gmail.com>
"Marco Costalba" <mcostalba@gmail.com> writes:
> On 8/17/06, Junio C Hamano <junkio@cox.net> wrote:
>
>> Interesting. That's really a matter of taste and interpretation.
>>...
>
> If it was a rename we had something like:
>
> diff-lib.c | 1795 -----------------------------------------
> diff.c | 1795 ++++++++++++++++++++++++++++++++++++++++
>
> and, with -C
>
> diff-lib.c => diff.c | 0
>
> and _this_ is correct. But with copy diff-lib.c => diff.c should not
> stay at zero lines changed because diff.c is not the same of
> diff-lib.c, but it's a _new_ file created with the same content of
> diff-lib.c and _then_ the original and only diff-lib.c file is further
> modified on his own (in our case changing 1862 lines).
>
> Please tell me where I get wrong.
That's why I said this is a matter of taste and interpretation.
Our differences lie in what we expect from these numbers. I do
not think your interpretation is wrong. It is just different
from mine, and I happen to think my interpretation is more
useful for my purposes.
The numbers currently shown give "how big a patch do I have to
go through if I were to review this change in a patch form,
assuming I am reasonably familiar with the current, pre-image,
code?" So straight copy does not count -- if the patch tells me
that new file diff.c has the same contents as old diff-lib.c,
then I know what the resulting diff.c would contain without
looking at the patch text to judge what its implications are
(including things like 'if file A.c is moved to sub/B.c, I know
A.c includes "C.h" and it needs to be adjusted to include
"../C.h"). In "copy plus edit" case, the change shown in the
diff text plus the fact that the file was copied from something
I know makes the patch part the only thing that needs to be
reviewed. The same logic applies to rename with or without
editing.
What you expect seems to be different. If I understand you
correctly, you are asking for the number of lines that need to
be touched (inserted and removed) in order to make the original
into the patched, when the source tree is taken as a whole. I
do not think it is wrong to want to know that number, which is
pretty much the same number the command gives without -M/-C
[*1*].
To make this topic even more interesting, we can compare these
three commands:
$ paths='diff-lib.c diff.c'
$ git diff-tree -r --stat --summary 6973dca -- $paths
$ git diff-tree -r --stat --summary -C 6973dca -- $paths
$ git diff-tree -r --stat --summary -B -C 6973dca -- $paths
The last one says:
6973dcaee76ef7b7bfcabd2f26e76205aae07858
diff-lib.c | 1928 +++-----------------------------------------------
diff-lib.c => diff.c | 0
2 files changed, 133 insertions(+), 1795 deletions(-)
rewrite diff-lib.c (99%)
rename diff-lib.c => diff.c (100%)
which, personally, I think tells the story closest to what
really happened for this change. What was known to be
diff-lib.c was renamed to diff.c without any change, while
diff-lib.c was replaced by completely new contents, losing all
1795 lines that were there and acquiring 133 brand new lines.
In this case, I do not _need_ to look at the 1795 lines that
were lost from diff-lib.c to review the new implementation of
diff-lib.c, assuming that I am familiar with the pre-image code
(so what I said earlier about the number of lines I have to
review is not quite true, but is close enough).
[Footnote]
*1* But if that is the number you are after, then you should
count rename and copy the same way by saying rename removes N
lines and adds N lines (that happen to be the same) elsewhere,
so you would not say 0 is the right answer.
^ permalink raw reply
* Re: Unresolved issues #3
From: A Large Angry SCM @ 2006-08-18 4:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpseyelcw.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
...
> * "A Large Angry SCM" wrote a nice summary, "Git files data
> formats documentation".
>
> Message-ID: <44D51D47.9090700@gmail.com>
>
> With one final update by Nico yesterday, I think it is ready
> for inclusion.
>
> Does somebody care to make a patch out of it to add it to
> Documentation/technical/, maybe removing pack-format.txt there
> after making sure all it talks about is covered by the new
> documentation?
>
> I do not have enough "virginity" to spot omissions in the
> description anymore, so comments from somebody new to the
> system are very much appreciated.
>
Two things:
1) I disagree with Nico's assessment that, other than his, there can not
exist any type 2 packs that have bit 6 set to mean copy from result.
2) The document, if included into the core Git documentation, would be
viewed as more authoritative than it actually is. It's really just a set
of (structured) notes on various aspects of the files Git reads and
writes, pulled from various sources. Little or no attempt was made to
separate "implementation artifact" from intended structure.
^ permalink raw reply
* [PATCH] gitweb: Support for snapshot
From: Aneesh Kumar K.V @ 2006-08-18 5:06 UTC (permalink / raw)
To: git
In-Reply-To: <20060817152946.GA5917@satan.home.org>
[-- Attachment #1: Type: text/plain, Size: 214 bytes --]
Now I read RFC 2616 the content-encoding need to be specified as x-gzip.
Also i am not sure whether the fact that it is registered with IANA exempt us from
adding it to html header.
The corrected patch below.
[-- Attachment #2: 0001-gitweb-Support-for-snapshot.txt --]
[-- Type: text/plain, Size: 3423 bytes --]
This adds snapshort support in gitweb. To enable one need to
set gitweb.snapshot = true in the config file.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
---
gitweb/gitweb.perl | 41 +++++++++++++++++++++++++++++++++++++----
1 files changed, 37 insertions(+), 4 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 04282fa..d6f96a3 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -15,6 +15,7 @@ use CGI::Carp qw(fatalsToBrowser);
use Encode;
use Fcntl ':mode';
use File::Find qw();
+use File::Basename qw(basename);
binmode STDOUT, ':utf8';
our $cgi = new CGI;
@@ -175,6 +176,7 @@ my %actions = (
"tag" => \&git_tag,
"tags" => \&git_tags,
"tree" => \&git_tree,
+ "snapshot" => \&git_snapshot,
);
$action = 'summary' if (!defined($action));
@@ -1320,6 +1322,7 @@ sub git_difftree_body {
sub git_shortlog_body {
# uses global variable $project
my ($revlist, $from, $to, $refs, $extra) = @_;
+ my $have_snapshot = git_get_project_config_bool('snapshot');
$from = 0 unless defined $from;
$to = $#{$revlist} if (!defined $to || $#{$revlist} < $to);
@@ -1344,8 +1347,11 @@ sub git_shortlog_body {
print "</td>\n" .
"<td class=\"link\">" .
$cgi->a({-href => href(action=>"commit", hash=>$commit)}, "commit") . " | " .
- $cgi->a({-href => href(action=>"commitdiff", hash=>$commit)}, "commitdiff") .
- "</td>\n" .
+ $cgi->a({-href => href(action=>"commitdiff", hash=>$commit)}, "commitdiff");
+ if ($have_snapshot) {
+ print " | " . $cgi->a({-href => href(action=>"snapshot", hash=>$commit)}, "snapshot");
+ }
+ print "</td>\n" .
"</tr>\n";
}
if (defined $extra) {
@@ -2112,6 +2118,29 @@ sub git_tree {
git_footer_html();
}
+sub git_snapshot {
+
+ if (!defined $hash) {
+ $hash = git_get_head_hash($project);
+ }
+
+ my $filename = basename($project) . "-$hash.tar.gz";
+
+ print $cgi->header(-type => 'application/x-tar',
+ -content-encoding => 'x-gzip',
+ '-content-disposition' => "inline; filename=\"$filename\"",
+ -status => '200 OK');
+
+ open my $fd, "-|", "$GIT tar-tree $hash \'$project\' | gzip" or
+ die_error(undef, "Execute git-tar-tree failed.");
+ binmode STDOUT, ':raw';
+ print <$fd>;
+ binmode STDOUT, ':utf8'; # as set at the beginning of gitweb.cgi
+ close $fd;
+
+
+}
+
sub git_log {
my $head = git_get_head_hash($project);
if (!defined $hash) {
@@ -2206,6 +2235,7 @@ sub git_commit {
}
my $refs = git_get_references();
my $ref = format_ref_marker($refs, $co{'id'});
+ my $have_snapshot = git_get_project_config_bool('snapshot');
my $formats_nav = '';
if (defined $file_name && defined $co{'parent'}) {
my $parent = $co{'parent'};
@@ -2241,8 +2271,11 @@ sub git_commit {
"<td class=\"sha1\">" .
$cgi->a({-href => href(action=>"tree", hash=>$co{'tree'}, hash_base=>$hash), class => "list"}, $co{'tree'}) .
"</td>" .
- "<td class=\"link\">" . $cgi->a({-href => href(action=>"tree", hash=>$co{'tree'}, hash_base=>$hash)}, "tree") .
- "</td>" .
+ "<td class=\"link\">" . $cgi->a({-href => href(action=>"tree", hash=>$co{'tree'}, hash_base=>$hash)}, "tree");
+ if ($have_snapshot) {
+ print " | " . $cgi->a({-href => href(action=>"snapshot", hash=>$hash)}, "snapshot");
+ }
+ print "</td>" .
"</tr>\n";
my $parents = $co{'parents'};
foreach my $par (@$parents) {
--
1.4.2.rc1.g83e1-dirty
^ permalink raw reply related
* Re: Unresolved issues #3
From: Jeff King @ 2006-08-18 5:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpseyelcw.fsf@assigned-by-dhcp.cox.net>
On Thu, Aug 17, 2006 at 09:09:03PM -0700, Junio C Hamano wrote:
> * Jeff King sent a patch to color git-status output
[...]
> Hoping to see the C implementation of run_status but I am in
> no rush myself.
I am working on this but got side-tracked by "real" work. The current
state is that I have a simplistic working C run_status, but I'm still
hoping to hack the diff code to simultaneously do the tree<->index and
index<->files diffs. I will try to send out something next week.
> I vaguely recall there was a companion patch to add vim
> colorizer for the current git-status output, meant for
> contrib/vim, but I lost it. If somebody cares deeply enough
> please send it over.
It's in <20060805032135.GA11244@coredump.intra.peff.net>. However, if I
can get the multi-diff support working, then the status format will
change. I will wait until that is resolved before submitting a patch to
put vim highlighting into contrib/.
-Peff
^ permalink raw reply
* [PATCH] make sha1_sort inline
From: David Rientjes @ 2006-08-18 5:30 UTC (permalink / raw)
To: git
Inlines sha1_sort as discussed in previous thread.
Signed-off-by: David Rientjes <rientjes@google.com>
---
builtin-pack-objects.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index f19f0d6..b7ba558 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -929,7 +929,8 @@ static struct object_entry **create_sort
return list;
}
-static int sha1_sort(const struct object_entry *a, const struct object_entry *b)
+static inline int sha1_sort(const struct object_entry *a,
+ const struct object_entry *b)
{
return hashcmp(a->sha1, b->sha1);
}
--
1.4.2.rc4.gd070-dirty
^ permalink raw reply related
* Re: [PATCH] make sha1_sort inline
From: Junio C Hamano @ 2006-08-18 5:43 UTC (permalink / raw)
To: David Rientjes; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0608172229070.25827@chino.corp.google.com>
David Rientjes <rientjes@google.com> writes:
> Inlines sha1_sort as discussed in previous thread.
The only use of this function is to got its address taken of,
and then the variable that has its address (current_sort) is
used by sort_comparator() function, whose address is given to
the library routine qsort(3).
Does it still make sense to declare it inline?
^ permalink raw reply
* [PATCH] cleans up builtin-mv
From: David Rientjes @ 2006-08-18 5:59 UTC (permalink / raw)
To: git
Cleans up builtin-mv by removing a needless check of source's length,
redefinition of source's length, and misuse of strlen call that was
already assigned.
Signed-off-by: David Rientjes <rientjes@google.com>
---
builtin-mv.c | 14 +++++++-------
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/builtin-mv.c b/builtin-mv.c
index c0c8764..54c9262 100644
--- a/builtin-mv.c
+++ b/builtin-mv.c
@@ -126,7 +126,7 @@ int cmd_mv(int argc, const char **argv,
/* Checking */
for (i = 0; i < count; i++) {
- int length;
+ int length = strlen(source[i]);
const char *bad = NULL;
if (show_only)
@@ -137,14 +137,13 @@ int cmd_mv(int argc, const char **argv,
bad = "bad source";
if (!bad &&
- (length = strlen(source[i])) >= 0 &&
!strncmp(destination[i], source[i], length) &&
(destination[i][length] == 0 || destination[i][length] == '/'))
bad = "can not move directory into itself";
if (S_ISDIR(st.st_mode)) {
const char *dir = source[i], *dest_dir = destination[i];
- int first, last, len = strlen(dir);
+ int first, last;
if (lstat(dest_dir, &st) == 0) {
bad = "cannot move directory over file";
@@ -153,14 +152,15 @@ int cmd_mv(int argc, const char **argv,
modes[i] = WORKING_DIRECTORY;
- first = cache_name_pos(source[i], len);
+ first = cache_name_pos(source[i], length);
if (first >= 0)
die ("Huh? %s/ is in index?", dir);
first = -1 - first;
for (last = first; last < active_nr; last++) {
const char *path = active_cache[last]->name;
- if (strncmp(path, dir, len) || path[len] != '/')
+ if (strncmp(path, dir, length) ||
+ path[length] != '/')
break;
}
@@ -189,7 +189,7 @@ int cmd_mv(int argc, const char **argv,
source[count + j] = path;
destination[count + j] =
prefix_path(dest_dir, dst_len,
- path + len);
+ path + length);
modes[count + j] = INDEX;
}
count += last - first;
@@ -217,7 +217,7 @@ int cmd_mv(int argc, const char **argv,
}
}
- if (!bad && cache_name_pos(source[i], strlen(source[i])) < 0)
+ if (!bad && cache_name_pos(source[i], length) < 0)
bad = "not under version control";
if (!bad) {
--
1.4.2.rc4.g55c3-dirty
^ permalink raw reply related
* [RFC] adding support for md5
From: David Rientjes @ 2006-08-18 6:01 UTC (permalink / raw)
To: git
I'd like to solicit some comments about implementing support for md5 as a
hash function that could be determined at runtime by the user during a
project init-db. md5, which I implemented as a configurable option in my
own tree, is a 128-bit hash that is slightly more recognized than sha1.
Likewise, it is also available in openssl/md5.h just as sha1 is available
through a library in openssl/sha1.h. My patch to move the hash name
comparison was a step in this direction in isolating many of the
particulars of hash-specific dependencies.
David
^ permalink raw reply
* Re: [PATCH] cleans up builtin-mv
From: David Rientjes @ 2006-08-18 6:12 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0608172230470.25827@chino.corp.google.com>
On Thu, 17 Aug 2006, David Rientjes wrote:
> Cleans up builtin-mv by removing a needless check of source's length,
> redefinition of source's length, and misuse of strlen call that was
> already assigned.
>
I'm not sure when this command had been added to the tree because it
definitely was not included six months ago in a git tree I use everyday.
It seems to me like this would more appropriately be handled by a simple
shell script that would be much simpler to implement and could not
possibly be slower than this implementation.
This patch is a small fraction of what could be changed in this
implementation and I don't doubt it will undergo a complete rewrite in the
future. I think the problems with it have compounded on top of itself
over time which doesn't make a lot of sense since it appears to be a
relatively new addition.
For example:
(length = strlen(source[i])) >= 0
was _completely_ unnecessary since the previous instruction was a call to
lstat(source[i], ...) which would return ENOENT if source[i] was empty.
strlen(source[i]) was assigned to a variable later in the function, this
time called "len" instead. There was also an additional call to
strlen(source[i]) on its own even though the len variable was within
scope.
This code is _utterly_ unsatisfactory.
David
^ permalink raw reply
* Another git-mv bug
From: Fredrik Kuivinen @ 2006-08-18 7:23 UTC (permalink / raw)
To: git
Hi,
In a Git repository:
$ git mv templates/info--exclude .
fatal: renaming templates/info--exclude failed: No such file or directory
- Fredrik
^ permalink raw reply
* [PATCH] git-apply: document remaining options in the man page
From: Jonas Fonseca @ 2006-08-18 8:45 UTC (permalink / raw)
To: git
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
[ On top of next if that matters. ]
I'm not sure if I got the --exclude note right, which says that running
apply from a subdirectory automatically excludes files outside the
subdirectory. As I mention below it looks like this excluding is only
done when --index or --cached is specified. It led me to investigate a
bit further and I think I might have found an issue or two.
I was playing with the prefix checking in use_patch() to try and see if
I could break it. I noticed that the patch filename will be prefixed
with the prefix, but not the paths in the patch. This means that if I
apply a patch created with a non-git diff for a file in a directory
with a name longer than the changed file it will not be applied, e.g.
git-am.txt in Documentation. So
v1.4.2-g169bec6:git/Documentation > git apply --index git-am.diff
will silently drop the change. Or maybe it is just me who doesn't know
how to see diffs in the index (git-diff-index reports no change to
Documentation/git-am.txt). The code from use_patch():
if (0 < prefix_length) { /* strlen("Documentation") = 13 */
int pathlen = strlen("git-am.txt"); /* = 10 */
if (pathlen <= prefix_length ||
memcmp(prefix, pathname, prefix_length))
return 0;
}
Anyway, the prefix check is only ever performed when using --index or
--cached. These options doesn't seem to support being run from a
subdirectories if the patch is given on stdin:
v1.4.2-g169bec6:git/Documentation > git apply --cached < git-am.diff
fatal: unable to create '.git/index': No such file or directory
I can make a follow-up patch if this is the way it's supposed to work.
In that case a better error message might be good to clearify things.
Lastly, `log -S<option>` is so great when doing these man pages updates
and you, like me, don't know the code very well, since you can "just"
paraphrase the commit message that will sometimes also describe the
scenario where the option is applicable. :)
Documentation/git-apply.txt | 28 +++++++++++++++++++++++-----
1 files changed, 23 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-apply.txt b/Documentation/git-apply.txt
index f1ab1f9..33d63a4 100644
--- a/Documentation/git-apply.txt
+++ b/Documentation/git-apply.txt
@@ -10,9 +10,9 @@ SYNOPSIS
--------
[verse]
'git-apply' [--stat] [--numstat] [--summary] [--check] [--index] [--apply]
- [--no-add] [--index-info] [--allow-binary-replacement]
- [--reverse] [-z] [-pNUM]
- [-CNUM] [--whitespace=<nowarn|warn|error|error-all|strip>]
+ [--no-add] [--index-info] [--allow-binary-replacement | --binary]
+ [-R | --reverse] [-z] [-pNUM] [-CNUM] [--inaccurate-eof] [--cached]
+ [--whitespace=<nowarn|warn|error|error-all|strip>] [--exclude=PATH]
[<patch>...]
DESCRIPTION
@@ -56,6 +56,11 @@ OPTIONS
up-to-date, it is flagged as an error. This flag also
causes the index file to be updated.
+--cached::
+ Apply a patch without touching the working tree. Instead, take the
+ cached data, apply the patch, and store the result in the index,
+ without using the working tree. This implies '--index'.
+
--index-info::
Newer git-diff output has embedded 'index information'
for each blob to help identify the original version that
@@ -63,7 +68,7 @@ OPTIONS
the original version of the blob is available locally,
outputs information about them to the standard output.
---reverse::
+-R, --reverse::
Apply the patch in reverse.
-z::
@@ -97,7 +102,7 @@ OPTIONS
the result with this option, which would apply the
deletion part but not addition part.
---allow-binary-replacement::
+--allow-binary-replacement, --binary::
When applying a patch, which is a git-enhanced patch
that was prepared to record the pre- and post-image object
name in full, and the path being patched exactly matches
@@ -108,6 +113,13 @@ OPTIONS
result. This allows binary files to be patched in a
very limited way.
+--exclude=<path-pattern>::
+ Don't apply changes to files matching the given path pattern. This can
+ be useful when importing patchsets, where you want to exclude certain
+ files or directories. Note, if you run git-apply from a subdirectory
+ it will automatically exclude changes for files outside the
+ subdirectory.
+
--whitespace=<option>::
When applying a patch, detect a new or modified line
that ends with trailing whitespaces (this includes a
@@ -128,6 +140,12 @@ OPTIONS
* `strip` outputs warnings for a few such errors, strips out the
trailing whitespaces and applies the patch.
+--inacurate-eof::
+ Under certain circumstances, some versions of diff do not correctly
+ detect a missing new-line at the end of the file. As a result, patches
+ created by such diff programs do not record incomplete lines
+ correctly. This option adds support for applying such patches by
+ working around this bug.
Configuration
-------------
--
Jonas Fonseca
^ permalink raw reply related
* Re: Unresolved issues #3
From: Catalin Marinas @ 2006-08-18 8:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpseyelcw.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 815 bytes --]
Junio C Hamano <junkio@cox.net> wrote:
> * Martin Langhoff proposed git-xxdiff as a helper after a failed
> merge.
>
> Message-ID: <11546492331601-git-send-email-martin@catalyst.net.nz>
>
> I like the general idea of this a lot, but am having a bit of
> trouble envisioning how we can integrate this while making
> sure mergers other than xxdiff can be added easily without
> disrupting the end user experience.
In StGIT I can configure the merge command and I currently use the
attached script (I need to add it to the StGIT repository). It tries
diff3 first and, if that fails, invokes emacs' merge (can use xxdiff
as well). It also checks whether the file was modified in case I want
to exit and solve the conflict later (maybe after getting conflict
information for the other files).
--
Catalin
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: merge-interactive.py --]
[-- Type: text/x-python, Size: 1950 bytes --]
#!/usr/bin/env python
"""Run diff3 and an interactive tool if this fails.
"""
__copyright__ = """
Copyright (C) 2006, Catalin Marinas <catalin.marinas@gmail.com>
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License version 2 as
published by the Free Software Foundation.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
"""
import sys, os
if len(sys.argv) != 5:
print >> sys.stderr, 'Usage: %s ancestor branch1 branch2 output' \
% sys.argv[0]
sys.exit(1)
ancestor = sys.argv[1]
branch1 = sys.argv[2]
branch2 = sys.argv[3]
output = sys.argv[4]
# default merger
if os.system('diff3 -L current -L ancestor -L patched -m -E '
'"%s" "%s" "%s" > "%s"'
% (branch1, ancestor, branch2, output)):
# interactive merge
if os.path.exists(output):
mtime = os.path.getmtime(output)
else:
mtime = 0
ret = os.system('emacs --eval \'(ediff-merge-files-with-ancestor '
'"%s" "%s" "%s" nil "%s")\''
% (branch1, branch2, ancestor, output))
#ret = os.system(
# 'xxdiff --title1 current --title2 ancestor --title3 patched '
# '--show-merged-pane -m -E -O -X -M "%s" "%s" "%s" "%s"'
# % (output, branch1, ancestor, branch2))
# error in the interactive merger, just exit
if ret:
sys.exit(2)
# check for file modification
if not os.path.exists(output) or mtime == os.path.getmtime(output):
sys.exit(3)
# everything's fine
sys.exit(0)
^ permalink raw reply
* Re: Unresolved issues #3
From: Jakub Narebski @ 2006-08-18 8:56 UTC (permalink / raw)
To: git
In-Reply-To: <7vpseyelcw.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> * Jeff Garzik reports that the summary page of gitweb does not
> look at anything other than "master" which is not appropriate
> for his tree.
>
> Message-ID: <44D874F0.6000907@garzik.org>
>
> I probably should bug gitweb gang (Jakub, Luben, Martin Waitz,
> Aneesh) about this.
For performance reasons this should probably wait for functioning
git-show-refs command. BTW. summary page doesn't show "Last Updated" based
on "master", but based on "HEAD" (current branch)... which usually is
"master" I guess in typical usage.
Another thing that I think is/might be important to gitweb, is to rewrite
commitdiff and blobdiff to not use external diff, but builtin
git-diff-tree... this probably would lead to changes in the output.
I'm thinking about "-B" without "-C" nor "-M" for plain output (is this
no-op for this combination?), and "-C", "-M" for HTML output.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ 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