* git blame not respecting --find-copies-harder ?
From: Stephen R. van den Berg @ 2008-07-30 9:39 UTC (permalink / raw)
To: Git Mailinglist
git clone git://git.cuci.nl/pike
Both of this "git blame" commands return the same (erroneous) results
at the end of the files (the last lines are older, and are from the old
README file next to it).
git blame README-CVS
git blame --find-copies-harder README-CVS
However, when using git show with and without --find-copies-harder, we
see that git indeed finds the copy with a 76% similarity index.
git show 9eb55816
git show --find-copies-harder 9eb55816
Shouldn't it be expected that blame should also give the same difference
in result with and without that option?
On a related note, it doesn't seem possible to make --find-copies-harder
a default; is that intentional?
--
Sincerely,
Stephen R. van den Berg.
How many weeks are there in a lightyear?
^ permalink raw reply
* Re: [ANNOUNCE] GitStats development finished (WRT GSoC)
From: Sverre Rabbelier @ 2008-07-30 9:12 UTC (permalink / raw)
To: Junio C Hamano
Cc: Git Mailinglist, Johannes Schindelin, Jakub Narebski,
David Symonds, Shawn O. Pearce, Sam Vilain
In-Reply-To: <7vabfz97fl.fsf@gitster.siamese.dyndns.org>
On Wed, Jul 30, 2008 at 09:07, Junio C Hamano <gitster@pobox.com> wrote:
> Can't wait running this, especially in conjunction with the "author" stuff
> ;-)
Hehe, don't expect too much of it yet though (the 'bug' module that
is), there won't be any "99% of the bugs come from Dscho" yet :P.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH v2] Support copy and rename detection in fast-export.
From: Alexander Gavrilov @ 2008-07-30 9:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, Johannes Schindelin, git
In-Reply-To: <7v7ib4hdpu.fsf@gitster.siamese.dyndns.org>
On Tue, Jul 29, 2008 at 8:11 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Alexander Gavrilov <angavrilov@gmail.com> writes:
>> ++
>> +Note that these options were always accepted by git-fast-export,
>> +but before a certain version it silently produced wrong results.
>> +You should always check the git version before using them.
>> +
>
> I do not quite follow the mention of "before a certain version", but I
> think it is talking about the earlier "fast-export" that took any diff
> options but did not act differently upon renamed/copied entries. If that
> is the case, I think we can say something like this instead:
>
> Note that earlier versions of this command did not complain and
> produced incorrect results if you gave these options.
>
> because docs always talk about the current version. My reading of Dscho's
> original 'show_filemodify' suggests me that "wrong results" does not just
> mean missing rename/copy information but a renamed old entity did not get
> removed correctly, resulting in an incorrect tree in the commit, right?
> Maybe we would want to be a bit more explicit about what kind of breakage
> you are talking about here.
Yes, broken renames is what I've been thinking of when I wrote that.
As fast-export is mainly meant to be used by third-party conversion
scripts, which are not bundled together with git, unsuspecting users
might try to run them using an old git version. The main point of my
note is that scripts should always check the version if they want to
use these options. It probably should also specify the exact value to
compare to, e.g:
Note that before git 1.6 this command did not complain and produced
incorrect results if you gave these options. Your scripts should always
check the version before using them.
> If you see a copied or renamed entry, you emit "this old path to that old
> path" first, and then say that same path got modified. It appears from my
> quick glance of fast-import that touching the same path more than once in
> a same commit like this sequence does would work fine (it will involve two
> calls to tree_content_set() for the same path but that is not something it
> has to forbid, and the function doesn't).
I'm sorry, but I don't quite understand what are you suggesting by
this paragraph. Yes, fast-import understands double modification, and
my test includes a check for this case. Of course, conversion scripts
for dumber targets might need to do one-line lookahead to eliminate
non-100% copies.
>> diff --git a/t/t9301-fast-export.sh b/t/t9301-fast-export.sh
>> index f18eec9..bb595b7 100755
>> --- a/t/t9301-fast-export.sh
>> +++ b/t/t9301-fast-export.sh
>> @@ -162,4 +162,50 @@ test_expect_success 'submodule fast-export | fast-import' '
>>
>> '
>>
>> +export GIT_AUTHOR_NAME='A U Thor'
>> +export GIT_COMMITTER_NAME='C O Mitter'
>> +
>> +test_expect_success 'setup copies' '
>> +
>> + git config --unset i18n.commitencoding &&
>
> These are somewhat unusual. Was there any reason for these exports and
> config?
>
t9301-fast-export.sh earlier changes these parameters to test
automatic conversion to utf8. I reset them back before my test, in
order to be able to test the import by comparing SHA-1 (encoding
conversion changes it). There may be a better way to do it, though.
^ permalink raw reply
* Re: Bizarre missing changes (git bug?)
From: Jakub Narebski @ 2008-07-30 8:36 UTC (permalink / raw)
To: Roman Zippel; +Cc: Martin Langhoff, Linus Torvalds, Tim Harper, git
In-Reply-To: <Pine.LNX.4.64.0807291433430.6791@localhost.localdomain>
Roman Zippel <zippel@linux-m68k.org> writes:
> I don't quite understand what you're trying to say.
> To avoid further confusion it maybe helps to specify a few of the terms:
>
> - full history graph: produced by "git-log --full-history --parents"
> - compact history graph: the full history graph without without any
> repeated merges, this is what my example script produces.
> - full simplified history: output of "git-log --full-history"
> - short simplified history: standard output of "git-log"
[...]
> Keep in mind that e.g. git-web is using the full simplified history, so
> what I'm offering also has the potential to improve git-web performance...
The fact that gitweb is using --full-history for a 'history' view
is a historical reason, backwards compatibility with the view that
was shown before gitweb used "git rev-list [flags] -- <path>", see
commit cdd4037d
gitweb: optimize per-file history generation
The rev-list command that is recent enough can filter commits
based on paths they touch, so use it instead of generating the
full list and limiting it by passing it with diff-tree --stdin.
[jc: The patch originally came from Luben Tuikov but the it was
corrupt, but it was short enough to be applied by hand. I
added the --full-history to make the output compatible with the
original while doing so.]
Signed-off-by: Junio C Hamano <junkio@cox.net>
Removing '--parents' was put later, to remove unnecessary merges
from a view (there was long discussion on git mailing list about
--full-history with and without --parents), in 208b2dff
gitweb: We do longer need the --parents flag in rev-list.
We only want to know the direct parents of a given commit object,
these parents are available in the --header output of rev-list. If
--parents is supplied with --full-history the output includes merge
commits that aren't relevant.
Signed-off-by: Robert Fitzsimons <robfitz@273k.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Besides gitweb currently does not generate graphical history view,
so '--parents' are unnecessary.
But if it was done from the scratch, gitweb should definitely
use simplified history, instead of what you call "full simplified
history", perhaps with an option to use '--full-history' (there
is infractructure in gitweb for adding extra options).
(Nitpick: it is 'gitweb', not 'git-web'.)
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* cvs diff -l equivalent?
From: Stephen R. van den Berg @ 2008-07-30 8:20 UTC (permalink / raw)
To: git
Someone popped this question on me. The closest I got was:
git diff .
But that still recurses. Any solutions without patching?
--
Sincerely,
Stephen R. van den Berg.
How many weeks are there in a lightyear?
^ permalink raw reply
* [PATCH] Fix merge name generation in "merge in C"
From: Junio C Hamano @ 2008-07-30 8:12 UTC (permalink / raw)
To: git; +Cc: Miklos Vajna
When merging an early part of a branch, e.g. "git merge xyzzy~20", we were
supposed to say "branch 'xyzzy' (early part)", but it incorrectly said
"branch 'refs/heads/xy' (early part)" instead.
The logic was supposed to first strip away "~20" part to make sure that
what follows "~" is a non-zero posint, prefix it with "refs/heads/" and
ask resolve_ref() if it is a ref. If it is, then we know xyzzy was a
branch, and we can give the correct message.
However, there were a few bugs. First of all, the logic to build this
"true branch refname" did not count the characters correctly. At this
point of the code, "len" is the number of trailing, non-name part of the
given extended SHA-1 expression given by the user, i.e. number of bytes in
"~20" in the above example.
In addition, the message forgot to skip "refs/heads/" it prefixed from the
output.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* It is a bit surprising that after beating merge-in-C to death, we
still find a minor breakage like this.
builtin-merge.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin-merge.c b/builtin-merge.c
index e78fa18..dde0c7e 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -396,12 +396,12 @@ static void merge_name(const char *remote, struct strbuf *msg)
struct strbuf truname = STRBUF_INIT;
strbuf_addstr(&truname, "refs/heads/");
strbuf_addstr(&truname, remote);
- strbuf_setlen(&truname, len+11);
+ strbuf_setlen(&truname, truname.len - len);
if (resolve_ref(truname.buf, buf_sha, 0, 0)) {
strbuf_addf(msg,
"%s\t\tbranch '%s'%s of .\n",
sha1_to_hex(remote_head->sha1),
- truname.buf,
+ truname.buf + 11,
(early ? " (early part)" : ""));
return;
}
^ permalink raw reply related
* Re: [ANNOUNCE] GitStats development finished (WRT GSoC)
From: Junio C Hamano @ 2008-07-30 7:07 UTC (permalink / raw)
To: sverre
Cc: Git Mailinglist, Johannes Schindelin, Jakub Narebski,
Junio C Hamano, David Symonds, Shawn O. Pearce, Sam Vilain
In-Reply-To: <bd6139dc0807291511v2d70d549r3682291eb10a745d@mail.gmail.com>
"Sverre Rabbelier" <alturin@gmail.com> writes:
> ... As a
> result it is quite clear what GitStats will look like at the end of my
> GSoC. I am going to continue working on it though, I am especially
> interested in getting the '--follow' part of 'git log' working in such
> a way that it can be incorporated into GitStats. As such, here is a
> summary of what GitStat is at the moment. From the documentation:
Wonderful.
> syntax: stats.py bug <options>
>
> The purpose of the bug module is to gather statistics on
> bugfixes within the content, and to aggregate this
> information to provide with a report of the last N commits.
Can't wait running this, especially in conjunction with the "author" stuff
;-)
^ permalink raw reply
* Re: [PATCH] Make it clear that push can take multiple refspecs
From: Junio C Hamano @ 2008-07-30 6:24 UTC (permalink / raw)
To: Abhijit Menon-Sen; +Cc: git
In-Reply-To: <20080730061727.GA1912@toroid.org>
Abhijit Menon-Sen <ams@toroid.org> writes:
> I think it's nice if items in the description exactly match something
> in the synopsis. It gives me more confidence that someone didn't just
> forget to update one or the other.
Yup; queued. Thanks.
^ permalink raw reply
* Re: [PATCH 1/4] builtin-help: make some internal functions available to other builtins
From: Junio C Hamano @ 2008-07-30 6:21 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <a2d2bc675801bb03e3035ec0102eb27f08f27f1b.1217372486.git.vmiklos@frugalware.org>
Thanks; all four patches queued.
^ permalink raw reply
* Re: [PATCH] Make it clear that push can take multiple refspecs
From: Abhijit Menon-Sen @ 2008-07-30 6:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwsj49t27.fsf@gitster.siamese.dyndns.org>
At 2008-07-29 16:20:00 -0700, gitster@pobox.com wrote:
>
> The synopsis talks about the ability for you to specify zero or more
> of whatever is called <refspec>, and here we define what _A_ refspec
> is.
Yes. The thing is, many places say "<refspec>..." both in the synopsis
and in the description (e.g. add, am, apply, commit...), and doing it
differently in some places seems more likely to be confusing than not.
I think it's nice if items in the description exactly match something
in the synopsis. It gives me more confidence that someone didn't just
forget to update one or the other.
(If you've queued the original git-push.txt patch, I'm happy to leave
the others alone, or change them one way or another, as you wish.)
-- ams
^ permalink raw reply
* Re: GIT 1.6.0-rc1
From: Junio C Hamano @ 2008-07-30 6:15 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20080730061012.GA4437@blimp.local>
Alex Riesen <raa.lkml@gmail.com> writes:
> Junio C Hamano, Wed, Jul 30, 2008 00:03:44 +0200:
>> Alex Riesen <raa.lkml@gmail.com> writes:
>> >> Alex, I ran the full test with this, but only on Linux boxes; obviously
>> >> not on any flavor of Windows. I think it is correct, and the "first line
>> >> of defence" fix is the same as your patch, so I'd assume it would work for
>> >> you as well. But extra eyeballs are always appreciated.
>> >
>> > Well, it works on Cygwin too. And I had my eyeballs on the code
>> > (wondered first if it will cause more fs accesses than before: it
>> > will, in the racy check. Which is correct, AFAICT)
>>
>> I thought racy check won't even trigger for gitlinks, no?
>>
>
> I didn't know. But now, come to think of it, there wouldn't be much
> point - the gitlinks are always compared by content, aren't they?
>
>> ce_modified_check_fs() has 3 call sites:
>>
>> - the call site in ie_match_stat() is protected with is_racy_timestamp()
>> that is always false for gitlinks;
>>
>> - the call site in ie_modified() we just took care of in the current
>> thread;
>>
>> - the other call site is in ce_smudge_racily_clean_entry(), which is
>> called from write_index() but it also is protected with
>> is_racy_timestamp() that is always false for gitlinks.
>
> So, the change in ce_modified_check_fs is not really needed, because
> the gitlink case is never executed?
That's what I meant by "futureproofing".
^ permalink raw reply
* Re: GIT 1.6.0-rc1
From: Alex Riesen @ 2008-07-30 6:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmyk0bb5r.fsf@gitster.siamese.dyndns.org>
Junio C Hamano, Wed, Jul 30, 2008 00:03:44 +0200:
> Alex Riesen <raa.lkml@gmail.com> writes:
> >> Alex, I ran the full test with this, but only on Linux boxes; obviously
> >> not on any flavor of Windows. I think it is correct, and the "first line
> >> of defence" fix is the same as your patch, so I'd assume it would work for
> >> you as well. But extra eyeballs are always appreciated.
> >
> > Well, it works on Cygwin too. And I had my eyeballs on the code
> > (wondered first if it will cause more fs accesses than before: it
> > will, in the racy check. Which is correct, AFAICT)
>
> I thought racy check won't even trigger for gitlinks, no?
>
I didn't know. But now, come to think of it, there wouldn't be much
point - the gitlinks are always compared by content, aren't they?
> ce_modified_check_fs() has 3 call sites:
>
> - the call site in ie_match_stat() is protected with is_racy_timestamp()
> that is always false for gitlinks;
>
> - the call site in ie_modified() we just took care of in the current
> thread;
>
> - the other call site is in ce_smudge_racily_clean_entry(), which is
> called from write_index() but it also is protected with
> is_racy_timestamp() that is always false for gitlinks.
So, the change in ce_modified_check_fs is not really needed, because
the gitlink case is never executed?
^ permalink raw reply
* Re: [RFC/PATCH v4 1/2] merge-base: teach "git merge-base" to accept more than 2 arguments
From: Junio C Hamano @ 2008-07-30 6:00 UTC (permalink / raw)
To: Christian Couder; +Cc: git, Johannes Schindelin, Miklos Vajna, Jakub Narebski
In-Reply-To: <20080730070414.f7b36eec.chriscool@tuxfamily.org>
Thanks; queued. Perhaps I'll add the test scirpt to demonstrate the
topology in the new documentation myself, and the merge-octupos update I
sent earlier to the list can come on top of this series.
^ permalink raw reply
* [PATCH] format-patch: Produce better output with --inline or --attach
From: Kevin Ballard @ 2008-07-30 5:49 UTC (permalink / raw)
To: git; +Cc: peff, Kevin Ballard, Junio C Hamano
In-Reply-To: <20080730052401.GC4034@sigill.intra.peff.net>
This patch makes two small changes to improve the output of --inline
and --attach.
The first is to write a newline preceding the boundary. This is needed because
MIME defines the encapsulation boundary as including the preceding CRLF (or in
this case, just LF), so we should be writing one. Without this, the last
newline in the pre-diff content is consumed instead.
The second change is to always write the line termination character
(default: newline) even when using --inline or --attach. This is simply to
improve the aesthetics of the resulting message. When using --inline an email
client should render the resulting message identically to the non-inline
version. And when using --attach this adds a blank line preceding the
attachment in the email, which is visually attractive.
Signed-off-by: Kevin Ballard <kevin@sb.org>
---
diff.c | 3 +--
log-tree.c | 2 +-
....format-patch_--attach_--stdout_initial..master | 6 ++++++
...format-patch_--attach_--stdout_initial..master^ | 4 ++++
...ff.format-patch_--attach_--stdout_initial..side | 2 ++
...tdout_--subject-prefix=TESTCASE_initial..master | 6 ++++++
....format-patch_--inline_--stdout_initial..master | 6 ++++++
...format-patch_--inline_--stdout_initial..master^ | 4 ++++
...ormat-patch_--inline_--stdout_initial..master^^ | 2 ++
...ff.format-patch_--inline_--stdout_initial..side | 2 ++
10 files changed, 34 insertions(+), 3 deletions(-)
diff --git a/diff.c b/diff.c
index a07812c..cbf2547 100644
--- a/diff.c
+++ b/diff.c
@@ -3223,11 +3223,10 @@ void diff_flush(struct diff_options *options)
if (output_format & DIFF_FORMAT_PATCH) {
if (separator) {
+ putc(options->line_termination, options->file);
if (options->stat_sep) {
/* attach patch instead of inline */
fputs(options->stat_sep, options->file);
- } else {
- putc(options->line_termination, options->file);
}
}
diff --git a/log-tree.c b/log-tree.c
index 5505606..bd8b9e4 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -198,7 +198,7 @@ void log_write_email_headers(struct rev_info *opt, const char *name,
extra_headers = subject_buffer;
snprintf(buffer, sizeof(buffer) - 1,
- "--%s%s\n"
+ "\n--%s%s\n"
"Content-Type: text/x-patch;"
" name=\"%s.diff\"\n"
"Content-Transfer-Encoding: 8bit\n"
diff --git a/t/t4013/diff.format-patch_--attach_--stdout_initial..master b/t/t4013/diff.format-patch_--attach_--stdout_initial..master
index cf6891f..43346b9 100644
--- a/t/t4013/diff.format-patch_--attach_--stdout_initial..master
+++ b/t/t4013/diff.format-patch_--attach_--stdout_initial..master
@@ -19,6 +19,8 @@ This is the second commit.
file2 | 3 ---
3 files changed, 5 insertions(+), 3 deletions(-)
delete mode 100644 file2
+
+
--------------g-i-t--v-e-r-s-i-o-n
Content-Type: text/x-patch; name="1bde4ae5f36c8d9abe3a0fce0c6aab3c4a12fe44.diff"
Content-Transfer-Encoding: 8bit
@@ -75,6 +77,8 @@ Content-Transfer-Encoding: 8bit
file1 | 3 +++
2 files changed, 5 insertions(+), 0 deletions(-)
create mode 100644 file1
+
+
--------------g-i-t--v-e-r-s-i-o-n
Content-Type: text/x-patch; name="9a6d4949b6b76956d9d5e26f2791ec2ceff5fdc0.diff"
Content-Transfer-Encoding: 8bit
@@ -122,6 +126,8 @@ Content-Transfer-Encoding: 8bit
file3 | 4 ++++
3 files changed, 9 insertions(+), 0 deletions(-)
create mode 100644 file3
+
+
--------------g-i-t--v-e-r-s-i-o-n
Content-Type: text/x-patch; name="c7a2ab9e8eac7b117442a607d5a9b3950ae34d5a.diff"
Content-Transfer-Encoding: 8bit
diff --git a/t/t4013/diff.format-patch_--attach_--stdout_initial..master^ b/t/t4013/diff.format-patch_--attach_--stdout_initial..master^
index fe02587..d7490a9 100644
--- a/t/t4013/diff.format-patch_--attach_--stdout_initial..master^
+++ b/t/t4013/diff.format-patch_--attach_--stdout_initial..master^
@@ -19,6 +19,8 @@ This is the second commit.
file2 | 3 ---
3 files changed, 5 insertions(+), 3 deletions(-)
delete mode 100644 file2
+
+
--------------g-i-t--v-e-r-s-i-o-n
Content-Type: text/x-patch; name="1bde4ae5f36c8d9abe3a0fce0c6aab3c4a12fe44.diff"
Content-Transfer-Encoding: 8bit
@@ -75,6 +77,8 @@ Content-Transfer-Encoding: 8bit
file1 | 3 +++
2 files changed, 5 insertions(+), 0 deletions(-)
create mode 100644 file1
+
+
--------------g-i-t--v-e-r-s-i-o-n
Content-Type: text/x-patch; name="9a6d4949b6b76956d9d5e26f2791ec2ceff5fdc0.diff"
Content-Transfer-Encoding: 8bit
diff --git a/t/t4013/diff.format-patch_--attach_--stdout_initial..side b/t/t4013/diff.format-patch_--attach_--stdout_initial..side
index 9ff828e..38f7902 100644
--- a/t/t4013/diff.format-patch_--attach_--stdout_initial..side
+++ b/t/t4013/diff.format-patch_--attach_--stdout_initial..side
@@ -17,6 +17,8 @@ Content-Transfer-Encoding: 8bit
file3 | 4 ++++
3 files changed, 9 insertions(+), 0 deletions(-)
create mode 100644 file3
+
+
--------------g-i-t--v-e-r-s-i-o-n
Content-Type: text/x-patch; name="c7a2ab9e8eac7b117442a607d5a9b3950ae34d5a.diff"
Content-Transfer-Encoding: 8bit
diff --git a/t/t4013/diff.format-patch_--inline_--stdout_--subject-prefix=TESTCASE_initial..master b/t/t4013/diff.format-patch_--inline_--stdout_--subject-prefix=TESTCASE_initial..master
index a8093be..fca5cce 100644
--- a/t/t4013/diff.format-patch_--inline_--stdout_--subject-prefix=TESTCASE_initial..master
+++ b/t/t4013/diff.format-patch_--inline_--stdout_--subject-prefix=TESTCASE_initial..master
@@ -19,6 +19,8 @@ This is the second commit.
file2 | 3 ---
3 files changed, 5 insertions(+), 3 deletions(-)
delete mode 100644 file2
+
+
--------------g-i-t--v-e-r-s-i-o-n
Content-Type: text/x-patch; name="1bde4ae5f36c8d9abe3a0fce0c6aab3c4a12fe44.diff"
Content-Transfer-Encoding: 8bit
@@ -75,6 +77,8 @@ Content-Transfer-Encoding: 8bit
file1 | 3 +++
2 files changed, 5 insertions(+), 0 deletions(-)
create mode 100644 file1
+
+
--------------g-i-t--v-e-r-s-i-o-n
Content-Type: text/x-patch; name="9a6d4949b6b76956d9d5e26f2791ec2ceff5fdc0.diff"
Content-Transfer-Encoding: 8bit
@@ -122,6 +126,8 @@ Content-Transfer-Encoding: 8bit
file3 | 4 ++++
3 files changed, 9 insertions(+), 0 deletions(-)
create mode 100644 file3
+
+
--------------g-i-t--v-e-r-s-i-o-n
Content-Type: text/x-patch; name="c7a2ab9e8eac7b117442a607d5a9b3950ae34d5a.diff"
Content-Transfer-Encoding: 8bit
diff --git a/t/t4013/diff.format-patch_--inline_--stdout_initial..master b/t/t4013/diff.format-patch_--inline_--stdout_initial..master
index aa110c0..6d6fac3 100644
--- a/t/t4013/diff.format-patch_--inline_--stdout_initial..master
+++ b/t/t4013/diff.format-patch_--inline_--stdout_initial..master
@@ -19,6 +19,8 @@ This is the second commit.
file2 | 3 ---
3 files changed, 5 insertions(+), 3 deletions(-)
delete mode 100644 file2
+
+
--------------g-i-t--v-e-r-s-i-o-n
Content-Type: text/x-patch; name="1bde4ae5f36c8d9abe3a0fce0c6aab3c4a12fe44.diff"
Content-Transfer-Encoding: 8bit
@@ -75,6 +77,8 @@ Content-Transfer-Encoding: 8bit
file1 | 3 +++
2 files changed, 5 insertions(+), 0 deletions(-)
create mode 100644 file1
+
+
--------------g-i-t--v-e-r-s-i-o-n
Content-Type: text/x-patch; name="9a6d4949b6b76956d9d5e26f2791ec2ceff5fdc0.diff"
Content-Transfer-Encoding: 8bit
@@ -122,6 +126,8 @@ Content-Transfer-Encoding: 8bit
file3 | 4 ++++
3 files changed, 9 insertions(+), 0 deletions(-)
create mode 100644 file3
+
+
--------------g-i-t--v-e-r-s-i-o-n
Content-Type: text/x-patch; name="c7a2ab9e8eac7b117442a607d5a9b3950ae34d5a.diff"
Content-Transfer-Encoding: 8bit
diff --git a/t/t4013/diff.format-patch_--inline_--stdout_initial..master^ b/t/t4013/diff.format-patch_--inline_--stdout_initial..master^
index 95e9ea4..18a1110 100644
--- a/t/t4013/diff.format-patch_--inline_--stdout_initial..master^
+++ b/t/t4013/diff.format-patch_--inline_--stdout_initial..master^
@@ -19,6 +19,8 @@ This is the second commit.
file2 | 3 ---
3 files changed, 5 insertions(+), 3 deletions(-)
delete mode 100644 file2
+
+
--------------g-i-t--v-e-r-s-i-o-n
Content-Type: text/x-patch; name="1bde4ae5f36c8d9abe3a0fce0c6aab3c4a12fe44.diff"
Content-Transfer-Encoding: 8bit
@@ -75,6 +77,8 @@ Content-Transfer-Encoding: 8bit
file1 | 3 +++
2 files changed, 5 insertions(+), 0 deletions(-)
create mode 100644 file1
+
+
--------------g-i-t--v-e-r-s-i-o-n
Content-Type: text/x-patch; name="9a6d4949b6b76956d9d5e26f2791ec2ceff5fdc0.diff"
Content-Transfer-Encoding: 8bit
diff --git a/t/t4013/diff.format-patch_--inline_--stdout_initial..master^^ b/t/t4013/diff.format-patch_--inline_--stdout_initial..master^^
index b8e81e1..4f258b8 100644
--- a/t/t4013/diff.format-patch_--inline_--stdout_initial..master^^
+++ b/t/t4013/diff.format-patch_--inline_--stdout_initial..master^^
@@ -19,6 +19,8 @@ This is the second commit.
file2 | 3 ---
3 files changed, 5 insertions(+), 3 deletions(-)
delete mode 100644 file2
+
+
--------------g-i-t--v-e-r-s-i-o-n
Content-Type: text/x-patch; name="1bde4ae5f36c8d9abe3a0fce0c6aab3c4a12fe44.diff"
Content-Transfer-Encoding: 8bit
diff --git a/t/t4013/diff.format-patch_--inline_--stdout_initial..side b/t/t4013/diff.format-patch_--inline_--stdout_initial..side
index 86ae923..e86dce6 100644
--- a/t/t4013/diff.format-patch_--inline_--stdout_initial..side
+++ b/t/t4013/diff.format-patch_--inline_--stdout_initial..side
@@ -17,6 +17,8 @@ Content-Transfer-Encoding: 8bit
file3 | 4 ++++
3 files changed, 9 insertions(+), 0 deletions(-)
create mode 100644 file3
+
+
--------------g-i-t--v-e-r-s-i-o-n
Content-Type: text/x-patch; name="c7a2ab9e8eac7b117442a607d5a9b3950ae34d5a.diff"
Content-Transfer-Encoding: 8bit
--
1.6.0.rc1.166.gbbfa8
^ permalink raw reply related
* Re: [PATCH] git-gui: Look for gitk in $PATH, not $LIBEXEC/git-core
From: Shawn O. Pearce @ 2008-07-30 5:42 UTC (permalink / raw)
To: Murphy, John; +Cc: Abhijit Menon-Sen, git
In-Reply-To: <20080729164856.GB1730@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> wrote:
> "Murphy, John" <john.murphy@bankofamerica.com> wrote:
> > I have rebuilt git-gui with version 0.10.2.18.gc629 it is still not finding gitk.
> > I have done some debugging in proc _which
> > I have found the issue is with the following line:
> >
> > set p [file join $p $what$_search_exe]
> >
> > The variable $p = gitk.exe
> >
> > And there is no such animal
> >
> > When I copy gitk to gitk.exe in /usr/local/git/bin, it works fine.
>
> This is definately a git-gui bug.
And this should fix it.
--8<--
git-gui: Fix gitk search in $PATH to work on Windows
Back in 15430be5a1 ("Look for gitk in $PATH, not $LIBEXEC/git-core")
git-gui learned to use [_which gitk] to locate where gitk's script
is as Git 1.6 will install gitk to $prefix/bin (in $PATH) and all
of the other tools are in $gitexecdir.
This failed on Windows because _which adds the ".exe" suffix as it
searches for the program on $PATH, under the assumption that we can
only execute something from Tcl if it is a proper Windows executable.
When scanning for gitk on Windows we need to omit the ".exe" suffix.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
git-gui.sh | 12 +++++++++---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/git-gui.sh b/git-gui.sh
index ce941ad..14b2d9a 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -317,7 +317,7 @@ proc _git_cmd {name} {
return $v
}
-proc _which {what} {
+proc _which {what args} {
global env _search_exe _search_path
if {$_search_path eq {}} {
@@ -340,8 +340,14 @@ proc _which {what} {
}
}
+ if {[is_Windows] && [lsearch -exact $args -script] >= 0} {
+ set suffix {}
+ } else {
+ set suffix $_search_exe
+ }
+
foreach p $_search_path {
- set p [file join $p $what$_search_exe]
+ set p [file join $p $what$suffix]
if {[file exists $p]} {
return [file normalize $p]
}
@@ -1686,7 +1692,7 @@ proc do_gitk {revs} {
# -- Always start gitk through whatever we were loaded with. This
# lets us bypass using shell process on Windows systems.
#
- set exe [_which gitk]
+ set exe [_which gitk -script]
set cmd [list [info nameofexecutable] $exe]
if {$exe eq {}} {
error_popup [mc "Couldn't find gitk in PATH"]
--
1.6.0.rc1.166.gbbfa8
--
Shawn.
^ permalink raw reply related
* Re: [PATCH 1/3] git-gui: Adapt discovery of oguilib to execdir 'libexec/git-core'
From: Steffen Prohaska @ 2008-07-30 5:39 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Johannes Sixt
In-Reply-To: <20080730052517.GF7225@spearce.org>
On Jul 30, 2008, at 7:25 AM, Shawn O. Pearce wrote:
> Steffen Prohaska <prohaska@zib.de> wrote:
>> Isn't only the computation of sharedir based on gitexecdir wrong?
>>
>>> ifndef sharedir
>>> sharedir := $(dir $(gitexecdir))share
>>
>> and could be replaced with this (instead of your patch):
>>
>> ifndef sharedir
>> +ifeq (git-core,$(notdir $(gitexecdir)))
>> + sharedir := $(dir $(patsubst %/,%,$(dir $(gitexecdir))))share
>> +else
>> sharedir := $(dir $(gitexecdir))share
>> endif
>> +endif
>
> Oh, damn good catch. Thanks.
>
> How about this then? Its your patch above, my message, and me
> forging your SOB...
looks good. SOB ok.
Thanks,
Steffen
^ permalink raw reply
* Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set
From: Steffen Prohaska @ 2008-07-30 5:35 UTC (permalink / raw)
To: Eyvind Bernhardsen
Cc: Dmitry Potapov, Johannes Schindelin, Avery Pennarun,
Joshua Jensen, Junio C Hamano, git
In-Reply-To: <A8BF9951-AB9D-4391-A6CB-E9778064F4A8@orakel.ntnu.no>
On Jul 29, 2008, at 11:17 PM, Eyvind Bernhardsen wrote:
>>> As you say, the reason I want the setting to be per-repository is
>>> that
>>> I don't think the cost is worthwhile for every repository.
>>
>> Side note: Personally, I am not very concerned about this cost, but
>> some
>> people are...
>
> Yeah :)
>
> I think the real penalty is that with autocrlf enabled, Git no
> longer stores exactly what I committed.
Git does *never* exactly store what you committed. Git compresses
your data and creates packs containing many of your individual
files in a single pack.
What matters is that git gives you exactly back what you committed. It
does so with core.autocrlf=true, unless you check out with a different
setting for autocrlf. There is a small chance that git decides that
a file is text even though it should be binary and that the content of
this file does not allow for reversible CRLF-conversion. In this case
git warns about the irreversible conversion and the user gets a chance
to correct git's choice.
We accept this slight chance of irreversible conversion because we do
want to handle line-endings of text files for cross-platform use. For
this, the goal of "giving you *exactly* back what you committed" is
modified. Instead, we want to give you exactly back what you committed,
except for line-endings (in text files), which should be converted to
the platform-dependent line-endings (LF or CRLF), depending on the
user's
setting.
Because of a design choice we made, CRLF must be converted on Windows.
We decided that the token that git uses *internally* to represent
a line-ending in a text file is LF. We made this choice because git
originally supported only Unix and so we chose the Unix line-ending for
representing line-endings internally. Now, Windows uses CRLF to
indicate line-endings but git internally uses LF, so we must convert
them. Note that if we had users that completely ignored their native
Windows environment and only used well-selected tools, all configured to
*never* write native Windows line-ending, for these users we could set
autocrlf=false and the repository would nonetheless only contain LFs.
Those exceptional super-expert users could manually modify their
settings. The average user (including me) will not be able to guarantee
that he will never create CRLF in text files on Windows. Those users
simply accept that they work on Windows and use the native line-endings
(CRLF) and because we care about these average users we set
autocrlf=true.
In contrast, setting autocrlf=input on Unix is only a safety valve. The
average user who is only working on Unix will most likely *never* create
CRLF line-endings. In a Unix-only environment it is actually very hard
to create CRLF line-endings. Thus, the current default (autocrlf unset)
assumes that all text files on Unix contain only LF, and git wants LF
internally, which means we do not need to convert the line-endings. In
cross-platform environments however, our assumption that all files on
Unix contain only LFs probably no longer holds. In a cross-platform
environment you can easily copy files from Windows to Unix and thus
*easily* create files on Unix that contains CRLF. In this case
autocrlf=input can save you, by correcting the line-endings for you. In
this case, git *does not* give you exactly back what you committed, but
gives you back the very same text you committed however with the native
LF line-endings.
Personally I believe that our assumption that it is virtually impossible
to unintentionally create CRLF line-endings on Unix is wrong; but the
prevailing opinion on the list is different. Personally, I believe that
autocrlf=input should be the default on Unix to shield the repository
from CRLFs. I am using autocrlf=input for some time now and it has
already saved me several times. Note that I am not working in a
Unix-only environment, but in a mixed Unix/Mac/Windows environment, so
unintentionally creating CRLFs is quite easy.
Another valid concern is speed. But the timings that Dmitry presented
indicate that the overhead of autocrlf is so small that it is hard to
measure in practice. I think we should stop raising this concern unless
someone comes up with timings that indicate a larger overhead than
measured by Dmitry.
Steffen
^ permalink raw reply
* Re: [PATCH 1/3] git-gui: Adapt discovery of oguilib to execdir 'libexec/git-core'
From: Shawn O. Pearce @ 2008-07-30 5:25 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git, Johannes Sixt
In-Reply-To: <AF6C526A-57ED-4386-A4CF-5260D82026B7@zib.de>
Steffen Prohaska <prohaska@zib.de> wrote:
> Isn't only the computation of sharedir based on gitexecdir wrong?
>
>> ifndef sharedir
>> sharedir := $(dir $(gitexecdir))share
>
> and could be replaced with this (instead of your patch):
>
> ifndef sharedir
> +ifeq (git-core,$(notdir $(gitexecdir)))
> + sharedir := $(dir $(patsubst %/,%,$(dir $(gitexecdir))))share
> +else
> sharedir := $(dir $(gitexecdir))share
> endif
> +endif
Oh, damn good catch. Thanks.
How about this then? Its your patch above, my message, and me
forging your SOB...
--8<--
From: Steffen Prohaska <prohaska@zib.de>
Subject: git-gui: Correct installation of library to be $prefix/share
We always wanted the library for git-gui to install into the
$prefix/share directory, not $prefix/libexec/share. All of
the files in our library are platform independent and may
be reused across systems, like any other content stored in
the share directory.
Our computation of where our library should install to was broken
when git itself started installing to $prefix/libexec/git-core,
which was one level down from where we expected it to be.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
Makefile | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index b19fb2d..c9d67fe 100644
--- a/Makefile
+++ b/Makefile
@@ -34,8 +34,12 @@ ifndef gitexecdir
endif
ifndef sharedir
+ifeq (git-core,$(notdir $(gitexecdir)))
+ sharedir := $(dir $(patsubst %/,%,$(dir $(gitexecdir))))share
+else
sharedir := $(dir $(gitexecdir))share
endif
+endif
ifndef INSTALL
INSTALL = install
--
1.6.0.rc1.166.gbbfa8
--
Shawn.
^ permalink raw reply related
* Re: [PATCH] format-patch: Produce better output with --inline or --attach
From: Jeff King @ 2008-07-30 5:24 UTC (permalink / raw)
To: Kevin Ballard; +Cc: git, Junio C Hamano
In-Reply-To: <1217375356-80287-1-git-send-email-kevin@sb.org>
On Tue, Jul 29, 2008 at 04:49:16PM -0700, Kevin Ballard wrote:
> The first is to write a newline preceding the boundary. This is needed
> because MIME defines the encapsulation boundary as including the
> preceding CRLF (or in this case, just LF), so we should be writing
> one. Without this, the last newline in the pre-diff content is
> consumed instead.
Hmm. I am surprised we haven't had more bug reports about this, but
perhaps these features aren't used too frequently. But I double checked
the MIME specs just to be sure, and you are definitely right.
> The second change is to always write the line termination character (default: newline)
Can you please wrap your commit messages at some more reasonable length?
This line is 86 characters long.
-Peff
^ permalink raw reply
* Re: What is 'git BRANCH'?
From: Jeff King @ 2008-07-30 5:14 UTC (permalink / raw)
To: sverre; +Cc: Junio C Hamano, Jurko Gospodnetić, git
In-Reply-To: <bd6139dc0807291549y66c56fbah928a854f37573680@mail.gmail.com>
On Wed, Jul 30, 2008 at 12:49:00AM +0200, Sverre Rabbelier wrote:
> Why does handle_internal_command not complain after the " for (i = 0;
> i < ARRAY_SIZE(commands); i++) {" that no matching commands were
> found? Is that not an implicit assertion that would do well with being
> asserted here?
Because it is called from two places. In one, we _know_ that this must
be internal, so we die right after. In the other, we try internal, then
external, then alias. So we don't want to die. Grep for
handle_internal_cmmand in git.c.
-Peff
^ permalink raw reply
* Re: [PATCH v2] Advertise the ability to abort a commit
From: Jeff King @ 2008-07-30 5:11 UTC (permalink / raw)
To: Anders Melchiorsen; +Cc: Junio C Hamano, git
In-Reply-To: <20080730050715.GA4034@sigill.intra.peff.net>
On Wed, Jul 30, 2008 at 01:07:15AM -0400, Jeff King wrote:
> > - die("no commit message? aborting commit.");
> > + die("no commit message. aborting commit.");
>
> I don't think the change of punctuation makes a big difference here,
> but this could probably stand to be reworded. Maybe:
>
> Aborting commit due to empty commit message.
Using "die" also prepends "fatal: " which is perhaps a bit much for an
expected feature. So maybe:
fprintf(stderr, "Aborting commit due to empty commit message.\n");
exit(1); /* or even some specific "intentional abort" exit code */
-Peff
^ permalink raw reply
* Re: [PATCH v2] Advertise the ability to abort a commit
From: Jeff King @ 2008-07-30 5:07 UTC (permalink / raw)
To: Anders Melchiorsen; +Cc: Junio C Hamano, git
In-Reply-To: <1217362342-30370-1-git-send-email-mail@cup.kalibalik.dk>
On Tue, Jul 29, 2008 at 10:12:22PM +0200, Anders Melchiorsen wrote:
> "# Please enter the commit message for your changes.\n"
> + "# To abort the commit, use an empty commit message.\n"
> "# (Comment lines starting with '#' will ");
I think this is a good thing to mention, but this text has been getting
longer lately. Maybe we can compact it like this:
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
?
> - die("no commit message? aborting commit.");
> + die("no commit message. aborting commit.");
I don't think the change of punctuation makes a big difference here,
but this could probably stand to be reworded. Maybe:
Aborting commit due to empty commit message.
-Peff
^ permalink raw reply
* [RFC/PATCH v4 2/2] documentation: merge-base: explain "git merge-base" with more than 2 args
From: Christian Couder @ 2008-07-30 5:04 UTC (permalink / raw)
To: git, Junio C Hamano, Johannes Schindelin; +Cc: Miklos Vajna, Jakub Narebski
From: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Documentation/git-merge-base.txt | 77 ++++++++++++++++++++++++++++++++-----
1 files changed, 66 insertions(+), 11 deletions(-)
diff --git a/Documentation/git-merge-base.txt b/Documentation/git-merge-base.txt
index 1a7ecbf..fd4b5c9 100644
--- a/Documentation/git-merge-base.txt
+++ b/Documentation/git-merge-base.txt
@@ -8,26 +8,81 @@ git-merge-base - Find as good common ancestors as possible for a merge
SYNOPSIS
--------
-'git merge-base' [--all] <commit> <commit>
+'git merge-base' [--all] <commit> <commit>...
DESCRIPTION
-----------
-'git-merge-base' finds as good a common ancestor as possible between
-the two commits. That is, given two commits A and B, `git merge-base A
-B` will output a commit which is reachable from both A and B through
-the parent relationship.
+'git-merge-base' finds best common ancestor(s) between two commits to use
+in a three-way merge. One common ancestor is 'better' than another common
+ancestor if the latter is an ancestor of the former. A common ancestor
+that does not have any better common ancestor than it is a 'best common
+ancestor', i.e. a 'merge base'. Note that there can be more than one
+merge bases between two commits.
-Given a selection of equally good common ancestors it should not be
-relied on to decide in any particular way.
-
-The 'git-merge-base' algorithm is still in flux - use the source...
+Among the two commits to compute their merge bases, one is specified by
+the first commit argument on the command line; the other commit is a
+(possibly hypothetical) commit that is a merge across all the remaining
+commits on the command line. As the most common special case, giving only
+two commits from the command line means computing the merge base between
+the given two commits.
OPTIONS
-------
--all::
- Output all common ancestors for the two commits instead of
- just one.
+ Output all merge bases for the commits, instead of just one.
+
+DISCUSSION
+----------
+
+Given two commits 'A' and 'B', `git merge-base A B` will output a commit
+which is reachable from both 'A' and 'B' through the parent relationship.
+
+For example, with this topology:
+
+ o---o---o---B
+ /
+ ---o---1---o---o---o---A
+
+the merge base between 'A' and 'B' is '1'.
+
+Given three commits 'A', 'B' and 'C', `git merge-base A B C` will compute the
+merge base between 'A' and an hypothetical commit 'M', which is a merge
+between 'B' and 'C'. For example, with this topology:
+
+ o---o---o---o---C
+ /
+ / o---o---o---B
+ / /
+ ---2---1---o---o---o---A
+
+the result of `git merge-base A B C` is '1'. This is because the
+equivalent topology with a merge commit 'M' between 'B' and 'C' is:
+
+
+ o---o---o---o---o
+ / \
+ / o---o---o---o---M
+ / /
+ ---2---1---o---o---o---A
+
+and the result of `git merge-base A M` is '1'. Commit '2' is also a
+common ancestor between 'A' and 'M', but '1' is a better common ancestor,
+because '2' is an ancestor of '1'. Hence, '2' is not a merge base.
+
+When the history involves criss-cross merges, there can be more than one
+'best' common ancestors between two commits. For example, with this
+topology:
+
+ ---1---o---A
+ \ /
+ X
+ / \
+ ---2---o---o---B
+
+both '1' and '2' are merge-base of A and B. Neither one is better than
+the other (both are 'best' merge base). When `--all` option is not given,
+it is unspecified which best one is output.
Author
------
--
1.6.0.rc0.42.g186458.dirty
^ permalink raw reply related
* [RFC/PATCH v4 1/2] merge-base: teach "git merge-base" to accept more than 2 arguments
From: Christian Couder @ 2008-07-30 5:04 UTC (permalink / raw)
To: git, Junio C Hamano, Johannes Schindelin; +Cc: Miklos Vajna, Jakub Narebski
Before this patch "git merge-base" accepted only 2 arguments, so
only merge bases between 2 references could be computed.
The purpose of this patch is to make "git merge-base" accept more
than 2 arguments, so that the merge bases between the first given
reference and all the other references can be computed.
This is easily implemented because the "get_merge_bases_many"
function in "commit.c" already implements the needed computation.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
builtin-merge-base.c | 24 ++++++++++++++++--------
1 files changed, 16 insertions(+), 8 deletions(-)
Changes since previous version are:
- the patch is simpler because it now goes on top of
a fix that added the "get_commit_reference" function,
- documentation has been removed from the first patch
and Junio's documentation has been added in a new 2/2
patch.
There are still no tests. I need to find time to work
on them before friday otherwise it will probably have
to wait until I come back from vacation.
diff --git a/builtin-merge-base.c b/builtin-merge-base.c
index 3382b13..b08da51 100644
--- a/builtin-merge-base.c
+++ b/builtin-merge-base.c
@@ -2,9 +2,11 @@
#include "cache.h"
#include "commit.h"
-static int show_merge_base(struct commit *rev1, struct commit *rev2, int show_all)
+static int show_merge_base(struct commit **rev, int rev_nr, int show_all)
{
- struct commit_list *result = get_merge_bases(rev1, rev2, 0);
+ struct commit_list *result;
+
+ result = get_merge_bases_many(rev[0], rev_nr - 1, rev + 1, 0);
if (!result)
return 1;
@@ -20,7 +22,7 @@ static int show_merge_base(struct commit *rev1, struct commit *rev2, int show_al
}
static const char merge_base_usage[] =
-"git merge-base [--all] <commit-id> <commit-id>";
+"git merge-base [--all] <commit-id> <commit-id>...";
static struct commit *get_commit_reference(const char *arg)
{
@@ -38,7 +40,8 @@ static struct commit *get_commit_reference(const char *arg)
int cmd_merge_base(int argc, const char **argv, const char *prefix)
{
- struct commit *rev1, *rev2;
+ struct commit **rev;
+ int rev_nr = 0;
int show_all = 0;
git_config(git_default_config, NULL);
@@ -51,10 +54,15 @@ int cmd_merge_base(int argc, const char **argv, const char *prefix)
usage(merge_base_usage);
argc--; argv++;
}
- if (argc != 3)
+ if (argc < 3)
usage(merge_base_usage);
- rev1 = get_commit_reference(argv[1]);
- rev2 = get_commit_reference(argv[2]);
- return show_merge_base(rev1, rev2, show_all);
+ rev = xmalloc((argc - 1) * sizeof(*rev));
+
+ do {
+ rev[rev_nr++] = get_commit_reference(argv[1]);
+ argc--; argv++;
+ } while (argc > 1);
+
+ return show_merge_base(rev, rev_nr, show_all);
}
--
1.6.0.rc0.42.g186458.dirty
^ permalink raw reply related
* Re: Bizarre missing changes (git bug?)
From: Linus Torvalds @ 2008-07-30 4:52 UTC (permalink / raw)
To: Jeff King; +Cc: Roman Zippel, Tim Harper, git
In-Reply-To: <20080730042609.GB3350@sigill.intra.peff.net>
On Wed, 30 Jul 2008, Jeff King wrote:
>
> I agree with you, btw. It is definitely correct and useful; however, I
> am curious if there is some "in between" level of simplification that
> might produce an alternate graph that has interesting features. And that
> is why I am trying to get Roman to lay out exactly what it is he wants.
Actually, I know what he wants, since I tried to describe it for the
filter-branch discussion. It's really not that conceptually complex.
Basically, the stupid model is to just do this:
- start with --full-history
- for each merge, look at both parents. If one parent leads directly to
a commit that can be reached from the the other, just remove that
parent as being redundant. And if that removal leads to a merge now
becoming a non-merge, and it has no changes wrt its single remaining
parent, remove the commit entirely (rewriting any parenthood to make
the rest all stay together, of course)
- repeat until you cannot do any more simplification (removing one commit
can actually cause its children to now become targets for this
simplification).
and I suspect that
(a) the stupid model is probably at least O(n^3) if done stupidly and
O(n^2) with some modest amount of smarts (keeping a list of at least
potential targets of simplification and expanding it only when
actually simplifying), but that
(b) you can concentrate on just the merges that the current optimizing
algorithm would have removed, so 'n' is not the total number of
commits, but at most the number of merges, and more likely actually
just the number of trivial merges in that file, and finally
(c) there is likely some smart and efficient graph minimization algorithm
that is O(nlogn) or something.
so I don't think it's likely to be hugely more expensive than the
topo-sort is. All the real expense is in the same thing the topo-sort
expense, namely in generating the list up-front.
I bet googling for "minimal directed acyclic graph" will give pointers.
And despite the fact that I've argued against Roman's world-view, I
actually _do_ think it would be nice to have that third mode, the same way
that we have --topo-order. It wouldn't be good for the _default_ view, but
then neither is --full-history, so that's not a big argument.
That said, I'd like to (again) repeat the caveat that it's probably best
done in the tool that actally visualizes the mess - exactly for the same
reason that I argued for the topological sort being done in gitk. It's
very painful to have to wait for the first few commits to start appearing
in the history window.
Admittedly most of my work is actually done on machines that are pretty
fast, but every once in a while I travel with a laptop. And more
importantly, not everybody gets new hardware from Intel for testing even
before the CPU has been released. So others will still appreciate
incremental history updates, even if my machine might be fast enough (and
my kernel tree always in the caches) that I myself could live with a
synchronous version a-la --topo-order.
Linus
^ 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