* [PATCH/RFCv2 0/2] format-patch: produce non colorized patches when color.ui=always
From: Pang Yan Han @ 2011-09-12 17:46 UTC (permalink / raw)
To: git; +Cc: gitster, peff, martin.von.zweigbergk, sdaoden, ib, Pang Yan Han
Hi list,
This 2-patch series has been rerolled with Jeff's suggestions.
For patch 1/2, I've renamed the new test file to t4051-format-patch-config.sh
and changed the description to "check that format-patch does not respect
porcelain config". In addition, I've slightly reworded the commit message to
include the date of the commit (c9bfb953) which introduces the regression.
For patch 2/2, as per Jeff's recommendation, teach git_format_config to
intercept color.ui in the same way as commit f3aafa4 (Disable color detection
during format-patch, 2006-07-09). This is inline with the way we avoid passing
down diff.color and color.diff to git_log_config and config functions further
down the callchain.
Pang Yan Han (2):
format-patch: demonstrate that color.ui=always produces colorized
patches
format-patch: produce non colorized patches when ui.color=always
builtin/log.c | 3 ++-
t/t4051-format-patch-config.sh | 23 +++++++++++++++++++++++
2 files changed, 25 insertions(+), 1 deletions(-)
create mode 100755 t/t4051-format-patch-config.sh
--
1.7.7.rc0.190.gb47b6
^ permalink raw reply
* Re: Chances of getting gitk series merged
From: Paul Mackerras @ 2011-09-12 17:32 UTC (permalink / raw)
To: Martin von Zweigbergk; +Cc: git
In-Reply-To: <alpine.DEB.2.00.1109082055560.12564@debian>
On Thu, Sep 08, 2011 at 09:08:57PM -0400, Martin von Zweigbergk wrote:
> I was happy to see in another thread that you are still here. If I
> understand correctly, you are the maintainer of gitk, meaning that all
> gitk patches go through you and then Junio pulls from you. I have this
> series [1] that I sent in out in April that I would like to get
> merged. Could you have a look at it?
I actually applied the series and I believe I pushed it out, but with
master.kernel.org being down I can't check. I got distracted before
asking Junio to pull, though.
Paul.
^ permalink raw reply
* Re: git-p4.skipSubmitEdit
From: L. A. Linden Levy @ 2011-09-12 17:12 UTC (permalink / raw)
To: Luke Diamand; +Cc: git@vger.kernel.org
In-Reply-To: <4E6DB5F0.7080303@diamand.org>
[-- Attachment #1: Type: text/plain, Size: 13243 bytes --]
I agree with almost all your points. I have answered them each in-line
below.
On Mon, 2011-09-12 at 03:34 -0400, Luke Diamand wrote:
> On 08/09/11 21:40, L. A. Linden Levy wrote:
> > Hi All,
> >
> > I have been using git-p4 for a while and it has allowed me to completely
> > change the way I develop and still be able to use perforce which my
> > company has for its main VCS. One thing that was driving me nuts was
> > that "git p4 submit" cycles through all of my individual commits and
> > asks me if I want to change them. The way I develop I often am checking
> > in 20 to 50 different small commits each with a descriptive git comment.
> > I felt like I was doing double duty by having emacs open on every commit
> > into perforce. So I modified git-p4 to have an option to skip the
> > editor. This option coupled with git-p4.skipSubmitEditCheck will make
> > the submission non-interactive for "git p4 submit".
>
>
> Sorry - I've not had a chance to look at this before now. But a couple
> of comments:
>
> - Is there a line wrap problem in the patch? It doesn't seem to want
> to apply for me.
Probably. Below are the results from following the patch submission
instructions.
From 16c4344de0047cbaf3381eca590a3e59b0d0a25c Mon Sep 17 00:00:00 2001
From: "Loren A. Linden Levy" <lindenle@gmail.com>
Date: Thu, 8 Sep 2011 13:37:22 -0700
Subject: [PATCH 1/5] changed git-p4
---
contrib/fast-import/git-p4 | 15 ++++++++++-----
1 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 2f7b270..a438b3e 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -935,18 +935,23 @@ class P4Submit(Command, P4UserMap):
tmpFile.write(submitTemplate + separatorLine + diff +
newdiff)
tmpFile.close()
mtime = os.stat(fileName).st_mtime
- if os.environ.has_key("P4EDITOR"):
- editor = os.environ.get("P4EDITOR")
+ if gitConfig("git-p4.skipSubmitEdit") == "true":
+ pass
else:
- editor = read_pipe("git var GIT_EDITOR").strip()
- system(editor + " " + fileName)
-
+ if os.environ.has_key("P4EDITOR"):
+ editor = os.environ.get("P4EDITOR")
+ else:
+ editor = read_pipe("git var GIT_EDITOR").strip()
+
+ system(editor + " " + fileName)
+
if gitConfig("git-p4.skipSubmitEditCheck") == "true":
checkModTime = False
else:
checkModTime = True
response = "y"
+
if checkModTime and (os.stat(fileName).st_mtime <= mtime):
response = "x"
while response != "y" and response != "n":
--
1.7.7.rc0.73.g16c43
From ed60bb737b89eea4b84719c458aeebebd666a2ae Mon Sep 17 00:00:00 2001
From: "Loren A. Linden Levy" <lindenle@gmail.com>
Date: Mon, 12 Sep 2011 09:52:52 -0700
Subject: [PATCH 2/5] removed white space for patch
---
contrib/fast-import/git-p4 | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index a438b3e..edd2525 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -942,9 +942,7 @@ class P4Submit(Command, P4UserMap):
editor = os.environ.get("P4EDITOR")
else:
editor = read_pipe("git var GIT_EDITOR").strip()
-
system(editor + " " + fileName)
-
if gitConfig("git-p4.skipSubmitEditCheck") == "true":
checkModTime = False
else:
--
1.7.7.rc0.73.g16c43
From ee7eaf73cf52100359b08600eab1279e03ef777b Mon Sep 17 00:00:00 2001
From: "Loren A. Linden Levy" <lindenle@gmail.com>
Date: Mon, 12 Sep 2011 09:55:11 -0700
Subject: [PATCH 3/5] modified the documentation
---
contrib/fast-import/git-p4.txt | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/contrib/fast-import/git-p4.txt
b/contrib/fast-import/git-p4.txt
index 52003ae..3dba636 100644
--- a/contrib/fast-import/git-p4.txt
+++ b/contrib/fast-import/git-p4.txt
@@ -202,10 +202,16 @@ able to find the relevant client. This client
spec will be used to
both filter the files cloned by git and set the directory layout as
specified in the client (this implies --keep-path style semantics).
-git-p4.skipSubmitModTimeCheck
+git-p4.skipSubmitEdit
git config [--global] git-p4.skipSubmitModTimeCheck false
+If true, submit will not invoke the editor to modify the p4 change
template.
+
+git-p4.skipSubmitEditCheck
+
+ git config [--global] git-p4.skipSubmitEditCheck false
+
If true, submit will not check if the p4 change template has been
modified.
git-p4.preserveUser
--
1.7.7.rc0.73.g16c43
From ee7eaf73cf52100359b08600eab1279e03ef777b Mon Sep 17 00:00:00 2001
From: "Loren A. Linden Levy" <lindenle@gmail.com>
Date: Mon, 12 Sep 2011 09:55:11 -0700
Subject: [PATCH 3/6] modified the documentation
---
contrib/fast-import/git-p4.txt | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/contrib/fast-import/git-p4.txt
b/contrib/fast-import/git-p4.txt
index 52003ae..3dba636 100644
--- a/contrib/fast-import/git-p4.txt
+++ b/contrib/fast-import/git-p4.txt
@@ -202,10 +202,16 @@ able to find the relevant client. This client
spec will be used to
both filter the files cloned by git and set the directory layout as
specified in the client (this implies --keep-path style semantics).
-git-p4.skipSubmitModTimeCheck
+git-p4.skipSubmitEdit
git config [--global] git-p4.skipSubmitModTimeCheck false
+If true, submit will not invoke the editor to modify the p4 change
template.
+
+git-p4.skipSubmitEditCheck
+
+ git config [--global] git-p4.skipSubmitEditCheck false
+
If true, submit will not check if the p4 change template has been
modified.
git-p4.preserveUser
--
1.7.7.rc0.73.g16c43
From c9d3b4ea4dcf1f5fd489dfacde550dd4c648afc7 Mon Sep 17 00:00:00 2001
From: "Loren A. Linden Levy" <lindenle@gmail.com>
Date: Mon, 12 Sep 2011 10:01:08 -0700
Subject: [PATCH 4/6] changed the order a bit
---
contrib/fast-import/git-p4 | 11 ++++++-----
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index edd2525..80bcc90 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -935,18 +935,19 @@ class P4Submit(Command, P4UserMap):
tmpFile.write(submitTemplate + separatorLine + diff +
newdiff)
tmpFile.close()
mtime = os.stat(fileName).st_mtime
+ if gitConfig("git-p4.skipSubmitEditCheck") == "true":
+ checkModTime = False
+ else:
+ checkModTime = True
if gitConfig("git-p4.skipSubmitEdit") == "true":
- pass
+ checkModTime = False
+ pass
else:
if os.environ.has_key("P4EDITOR"):
editor = os.environ.get("P4EDITOR")
else:
editor = read_pipe("git var GIT_EDITOR").strip()
system(editor + " " + fileName)
- if gitConfig("git-p4.skipSubmitEditCheck") == "true":
- checkModTime = False
- else:
- checkModTime = True
response = "y"
--
1.7.7.rc0.73.g16c43
From de3d67a301b49e4d986e83727b822aa5fd257527 Mon Sep 17 00:00:00 2001
From: "Loren A. Linden Levy" <lindenle@gmail.com>
Date: Mon, 12 Sep 2011 10:03:03 -0700
Subject: [PATCH 5/6] cleaned up whitespace for making a patch
---
contrib/fast-import/git-p4 | 2 +-
contrib/fast-import/git-p4.txt | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 80bcc90..1cd65a3 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -941,7 +941,7 @@ class P4Submit(Command, P4UserMap):
checkModTime = True
if gitConfig("git-p4.skipSubmitEdit") == "true":
checkModTime = False
- pass
+ pass
else:
if os.environ.has_key("P4EDITOR"):
editor = os.environ.get("P4EDITOR")
diff --git a/contrib/fast-import/git-p4.txt
b/contrib/fast-import/git-p4.txt
index 3dba636..8291e7a 100644
--- a/contrib/fast-import/git-p4.txt
+++ b/contrib/fast-import/git-p4.txt
@@ -208,7 +208,7 @@ git-p4.skipSubmitEdit
If true, submit will not invoke the editor to modify the p4 change
template.
-git-p4.skipSubmitEditCheck
+git-p4.skipSubmitEditCheck
git config [--global] git-p4.skipSubmitEditCheck false
--
1.7.7.rc0.73.g16c43
From 64c4878d12748daeda637b3d7d2f018c316b4239 Mon Sep 17 00:00:00 2001
From: "Loren A. Linden Levy" <lindenle@gmail.com>
Date: Mon, 12 Sep 2011 10:10:22 -0700
Subject: [PATCH 6/6] made the docs correct for the new option
---
contrib/fast-import/git-p4.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/fast-import/git-p4.txt
b/contrib/fast-import/git-p4.txt
index 8291e7a..f1c1d0c 100644
--- a/contrib/fast-import/git-p4.txt
+++ b/contrib/fast-import/git-p4.txt
@@ -204,7 +204,7 @@ specified in the client (this implies --keep-path
style semantics).
git-p4.skipSubmitEdit
- git config [--global] git-p4.skipSubmitModTimeCheck false
+ git config [--global] git-p4.skipSubmitEdit false
If true, submit will not invoke the editor to modify the p4 change
template.
--
1.7.7.rc0.73.g16c43
> - needs an update to the documentation in git-p4.txt
Done. Also I think the skipSubmitEditCheck was incorrectly name
git-p4.skipSubmitModTimeCheck in the git-p4.txt file. I updated this as
well.
> - is there any way to eliminate the slightly ugly
> "if/pass/else/do-stuff" construct?
I think it is logically correct and describes the situation well. We are
skipping the editor so we pass it. If you still do not agree then
perhaps a suggestion of a better logical flow would help me.
> - I'd think if you turned off the editor completely then there's no
> point doing the submit-edit-check.
I have changed the ordering so that at the moment this happens because I
agree with you.
> - You probably need to follow the instructions in
> Documentation/SubmittingPatches so that Junio will pay attention to the
> patch.
See point #1.
> Regards!
> Luke
>
>
> >
> > Below are the patch and environment results:
> >
> >
> > $ git config -l
> > ...
> > user.name=Loren A. Linden Levy
> > git-p4.skipsubmitedit=true
> > git-p4.skipsubmiteditcheck=true
> > ...
> >
> > $ git format-patch origin/master --stdout
> >
> > From 16c4344de0047cbaf3381eca590a3e59b0d0a25c Mon Sep 17 00:00:00 2001
> > From: "Loren A. Linden Levy"<lindenle@gmail.com>
> > Date: Thu, 8 Sep 2011 13:37:22 -0700
> > Subject: [PATCH] changed git-p4
> >
> > ---
> > contrib/fast-import/git-p4 | 15 ++++++++++-----
> > 1 files changed, 10 insertions(+), 5 deletions(-)
> >
> > diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
> > index 2f7b270..a438b3e 100755
> > --- a/contrib/fast-import/git-p4
> > +++ b/contrib/fast-import/git-p4
> > @@ -935,18 +935,23 @@ class P4Submit(Command, P4UserMap):
> > tmpFile.write(submitTemplate + separatorLine + diff +
> > newdiff)
> > tmpFile.close()
> > mtime = os.stat(fileName).st_mtime
> > - if os.environ.has_key("P4EDITOR"):
> > - editor = os.environ.get("P4EDITOR")
> > + if gitConfig("git-p4.skipSubmitEdit") == "true":
> > + pass
> > else:
> > - editor = read_pipe("git var GIT_EDITOR").strip()
> > - system(editor + " " + fileName)
> > -
> > + if os.environ.has_key("P4EDITOR"):
> > + editor = os.environ.get("P4EDITOR")
> > + else:
> > + editor = read_pipe("git var GIT_EDITOR").strip()
> > +
> > + system(editor + " " + fileName)
> > +
> > if gitConfig("git-p4.skipSubmitEditCheck") == "true":
> > checkModTime = False
> > else:
> > checkModTime = True
> >
> > response = "y"
> > +
> > if checkModTime and (os.stat(fileName).st_mtime<= mtime):
> > response = "x"
> > while response != "y" and response != "n":
>
--
Alex Linden Levy
Senior Software Engineer
MobiTV, Inc.
6425 Christie Avenue, 5th Floor, Emeryville, CA 94608
phone 510.450.5190 mobile 720.352.8394
email alevy@mobitv.com web www.mobitv.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply related
* Re: [PATCH/RFC 1/2] format-patch: demonstrate that color.ui=always produces colorized patches
From: Jeff King @ 2011-09-12 16:58 UTC (permalink / raw)
To: Pang Yan Han; +Cc: git, gitster, martin.von.zweigbergk, sdaoden, ib
In-Reply-To: <1315843016-10959-2-git-send-email-pangyanhan@gmail.com>
On Mon, Sep 12, 2011 at 11:56:55PM +0800, Pang Yan Han wrote:
> Hi, I don't know if I actually understand the naming convention for tests
> correctly here, so I used the next available number for the last 2 digits.
>
> t/t4051-format-patch-color.sh | 23 +++++++++++++++++++++++
Usually we would try to keep format-patch tests clustered numerically,
but it seems the t40* space has gotten quite filled up and fragmented.
So I think where you added it is fine (and if somebody cares to
reorganize tests, they can do so later).
Often if there is only one or two tests to add, it is more logical to
add to an existing script. However, I think in this case, starting a new
script to check how format-patch handles various config features
(including color) makes sense. Maybe it makes sense to call it
"format-patch-config" instead, and set the description to something like
"check that format-patch does not respect porcelain config".
-Peff
^ permalink raw reply
* Re: [PATCH/RFC 0/2] format-patch: produce non colorized patches when color.ui=always
From: Jeff King @ 2011-09-12 16:53 UTC (permalink / raw)
To: Pang Yan Han; +Cc: git, gitster, martin.von.zweigbergk, sdaoden, ib
In-Reply-To: <1315843016-10959-1-git-send-email-pangyanhan@gmail.com>
On Mon, Sep 12, 2011 at 11:56:54PM +0800, Pang Yan Han wrote:
> commit c9bfb953 (want_color: automatically fallback to color.ui) introduced
> a regression which causes format-patch to produce colorized patches when
> color.ui is set to "always".
>
> Since patches are ultimately intended for machine consumption, having color
> codes present in them is undesirable.
Thanks for looking at this. I meant to do so last week, but it looks
like my procrastination paid off. :)
> My understanding of the codebase is very limited. I've looked into builtin/log.c
> and the call chain which causes format-patch to produce colorized output is:
>
> git_format_config
> |_ git_log_config
> |_ git_diff_ui_config
> |_ git_color_config
> |_ git_config_colorbool
>
> which causes git_use_color_default to be set to 1 when color.ui is set to
> "always".
>
> I believe that I can assume that the parsing done in git_diff_ui_config is
> related to the [<common diff options>] based on git format-patch manpage?
Yes. However, there is also git_diff_basic_config, which is used by the
diff plumbing tools. So my plan had been to provide a callpath like
this:
git_format_config
|_ git_log_basic_config
|_ git_diff_basic_config
|_git_default_config
However, git_diff_ui_config does some other things that affect patch
output, including:
diff.renames
diff.mnemonicprefix
diff.noprefix
diff.external
diff.wordregex
diff.ignoresubmodules
Which of these are OK for format-patch to respect, and which not? Even
though it is plumbing, I think people depend on it respecting
diff.renames. So probably switching to just using git_diff_basic_config
is not right.
Another option is to just clear ALLOW_COLOR from the diff_options before
producing any output. But that would disable something like:
git format-patch --color ...
which, while it is crazy for somebody actually generating a patch to
send, may be useful for somebody who wants to review what format-patch
will produce. So that's not right either.
At this point in my thinking, I scratched my head a bit. Shouldn't
setting "diff.color = always" have the exact same problem? But it
doesn't. And indeed, we have code to handle that in f3aafa4 (Disable
color detection during format-patch, 2006-07-09). It intercepts
diff.color in git_format_config and doesn't pass it along.
I can't decide if that is a hack (because format-patch needs to know
about diff config variables) or elegant (because it can intercept and
ignore whichever variables it likes). But it probably makes sense to use
the same strategy for color.ui, so at least we don't have two different
hacks. :)
Can you tweak your 2/2 to use that approach?
> I understand that this is very hacky but well, I'm really looking for ways
> to contribute to Git and this seems like one.
>
> Any advice on how this can be better solved is deeply appreciated.
Welcome to git development. :) Despite my comments above, thank you for
a well-written submission. We don't always get the patches perfect the
first time, but communicating the problem and the proposed solution well
helps reviewers move it in the right direction.
-Peff
^ permalink raw reply
* Re: [PATCH v2 0/7] Improved infrastructure for refname normalization
From: Junio C Hamano @ 2011-09-12 16:44 UTC (permalink / raw)
To: Michael Haggerty; +Cc: git, cmn, A Large Angry SCM
In-Reply-To: <4E6E2122.8000201@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
> OTOH I am again having serious doubts that trying to support
> unnormalized refnames is a good idea.
Sorry, I am confused. I thought the way you are planning forward is to
leave unnormalized ones unchecked as the current code does (and mark the
places that do so with _unsafe()), with the eventual goal of fixing the
caller to pass only normalized ones to make call to the "safe" version?
^ permalink raw reply
* [PATCH/RFC 2/2] format-patch: produce non colorized patches when ui.color=always
From: Pang Yan Han @ 2011-09-12 15:56 UTC (permalink / raw)
To: git; +Cc: gitster, peff, martin.von.zweigbergk, sdaoden, ib, Pang Yan Han
In-Reply-To: <1315843016-10959-1-git-send-email-pangyanhan@gmail.com>
commit c9bfb953 (want_color: automatically fallback to color.ui) introduced
a regression where format-patch produces colorized patches when color.ui is
set to "always".
Teach format-patch to disable colorized output by introducing the color_disable
function in color.c
Signed-off-by: Pang Yan Han <pangyanhan@gmail.com>
---
builtin/log.c | 1 +
color.c | 5 +++++
color.h | 1 +
t/t4051-format-patch-color.sh | 2 +-
4 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/builtin/log.c b/builtin/log.c
index d760ee0..f62520d 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -1090,6 +1090,7 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
extra_to.strdup_strings = 1;
extra_cc.strdup_strings = 1;
git_config(git_format_config, NULL);
+ color_disable();
init_revisions(&rev, prefix);
rev.commit_format = CMIT_FMT_EMAIL;
rev.verbose_header = 1;
diff --git a/color.c b/color.c
index e8e2681..48e7208 100644
--- a/color.c
+++ b/color.c
@@ -207,6 +207,11 @@ int want_color(int var)
return var;
}
+void color_disable(void)
+{
+ git_use_color_default = 0;
+}
+
int git_color_config(const char *var, const char *value, void *cb)
{
if (!strcmp(var, "color.ui")) {
diff --git a/color.h b/color.h
index 9a8495b..ff4e6e5 100644
--- a/color.h
+++ b/color.h
@@ -77,6 +77,7 @@ int git_color_default_config(const char *var, const char *value, void *cb);
int git_config_colorbool(const char *var, const char *value);
int want_color(int var);
+void color_disable(void);
void color_parse(const char *value, const char *var, char *dst);
void color_parse_mem(const char *value, int len, const char *var, char *dst);
__attribute__((format (printf, 3, 4)))
diff --git a/t/t4051-format-patch-color.sh b/t/t4051-format-patch-color.sh
index db30840..44dba16 100755
--- a/t/t4051-format-patch-color.sh
+++ b/t/t4051-format-patch-color.sh
@@ -13,7 +13,7 @@ test_expect_success setup '
git commit -m "commit2"
'
-test_expect_failure 'format patch with ui.color=always generates non colorized patch' '
+test_expect_success 'format patch with ui.color=always generates non colorized patch' '
git config color.ui always &&
git format-patch -1 &&
mv 0001-commit2.patch actual &&
--
1.7.7.rc0.190.g816e
^ permalink raw reply related
* [PATCH/RFC 1/2] format-patch: demonstrate that color.ui=always produces colorized patches
From: Pang Yan Han @ 2011-09-12 15:56 UTC (permalink / raw)
To: git; +Cc: gitster, peff, martin.von.zweigbergk, sdaoden, ib, Pang Yan Han
In-Reply-To: <1315843016-10959-1-git-send-email-pangyanhan@gmail.com>
commit c9bfb953 (want_color: automatically fallback to color.ui) introduced
a regression where format-patch produces colorized patches when color.ui is
set to "always". Demonstrate this through a new test.
Signed-off-by: Pang Yan Han <pangyanhan@gmail.com>
---
Hi, I don't know if I actually understand the naming convention for tests
correctly here, so I used the next available number for the last 2 digits.
t/t4051-format-patch-color.sh | 23 +++++++++++++++++++++++
1 files changed, 23 insertions(+), 0 deletions(-)
create mode 100755 t/t4051-format-patch-color.sh
diff --git a/t/t4051-format-patch-color.sh b/t/t4051-format-patch-color.sh
new file mode 100755
index 0000000..db30840
--- /dev/null
+++ b/t/t4051-format-patch-color.sh
@@ -0,0 +1,23 @@
+#!/bin/sh
+
+test_description='format-patch - check for non colorized output'
+
+. ./test-lib.sh
+
+test_expect_success setup '
+ echo foo >foo &&
+ git add foo &&
+ git commit -m "commit1" &&
+ echo bar >foo &&
+ git add foo &&
+ git commit -m "commit2"
+'
+
+test_expect_failure 'format patch with ui.color=always generates non colorized patch' '
+ git config color.ui always &&
+ git format-patch -1 &&
+ mv 0001-commit2.patch actual &&
+ test_must_fail grep "\[31m-" actual
+'
+
+test_done
--
1.7.7.rc0.190.g816e
^ permalink raw reply related
* [PATCH/RFC 0/2] format-patch: produce non colorized patches when color.ui=always
From: Pang Yan Han @ 2011-09-12 15:56 UTC (permalink / raw)
To: git; +Cc: gitster, peff, martin.von.zweigbergk, sdaoden, ib, Pang Yan Han
Hi list,
commit c9bfb953 (want_color: automatically fallback to color.ui) introduced
a regression which causes format-patch to produce colorized patches when
color.ui is set to "always".
Since patches are ultimately intended for machine consumption, having color
codes present in them is undesirable.
My understanding of the codebase is very limited. I've looked into builtin/log.c
and the call chain which causes format-patch to produce colorized output is:
git_format_config
|_ git_log_config
|_ git_diff_ui_config
|_ git_color_config
|_ git_config_colorbool
which causes git_use_color_default to be set to 1 when color.ui is set to
"always".
I believe that I can assume that the parsing done in git_diff_ui_config is
related to the [<common diff options>] based on git format-patch manpage?
I've introduced a color_disable function in color.c which changes
git_use_color_default to 0. This is the simplest solution I can see without
heavily touching the stuff in the call chain above since they might be
needed for format-patch.
I understand that this is very hacky but well, I'm really looking for ways
to contribute to Git and this seems like one.
Any advice on how this can be better solved is deeply appreciated.
Thanks.
Pang Yan Han (2):
format-patch: demonstrate that color.ui=always produces colorized
patches
format-patch: produce non colorized patches when ui.color=always
builtin/log.c | 1 +
color.c | 5 +++++
color.h | 1 +
t/t4051-format-patch-color.sh | 23 +++++++++++++++++++++++
4 files changed, 30 insertions(+), 0 deletions(-)
create mode 100755 t/t4051-format-patch-color.sh
--
1.7.7.rc0.190.g816e
^ permalink raw reply
* Re: [PATCH v2 0/7] Improved infrastructure for refname normalization
From: Michael Haggerty @ 2011-09-12 15:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, cmn, A Large Angry SCM
In-Reply-To: <7vehzmbd0o.fsf@alter.siamese.dyndns.org>
On 09/12/2011 06:28 AM, Junio C Hamano wrote:
> Michael Haggerty <mhagger@alum.mit.edu> writes:
> There were a few minor things that looked worth mentioning while
> reviewing, though.
>
> - (style) You seem to be fond of pre-increment a lot, but in general our
> codebase prefers post-increment especially when the end result does not
> make any difference, e.g.
>
> for (i = 1; ...; ++i) {
> ...
OK, changed.
> - (series structure) It might make the series progress easier to follow
> if you introduced check_ref_format_unsafe() in the same commit where
> you change check_ref_format() to take flags parameter.
OK. I'll take the opportunity to rename the functions to
check_refname_format*(), to make it more obvious that they only concern
themselves with the refnames and not the references themselves.
I discovered a bug in my code for handling refnames without
normalization; I will also fix that in v3.
OTOH I am again having serious doubts that trying to support
unnormalized refnames is a good idea. I will write more when I have
time to argue my case.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* [PATCH v2] git svn dcommit: new option --interactive.
From: Frédéric Heitzmann @ 2011-09-12 14:57 UTC (permalink / raw)
To: git; +Cc: gitster, normalperson, jaysoffian, Frédéric Heitzmann
Allow the user to check the patch set before it is commited to SNV. It is
then possible to accept/discard one patch, accept all, or quit.
This interactive mode is similar with 'git send email' behaviour. However,
'git svn dcommit' returns as soon as one patch is discarded.
Part of the code was taken from git-send-email.perl (see 'ask' function)
Tests several combinations of potential answers to
'git svn dcommit --interactive'. For each of them, test whether patches
were commited to SVN or not.
Thanks-to Eric Wong <normalperson@yhbt.net> for the initial idea.
Signed-off-by: Frédéric Heitzmann <frederic.heitzmann@gmail.com>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
Documentation/git-svn.txt | 8 +++
git-svn.perl | 76 +++++++++++++++++++++++++++++++-
t/t9160-git-svn-dcommit-interactive.sh | 64 +++++++++++++++++++++++++++
3 files changed, 147 insertions(+), 1 deletions(-)
create mode 100644 t/t9160-git-svn-dcommit-interactive.sh
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index e75fc19..022989f 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -226,6 +226,14 @@ discouraged.
branches, use a single space character between the branches
(`--mergeinfo="/branches/foo:1-10 /branches/bar:3,5-6,8"`)
+--interactive;;
+ Ask the user to confirm that a patch set should actually be sent to SVN.
+ For each patch, one may answer "yes" (accept this patch), "no" (discard this
+ patch), "all" (accept all patches), or "quit".
+ +
+ 'git svn dcommit' returns immediately if answer if "no" or "quit", without
+ commiting anything to SVN.
+
'branch'::
Create a branch in the SVN repository.
diff --git a/git-svn.perl b/git-svn.perl
index d067837..56b6867 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -87,7 +87,7 @@ my ($_stdin, $_help, $_edit,
$_version, $_fetch_all, $_no_rebase, $_fetch_parent,
$_merge, $_strategy, $_dry_run, $_local,
$_prefix, $_no_checkout, $_url, $_verbose,
- $_git_format, $_commit_url, $_tag, $_merge_info);
+ $_git_format, $_commit_url, $_tag, $_merge_info, $_interactive);
$Git::SVN::_follow_parent = 1;
$SVN::Git::Fetcher::_placeholder_filename = ".gitignore";
$_q ||= 0;
@@ -163,6 +163,7 @@ my %cmd = (
'revision|r=i' => \$_revision,
'no-rebase' => \$_no_rebase,
'mergeinfo=s' => \$_merge_info,
+ 'interactive|i' => \$_interactive,
%cmt_opts, %fc_opts } ],
branch => [ \&cmd_branch,
'Create a branch in the SVN repository',
@@ -256,6 +257,27 @@ my %cmd = (
{} ],
);
+use Term::ReadLine;
+package FakeTerm;
+sub new {
+ my ($class, $reason) = @_;
+ return bless \$reason, shift;
+}
+sub readline {
+ my $self = shift;
+ die "Cannot use readline on FakeTerm: $$self";
+}
+package main;
+
+my $term = eval {
+ $ENV{"GIT_SVN_NOTTY"}
+ ? new Term::ReadLine 'git-svn', \*STDIN, \*STDOUT
+ : new Term::ReadLine 'git-svn';
+};
+if ($@) {
+ $term = new FakeTerm "$@: going non-interactive";
+}
+
my $cmd;
for (my $i = 0; $i < @ARGV; $i++) {
if (defined $cmd{$ARGV[$i]}) {
@@ -366,6 +388,36 @@ sub version {
exit 0;
}
+sub ask {
+ my ($prompt, %arg) = @_;
+ my $valid_re = $arg{valid_re};
+ my $default = $arg{default};
+ my $resp;
+ my $i = 0;
+
+ if ( !( defined($term->IN)
+ && defined( fileno($term->IN) )
+ && defined( $term->OUT )
+ && defined( fileno($term->OUT) ) ) ){
+ return defined($default) ? $default : undef;
+ }
+
+ while ($i++ < 10) {
+ $resp = $term->readline($prompt);
+ if (!defined $resp) { # EOF
+ print "\n";
+ return defined $default ? $default : undef;
+ }
+ if ($resp eq '' and defined $default) {
+ return $default;
+ }
+ if (!defined $valid_re or $resp =~ /$valid_re/) {
+ return $resp;
+ }
+ }
+ return undef;
+}
+
sub do_git_init_db {
unless (-d $ENV{GIT_DIR}) {
my @init_db = ('init');
@@ -557,6 +609,28 @@ sub cmd_dcommit {
"If these changes depend on each other, re-running ",
"without --no-rebase may be required."
}
+
+ if (defined $_interactive){
+ my $ask_default = "y";
+ foreach my $d (@$linear_refs){
+ print "debug : d = $d\n";
+ my ($fh, $ctx) = command_output_pipe(qw(show --summary), "$d");
+ while (<$fh>){
+ print $_;
+ }
+ command_close_pipe($fh, $ctx);
+ $_ = ask("Commit this patch to SVN? ([y]es (default)|[n]o|[q]uit|[a]ll): ",
+ valid_re => qr/^(?:yes|y|no|n|quit|q|all|a)/i,
+ default => $ask_default);
+ die "Commit this patch reply required" unless defined $_;
+ if (/^[nq]/i) {
+ exit(0);
+ } elsif (/^a/i) {
+ last;
+ }
+ }
+ }
+
my $expect_url = $url;
Git::SVN::remove_username($expect_url);
if (defined($_merge_info)) {
diff --git a/t/t9160-git-svn-dcommit-interactive.sh b/t/t9160-git-svn-dcommit-interactive.sh
new file mode 100644
index 0000000..e38d9fa
--- /dev/null
+++ b/t/t9160-git-svn-dcommit-interactive.sh
@@ -0,0 +1,64 @@
+#!/bin/sh
+#
+# Copyright (c) 2011 Frédéric Heitzmann
+
+test_description='git svn dcommit --interactive series'
+. ./lib-git-svn.sh
+
+test_expect_success 'initialize repo' '
+ svn_cmd mkdir -m"mkdir test-interactive" "$svnrepo/test-interactive" &&
+ git svn clone "$svnrepo/test-interactive" test-interactive &&
+ cd test-interactive &&
+ touch foo && git add foo && git commit -m"foo: first commit" &&
+ git svn dcommit
+ '
+
+test_expect_success 'answers: y [\n] yes' '
+ (
+ echo "change #1" >> foo && git commit -a -m"change #1" &&
+ echo "change #2" >> foo && git commit -a -m"change #2" &&
+ echo "change #3" >> foo && git commit -a -m"change #3" &&
+ ( echo "y
+
+y" | GIT_SVN_NOTTY=1 git svn dcommit --interactive ) &&
+ test $(git rev-parse HEAD) = $(git rev-parse remotes/git-svn)
+ )
+ '
+
+test_expect_success 'answers: yes yes no' '
+ (
+ echo "change #1" >> foo && git commit -a -m"change #1" &&
+ echo "change #2" >> foo && git commit -a -m"change #2" &&
+ echo "change #3" >> foo && git commit -a -m"change #3" &&
+ ( echo "yes
+yes
+no" | GIT_SVN_NOTTY=1 git svn dcommit --interactive ) &&
+ test $(git rev-parse HEAD^^^) = $(git rev-parse remotes/git-svn) &&
+ git reset --hard remotes/git-svn
+ )
+ '
+
+test_expect_success 'answers: yes quit' '
+ (
+ echo "change #1" >> foo && git commit -a -m"change #1" &&
+ echo "change #2" >> foo && git commit -a -m"change #2" &&
+ echo "change #3" >> foo && git commit -a -m"change #3" &&
+ ( echo "yes
+quit" | GIT_SVN_NOTTY=1 git svn dcommit --interactive ) &&
+ test $(git rev-parse HEAD^^^) = $(git rev-parse remotes/git-svn) &&
+ git reset --hard remotes/git-svn
+ )
+ '
+
+test_expect_success 'answers: all' '
+ (
+ echo "change #1" >> foo && git commit -a -m"change #1" &&
+ echo "change #2" >> foo && git commit -a -m"change #2" &&
+ echo "change #3" >> foo && git commit -a -m"change #3" &&
+ ( echo "all" | GIT_SVN_NOTTY=1 git svn dcommit --interactive ) &&
+ test $(git rev-parse HEAD) = $(git rev-parse remotes/git-svn) &&
+ git reset --hard remotes/git-svn
+ )
+ '
+
+test_done
--
1.7.7.rc0.73.g0a352.dirty
^ permalink raw reply related
* Re: [PATCH v2] git-svn: teach git-svn to populate svn:mergeinfo
From: Bryan Jacobs @ 2011-09-12 14:24 UTC (permalink / raw)
To: Eric Wong; +Cc: git, Sam Vilain
In-Reply-To: <20110909222159.GA6530@dcvr.yhbt.net>
On Fri, 9 Sep 2011 15:21:59 -0700
Eric Wong <normalperson@yhbt.net> wrote:
> Some comments inline, but I can clean them up myself and push out in a
> bit.
>
> > --- a/Documentation/git-svn.txt
> > +++ b/Documentation/git-svn.txt
> > @@ -213,6 +213,14 @@ discouraged.
> > store this information (as a property), and svn clients
> > starting from version 1.5 can make use of it. 'git svn' currently
> > does not use it and does not set it automatically.
>
> I noticed this conflicts when applying due to the missing --mergeinfo=
> documentation. Did you intend to remove --mergeinfo entirely and
> replace it with this? I think some folks already depend on it (it's
> been around since last year).
No, that was me munging my patch base. Feel free to set the
documentation for mergeinfo however you like, even documenting this
feature if you wish. The functionality of --mergeinfo still should work
with this patch, although obviously if it's provided the
auto-population will be bypassed.
> > + if (not defined($push_merge_info)
> > + or $push_merge_info eq "false"
> > + or $push_merge_info eq "no"
> > + or $push_merge_info eq "never") {
>
> I missed this the first time, but "||" and "!" are easier for
> C programmers to understand and higher in precedence (ref: perlop
> manpage)
>
You're right, "||" and "!" are better here. TMTOWTDI is the Perl motto,
no? A double-edged sword.
Thanks for the help and review. I'll let you do the cleanup and push
the resulting patch when you feel it's ready (as you suggested), rather
than iterating again for these small changes.
Bryan Jacobs
^ permalink raw reply
* Re: What's cooking in git.git (Sep 2011, #03; Sun, 11)
From: Sverre Rabbelier @ 2011-09-12 8:16 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Junio C Hamano, git
In-Reply-To: <vpqehzm6wrt.fsf@bauges.imag.fr>
Heya,
On Mon, Sep 12, 2011 at 09:32, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> I agree it's not urgent, but this serie doesn't touch the code itself,
> so it should be pretty harmless. It fixes some relatively important
> documentation issues, and a nice side effect of putting them in a
> release soon would be to update the doc available at
> http://www.kernel.org/pub/software/scm/git/docs/git-remote-helpers.html
> (when kernel.org is not down).
Agreed. Do we have a different policy for documentation cooking than
code though?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Git new-feature-branch best practices
From: Alexey Shumkin @ 2011-09-12 8:02 UTC (permalink / raw)
To: git
In-Reply-To: <1315769475.2560.39.camel@mamburu>
take a look
http://comments.gmane.org/gmane.comp.version-control.git/181129
^ permalink raw reply
* Re: git-p4.skipSubmitEdit
From: Luke Diamand @ 2011-09-12 7:34 UTC (permalink / raw)
To: L. A. Linden Levy, git
In-Reply-To: <1315514452.10046.0.camel@uncle-pecos>
On 08/09/11 21:40, L. A. Linden Levy wrote:
> Hi All,
>
> I have been using git-p4 for a while and it has allowed me to completely
> change the way I develop and still be able to use perforce which my
> company has for its main VCS. One thing that was driving me nuts was
> that "git p4 submit" cycles through all of my individual commits and
> asks me if I want to change them. The way I develop I often am checking
> in 20 to 50 different small commits each with a descriptive git comment.
> I felt like I was doing double duty by having emacs open on every commit
> into perforce. So I modified git-p4 to have an option to skip the
> editor. This option coupled with git-p4.skipSubmitEditCheck will make
> the submission non-interactive for "git p4 submit".
Sorry - I've not had a chance to look at this before now. But a couple
of comments:
- Is there a line wrap problem in the patch? It doesn't seem to want
to apply for me.
- needs an update to the documentation in git-p4.txt
- is there any way to eliminate the slightly ugly
"if/pass/else/do-stuff" construct?
- I'd think if you turned off the editor completely then there's no
point doing the submit-edit-check.
- You probably need to follow the instructions in
Documentation/SubmittingPatches so that Junio will pay attention to the
patch.
Regards!
Luke
>
> Below are the patch and environment results:
>
>
> $ git config -l
> ...
> user.name=Loren A. Linden Levy
> git-p4.skipsubmitedit=true
> git-p4.skipsubmiteditcheck=true
> ...
>
> $ git format-patch origin/master --stdout
>
> From 16c4344de0047cbaf3381eca590a3e59b0d0a25c Mon Sep 17 00:00:00 2001
> From: "Loren A. Linden Levy"<lindenle@gmail.com>
> Date: Thu, 8 Sep 2011 13:37:22 -0700
> Subject: [PATCH] changed git-p4
>
> ---
> contrib/fast-import/git-p4 | 15 ++++++++++-----
> 1 files changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
> index 2f7b270..a438b3e 100755
> --- a/contrib/fast-import/git-p4
> +++ b/contrib/fast-import/git-p4
> @@ -935,18 +935,23 @@ class P4Submit(Command, P4UserMap):
> tmpFile.write(submitTemplate + separatorLine + diff +
> newdiff)
> tmpFile.close()
> mtime = os.stat(fileName).st_mtime
> - if os.environ.has_key("P4EDITOR"):
> - editor = os.environ.get("P4EDITOR")
> + if gitConfig("git-p4.skipSubmitEdit") == "true":
> + pass
> else:
> - editor = read_pipe("git var GIT_EDITOR").strip()
> - system(editor + " " + fileName)
> -
> + if os.environ.has_key("P4EDITOR"):
> + editor = os.environ.get("P4EDITOR")
> + else:
> + editor = read_pipe("git var GIT_EDITOR").strip()
> +
> + system(editor + " " + fileName)
> +
> if gitConfig("git-p4.skipSubmitEditCheck") == "true":
> checkModTime = False
> else:
> checkModTime = True
>
> response = "y"
> +
> if checkModTime and (os.stat(fileName).st_mtime<= mtime):
> response = "x"
> while response != "y" and response != "n":
^ permalink raw reply
* Re: What's cooking in git.git (Sep 2011, #03; Sun, 11)
From: Matthieu Moy @ 2011-09-12 7:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwrde9t6h.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> * jn/remote-helpers-doc (2011-09-01) 3 commits
> - (short) documentation for the testgit remote helper
> - Documentation/git-remote-helpers: explain how import works with multiple refs
> - Documentation/remote-helpers: explain capabilities first
>
> Not urgent.
I agree it's not urgent, but this serie doesn't touch the code itself,
so it should be pretty harmless. It fixes some relatively important
documentation issues, and a nice side effect of putting them in a
release soon would be to update the doc available at
http://www.kernel.org/pub/software/scm/git/docs/git-remote-helpers.html
(when kernel.org is not down).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* What's cooking in git.git (Sep 2011, #03; Sun, 11)
From: Junio C Hamano @ 2011-09-12 6:21 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' while commits prefixed with '+' are in 'next'.
Some of the recent patches are fixes to new feature topics already merged
to "master" and are being fast tracked for 1.7.7-rc1, but otherwise
patches for new features and fixes to longstanding issues will stay in
'pu' or 'next' until the 1.7.7 final.
I was hoping that k.org would be back into healthy state soonish and that
is why I haven't tagged the -rc1 yet, but it has already been two weeks,
so sometime in the middle of the coming week -rc1 will happen with or
without k.org repository keeping in sync with us.
In the meantime, here are the repositories that have my integration
branches:
With maint, master, next, pu and todo:
url = git://repo.or.cz/alt-git.git
url = https://code.google.com/p/git-core/
With only maint and master:
url = git://git.sourceforge.jp/gitroot/git-core/git.git
url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
With all the topics and integration branches:
url = https://github.com/gitster/git
--------------------------------------------------
[New Topics]
* hl/iso8601-more-zone-formats (2011-09-09) 2 commits
- fixup? simplification and tightening
- date.c: Support iso8601 timezone formats
* jc/signed-push (2011-09-09) 7 commits
. push -s: support pre-receive-signature hook
. push -s: receiving end
. push -s: send signed push certificate
. push -s: skeleton
. refactor run_receive_hook()
- Split GPG interface into its own helper library
- send-pack: typofix error message
(this branch is tangled with jc/signed-push-3.)
This was the v2 that updated notes tree on the receiving end.
* jc/signed-push-3 (2011-09-09) 4 commits
- push -s: signed push
- rename "match_refs()" to "match_push_refs()"
- Split GPG interface into its own helper library
- send-pack: typofix error message
(this branch is tangled with jc/signed-push.)
This is the third edition, that moves the preparation of the notes tree to
the sending end.
* jc/run-receive-hook-cleanup (2011-09-09) 1 commit
- refactor run_receive_hook()
This is a remnant in the jc/signed-push topic that has become unnecessary
for the purpose of jc/signed-push-3, but is retained for its clean-up
value.
The corresponding one will be dropped when rebuilding the jc/signed-push
topic on top of this topic later.
* jk/for-each-ref (2011-09-08) 5 commits
- for-each-ref: add split message parts to %(contents:*).
- for-each-ref: handle multiline subjects like --pretty
- for-each-ref: refactor subject and body placeholder parsing
- t6300: add more body-parsing tests
- t7004: factor out gpg setup
* wh/normalize-alt-odb-path (2011-09-07) 1 commit
- sha1_file: normalize alt_odb path before comparing and storing
* fk/use-kwset-pickaxe-grep-f (2011-09-11) 2 commits
- obstack.c: Fix some sparse warnings
- sparse: Fix an "Using plain integer as NULL pointer" warning
* jc/make-static (2011-09-11) 2 commits
(merged to 'next' on 2011-09-11 at 2acb0af)
+ vcs-svn: remove unused functions and make some static
+ make-static: master
* jl/maint-fetch-submodule-check-fix (2011-09-09) 1 commit
- fetch: skip on-demand checking when no submodules are configured
* rj/quietly-create-dep-dir (2011-09-11) 1 commit
- Makefile: Make dependency directory creation less noisy
* js/cred-macos-x-keychain (2011-09-11) 1 commit
- contrib: add a credential helper for Mac OS X's keychain
(this branch uses jk/http-auth-keyring.)
* mh/check-ref-format (2011-09-11) 8 commits
- Add tools to avoid the use of unnormalized refnames.
- Do not allow ".lock" at the end of any refname component
- Add a library function normalize_refname()
- Change check_ref_format() to take a flags argument
- fixup asciidoc formatting
- git check-ref-format: add options --allow-onelevel and --refspec-pattern
- Change bad_ref_char() to return a boolean value
- t1402: add some more tests
* mz/remote-rename (2011-09-11) 4 commits
- remote: only update remote-tracking branch if updating refspec
- remote rename: warn when refspec was not updated
- remote: "rename o foo" should not rename ref "origin/bar"
- remote: write correct fetch spec when renaming remote 'remote'
* rj/maint-t9159-svn-rev-notation (2011-09-11) 1 commit
- t9159-*.sh: Add an svn version check
--------------------------------------------------
[Stalled]
* jk/add-i-hunk-filter (2011-07-27) 5 commits
(merged to 'next' on 2011-08-11 at 8ff9a56)
+ add--interactive: add option to autosplit hunks
+ add--interactive: allow negatation of hunk filters
+ add--interactive: allow hunk filtering on command line
+ add--interactive: factor out regex error handling
+ add--interactive: refactor patch mode argument processing
Needs documentation updates, tests, and integration with the higher level
callers, e.g. "git add -p".
* jh/receive-count-limit (2011-05-23) 10 commits
- receive-pack: Allow server to refuse pushes with too many objects
- pack-objects: Estimate pack size; abort early if pack size limit is exceeded
- send-pack/receive-pack: Allow server to refuse pushing too large packs
- pack-objects: Allow --max-pack-size to be used together with --stdout
- send-pack/receive-pack: Allow server to refuse pushes with too many commits
- pack-objects: Teach new option --max-commit-count, limiting #commits in pack
- receive-pack: Prepare for addition of the new 'limit-*' family of capabilities
- Tighten rules for matching server capabilities in server_supports()
- send-pack: Attempt to retrieve remote status even if pack-objects fails
- Update technical docs to reflect side-band-64k capability in receive-pack
Would need another round to separate per-pack and per-session limits.
* jm/mergetool-pathspec (2011-06-22) 2 commits
- mergetool: Don't assume paths are unmerged
- mergetool: Add tests for filename with whitespace
I think this is a good idea, but it probably needs a re-roll.
Cf. $gmane/176254, 176255, 166256
* jk/generation-numbers (2011-09-11) 8 commits
- metadata-cache.c: make two functions static
- limit "contains" traversals based on commit generation
- check commit generation cache validity against grafts
- pretty: support %G to show the generation number of a commit
- commit: add commit_generation function
- add metadata-cache infrastructure
- decorate: allow storing values instead of pointers
- Merge branch 'jk/tag-contains-ab' (early part) into HEAD
The initial "tag --contains" de-pessimization without need for generation
numbers is already in; backburnered.
* sr/transport-helper-fix-rfc (2011-07-19) 2 commits
- t5800: point out that deleting branches does not work
- t5800: document inability to push new branch with old content
* po/cygwin-backslash (2011-08-05) 2 commits
- On Cygwin support both UNIX and DOS style path-names
- git-compat-util: add generic find_last_dir_sep that respects is_dir_sep
I think a further refactoring (no, not my suggestion) was offered?
--------------------------------------------------
[Cooking]
* cb/common-prefix-unification (2011-09-11) 4 commits
- dir.c: make common_prefix_len() static
- rename pathspec_prefix() to common_prefix() and move to dir.[ch]
- consolidate pathspec_prefix and common_prefix
- remove prefix argument from pathspec_prefix
* cb/send-email-help (2011-09-05) 1 commit
- send-email: add option -h
* jc/fetch-pack-fsck-objects (2011-09-04) 3 commits
- test: fetch/receive with fsckobjects
- transfer.fsckobjects: unify fetch/receive.fsckobjects
- fetch.fsckobjects: verify downloaded objects
* jc/receive-verify (2011-09-09) 6 commits
- receive-pack: check connectivity before concluding "git push"
- check_everything_connected(): libify
- check_everything_connected(): refactor to use an iterator
- fetch: verify we have everything we need before updating our ref
- rev-list --verify-object
- list-objects: pass callback data to show_objects()
(this branch uses jc/traverse-commit-list; is tangled with jc/fetch-verify and jc/fetch-verify.)
* tr/doc-note-rewrite (2011-09-05) 1 commit
- Documentation: "on for all" configuration of notes.rewriteRef
It was questioned if the new text suggests a sane and safe thing to do.
* jc/request-pull-show-head (2011-09-06) 1 commit
- State what commit to expect in request-pull
* jn/maint-http-error-message (2011-09-06) 2 commits
- http: avoid empty error messages for some curl errors
- http: remove extra newline in error message
* bk/ancestry-path (2011-08-25) 3 commits
(merged to 'next' on 2011-09-02 at d05ba5d)
+ revision: do not include sibling history in --ancestry-path output
+ revision: keep track of the end-user input from the command line
+ rev-list: Demonstrate breakage with --ancestry-path --all
The topic came up a bit too late in the cycle.
Will cook for a while.
* mg/branch-list (2011-09-08) 6 commits
(merged to 'next' on 2011-09-11 at 20a9cdb)
+ branch: -v does not automatically imply --list
(merged to 'next' on 2011-09-02 at b818eae)
+ branch: allow pattern arguments
+ branch: introduce --list option
+ git-branch: introduce missing long forms for the options
+ git-tag: introduce long forms for the options
+ t6040: test branch -vv
Not urgent; the topic came up a bit too late in the cycle.
* mm/rebase-i-exec-edit (2011-08-26) 2 commits
(merged to 'next' on 2011-09-02 at e75b1b9)
+ rebase -i: notice and warn if "exec $cmd" modifies the index or the working tree
+ rebase -i: clean error message for --continue after failed exec
Not urgent; the topic came up a bit too late in the cycle.
* jk/default-attr (2011-08-26) 1 commit
- attr: map builtin userdiff drivers to well-known extensions
Not urgent; I fixed up the test breakage just for fun.
* hv/submodule-merge-search (2011-08-26) 5 commits
- submodule: Search for merges only at end of recursive merge
- allow multiple calls to submodule merge search for the same path
- submodule: Demonstrate known breakage during recursive merge
- push: Don't push a repository with unpushed submodules
(merged to 'next' on 2011-08-24 at 398e764)
+ push: teach --recurse-submodules the on-demand option
(this branch is tangled with fg/submodule-auto-push.)
Not urgent; the topic came up a bit too late in the cycle.
The bottom one needs to be replaced with a properly written commit log message.
* mm/mediawiki-as-a-remote (2011-09-01) 2 commits
- git-remote-mediawiki: allow push to set MediaWiki metadata
- Add a remote helper to interact with mediawiki (fetch & push)
Fun.
Not urgent; the topic came up a bit too late in the cycle.
* nd/maint-autofix-tag-in-head (2011-08-26) 3 commits
- Accept tags in HEAD or MERGE_HEAD
- merge: remove global variable head[]
- merge: keep stash[] a local variable
Probably needs a re-roll to aim a bit higher.
Not urgent; will not be in 1.7.7.
* bc/unstash-clean-crufts (2011-08-27) 4 commits
(merged to 'next' on 2011-09-02 at 7bfd66f)
+ git-stash: remove untracked/ignored directories when stashed
+ t/t3905: add missing '&&' linkage
+ git-stash.sh: fix typo in error message
+ t/t3905: use the name 'actual' for test output, swap arguments to test_cmp
Not urgent; the topic came up a bit too late in the cycle.
* da/make-auto-header-dependencies (2011-08-30) 1 commit
(merged to 'next' on 2011-09-02 at e04a4af)
+ Makefile: Improve compiler header dependency check
(this branch uses fk/make-auto-header-dependencies.)
Not urgent; will not be in 1.7.7.
* gb/am-hg-patch (2011-08-29) 1 commit
(merged to 'next' on 2011-09-02 at 3edfe4c)
+ am: preliminary support for hg patches
Not urgent; the topic came up a bit too late in the cycle.
* jc/diff-index-unpack (2011-08-29) 3 commits
(merged to 'next' on 2011-09-02 at 4206bd9)
+ diff-index: pass pathspec down to unpack-trees machinery
+ unpack-trees: allow pruning with pathspec
+ traverse_trees(): allow pruning with pathspec
Will cook for a while.
* jn/remote-helpers-doc (2011-09-01) 3 commits
- (short) documentation for the testgit remote helper
- Documentation/git-remote-helpers: explain how import works with multiple refs
- Documentation/remote-helpers: explain capabilities first
Not urgent.
* nm/grep-object-sha1-lock (2011-08-30) 1 commit
(merged to 'next' on 2011-09-02 at 336f57d)
+ grep: Fix race condition in delta_base_cache
Not urgent; the topic came up a bit too late in the cycle.
* tr/mergetool-valgrind (2011-08-30) 1 commit
(merged to 'next' on 2011-09-02 at f5f2c61)
+ Symlink mergetools scriptlets into valgrind wrappers
Not urgent; the topic came up a bit too late in the cycle.
* fg/submodule-auto-push (2011-09-11) 2 commits
(merged to 'next' on 2011-09-11 at 3fc86f7)
+ submodule.c: make two functions static
(merged to 'next' on 2011-08-24 at 398e764)
+ push: teach --recurse-submodules the on-demand option
(this branch is tangled with hv/submodule-merge-search.)
What the topic aims to achieve may make sense, but the implementation
looked somewhat suboptimal.
* jc/fetch-verify (2011-09-01) 3 commits
- fetch: verify we have everything we need before updating our ref
- rev-list --verify-object
- list-objects: pass callback data to show_objects()
(this branch uses jc/traverse-commit-list; is tangled with jc/receive-verify and jc/receive-verify.)
Make "git fetch" verify what it received a bit more carefully before
updating the refs in the receiving end.
Not urgent; the topic came up a bit too late in the cycle.
* jc/traverse-commit-list (2011-08-22) 3 commits
(merged to 'next' on 2011-08-24 at df50dd7)
+ revision.c: update show_object_with_name() without using malloc()
+ revision.c: add show_object_with_name() helper function
+ rev-list: fix finish_object() call
(this branch is used by jc/fetch-verify and jc/receive-verify.)
Not urgent; will not be in 1.7.7.
* fk/make-auto-header-dependencies (2011-08-18) 1 commit
(merged to 'next' on 2011-08-24 at 3da2c25)
+ Makefile: Use computed header dependencies if the compiler supports it
(this branch is used by da/make-auto-header-dependencies.)
Not urgent; will not be in 1.7.7.
* mh/iterate-refs (2011-09-11) 7 commits
- refs.c: make create_cached_refs() static
- Retain caches of submodule refs
- Store the submodule name in struct cached_refs
- Allocate cached_refs objects dynamically
- Change the signature of read_packed_refs()
- Access reference caches only through new function get_cached_refs()
- Extract a function clear_cached_refs()
I did not see anything fundamentally wrong with this series, but it was
unclear what the benefit of these changes are. If the series were to read
parts of the ref hierarchy (like refs/heads/) lazily, the story would
have been different, though.
Not urgent; will not be in 1.7.7.
* hv/submodule-update-none (2011-08-11) 2 commits
(merged to 'next' on 2011-08-24 at 5302fc1)
+ add update 'none' flag to disable update of submodule by default
+ submodule: move update configuration variable further up
Not urgent; will not be in 1.7.7.
* jc/lookup-object-hash (2011-08-11) 6 commits
(merged to 'next' on 2011-08-24 at 5825411)
+ object hash: replace linear probing with 4-way cuckoo hashing
+ object hash: we know the table size is a power of two
+ object hash: next_size() helper for readability
+ pack-objects --count-only
+ object.c: remove duplicated code for object hashing
+ object.c: code movement for readability
I do not think there is anything fundamentally wrong with this series, but
the risk of breakage far outweighs observed performance gain in one
particular workload. Will keep it in 'next' at least for one cycle.
Not urgent; will not be in 1.7.7.
* fg/submodule-git-file-git-dir (2011-08-22) 2 commits
(merged to 'next' on 2011-08-23 at 762194e)
+ Move git-dir for submodules
+ rev-parse: add option --resolve-git-dir <path>
I do not think there is anything fundamentally wrong with this series, but
the risk of breakage outweighs any benefit for having this new
feature. Will keep it in 'next' at least for one cycle.
Not urgent; will not be in 1.7.7.
* jk/http-auth-keyring (2011-09-11) 14 commits
(merged to 'next' on 2011-09-11 at 491ce6a)
+ credentials: make credential_fill_gently() static
(merged to 'next' on 2011-08-03 at b06e80e)
+ credentials: add "getpass" helper
+ credentials: add "store" helper
+ credentials: add "cache" helper
+ docs: end-user documentation for the credential subsystem
+ http: use hostname in credential description
+ allow the user to configure credential helpers
+ look for credentials in config before prompting
+ http: use credential API to get passwords
+ introduce credentials API
+ http: retry authentication failures for all http requests
+ remote-curl: don't retry auth failures with dumb protocol
+ improve httpd auth tests
+ url: decode buffers that are not NUL-terminated
(this branch is used by js/cred-macos-x-keychain.)
Looked mostly reasonable except for the limitation that it is not clear
how to deal with a site at which a user needs to use different passwords
for different repositories. Will keep it in "next" at least for one cycle,
until we start hearing real-world success reports on the list.
Not urgent; will not be in 1.7.7.
* rr/revert-cherry-pick-continue (2011-09-11) 19 commits
(merged to 'next' on 2011-09-11 at 7d78054)
+ builtin/revert.c: make commit_list_append() static
(merged to 'next' on 2011-08-24 at 712c115)
+ revert: Propagate errors upwards from do_pick_commit
+ revert: Introduce --continue to continue the operation
+ revert: Don't implicitly stomp pending sequencer operation
+ revert: Remove sequencer state when no commits are pending
+ reset: Make reset remove the sequencer state
+ revert: Introduce --reset to remove sequencer state
+ revert: Make pick_commits functionally act on a commit list
+ revert: Save command-line options for continuing operation
+ revert: Save data for continuing after conflict resolution
+ revert: Don't create invalid replay_opts in parse_args
+ revert: Separate cmdline parsing from functional code
+ revert: Introduce struct to keep command-line options
+ revert: Eliminate global "commit" variable
+ revert: Rename no_replay to record_origin
+ revert: Don't check lone argument in get_encoding
+ revert: Simplify and inline add_message_to_msg
+ config: Introduce functions to write non-standard file
+ advice: Introduce error_resolve_conflict
Will keep it in 'next' at least for one cycle.
Not urgent; will not be in 1.7.7.
--------------------------------------------------
[Discarded]
* jk/pager-with-alias (2011-08-19) 1 commit
. support pager.* for aliases
* cb/maint-quiet-push (2011-09-05) 4 commits
. t5541: avoid TAP test miscounting
. push: old receive-pack does not understand --quiet
. fix push --quiet via http
. tests for push --quiet
Dropped for rerolling after 1.7.7 cycle.
^ permalink raw reply
* Re: [PATCH 1/3] make-static: master
From: Ramkumar Ramachandra @ 2011-09-12 6:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ramsay Jones, GIT Mailing-list
In-Reply-To: <7vhb4in4j7.fsf@alter.siamese.dyndns.org>
Hi Junio,
Junio C Hamano writes:
> Many symbols that are exported to the global scope do not have to be.
>
> Signed-off-by: Junio C Hamano <junio@pobox.com>
> ---
> * To be applied on top of 3793ac5 (RelNotes/1.7.7: minor fixes, 2011-09-07)
> [...]
Awesome! I've seen many similar "make-static" patches come up on the
list, but turned down due to code churn issues. I'm happy to finally
see it being merged. What does this mean: should we try to get such
things merged immediately after a release? On a related note: I'd
also like to know if we can do anything about restructuring the source
tree (moving files around, renaming etc).
Minor nit: I can see commits with "Author: Junio C Hamano
<gitster@pobox.com>", and "Signed-off-by: Junio C Hamano
<junio@pobox.com>" on both 'pu' and 'next'. They seem to be different
people at first glance :)
Thanks.
-- Ram
^ permalink raw reply
* Re: [PATCH] send-mail: Add option to sleep between sending each email.
From: Ramkumar Ramachandra @ 2011-09-12 5:34 UTC (permalink / raw)
To: Junio C Hamano
Cc: Matthieu Moy, Georgi Chorbadzhiyski, Git List, Michael Witten
In-Reply-To: <7vbouvx8j5.fsf@alter.siamese.dyndns.org>
Hi,
Michael Witten writes:
> [...]
> From a quick glance, my patch would appear to have become more advanced,
> as per your own request, Junio:
>
> Message-ID: <7vskkh1va5.fsf@gitster.siamese.dyndns.org>
> http://thread.gmane.org/gmane.comp.version-control.git/116083
Wow, that was over two years ago. I only started contributing to Git
a little over a year and a half ago: no wonder I missed the
discussion. Thanks for digging it out.
Junio C Hamano writes:
> [...]
> IIRC, "git send-email" does its best to force ordering by assigning
> monotonically increasing timestamps on the Date: field, so that the
> recipients can sort the messages based on it, in addition to the
> In-Reply-To field to help threading. I personally do not think there is
> anything more than that that should done in the program.
I agree with Junio here. However, I realize that the patch adds some
value: perhaps we can have it as a script under 'contrib/'?
Thanks.
-- Ram
^ permalink raw reply
* Re: [PATCH] SubmittingPathces: remove Cogito reference
From: Ramkumar Ramachandra @ 2011-09-12 5:25 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Junio C Hamano, Git List
In-Reply-To: <1315744690-6477-1-git-send-email-srabbelier@gmail.com>
Hi Sverre,
Sverre Rabbelier writes:
> Subject: [PATCH] SubmittingPathces: remove Cogito reference
You misspelled SubmittingPatches there. Also, I feel that the subject
is a little misleading. Perhaps something like this instead?
SubmittingPatches: Remove diff tool examples
> [...]
Looks alright otherwise.
Thanks.
-- Ram
^ permalink raw reply
* Re: [PATCH v2 0/7] Improved infrastructure for refname normalization
From: Junio C Hamano @ 2011-09-12 4:28 UTC (permalink / raw)
To: Michael Haggerty; +Cc: git, cmn, A Large Angry SCM
In-Reply-To: <1315637443-14012-1-git-send-email-mhagger@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
> Patch series re-roll:
Thanks for working on this. I very much like the general direction of the
series, the strategy to avoid wholesale audit of the callers and marking
the places that needs fixing with "_unsafe()".
There were a few minor things that looked worth mentioning while
reviewing, though.
- (style) You seem to be fond of pre-increment a lot, but in general our
codebase prefers post-increment especially when the end result does not
make any difference, e.g.
for (i = 1; ...; ++i) {
...
- (series structure) It might make the series progress easier to follow
if you introduced check_ref_format_unsafe() in the same commit where
you change check_ref_format() to take flags parameter.
^ permalink raw reply
* Business transaction.
From: Mr. Daniel Tsai @ 2011-09-11 14:35 UTC (permalink / raw)
To: danieltsai0
Hello my friend. My name is Daniel Tsai and
I live in Hong Kong. I want you to be my
partner in a business transaction of 44.5Million USD.
If you are interested for more details,
you MUST reply me to my private email address:
danieltsai11@yahoo.com.hk or danieltsai95@aol.com
when I get your message, I will tell you what
to do next. Thank you.
Mr. Daniel Tsai
^ permalink raw reply
* Re: [PATCH] Support empty blob in fsck --lost-found
From: Junio C Hamano @ 2011-09-12 1:10 UTC (permalink / raw)
To: BJ Hargrave; +Cc: git
In-Reply-To: <348F09EE-5EE2-4F3E-B1B1-6FD34BDBD117@bjhargrave.com>
BJ Hargrave <bj@bjhargrave.com> writes:
> On Sep 11, 2011, at 16:43 , Junio C Hamano wrote:
>
>> Funny.
>>
>> I am sure we fixed a similar breakage elsewhere a few years ago, by
>> swapping the size and nmemb to the calls (i.e. instead of writing one
>> block of "size" bytes, you could write "size" blocks of 1-byte) and making
>> sure fwrite() reports the number of items. IOW
>>
>> if (buf && fwrite(buf, 1, size, f) != size)
>> die_errno("Could not write '%s'", filename);
>>
>
> Do you want me to resubmit the patch using this technique instead of the size > 0 check?
Not really.
I am not sure when/why we would try to write an empty blob out to begin
with...
^ permalink raw reply
* Re: [PATCH 1/3] sparse: Fix some "symbol not declared" warnings
From: Junio C Hamano @ 2011-09-12 0:06 UTC (permalink / raw)
To: GIT Mailing-list; +Cc: Ramsay Jones
In-Reply-To: <7vobyqn4jh.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> There are many others that can be identified by running the attached
> script after you build your git. I'll follow this message up with three
> consolidated patches, but the latter two needs to be split into smaller
> pieces to be either queued on top (for topics in next) or squashed into
> (for topics in pu), which I am not going to do myself today (hint, hint).
Well, I lied ;-) I've separated things out, queued fix-ups at the tips of
branches, and pushed out the integration result to the public repositories
(other than k.org that seems to be still down).
^ permalink raw reply
* Recorded talk on using git-svn
From: Thomas Ferris Nicolaisen @ 2011-09-11 22:14 UTC (permalink / raw)
To: git
Hi,
I just did a talk at JavaZone this week about using git-svn, and the
recording is now online:
http://vimeo.com/28762003
The demo features normal use of git-svn, plus setup of a git-svn
mirror, using Jenkins to automatically sync the git mirror, and then
putting the mirror on Github.
Maybe some here will find it useful.
^ 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