Unapplied patches reminder

Unapplied patches reminder

[Nanako Shiraishi]

Junio, I saw these patches and thought what they try to do were 
sensible, but I don't them in your tree. I didn't see much discussion 
on most of them, either.

Because I don't read C very well, I may have listed some patches 
here that you may have discarded because the code was no good, and 
if so I apologize for wasting your time, but I thought at least 
some of them should be salvaged.

Here is the list.

From: Geoffrey Thomas <geofft@mit.edu>
Subject: [PATCH] diffcore-order: Default the order file to .git/info/order.
Date: Sat, 12 Sep 2009 19:49:48 -0400
Message-ID: <1252799388-16295-1-git-send-email-geofft@mit.edu>

    Since order files tend to be useful for all operations in the
    project/repository, add a default location for the order file, so that
    you don't have to specify -O<orderfile> on every diff or similar
    operation.

From:	Heiko Voigt <hvoigt@hvoigt.net>
Subject: [PATCH] fix testsuite to not use any hooks possibly provided by source
Date:	Wed, 23 Sep 2009 20:30:28 +0200
Message-ID: <20090923183023.GA85456@book.hvoigt.net>

    This is useful if you are using the testsuite with local changes that
    include activated default hooks suitable for your teams installation.

From:	Jeff King <peff@peff.net>
Subject: Re: [BUG?] git-cvsimport: path to cvspsfile
Date:	Wed, 23 Sep 2009 15:14:29 -0400
Message-ID: <20090923191428.GA30104@coredump.intra.peff.net>

    Bug. The script does a chdir() and then looks at the cvspsfile later. I
    think "-A" would have the same problem. Here is a totally untested patch
    to address the issue. Johannes, will this is_absolute_path actually work
    on Windows? I think The Right Way would be to use
    File::Spec::file_name_is_absolute, but I haven't checked whether that is
    part of core perl and if so, which version it appeared in.

From: "Rolf Bjarne Kvinge" <RKvinge@novell.com>
Subject: git rev-list --pretty=raw strips empty lines
Date: Tue, 06 Oct 2009 14:33:37 +0200
Message-ID: <op.u1do6bq5k71drc@linux.lacasa>

    It seems like the --pretty=raw format strips off empty newlines from the beginning of log messages, while I'd expect the raw format to not do any transformations (just as the documentation says: "The 'raw' format shows the entire commit exactly as stored in the commit object").

    The below changes works for me, not sure if I'm right about this though (my first time here ;-)

From:	"Carlos R. Mafra" <crmafra@aei.mpg.de>
Subject: [PATCH] Makefile: clean block-sha1/ directory instead of mozilla-sha1/
Date:	Sun, 11 Oct 2009 15:32:19 +0200

    'make clean' should remove the object files from block-sha1/
    instead of the non-existent mozilla-sha1/ directory.

From: Per Strandh <Per.Strandh@q-matic.se>
Subject: [PATCH] git-p4: Fixed bug that didn't allow spaces in the depot
Date: Tue, 13 Oct 2009 22:09:12 +0200
Message-ID: <65D9329CA2AF94438F542D48F2A42E830F95F51514@GOT-SRV-005.QMATIC.local>

    git-p4 clone (and sync) did not work if the specified depot path contained spaces.
    Fixed by quoting the argument to the "p4 changes" and "p4 files" commands.

From: "Tom G. Christensen" <tgc@statsbiblioteket.dk>
Subject: [PATCH] NO_PERL_MAKEMAKER should behave more like ExtUtils::MakeMaker
Date: Tue, 13 Oct 2009 13:14:31 +0200
Message-ID: <1255432471-14168-1-git-send-email-tgc@statsbiblioteket.dk>

    This change makes NO_PERL_MAKEMAKER behave more as ExtUtils::MakeMaker
    by installing the modules into the perl libdir and not $(prefix)/lib.
    It will default to sitelib but will allow the user to choose by setting
    the INSTALLDIRS variable which is also honored by ExtUtils::MakeMaker.

From:	Björn Gustavsson <bgustavsson@gmail.com>
Subject: [PATCH] push: fix usage: --tags is incompatible with --all and --mirror
Date:	Thu, 15 Oct 2009 18:39:05 +0200
Message-ID: <4AD75029.1010109@gmail.com>

    Correct the usage text to make it clear that --tags cannot
    be combined with --all or --mirror.

From: Vietor Liu <vietor@vxwo.org>
Subject: [PATCH v4] git-gui: adjust the minimum height of diff pane for
Date: Fri, 16 Oct 2009 17:41:26 +0800
Message-Id: <1255686086-3949-1-git-send-email-vietor@vxwo.org>

    When the main window is maximized, if the screen height is shorter (e.g.
    Netbook screen 1024x600), both the partial commit pane and the status bar
    are hidden.

From: Junio C Hamano <gitster@pobox.com>
Subject: Re: Q: supplying large sets of path to git commands
Date: Fri, 16 Oct 2009 15:08:07 -0700
Message-ID: <7vtyxzrnzs.fsf@alter.siamese.dyndns.org>

    Here is how one might implement it for diff/log family of commands that
    use "setup_revisions()".

    I didn't test it (of course) beyond running 

	./git diff --name-only HEAD | ./git diff --stdin-paths --stat -p

From:	Björn Gustavsson <bgustavsson@gmail.com>
Subject: [PATCH] bash: complete more options for 'git rebase'
Date:	Sat, 17 Oct 2009 11:33:38 +0200
Message-ID: <4AD98F72.1060901@gmail.com>

    Complete all long options for 'git rebase' except --no-verify
    (probably used very seldom) and the long options corresponding
    to -v, -q, and -f.

From: René Scharfe <rene.scharfe@lsrfire.ath.cx>
Subject: [PATCH] describe: load refnames before calling describe()
Date: Sat, 17 Oct 2009 18:30:48 +0200
Message-ID: <4AD9F138.3080405@lsrfire.ath.cx>

    Get rid of the static variable that was used to prevent loading all
    the refnames multiple times by moving that code out of describe(),
    simply making sure it is only run once that way.

-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/

Re: Unapplied patches reminder

[Junio C Hamano]

Nanako Shiraishi <nanako3@lavabit.com> writes:

> Junio, I saw these patches and thought what they try to do were 
> sensible, but I don't them in your tree. I didn't see much discussion 
> on most of them, either.
>
> Because I don't read C very well, I may have listed some patches 
> here that you may have discarded because the code was no good, and 
> if so I apologize for wasting your time, but I thought at least 
> some of them should be salvaged.

Thanks; very appreciated, and I wish there were more like you to help us
keep track things.

Will comment on individual patches separately.

Re: Unapplied patches reminder

[Junio C Hamano]

Nanako Shiraishi <nanako3@lavabit.com> writes:

> Junio, I saw these patches and thought what they try to do were 
> sensible, but I don't them in your tree. I didn't see much discussion 
> on most of them, either.
>
> Because I don't read C very well, I may have listed some patches 
> here that you may have discarded because the code was no good, and 
> if so I apologize for wasting your time, but I thought at least 
> some of them should be salvaged.
> ...
> From:	Heiko Voigt <hvoigt@hvoigt.net>
> Subject: [PATCH] fix testsuite to not use any hooks possibly provided by source
> Date:	Wed, 23 Sep 2009 20:30:28 +0200
> Message-ID: <20090923183023.GA85456@book.hvoigt.net>
>
>     This is useful if you are using the testsuite with local changes that
>     include activated default hooks suitable for your teams installation.

This may be useful when Heiko or somebody actually has changes that needs
this fix, but otherwise was an unnecessary code churn during pre-release 
code freeze.  I am reasonably sure that Heiko will include it in a series
that requires this one.

In other words, I am not against it per-se, but I would prefer to see
patches that actually depends on this change at the same time.  Otherwise
this "is supposed to be no-op, and promises it will help in the future",
and needs extra mental effort to validate the latter claim.

Re: Re: Unapplied patches reminder

[Heiko Voigt]

On Sun, Oct 18, 2009 at 04:31:49PM -0700, Junio C Hamano wrote:
> Nanako Shiraishi <nanako3@lavabit.com> writes:
> > ...
> > From:	Heiko Voigt <hvoigt@hvoigt.net>
> > Subject: [PATCH] fix testsuite to not use any hooks possibly provided by source
> > Date:	Wed, 23 Sep 2009 20:30:28 +0200
> > Message-ID: <20090923183023.GA85456@book.hvoigt.net>
> >
> >     This is useful if you are using the testsuite with local changes that
> >     include activated default hooks suitable for your teams installation.
> 
> This may be useful when Heiko or somebody actually has changes that needs
> this fix, but otherwise was an unnecessary code churn during pre-release 
> code freeze.  I am reasonably sure that Heiko will include it in a series
> that requires this one.
> 
> In other words, I am not against it per-se, but I would prefer to see
> patches that actually depends on this change at the same time.  Otherwise
> this "is supposed to be no-op, and promises it will help in the future",
> and needs extra mental effort to validate the latter claim.

Well, currently we do not have any activated hooks. They are all sample.
And because the use scenarios for git are so diverse we will probably
never have any default hook activated.
But I imagine that if you are creating a default installation for any
team you will activate some. For an example take this patch:

http://thread.gmane.org/gmane.comp.version-control.git/110874

it is not in master because it was to specific but I have such a hook
activated. It does not allow you to commit on master which breaks the
testsuite.

So in my opinion we should not run the testsuite with hooks even though
the current defaults are all deactivated.

I am afraid that I will never be able to persuade everyone on the list
to not commit on master... ;)

cheers Heiko

P.S.: Just thinking of previous hooks, I might make it an option like
      hooks.doNotCommitOnMaster. But still the hooks would be
      deactivated.

Re: Unapplied patches reminder

[Junio C Hamano]

Nanako Shiraishi <nanako3@lavabit.com> writes:

> Junio, I saw these patches and thought what they try to do were 
> sensible, but I don't them in your tree. I didn't see much discussion 
> on most of them, either.
>
> Because I don't read C very well, I may have listed some patches 
> here that you may have discarded because the code was no good, and 
> if so I apologize for wasting your time, but I thought at least 
> some of them should be salvaged.
> ...
> From:	Jeff King <peff@peff.net>
> Subject: Re: [BUG?] git-cvsimport: path to cvspsfile
> Date:	Wed, 23 Sep 2009 15:14:29 -0400
> Message-ID: <20090923191428.GA30104@coredump.intra.peff.net>
>
>     Bug. The script does a chdir() and then looks at the cvspsfile later. I
>     think "-A" would have the same problem. Here is a totally untested patch
>     to address the issue. Johannes, will this is_absolute_path actually work
>     on Windows? I think The Right Way would be to use
>     File::Spec::file_name_is_absolute, but I haven't checked whether that is
>     part of core perl and if so, which version it appeared in.

My understanding of this is that it is a typical "how about this" that is
still waiting for a follow-up discussion that will result in an eventual
solution.

> From: Junio C Hamano <gitster@pobox.com>
> Subject: Re: Q: supplying large sets of path to git commands
> Date: Fri, 16 Oct 2009 15:08:07 -0700
> Message-ID: <7vtyxzrnzs.fsf@alter.siamese.dyndns.org>
>
>     Here is how one might implement it for diff/log family of commands that
>     use "setup_revisions()".
>
>     I didn't test it (of course) beyond running 
>
> 	./git diff --name-only HEAD | ./git diff --stdin-paths --stat -p

Ditto.

Re: Unapplied patches reminder

[Jeff King]

On Sun, Oct 18, 2009 at 04:31:54PM -0700, Junio C Hamano wrote:

> > From:	Jeff King <peff@peff.net>
> > Subject: Re: [BUG?] git-cvsimport: path to cvspsfile
> > Date:	Wed, 23 Sep 2009 15:14:29 -0400
> > Message-ID: <20090923191428.GA30104@coredump.intra.peff.net>
> >
> >     Bug. The script does a chdir() and then looks at the cvspsfile later. I
> >     think "-A" would have the same problem. Here is a totally untested patch
> >     to address the issue. Johannes, will this is_absolute_path actually work
> >     on Windows? I think The Right Way would be to use
> >     File::Spec::file_name_is_absolute, but I haven't checked whether that is
> >     part of core perl and if so, which version it appeared in.
> 
> My understanding of this is that it is a typical "how about this" that is
> still waiting for a follow-up discussion that will result in an eventual
> solution.

Yep. I got comments from JSixt, but I never got around to re-rolling.
Here it is, though still only lightly tested by me (happily, I have not
had to touch CVS for a few years).

-- >8 --
Subject: [PATCH] cvsimport: fix relative argument filenames

One of the first things that cvsimport does is chdir to the
newly created git repo. This means that any filenames given
to us on the command line will be looked up relative to the
git repo directory. This is probably not what the user
expects, so let's remember and prepend the original
directory for relative filenames.

Signed-off-by: Jeff King <peff@peff.net>
---
 git-cvsimport.perl |   17 ++++++++++++++---
 1 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index 1ad20ac..a7d215c 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -579,10 +579,21 @@ sub get_headref ($) {
 	return $r;
 }
 
+my $user_filename_prepend = '';
+sub munge_user_filename {
+	my $name = shift;
+	return File::Spec->file_name_is_absolute($name) ?
+		$name :
+		$user_filename_prepend . $name;
+}
+
 -d $git_tree
 	or mkdir($git_tree,0777)
 	or die "Could not create $git_tree: $!";
-chdir($git_tree);
+if ($git_tree ne '.') {
+	$user_filename_prepend = getwd() . '/';
+	chdir($git_tree);
+}
 
 my $last_branch = "";
 my $orig_branch = "";
@@ -644,7 +655,7 @@ unless (-d $git_dir) {
 -f "$git_dir/cvs-authors" and
   read_author_info("$git_dir/cvs-authors");
 if ($opt_A) {
-	read_author_info($opt_A);
+	read_author_info(munge_user_filename($opt_A));
 	write_author_info("$git_dir/cvs-authors");
 }
 
@@ -679,7 +690,7 @@ unless ($opt_P) {
 	$? == 0 or die "git-cvsimport: fatal: cvsps reported error\n";
 	close $cvspsfh;
 } else {
-	$cvspsfile = $opt_P;
+	$cvspsfile = munge_user_filename($opt_P);
 }
 
 open(CVS, "<$cvspsfile") or die $!;
-- 
1.6.5.1.121.g1a4d5

Re: Unapplied patches reminder

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> Yep. I got comments from JSixt, but I never got around to re-rolling.
> Here it is, though still only lightly tested by me (happily, I have not
> had to touch CVS for a few years).
>
> -- >8 --
> Subject: [PATCH] cvsimport: fix relative argument filenames

Thanks, applied.

Re: Unapplied patches reminder

[Junio C Hamano]

Nanako Shiraishi <nanako3@lavabit.com> writes:

> Junio, I saw these patches and thought what they try to do were 
> sensible, but I don't them in your tree. I didn't see much discussion 
> on most of them, either.
>
> Because I don't read C very well, I may have listed some patches 
> here that you may have discarded because the code was no good, and 
> if so I apologize for wasting your time, but I thought at least 
> some of them should be salvaged.
> ...
> From: "Rolf Bjarne Kvinge" <RKvinge@novell.com>
> Subject: git rev-list --pretty=raw strips empty lines
> Date: Tue, 06 Oct 2009 14:33:37 +0200
> Message-ID: <op.u1do6bq5k71drc@linux.lacasa>
>
>     It seems like the --pretty=raw format strips off empty newlines from
>     the beginning of log messages, while I'd expect the raw format to
>     not do any transformations (just as the documentation says: "The
>     'raw' format shows the entire commit exactly as stored in the commit
>     object").
>
>     The below changes works for me, not sure if I'm right about this
>     though (my first time here ;-)

I do not recall seeing this one; most likely it was lost in the noise,
especially because it did not look like a patch submission, without having
anything resembling a commit log message.

I think the change itself is an uncontroversial one, even though this
really changes the behaviour.

> From: Per Strandh <Per.Strandh@q-matic.se>
> Subject: [PATCH] git-p4: Fixed bug that didn't allow spaces in the depot
> Date: Tue, 13 Oct 2009 22:09:12 +0200
> Message-ID: <65D9329CA2AF94438F542D48F2A42E830F95F51514@GOT-SRV-005.QMATIC.local>
>
>     git-p4 clone (and sync) did not work if the specified depot path contained spaces.
>     Fixed by quoting the argument to the "p4 changes" and "p4 files" commands.

I do recall ignoring this one because (1) I never use git-p4 myself and
always rely on Acks from people who have been involved in it, and (2) the
message was mangled (perhaps it had two or three copies of patches as
attachments).

Re: Unapplied patches reminder

[Rolf Bjarne Kvinge]

[-- Attachment #1: Type: text/plain, Size: 2266 bytes --]

On Mon, 19 Oct 2009 01:31:59 +0200, Junio C Hamano <gitster@pobox.com> wrote:

> Nanako Shiraishi <nanako3@lavabit.com> writes:
>
>> Junio, I saw these patches and thought what they try to do were
>> sensible, but I don't them in your tree. I didn't see much discussion
>> on most of them, either.
>>
>> Because I don't read C very well, I may have listed some patches
>> here that you may have discarded because the code was no good, and
>> if so I apologize for wasting your time, but I thought at least
>> some of them should be salvaged.
>> ...
>> From: "Rolf Bjarne Kvinge" <RKvinge@novell.com>
>> Subject: git rev-list --pretty=raw strips empty lines
>> Date: Tue, 06 Oct 2009 14:33:37 +0200
>> Message-ID: <op.u1do6bq5k71drc@linux.lacasa>
>>
>>     It seems like the --pretty=raw format strips off empty newlines from
>>     the beginning of log messages, while I'd expect the raw format to
>>     not do any transformations (just as the documentation says: "The
>>     'raw' format shows the entire commit exactly as stored in the commit
>>     object").
>>
>>     The below changes works for me, not sure if I'm right about this
>>     though (my first time here ;-)
>
> I do not recall seeing this one; most likely it was lost in the noise,
> especially because it did not look like a patch submission, without having
> anything resembling a commit log message.
>
> I think the change itself is an uncontroversial one, even though this
> really changes the behaviour.

My specific need is to be able to get out the exact same log message as I committed, another way of getting the same result would be to implement --pretty=xml (along the lines of subversions 'svn log --xml'). This would prevent behavioural changes. And yes, I'm willing to implement it if you agree it's a good idea.

Regarding the previous patch I just found that it's not complete - git would still print lines with only whitespace as empty lines (i.e. stripping off the whitespace). I'm attaching a revised patch that fixes this issue, but since I found the resulting code slightly ugly, I also found an easier approach: in pretty_print_commit (pretty.c) just print the commit message buffer and return.

Rolf

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

[-- Attachment #2: 0001-pretty.c-Don-t-do-any-transformations-when-using-the.patch --]
[-- Type: application/octet-stream, Size: 0 bytes --]



[-- Attachment #3: 0001-pretty.c-special-case-raw-format.patch --]
[-- Type: application/octet-stream, Size: 874 bytes --]

From 4fa9e4c1c133fbe3423c979efd5722dd7bd5d530 Mon Sep 17 00:00:00 2001
From: Rolf Bjarne Kvinge <RKvinge@novell.com>
Date: Mon, 19 Oct 2009 13:31:17 +0200
Subject: [PATCH] pretty.c: Don't do any transformations when using the 'raw' format.

When formatting commits with the 'raw' format, print the commit exactly as
stored.

Signed-off-by: Rolf Bjarne Kvinge <RKvinge@novell.com>
---
 pretty.c |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/pretty.c b/pretty.c
index f5983f8..96dac9a 100644
--- a/pretty.c
+++ b/pretty.c
@@ -915,6 +915,11 @@ void pretty_print_commit(enum cmit_fmt fmt, const struct commit *commit,
 		return;
 	}
 
+	if (fmt == CMIT_FMT_RAW) {
+		strbuf_add(sb, msg, strlen (msg));
+		return;
+	}
+
 	reencoded = reencode_commit_message(commit, &encoding);
 	if (reencoded) {
 		msg = reencoded;
-- 
1.6.5.rc2.17.gdbc1b.dirty

Re: Unapplied patches reminder

[Per Strandh]

"Junio C Hamano" <gitster@pobox.com> skrev i meddelandet 
news:7vzl7ogtxs.fsf@alter.siamese.dyndns.org...
>> From: Per Strandh <Per.Strandh@q-matic.se>
>> Subject: [PATCH] git-p4: Fixed bug that didn't allow spaces in the depot
>> Date: Tue, 13 Oct 2009 22:09:12 +0200
>> Message-ID: 
>> <65D9329CA2AF94438F542D48F2A42E830F95F51514@GOT-SRV-005.QMATIC.local>
>>
>>     git-p4 clone (and sync) did not work if the specified depot path 
>> contained spaces.
>>     Fixed by quoting the argument to the "p4 changes" and "p4 files" 
>> commands.
>
> I do recall ignoring this one because (1) I never use git-p4 myself and
> always rely on Acks from people who have been involved in it, and (2) the
> message was mangled (perhaps it had two or three copies of patches as
> attachments).


Sorry for posting a mangled patch.
Please let someone involved in the git-p4 code review/approve/apply the 
patch.

Regards
/Per/



>From c70682a9c4051f2dc92e2dd92f1710c755df6cfe Mon Sep 17 00:00:00 2001
From: Per Strandh <per.strandh@q-matic.se>
Date: Fri, 9 Oct 2009 12:11:14 +0200
Subject: [PATCH] git-p4: Fixed bug that didn't allow spaces in the depot 
path

git-p4 clone (and sync) did not work if the specified depot path contained 
spaces.
Fixed by quoting the argument to the "p4 changes" and "p4 files" commands.

Signed-off-by: Per Strandh <per.strandh@q-matic.se>
---
 contrib/fast-import/git-p4 |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index e710219..01b6bbb 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -440,8 +440,8 @@ def originP4BranchesExist():

 def p4ChangesForPaths(depotPaths, changeRange):
     assert depotPaths
-    output = p4_read_pipe_lines("changes " + ' '.join (["%s...%s" % (p, 
changeRange)
-                                                        for p in 
depotPaths]))
+    output = p4_read_pipe_lines("changes \"" + ' '.join (["%s...%s" % (p, 
changeRange)
+                                                        for p in 
depotPaths]) + "\"" )

     changes = {}
     for line in output:
@@ -1437,10 +1437,10 @@ class P4Sync(Command):
         newestRevision = 0

         fileCnt = 0
-        for info in p4CmdList("files "
+        for info in p4CmdList("files \""
                               +  ' '.join(["%s...%s"
                                            % (p, revision)
-                                           for p in self.depotPaths])):
+                                           for p in self.depotPaths]) + 
"\""):

             if info['code'] == 'error':
                 sys.stderr.write("p4 returned an error: %s\n"
-- 
1.6.3.msysgit.0

 

Re: Unapplied patches reminder

[Junio C Hamano]

Nanako Shiraishi <nanako3@lavabit.com> writes:

> Junio, I saw these patches and thought what they try to do were 
> sensible, but I don't them in your tree. I didn't see much discussion 
> on most of them, either.
>
> Because I don't read C very well, I may have listed some patches 
> here that you may have discarded because the code was no good, and 
> if so I apologize for wasting your time, but I thought at least 
> some of them should be salvaged.
> ...
> From:	"Carlos R. Mafra" <crmafra@aei.mpg.de>
> Subject: [PATCH] Makefile: clean block-sha1/ directory instead of mozilla-sha1/
> Date:	Sun, 11 Oct 2009 15:32:19 +0200
>
>     'make clean' should remove the object files from block-sha1/
>     instead of the non-existent mozilla-sha1/ directory.

This was lost in the noise, and it is an obviously correct patch.

Thanks for a reminder.

> From:	Björn Gustavsson <bgustavsson@gmail.com>
> Subject: [PATCH] push: fix usage: --tags is incompatible with --all and --mirror
> Date:	Thu, 15 Oct 2009 18:39:05 +0200
> Message-ID: <4AD75029.1010109@gmail.com>
>
>     Correct the usage text to make it clear that --tags cannot
>     be combined with --all or --mirror.

Ditto.

> From: René Scharfe <rene.scharfe@lsrfire.ath.cx>
> Subject: [PATCH] describe: load refnames before calling describe()
> Date: Sat, 17 Oct 2009 18:30:48 +0200
> Message-ID: <4AD9F138.3080405@lsrfire.ath.cx>
>
>     Get rid of the static variable that was used to prevent loading all
>     the refnames multiple times by moving that code out of describe(),
>     simply making sure it is only run once that way.

Ditto.

Re: Unapplied patches reminder

[Junio C Hamano]

Nanako Shiraishi <nanako3@lavabit.com> writes:

> Junio, I saw these patches and thought what they try to do were 
> sensible, but I don't them in your tree. I didn't see much discussion 
> on most of them, either.
>
> Because I don't read C very well, I may have listed some patches 
> here that you may have discarded because the code was no good, and 
> if so I apologize for wasting your time, but I thought at least 
> some of them should be salvaged.
> ...
> From: Geoffrey Thomas <geofft@mit.edu>
> Subject: [PATCH] diffcore-order: Default the order file to .git/info/order.
> Date: Sat, 12 Sep 2009 19:49:48 -0400
> Message-ID: <1252799388-16295-1-git-send-email-geofft@mit.edu>
>
>     Since order files tend to be useful for all operations in the
>     project/repository, add a default location for the order file, so that
>     you don't have to specify -O<orderfile> on every diff or similar
>     operation.

Except that "$GIT_DIR/info/order" is a bit too generic a name ("eh,
'order'?  Order of what?"), I do not think this will hurt, as no existing
repositories would have such a file that would cause any behaviour change
to existing users.  The reason I did not queue it was because there wasn't
any discussion on it (not even the filename being too generic) which was
an indication that not many people are interested in such a feature.

That of course can be remedied by interested people speaking out.

Re: Unapplied patches reminder

[Greg Price]

Junio wrote:
> > From: Geoffrey Thomas <geofft@mit.edu>
> > Subject: [PATCH] diffcore-order: Default the order file to .git/info/order.
> > Date: Sat, 12 Sep 2009 19:49:48 -0400
> > Message-ID: <1252799388-16295-1-git-send-email-geofft@mit.edu>
> >
> >     Since order files tend to be useful for all operations in the
> >     project/repository, add a default location for the order file, so that
> >     you don't have to specify -O<orderfile> on every diff or similar
> >     operation.
>
> Except that "$GIT_DIR/info/order" is a bit too generic a name ("eh,
> 'order'?  Order of what?"), I do not think this will hurt, as no existing
> repositories would have such a file that would cause any behaviour change
> to existing users.  The reason I did not queue it was because there wasn't
> any discussion on it (not even the filename being too generic) which was
> an indication that not many people are interested in such a feature.
>
> That of course can be remedied by interested people speaking out.

I never use the -O option, but if this feature were available I think
I would use it.  It would make it possible to configure a helpful
order once -- for example, putting a changelog file first in order to
compare it with the commit message -- and then always use it without
effort.

A less generic name might be 'difforder'.

Greg

Re: Unapplied patches reminder

[Junio C Hamano]

Nanako Shiraishi <nanako3@lavabit.com> writes:

> Junio, I saw these patches and thought what they try to do were 
> sensible, but I don't them in your tree. I didn't see much discussion 
> on most of them, either.
>
> Because I don't read C very well, I may have listed some patches 
> here that you may have discarded because the code was no good, and 
> if so I apologize for wasting your time, but I thought at least 
> some of them should be salvaged.
> ...
> From: "Tom G. Christensen" <tgc@statsbiblioteket.dk>
> Subject: [PATCH] NO_PERL_MAKEMAKER should behave more like ExtUtils::MakeMaker
> Date: Tue, 13 Oct 2009 13:14:31 +0200
> Message-ID: <1255432471-14168-1-git-send-email-tgc@statsbiblioteket.dk>
>
>     This change makes NO_PERL_MAKEMAKER behave more as ExtUtils::MakeMaker
>     by installing the modules into the perl libdir and not $(prefix)/lib.
>     It will default to sitelib but will allow the user to choose by setting
>     the INSTALLDIRS variable which is also honored by ExtUtils::MakeMaker.

I still have this in my inbox, but I tend to wait for Acks to patches that
touch perl/ area before acting on them, which hasn't happened.

P.S. Originally I somehow mistook this from tchrist (aka thoth) and
blindly applied, but then realized it is a different Tom with slightly
different family name and recategorized the patch to go through the usual
review cycle.

Re: Unapplied patches reminder

[Junio C Hamano]

Nanako Shiraishi <nanako3@lavabit.com> writes:

> Junio, I saw these patches and thought what they try to do were 
> sensible, but I don't them in your tree. I didn't see much discussion 
> on most of them, either.
>
> Because I don't read C very well, I may have listed some patches 
> here that you may have discarded because the code was no good, and 
> if so I apologize for wasting your time, but I thought at least 
> some of them should be salvaged.
> ...
> From: Vietor Liu <vietor@vxwo.org>
> Subject: [PATCH v4] git-gui: adjust the minimum height of diff pane for
> Date: Fri, 16 Oct 2009 17:41:26 +0800
> Message-Id: <1255686086-3949-1-git-send-email-vietor@vxwo.org>
>
>     When the main window is maximized, if the screen height is shorter (e.g.
>     Netbook screen 1024x600), both the partial commit pane and the status bar
>     are hidden.

I never apply patches to git-gui and gitk myself, but expect to be fed
them via respective area experts.

> From:	Björn Gustavsson <bgustavsson@gmail.com>
> Subject: [PATCH] bash: complete more options for 'git rebase'
> Date:	Sat, 17 Oct 2009 11:33:38 +0200
> Message-ID: <4AD98F72.1060901@gmail.com>
>
>     Complete all long options for 'git rebase' except --no-verify
>     (probably used very seldom) and the long options corresponding
>     to -v, -q, and -f.

Likewise; I was expecting Shawn to Ack/Nak this one.