* [PATCH 3/4] t4014: "no-add-headers" is actually called "no-add-header"
From: Thomas Rast @ 2011-08-29 20:10 UTC (permalink / raw)
To: git; +Cc: Stephen Boyd, Junio C Hamano
In-Reply-To: <bbfb7190ca0125798417f57f4d33b5443257e478.1314648438.git.trast@student.ethz.ch>
Since c426003 (format-patch: add --no-cc, --no-to, and
--no-add-headers, 2010-03-07) the tests have checked for an option
called --no-add-headers introduced by letting the user negate
--add-header.
However, the parseopt machinery does not automatically pluralize
anything, so it is in fact called --no-add-header.
Since the option never worked, is not documented anywhere, and
implementing an actual --no-add-headers would lead to silly code
complications, we just adapt the test to the code.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
t/t4014-format-patch.sh | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh
index a45d4fb..5cbc066 100755
--- a/t/t4014-format-patch.sh
+++ b/t/t4014-format-patch.sh
@@ -219,11 +219,11 @@ test_expect_success '--no-cc overrides config.cc' '
! grep "^Cc: C. E. Cipient <rcipient@example.com>\$" patch12
'
-test_expect_failure '--no-add-headers overrides config.headers' '
+test_expect_success '--no-add-header overrides config.headers' '
git config --replace-all format.headers \
"Header1: B. E. Cipient <rcipient@example.com>" &&
- git format-patch --no-add-headers --stdout master..side |
+ git format-patch --no-add-header --stdout master..side |
sed -e "/^\$/q" >patch13 &&
check_patch patch13 &&
! grep "^Header1: B. E. Cipient <rcipient@example.com>\$" patch13
--
1.7.7.rc0.370.gdcae57
^ permalink raw reply related
* [PATCH 2/4] t4014: invoke format-patch with --stdout where intended
From: Thomas Rast @ 2011-08-29 20:10 UTC (permalink / raw)
To: git; +Cc: Stephen Boyd, Junio C Hamano
In-Reply-To: <bbfb7190ca0125798417f57f4d33b5443257e478.1314648438.git.trast@student.ethz.ch>
The test wrote something along the lines of 0001-foo.patch to output,
which of course never contained a signature. Luckily the tested
behaviour is actually present.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
t/t4014-format-patch.sh | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh
index b4d4207..a45d4fb 100755
--- a/t/t4014-format-patch.sh
+++ b/t/t4014-format-patch.sh
@@ -698,8 +698,8 @@ test_expect_success 'format-patch --no-signature supresses signatures' '
! grep "^-- \$" output
'
-test_expect_failure 'format-patch --signature="" supresses signatures' '
- git format-patch --signature="" -1 >output &&
+test_expect_success 'format-patch --signature="" supresses signatures' '
+ git format-patch --stdout --signature="" -1 >output &&
check_patch output &&
! grep "^-- \$" output
'
--
1.7.7.rc0.370.gdcae57
^ permalink raw reply related
* [PATCH 1/4] t4014: check for empty files from git format-patch --stdout
From: Thomas Rast @ 2011-08-29 20:10 UTC (permalink / raw)
To: git; +Cc: Stephen Boyd, Junio C Hamano
Most kinds of failure in 'git format-patch --stdout >output' will
result in an empty 'output'. This slips past checks that only verify
absence of output, such as the '! grep ...' that are quite prevalent
in t4014.
Introduce a helper check_patch() that checks that at least From, Date
and Subject are present, thus making sure it looks vaguely like a
patch (or cover letter) email. Then insert calls to it in all tests
that do have positive checks for content.
This makes two of the tests fail. Mark them as such; they'll be
fixed in a moment.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
I noticed "fatal: unrecognized argument: --no-add-headers" in the
slow-moving 'make valgrind' output, and unearthed some more
problems... The other three patches are a corollary of this.
t/t4014-format-patch.sh | 21 +++++++++++++++++++--
1 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh
index 92248d2..b4d4207 100755
--- a/t/t4014-format-patch.sh
+++ b/t/t4014-format-patch.sh
@@ -179,12 +179,21 @@ test_expect_success 'configuration To: header' '
grep "^To: R. E. Cipient <rcipient@example.com>\$" patch9
'
+# check_patch <patch>: Verify that <patch> looks like a half-sane
+# patch email to avoid a false positive with !grep
+check_patch () {
+ grep -e "^From:" "$1" &&
+ grep -e "^Date:" "$1" &&
+ grep -e "^Subject:" "$1"
+}
+
test_expect_success '--no-to overrides config.to' '
git config --replace-all format.to \
"R. E. Cipient <rcipient@example.com>" &&
git format-patch --no-to --stdout master..side |
sed -e "/^\$/q" >patch10 &&
+ check_patch patch10 &&
! grep "^To: R. E. Cipient <rcipient@example.com>\$" patch10
'
@@ -195,6 +204,7 @@ test_expect_success '--no-to and --to replaces config.to' '
git format-patch --no-to --to="Someone Else <else@out.there>" \
--stdout master..side |
sed -e "/^\$/q" >patch11 &&
+ check_patch patch11 &&
! grep "^To: Someone <someone@out.there>\$" patch11 &&
grep "^To: Someone Else <else@out.there>\$" patch11
'
@@ -205,15 +215,17 @@ test_expect_success '--no-cc overrides config.cc' '
"C. E. Cipient <rcipient@example.com>" &&
git format-patch --no-cc --stdout master..side |
sed -e "/^\$/q" >patch12 &&
+ check_patch patch12 &&
! grep "^Cc: C. E. Cipient <rcipient@example.com>\$" patch12
'
-test_expect_success '--no-add-headers overrides config.headers' '
+test_expect_failure '--no-add-headers overrides config.headers' '
git config --replace-all format.headers \
"Header1: B. E. Cipient <rcipient@example.com>" &&
git format-patch --no-add-headers --stdout master..side |
sed -e "/^\$/q" >patch13 &&
+ check_patch patch13 &&
! grep "^Header1: B. E. Cipient <rcipient@example.com>\$" patch13
'
@@ -480,6 +492,7 @@ test_expect_success 'cover-letter inherits diff options' '
git mv file foo &&
git commit -m foo &&
git format-patch --cover-letter -1 &&
+ check_patch 0000-cover-letter.patch &&
! grep "file => foo .* 0 *\$" 0000-cover-letter.patch &&
git format-patch --cover-letter -1 -M &&
grep "file => foo .* 0 *\$" 0000-cover-letter.patch
@@ -657,6 +670,7 @@ test_expect_success 'format-patch --no-signature ignores format.signature' '
git config format.signature "config sig" &&
git format-patch --stdout --signature="my sig" --no-signature \
-1 >output &&
+ check_patch output &&
! grep "config sig" output &&
! grep "my sig" output &&
! grep "^-- \$" output
@@ -673,17 +687,20 @@ test_expect_success 'format-patch --signature --cover-letter' '
test_expect_success 'format.signature="" supresses signatures' '
git config format.signature "" &&
git format-patch --stdout -1 >output &&
+ check_patch output &&
! grep "^-- \$" output
'
test_expect_success 'format-patch --no-signature supresses signatures' '
git config --unset-all format.signature &&
git format-patch --stdout --no-signature -1 >output &&
+ check_patch output &&
! grep "^-- \$" output
'
-test_expect_success 'format-patch --signature="" supresses signatures' '
+test_expect_failure 'format-patch --signature="" supresses signatures' '
git format-patch --signature="" -1 >output &&
+ check_patch output &&
! grep "^-- \$" output
'
--
1.7.7.rc0.370.gdcae57
^ permalink raw reply related
* [PATCH] t6030: use $SHELL_PATH to invoke user's preferred shell instead of bare sh
From: Brandon Casey @ 2011-08-29 20:09 UTC (permalink / raw)
To: gitster; +Cc: git, Brandon Casey
From: Brandon Casey <drafnel@gmail.com>
Some platforms (IRIX, Solaris) provide an ancient /bin/sh which chokes on
modern shell syntax like $(). SHELL_PATH is provided to allow the user to
specify a working sh, let's use it here.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
t/t6030-bisect-porcelain.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/t/t6030-bisect-porcelain.sh b/t/t6030-bisect-porcelain.sh
index 62125ec..c53af62 100755
--- a/t/t6030-bisect-porcelain.sh
+++ b/t/t6030-bisect-porcelain.sh
@@ -732,7 +732,7 @@ test_expect_success 'bisect: demonstrate identification of damage boundary' "
git bisect reset &&
git checkout broken &&
git bisect start broken master --no-checkout &&
- git bisect run sh -c '
+ git bisect run \"$SHELL_PATH\" -c '
GOOD=\$(git for-each-ref \"--format=%(objectname)\" refs/bisect/good-*) &&
git rev-list --objects BISECT_HEAD --not \$GOOD >tmp.\$\$ &&
git pack-objects --stdout >/dev/null < tmp.\$\$
--
1.7.6.1
^ permalink raw reply related
* [PATCH] Use memmove in ident_to_git
From: trast @ 2011-08-29 20:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Pierre Habouzit, Thomas Rast
From: Thomas Rast <trast@student.ethz.ch>
convert_to_git sets src=dst->buf if any of the preceding conversions
actually did any work. Thus in ident_to_git we have to use memmove
instead of memcpy as far as src->dst copying is concerned.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Valgrind intermittently detected this for me in t0021, hence the
patch. As far as I'm aware it has been broken since the rewrite to
memcpy back in 5ecd293 (Rewrite convert_to_{git,working_tree} to use
strbuf's., 2007-09-16). It probably never really mattered as all
involved copies are towards lower addresses (content is only removed)
and thus a straightforward memcpy operation will do the right thing by
accident.
convert.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/convert.c b/convert.c
index 416bf83..3bb5a4d 100644
--- a/convert.c
+++ b/convert.c
@@ -533,7 +533,7 @@ static int ident_to_git(const char *path, const char *src, size_t len,
dollar = memchr(src, '$', len);
if (!dollar)
break;
- memcpy(dst, src, dollar + 1 - src);
+ memmove(dst, src, dollar + 1 - src);
dst += dollar + 1 - src;
len -= dollar + 1 - src;
src = dollar + 1;
@@ -553,7 +553,7 @@ static int ident_to_git(const char *path, const char *src, size_t len,
src = dollar + 1;
}
}
- memcpy(dst, src, len);
+ memmove(dst, src, len);
strbuf_setlen(buf, dst + len - buf->buf);
return 1;
}
--
1.7.7.rc0.370.gdcae57
^ permalink raw reply related
* Re: [PATCH v2 1/2] check-ref-format --print: Normalize refnames that start with slashes
From: Jeff King @ 2011-08-29 20:02 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, Michael Haggerty, git, cmn
In-Reply-To: <4E5BEF47.5020608@kdbg.org>
On Mon, Aug 29, 2011 at 09:57:59PM +0200, Johannes Sixt wrote:
> Am 29.08.2011 20:50, schrieb Jeff King:
> > Have you considered publishing the
> > tips of topic branches you apply?
>
> Try 'git remote add github git://github.com/gitster/git' and drop your
> jaws on the wealth of branches you get on every 'git fetch github'.
Hmph. I had no idea that existed. Searching the list, it was mentioned
in a What's Cooking in May 2010.
-Peff
^ permalink raw reply
* Re: [PATCH v2 1/2] check-ref-format --print: Normalize refnames that start with slashes
From: Johannes Sixt @ 2011-08-29 19:57 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Michael Haggerty, git, cmn
In-Reply-To: <20110829185011.GC756@sigill.intra.peff.net>
Am 29.08.2011 20:50, schrieb Jeff King:
> Have you considered publishing the
> tips of topic branches you apply?
Try 'git remote add github git://github.com/gitster/git' and drop your
jaws on the wealth of branches you get on every 'git fetch github'.
-- Hannes
^ permalink raw reply
* Re: More formatting with 'git tag -l'
From: Jeff King @ 2011-08-29 19:36 UTC (permalink / raw)
To: Michał Górny; +Cc: git
In-Reply-To: <20110829211018.2ce4ebab@pomiocik.lan>
On Mon, Aug 29, 2011 at 09:10:18PM +0200, Michał Górny wrote:
> Would it be feasible to add more formatting options to 'git tag -l'.
> Right now, it's just '-n' but if more formatting options were added,
> I think I could use annotated tags as a nice source for autogenerated
> 'NEWS' file.
>
> What I am most concerned about is the date of last commit contained
> in the tag. Having an option to format each printed tag and use that
> information along with tag details in a format string (like the one
> used by 'git log') would be great.
You can do something similar with 'git for-each-ref', which is probably
what you should be using if you are scripting, anyway (as it is
"plumbing" and guaranteed not to change in future releases). Something
like:
FORMAT='%(refname:short)
%(taggerdate)
%(subject)'
git for-each-ref --format="$FORMAT" refs/tags/
If you want to do more complex things, try the "--shell" option (or
--perl, --python, etc), which makes it easy to write little scriptlets
in your format, like:
FORMAT='
REF=%(refname:short)
TDATE=%(taggerdate)
CDATE=%(committerdate)
if test -z "$TDATE"; then
echo "$REF: unannotated tag, commit date is $CDATE"
else
echo "$REF: annotated tag, tag date is $TDATE"
fi
'
git for-each-ref --shell --format="$FORMAT" refs/tags/ | sh
See "git help for-each-ref" for more discussion and examples.
-Peff
^ permalink raw reply
* Re: git bug reporting
From: Bryan Jacobs @ 2011-08-29 19:34 UTC (permalink / raw)
To: Jeff King; +Cc: Scott Chacon, git
In-Reply-To: <20110829192618.GF756@sigill.intra.peff.net>
On Mon, 29 Aug 2011 15:26:18 -0400
Jeff King <peff@peff.net> wrote:
> On Mon, Aug 29, 2011 at 01:20:52PM -0400, Bryan Jacobs wrote:
>
> > Dear git Developers,
> >
> > Apologies if this is not the right forum for bug reports. I was
> > unable to find a Bugzilla/Redmine/Flyspray instance for issue
> > maintenance, nor some "proper procedure" on the git web page.
>
> Yes, this is the right place. This question seems to be coming up a
> lot lately. And indeed, looking at the webpage and the wiki, we are
> not very clear that the mailing list is the place for such things.
>
> Do you mind telling us where you looked? That will give us at least
> one spot that we know should be more clear. :)
I looked at the git-scm.com main page, the "documentation" sub-page,
the wiki front page, and googled the site for terms like "issue tracker"
and "bug reports", then read the FAQ.
> In the meantime, I've updated:
>
> 1. The GitCommunity wiki page to mention that bug reports should go
> to the list.
>
> 2. Added an entry "How do I report a bug in git?" to the FAQ on the
> wiki.
>
> 3. Sent Scott a patch for git-scm.org to mention bug reporting under
> the big "Got questions" banner on the front page that points
> people to the mailing list. Pull request is here:
>
> https://github.com/schacon/gitscm/pull/11
>
> It may make sense to have a specific page on reporting bugs, and
> link to it via a bigger "how to report bugs" somewhere on the
> front page of git-scm.org.
Thank you very much for your efforts. It looks like you hit all but one
of the places I looked. I agree that having a link from some part of the
git-scm landing page would make sense, that's common practice for
software projects and seems to me a logical place for it. I (obviously)
read the text under the "got questions" bit; it was what sent me to
this list. If it had said "report a bug here" I would have felt more
confident about sending this message.
Bryan Jacobs
^ permalink raw reply
* git bug reporting
From: Jeff King @ 2011-08-29 19:26 UTC (permalink / raw)
To: Bryan Jacobs; +Cc: Scott Chacon, git
In-Reply-To: <20110829132052.0ad7a088@robyn.woti.com>
On Mon, Aug 29, 2011 at 01:20:52PM -0400, Bryan Jacobs wrote:
> Dear git Developers,
>
> Apologies if this is not the right forum for bug reports. I was unable
> to find a Bugzilla/Redmine/Flyspray instance for issue maintenance, nor
> some "proper procedure" on the git web page.
Yes, this is the right place. This question seems to be coming up a lot
lately. And indeed, looking at the webpage and the wiki, we are not very
clear that the mailing list is the place for such things.
Do you mind telling us where you looked? That will give us at least one
spot that we know should be more clear. :)
In the meantime, I've updated:
1. The GitCommunity wiki page to mention that bug reports should go
to the list.
2. Added an entry "How do I report a bug in git?" to the FAQ on the
wiki.
3. Sent Scott a patch for git-scm.org to mention bug reporting under
the big "Got questions" banner on the front page that points people
to the mailing list. Pull request is here:
https://github.com/schacon/gitscm/pull/11
It may make sense to have a specific page on reporting bugs, and
link to it via a bigger "how to report bugs" somewhere on the front
page of git-scm.org.
-Peff
^ permalink raw reply
* More formatting with 'git tag -l'
From: Michał Górny @ 2011-08-29 19:10 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 519 bytes --]
Hello,
Would it be feasible to add more formatting options to 'git tag -l'.
Right now, it's just '-n' but if more formatting options were added,
I think I could use annotated tags as a nice source for autogenerated
'NEWS' file.
What I am most concerned about is the date of last commit contained
in the tag. Having an option to format each printed tag and use that
information along with tag details in a format string (like the one
used by 'git log') would be great.
--
Best regards,
Michał Górny
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/2] check-ref-format --print: Normalize refnames that start with slashes
From: Jeff King @ 2011-08-29 19:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael Haggerty, git, cmn
In-Reply-To: <20110829185011.GC756@sigill.intra.peff.net>
On Mon, Aug 29, 2011 at 02:50:12PM -0400, Jeff King wrote:
> 3. Having better tool support for comparing two sets of commits. The
> ideal interface (to me) for this workflow would be something like:
BTW, this discussion is obviously about comparing what was applied
upstream with what was submitted, but I think such a tool could have
other purposes, too. It should be able to provide a much nicer interdiff
between two versions of the same series (e.g., for reviewers looking at
a re-roll). You could even use it as maintainer to apply a re-roll,
giving you a chance to review the differences as you apply.
-Peff
^ permalink raw reply
* Re: Idea: "git format-patch" should get more information out of git
From: Jeff King @ 2011-08-29 18:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael Haggerty, git, Johan Herland, Jonathan Nieder
In-Reply-To: <7v1uw69h96.fsf@alter.siamese.dyndns.org>
On Sat, Aug 27, 2011 at 11:34:13PM -0700, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
> > Michael Haggerty <mhagger@alum.mit.edu> writes:
> >
> >> 4. There is no place to store the "additional information" (the part
> >> that comes in patch emails between the "---" and the diffstat) while
> >> working on the patch series;...
> >
> > I thought there was a RFC floating around to do this using notes and also
> > teach it to "commit -e" a few months ago? I vaguelly recall that Peff and
> > one of the J's were involved, so I am CC'ing them.
>
> Also, when I prepare a commit to be sent with an additional piece of
> information, I often write "---" and the additional message after my
> S-o-b: line while preparing the commit log message. Unlike format-patch
> that strips that off, commit keeps it, which is handy.
After playing around a bit with my earlier series, I made the
realization (perhaps obvious to others :) ), that if you are in a
pure-patch workflow, keeping the "---" in your commit message locally is
much simpler. It follows the commit around through rebases
automatically, it gets put into format-patch output automatically, and
so forth.
The only real downside is that you can never tell git "don't show me the
cover letter cruft". Which is probably OK for your own local patches.
But the point of the "---" is that information should never make it into
a repo, which means in any workflow that involves pulling actual git
commits, it won't work (after reading Michael's response in another
thread, though, I think he would be interested in a hybrid
pull-or-apply-via-mail system).
-Peff
^ permalink raw reply
* Re: [PATCH v2 1/2] check-ref-format --print: Normalize refnames that start with slashes
From: Jeff King @ 2011-08-29 18:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael Haggerty, git, cmn
In-Reply-To: <7vty92adv0.fsf@alter.siamese.dyndns.org>
On Sat, Aug 27, 2011 at 11:30:26AM -0700, Junio C Hamano wrote:
> It sometimes gets frustrating to see a re-rolled submission that ignores
> the fix-ups to messages and patches I make locally before queued to 'pu'.
>
> It is easy for me to say that they should fetch 'pu' to see what is queued
> before resubmitting, but I've been wondering if there is a better way to
> communicate back such differences, so that submitters can easily sanity
> check to see if my fix-ups are sensible, and to ensure that the re-rolled
> patches do not discard them by mistake before submitting.
FWIW, I never do this, nor did I realize I was expected to. It takes
effort on the part of the submitter, which means they're probably not
inclined to do so unless there are changes that they know are pending.
I.e., if I see changes as replies on the list, I grab them and put them
into my re-roll. But I am not in the habit of poking through pu, trying
to match up equivalent patches, and then comparing them against my
versions, just on the off chance that some change has been made that
wasn't mentioned on the list. I always assumed that you did one of:
1. Comment on the patch via email, just as any other reviewer, so it
can go into the re-roll.
2. Fix-up the patch or commit message during "am", with the assumption
that it is ready to be merged at least to "next", at which point
re-rolls are no longer OK, anyway.
I mentioned "it takes effort" above. I don't mean "submitters shouldn't
be expected to put in extra effort". But we should make sure the effort
is well-spent, which means:
1. Giving them some indication that you tweaked things during
application. It doesn't have to be an inclusive list. Even saying
"Thanks, applied with some spelling fixes" instead of your usual
"Thanks" is enough (actually, I think you frequently do so
already).
2. Having better tool support for picking out the topics. Right now
we don't know the name of the topic branch you choose without
hunting for it in pu (or seeing it later in a What's Cooking
message). And even if we do, picking the tip commit out of pu
requires a bit of scripting. Have you considered publishing the
tips of topic branches you apply? Probably it makes sense to keep
them out of refs/heads/ in git.git, but even having them available
in refs/topics/ would allow interested parties to fetch them.
3. Having better tool support for comparing two sets of commits. The
ideal interface (to me) for this workflow would be something like:
$ git compare-series my-topic origin/my-topic origin
Patch 1: first patch subject...OK
Patch 2: second patch subject...
diff --git a/hello.c b/hello.c
index cef8b34..4f08083 100644
--- a/hello.c
+++ b/hello.c
@@ -1,6 +1,6 @@
#include <stdio.h>
int main(void)
{
- printf("hello wrold\n!");
+ printf("hello world\n!");
return 0;
}
Accept change from upstream [y,n,q]?
Patch 3: third patch subject...
diff --git a/COMMIT_MSG b/COMMIT_MSG
index 54c8fa2..fd7b9be 100644
--- a/COMMIT_MSG
+++ b/COMMIT_MSG
@@ -1,3 +1,3 @@
third patch subject
-This patch has a commit message with a tpyo in it.
+This patch has a commit message with a typo in it.
Accept commit message update from upstream [y,n,q]?
where the implementation would be something like:
a. Get two series of commits as $3..$1 and $3..$2.
b. Try to match commits from series one to series two, ending up
with some ordered list of pairs like the one below (entries on
the left would be commit sha1s from series 1; entries on the
right would be commit sha1s from series 2).
(P1, P1) (an unmodified version of a patch)
(P2, P2') (a modified version of a patch)
(P3, ) (dropped P3 in series 2)
(, P4) (added P4 in series 2)
The matching would probably involve some text similarity
analysis of the commit messages (or possibly the patch
itself, though that can get confused if an early patch is
tweaked with a change that cascades through the series).
c. Do a sort of interactive rebase over this list. For unmodified
pairs, take the commit from either. For modified pairs,
checkout the commit from series 1, then "checkout -p" the
commit from series 2 on top of it. The resulting commit is
then applied to the intermediate rebase result. For modified
commit messages, do a "git add -p" in a one-off sub-repository
with only COMMIT_MSG in it, and then use the result as the
final commit message. For dropped patches, show the patch from
series 1 and say "Drop this patch?" For added patches, do the
same (but with "Add this patch?").
I'm not sure how reordering of patches would be handled, if at
all. Maybe just as a deletion and an addition.
Anyway, that's just an idea I had while writing this message. I wouldn't
be surprised if there are a ton of awful corner cases I didn't think
about, or that somebody has a much better way of accomplishing the same
thing.
I often end up with something close to this by rebasing my topic
branches on top of master. Once your version hits master, then I see
your changes as conflicts. It's a bit annoying, though, because the
conflicts are frequently annoying to resolve. E.g., you fix a typo in
the line, and then every patch in the series after that which modified
the same line (or even a nearby one) ends up conflicting.
-Peff
^ permalink raw reply
* Re: [PATCH 1/2] am: preliminary support for hg patches
From: Giuseppe Bilotta @ 2011-08-29 17:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v62lg6tr3.fsf@alter.siamese.dyndns.org>
On Mon, Aug 29, 2011 at 6:57 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
>
>> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
>
> I'll leave nitpicking of this patch and helping to improve it to people
> who actually have to deal with Hg generated patches for now.
[snip]
>> + # hg stores changeset metadata in #-commented lines preceding
>> + # the commit message and diff(s). The only metadata we care about
>> + # are the User and Date (Node ID and Parent are hashes which are
>> + # only relevant to the hg repository and thus not useful to us)
>> + # Since we cannot guarantee that the commit message is in git-friendly
>> + # format, we put no Subject: line and just consume all of the message
>> + # as the body
>
> Personally I am a bit worried about the phoney "diff --git" output Hg
> seems to (be able to) produce. Do they have "index ..." line that express
> the blob object names in git terms (implausible), for example? We _might_
> want to strip s/diff --git /diff / so that apply won't be confused if that
> turns out to be a problem.
Nope, it doesn't have index .... lines. Still, the patches seems to
apply correctly. Well, the couple of patches I tested did, at least,
even though they were marked as diff --git and they were lacking the
index ... lines.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: t0300-credentials: poll failed: invalid argument
From: Jeff King @ 2011-08-29 17:43 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Git List
In-Reply-To: <01E9C05C-A19D-45B0-B15D-DA6B911C11A9@silverinsanity.com>
On Mon, Aug 29, 2011 at 01:28:05PM -0400, Brian Gernhardt wrote:
> > Ugh, sorry, this is my fault. The check_expiration() function can return
> > a totally bogus value before we actually get any credentials.
> >
> > Does this patch fix it for you?
>
> Yes it does! Surprisingly enough, non-bogus parameters keeps poll
> from erroring with EINVAL. Funny that. ;-)
Great. I'm working on a few more patches on top of that topic, so I'll
add it to my list to send out in the next day or so.
-Peff
^ permalink raw reply
* Re: t0300-credentials: poll failed: invalid argument
From: Brian Gernhardt @ 2011-08-29 17:28 UTC (permalink / raw)
To: Jeff King; +Cc: Git List
In-Reply-To: <20110829171411.GB756@sigill.intra.peff.net>
On Aug 29, 2011, at 1:14 PM, Jeff King wrote:
> On Sun, Aug 28, 2011 at 12:40:56AM -0400, Brian Gernhardt wrote:
>
>> The only usage of poll I see in the credentials system is:
>>
>> credentials-cache--daemon.c
>> 177: if (poll(&pfd, 1, 1000 * wakeup) < 0) {
>>
>> My guess is that (1000 * wakeup) is more than INT_MAX and is becoming
>> negative as the man page for poll seems to indicate that it will fail
>> if timeout < -1.
>>
>> Does anyone familiar with the credentials daemon want to try to figure
>> out a reasonable fix?
>
> Ugh, sorry, this is my fault. The check_expiration() function can return
> a totally bogus value before we actually get any credentials.
>
> Does this patch fix it for you?
Yes it does! Surprisingly enough, non-bogus parameters keeps poll from erroring with EINVAL. Funny that. ;-)
Many thanks,
~~ Brian
^ permalink raw reply
* git-svn and mergeinfo
From: Bryan Jacobs @ 2011-08-29 17:20 UTC (permalink / raw)
To: git
Dear git Developers,
Apologies if this is not the right forum for bug reports. I was unable
to find a Bugzilla/Redmine/Flyspray instance for issue maintenance, nor
some "proper procedure" on the git web page.
I have been (ab)using git-svn for committing to a central SVN
repository while doing my work locally with git. To this end, I've
written a set of scripts and hooks which perform squash merges locally
and then dcommit them with proper svn:mergeinfo annotations. The final
result is the perfect appearance of having done a native SVN merge in
the central repository, while using only local git commands and
gaining the full benefit of git's conflict resolution and developer
convenience.
However, to make this work with git 1.7.6, I needed to make *one* change
to the git internals: --merge-info does not allow setting mergeinfo for
more than one branch. Because it's a complete overwrite operation
instead of an update, this is a serious issue preventing its use for
nontrivial branches.
Might I suggest adding a block like the following around line 552 of
git-svn?
if (defined($_merge_info))
{
$_merge_info =~ tr{ }{\n};
}
This will replace any spaces in --merge-info with newlines, allowing
specification of an svn:mergeinfo that contains merges from more than a
singe branch. So the user can provide "--merge-info
'/branch1:r2323-3849,r8888 /branch2:r9999'" and the like.
Thank you for your consideration. I am not subscribed to this list, so
if there are any replies, please copy my address.
Bryan Jacobs
^ permalink raw reply
* Re: What's the difference between `git show branch:file | diff -u - file` vs `git diff branch file`?
From: Junio C Hamano @ 2011-08-29 17:18 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Marat Radchenko, git
In-Reply-To: <CACsJy8Dar5i3Fn+rhOq78vdsqRL4D+RNUc5G64BM-6DvKC=L5w@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> That may explain it. "git diff <ref>" walks through the index, unpacks
> tree objects along the way, matches up entries with the same path from
> the branch, the index then feeds matching entries to diff function.
Yeah, that would explain it. The implementation of diff-index has changed
a few times and the latest incarnation is based on unpack-trees, _merging_
the tree and the index, introduced by d1f2d7e (Make run_diff_index() use
unpack_trees(), not read_tree(), 2008-01-19).
Of course the merge machinery does not know anything about pruning with
pathspec, so it is understandable (not justifiable) it would walk the full
tree.
Will try to find time this week to cook up something.
^ permalink raw reply
* Re: t0300-credentials: poll failed: invalid argument
From: Jeff King @ 2011-08-29 17:14 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Git List
In-Reply-To: <5C993C44-D045-4344-95C1-94D3E6DB0316@silverinsanity.com>
On Sun, Aug 28, 2011 at 12:40:56AM -0400, Brian Gernhardt wrote:
> The only usage of poll I see in the credentials system is:
>
> credentials-cache--daemon.c
> 177: if (poll(&pfd, 1, 1000 * wakeup) < 0) {
>
> My guess is that (1000 * wakeup) is more than INT_MAX and is becoming
> negative as the man page for poll seems to indicate that it will fail
> if timeout < -1.
>
> Does anyone familiar with the credentials daemon want to try to figure
> out a reasonable fix?
Ugh, sorry, this is my fault. The check_expiration() function can return
a totally bogus value before we actually get any credentials.
Does this patch fix it for you?
-- >8 --
Subject: [PATCH] credential-cache: fix expiration calculation corner cases
The main credential-cache daemon loop calls poll to wait for
a client or to trigger the expiration of credentials. When
the last credential we hold expires, we exit.
However, there is a corner case: when we first start up, we
have no credentials, and are waiting for a client to
provide us with one. In this case, we ended up handing
complete junk for the timeout argument to poll(). On some
systems, this caused us to just wait a long time for the
client (which usually showed up within a second or so). On
OS X, however, the system quite reasonably complained about
our junk value with EINVAL.
Fixing this is pretty straightforward; we just notice that
we have no entries to compare against. However, that bug was
covering up another one: our expiration calculation didn't
give clients a chance to actually connect and provide us
with a credential before we decided that we should exit
because we weren't holding any credentials!
The new algorithm is:
1. Sleep until it's time to expire the most recent
credential.
2. If we don't have any credentials yet, wait 30 seconds
for a client to contact us and give us one.
3. After expiring the last credential, wait 30 seconds for
a client to provide us with one.
Technically only parts (1) and (2) are needed to implement
the original intended behavior.
But (3) is a minor optimization that is made easy by the new
code. When a client gives us a credential, then removes it
(e.g., because it had a bogus password), and then gives us
another one, we used to exit, forcing the client to start a
new daemon instance. Instead, we can just reuse the existing
daemon instance.
Signed-off-by: Jeff King <peff@peff.net>
---
credential-cache--daemon.c | 23 +++++++++++++++++++++--
1 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/credential-cache--daemon.c b/credential-cache--daemon.c
index f520347..d6769b1 100644
--- a/credential-cache--daemon.c
+++ b/credential-cache--daemon.c
@@ -57,20 +57,33 @@ static void remove_credential(const struct credential *c)
static int check_expirations(void)
{
+ static unsigned long wait_for_entry_until;
int i = 0;
unsigned long now = time(NULL);
unsigned long next = (unsigned long)-1;
+ /*
+ * Initially give the client 30 seconds to actually contact us
+ * and store a credential before we decide there's no point in
+ * keeping the daemon around.
+ */
+ if (!wait_for_entry_until)
+ wait_for_entry_until = now + 30;
+
while (i < entries_nr) {
if (entries[i].expiration <= now) {
entries_nr--;
- if (!entries_nr)
- return 0;
free(entries[i].item.description);
free(entries[i].item.unique);
free(entries[i].item.username);
free(entries[i].item.password);
memcpy(&entries[i], &entries[entries_nr], sizeof(*entries));
+ /*
+ * Stick around 30 seconds in case a new credential
+ * shows up (e.g., because we just removed a failed
+ * one, and we will soon get the correct one).
+ */
+ wait_for_entry_until = now + 30;
}
else {
if (entries[i].expiration < next)
@@ -79,6 +92,12 @@ static int check_expirations(void)
}
}
+ if (!entries_nr) {
+ if (wait_for_entry_until <= now)
+ return 0;
+ next = wait_for_entry_until;
+ }
+
return next - now;
}
--
1.7.6.10.g62f04
^ permalink raw reply related
* Re: [PATCH 1/2] am: preliminary support for hg patches
From: Junio C Hamano @ 2011-08-29 16:57 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git
In-Reply-To: <1314636247-26125-2-git-send-email-giuseppe.bilotta@gmail.com>
Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
I'll leave nitpicking of this patch and helping to improve it to people
who actually have to deal with Hg generated patches for now.
> + hg)
> + this=0
> + for hg in "$@"
> + do
> + this=`expr "$this" + 1`
> + msgnum=`printf "%0${prec}d" $this`
> + # hg stores changeset metadata in #-commented lines preceding
> + # the commit message and diff(s). The only metadata we care about
> + # are the User and Date (Node ID and Parent are hashes which are
> + # only relevant to the hg repository and thus not useful to us)
> + # Since we cannot guarantee that the commit message is in git-friendly
> + # format, we put no Subject: line and just consume all of the message
> + # as the body
Personally I am a bit worried about the phoney "diff --git" output Hg
seems to (be able to) produce. Do they have "index ..." line that express
the blob object names in git terms (implausible), for example? We _might_
want to strip s/diff --git /diff / so that apply won't be confused if that
turns out to be a problem.
Thanks.
> + perl -M'POSIX qw(strftime)' -ne 'BEGIN { $subject = 0 }
> + if ($subject) { print ; }
> + elsif (/^\# User /) { s/\# User/From:/ ; print ; }
> + elsif (/^\# Date /) {
> + my ($hashsign, $str, $time, $tz) = split ;
> + $tz = sprintf "%+05d", (0-$tz)/36;
> + print "Date: " .
> + strftime("%a, %d %b %Y %H:%M:%S ",
> + localtime($time))
> + . "$tz\n";
> + } elsif (/^\# /) { next ; }
> + else {
> + print "\n", $_ ;
> + $subject = 1;
> + }
> + ' < "$hg" > "$dotest/$msgnum" || clean_abort
> + done
> + echo "$this" > "$dotest/last"
> + this=
> + msgnum=
> + ;;
> *)
> if test -n "$patch_format" ; then
> clean_abort "$(eval_gettext "Patch format \$patch_format is not supported.")"
^ permalink raw reply
* Re: git-config: case insensitivity for subsections
From: Alex Vandiver @ 2011-08-29 16:47 UTC (permalink / raw)
To: Jeff King; +Cc: milki, git
In-Reply-To: <20110829155819.GA756@sigill.intra.peff.net>
On Mon, 2011-08-29 at 11:58 -0400, Jeff King wrote:
> Isn't his config somewhat broken? It looks like this:
>
> last = "!f(){ since="$1"; shift; git lg --since=\"last $since\" "$@"; }; f"
>
> Those interior double-quotes should all be backslash-escaped. I didn't
> check, but git should interpret this as:
>
> !f(){ since=$1; shift; git lg --since="last $since" $@; }; f
>
> which is probably not quite what he wanted (the quotes around $1 were
> actually superfluous, but the ones around $@ are important).
Yes, those should be escaped to do what he probably intends.
Nonetheless, certainly a parsing bug.
> That being said, I think it is intentional that the value is not just "a
> single double-quoted chunk" but rather could consist of several quoted
> (or unquoted) chunks concatenated together. What does your parser think
> of:
>
> [foo]
> bar = "foo"bar"baz"
>
> It should be:
>
> $ git config foo.bar
> foobarbaz
And with the below patch to config-gitlike, it does -- thanks for the
bug report.
- Alex
--------8<-----------
From 433dcc2f739c8906c65329a899b45424c146535c Mon Sep 17 00:00:00 2001
From: Alex Vandiver <alexmv@bestpractical.com>
Date: Mon, 29 Aug 2011 12:04:37 -0400
Subject: [PATCH] Allow quoted strings to adjoin directly to unquoted strings
This resolves a bug wherein:
[foo]
bar = "foo"bar"baz"
...was incorrectly parsed as << foo.bar=foobar"baz" >> and not the
correct << foo.bar=foobarbaz >>. Make the fall-through value not
consume quotes when consuming a token, as it should be instead parsed as
the start of a quoted-value. This bug was only evident when the quoted
value abutted the unquoted value with no separating space.
---
lib/Config/GitLike.pm | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/lib/Config/GitLike.pm b/lib/Config/GitLike.pm
index c19911e..8a7195b 100644
--- a/lib/Config/GitLike.pm
+++ b/lib/Config/GitLike.pm
@@ -333,7 +333,7 @@ sub parse_content {
$value .= $v;
}
# valid value (no escape codes)
- elsif ($c =~ s/\A([^\t \\\n]+)//im) {
+ elsif ($c =~ s/\A([^\t \\\n"]+)//im) {
$value .= $1;
# unparseable
}
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH] am: format is in $patch_format, not parse_patch
From: Giuseppe Bilotta @ 2011-08-29 16:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vaaas6vtt.fsf@alter.siamese.dyndns.org>
On Mon, Aug 29, 2011 at 6:12 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
>
>> The error message given when the patch format was not recognized was
>> wrong, since the variable checked was $parse_patch rather than
>> $patch_format. Fix by checking the non-emptyness of the correct
>> variable.
>
> Thanks for a fix to a problem that is from more than two years ago ;-)
You're welcome. I'm actually surprised that wasn't something _I_ did
by mistake ;-)
That part of the code isn't being stressed too much. I've just found
another issue. Patch coming, plus another enhancement.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* [PATCH 2/2] am: fix stgit patch mangling
From: Giuseppe Bilotta @ 2011-08-29 16:44 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1314636247-26125-1-git-send-email-giuseppe.bilotta@gmail.com>
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
git-am.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index 729ee51..14696d4 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -295,7 +295,7 @@ split_patches ()
perl -ne 'BEGIN { $subject = 0 }
if ($subject > 1) { print ; }
elsif (/^\s+$/) { next ; }
- elsif (/^Author:/) { print s/Author/From/ ; }
+ elsif (/^Author:/) { s/Author/From/ ; print ;}
elsif (/^(From|Date)/) { print ; }
elsif ($subject) {
$subject = 2 ;
--
1.7.7.rc0.331.g25483.dirty
^ permalink raw reply related
* [PATCH 1/2] am: preliminary support for hg patches
From: Giuseppe Bilotta @ 2011-08-29 16:44 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1314636247-26125-1-git-send-email-giuseppe.bilotta@gmail.com>
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
git-am.sh | 34 ++++++++++++++++++++++++++++++++++
1 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index 4fff195..729ee51 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -311,6 +311,40 @@ split_patches ()
this=
msgnum=
;;
+ hg)
+ this=0
+ for hg in "$@"
+ do
+ this=`expr "$this" + 1`
+ msgnum=`printf "%0${prec}d" $this`
+ # hg stores changeset metadata in #-commented lines preceding
+ # the commit message and diff(s). The only metadata we care about
+ # are the User and Date (Node ID and Parent are hashes which are
+ # only relevant to the hg repository and thus not useful to us)
+ # Since we cannot guarantee that the commit message is in git-friendly
+ # format, we put no Subject: line and just consume all of the message
+ # as the body
+ perl -M'POSIX qw(strftime)' -ne 'BEGIN { $subject = 0 }
+ if ($subject) { print ; }
+ elsif (/^\# User /) { s/\# User/From:/ ; print ; }
+ elsif (/^\# Date /) {
+ my ($hashsign, $str, $time, $tz) = split ;
+ $tz = sprintf "%+05d", (0-$tz)/36;
+ print "Date: " .
+ strftime("%a, %d %b %Y %H:%M:%S ",
+ localtime($time))
+ . "$tz\n";
+ } elsif (/^\# /) { next ; }
+ else {
+ print "\n", $_ ;
+ $subject = 1;
+ }
+ ' < "$hg" > "$dotest/$msgnum" || clean_abort
+ done
+ echo "$this" > "$dotest/last"
+ this=
+ msgnum=
+ ;;
*)
if test -n "$patch_format" ; then
clean_abort "$(eval_gettext "Patch format \$patch_format is not supported.")"
--
1.7.7.rc0.331.g25483.dirty
^ permalink raw reply related
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