threads / discuss / 21273

Unapplied patches reminder

Subject: Unapplied patches reminder

## tl;dr

15 messages between Oct 18, 2009 and Dec 7, 2009.

replies: 14people: 7as markdown or json

Nanako Shiraishi· Oct 18, 2009, 20:20 UTC · lore

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/
Junio C Hamano· Oct 18, 2009, 23:31 UTC · re: Nanako Shiraishi · lore

Re: Unapplied patches reminder

Nanako Shiraishi <nanako3@lavabit.com> writes:
Show 8 quoted lines
> 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.
Junio C Hamano· Oct 18, 2009, 23:31 UTC · re: Nanako Shiraishi · lore

Re: Unapplied patches reminder

Nanako Shiraishi <nanako3@lavabit.com> writes:
Show 16 quoted lines
> 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.

Heiko Voigt· Oct 19, 2009, 08:10 UTC · re: Junio C Hamano · lore

Re: Re: Unapplied patches reminder

On Sun, Oct 18, 2009 at 04:31:49PM -0700, Junio C Hamano wrote:
Show 19 quoted lines
> 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.
Junio C Hamano· Oct 18, 2009, 23:31 UTC · re: Nanako Shiraishi · lore

Re: Unapplied patches reminder

Nanako Shiraishi <nanako3@lavabit.com> writes:
Show 20 quoted lines
> 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.

Show 11 quoted lines
> 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.
Jeff King· Oct 19, 2009, 06:49 UTC · re: Junio C Hamano · lore

Re: Unapplied patches reminder

On Sun, Oct 18, 2009 at 04:31:54PM -0700, Junio C Hamano wrote:
Show 15 quoted lines
> > 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
Junio C Hamano· Oct 19, 2009, 08:05 UTC · re: Jeff King · lore

Re: Unapplied patches reminder

Jeff King <peff@peff.net> writes:
Show 6 quoted lines
> 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.
Junio C Hamano· Oct 18, 2009, 23:31 UTC · re: Nanako Shiraishi · lore

Re: Unapplied patches reminder

Nanako Shiraishi <nanako3@lavabit.com> writes:
Show 22 quoted lines
> 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.

Show 7 quoted lines
> 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).

Rolf Bjarne Kvinge· Oct 19, 2009, 11:57 UTC · re: Junio C Hamano · lore

Re: Unapplied patches reminder

On Mon, 19 Oct 2009 01:31:59 +0200, Junio C Hamano <gitster@pobox.com> wrote:
Show 31 quoted lines
> 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/



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
Per Strandh· Oct 19, 2009, 13:08 UTC · re: Junio C Hamano · lore

Re: Unapplied patches reminder

"Junio C Hamano" <gitster@pobox.com> skrev i meddelandet news:7vzl7ogtxs.fsf@alter.siamese.dyndns.org...

Show 15 quoted lines
>> 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
Junio C Hamano· Oct 18, 2009, 23:32 UTC · re: Nanako Shiraishi · lore

Re: Unapplied patches reminder

Nanako Shiraishi <nanako3@lavabit.com> writes:
Show 15 quoted lines
> 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.
Show 7 quoted lines
> 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.
Show 8 quoted lines
> 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.
Junio C Hamano· Oct 18, 2009, 23:32 UTC · re: Nanako Shiraishi · lore

Re: Unapplied patches reminder

Nanako Shiraishi <nanako3@lavabit.com> writes:
Show 18 quoted lines
> 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.
Greg Price· Dec 7, 2009, 03:03 UTC · re: Junio C Hamano · lore

Re: Unapplied patches reminder

Junio wrote:
Show 18 quoted lines
> > 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
Junio C Hamano· Oct 18, 2009, 23:32 UTC · re: Nanako Shiraishi · lore

Re: Unapplied patches reminder

Nanako Shiraishi <nanako3@lavabit.com> writes:
Show 18 quoted lines
> 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.

Junio C Hamano· Oct 18, 2009, 23:32 UTC · re: Nanako Shiraishi · lore

Re: Unapplied patches reminder

Nanako Shiraishi <nanako3@lavabit.com> writes:
Show 17 quoted lines
> 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.

Show 8 quoted lines
> 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.

← back to recent threads