* [PATCH 2/2] git-svn: Simplify calculation of GIT_DIR
From: Barry Wardell @ 2013-01-21 1:22 UTC (permalink / raw)
To: git; +Cc: Barry Wardell
In-Reply-To: <1358731322-44600-1-git-send-email-barry.wardell@gmail.com>
Since git-rev-parse already checks for the $GIT_DIR environment
variable and that it returns an actual git repository, there is no
need to repeat the checks again here.
This also fixes a problem where git-svn did not work in cases where
.git was a file with a gitdir: link.
Signed-off-by: Barry Wardell <barry.wardell@gmail.com>
---
git-svn.perl | 36 +++++++++++++-----------------------
1 file changed, 13 insertions(+), 23 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index bd5266c..3bcd769 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -61,8 +61,6 @@ my $cmd_dir_prefix = eval {
command_oneline([qw/rev-parse --show-prefix/], STDERR => 0)
} || '';
-my $git_dir_user_set = 1 if defined $ENV{GIT_DIR};
-$ENV{GIT_DIR} ||= '.git';
$Git::SVN::Ra::_log_window_size = 100;
if (! exists $ENV{SVN_SSH} && exists $ENV{GIT_SSH}) {
@@ -325,27 +323,19 @@ for (my $i = 0; $i < @ARGV; $i++) {
};
# make sure we're always running at the top-level working directory
-unless ($cmd && $cmd =~ /(?:clone|init|multi-init)$/) {
- unless (-d $ENV{GIT_DIR}) {
- if ($git_dir_user_set) {
- die "GIT_DIR=$ENV{GIT_DIR} explicitly set, ",
- "but it is not a directory\n";
- }
- my $git_dir = delete $ENV{GIT_DIR};
- my $cdup = undef;
- git_cmd_try {
- $cdup = command_oneline(qw/rev-parse --show-cdup/);
- $git_dir = '.' unless ($cdup);
- chomp $cdup if ($cdup);
- $cdup = "." unless ($cdup && length $cdup);
- } "Already at toplevel, but $git_dir not found\n";
- chdir $cdup or die "Unable to chdir up to '$cdup'\n";
- unless (-d $git_dir) {
- die "$git_dir still not found after going to ",
- "'$cdup'\n";
- }
- $ENV{GIT_DIR} = $git_dir;
- }
+if ($cmd && $cmd =~ /(?:clone|init|multi-init)$/) {
+ $ENV{GIT_DIR} ||= ".git";
+} else {
+ git_cmd_try {
+ $ENV{GIT_DIR} = command_oneline([qw/rev-parse --git-dir/]);
+ } "Unable to find .git directory\n";
+ my $cdup = undef;
+ git_cmd_try {
+ $cdup = command_oneline(qw/rev-parse --show-cdup/);
+ chomp $cdup if ($cdup);
+ $cdup = "." unless ($cdup && length $cdup);
+ } "Already at toplevel, but $ENV{GIT_DIR} not found\n";
+ chdir $cdup or die "Unable to chdir up to '$cdup'\n";
$_repository = Git->repository(Repository => $ENV{GIT_DIR});
}
--
1.8.0
^ permalink raw reply related
* [PATCH v3 0/2] Make git-svn work with gitdir links
From: Barry Wardell @ 2013-01-21 1:22 UTC (permalink / raw)
To: git; +Cc: Barry Wardell
In-Reply-To: <20120308005103.GA27398@dcvr.yhbt.net>
These patches fix a bug which prevented git-svn from working with repositories
which use gitdir links.
Changes since v2:
- Rebased onto latest master.
- Added test case which verifies that the problem has been fixed.
- Fixed problems with git svn (init|clone|multi-init).
- All git-svn test cases now pass (except two in t9101 which also failed
before these patches).
Barry Wardell (2):
git-svn: Add test for git-svn repositories with a gitdir link
git-svn: Simplify calculation of GIT_DIR
git-svn.perl | 36 +++++++++++++-----------------------
t/t9100-git-svn-basic.sh | 8 ++++++++
2 files changed, 21 insertions(+), 23 deletions(-)
--
1.8.0
^ permalink raw reply
* Re: [PATCH 0/3] fixup remaining cvsimport tests
From: Chris Rorvick @ 2013-01-21 1:34 UTC (permalink / raw)
To: Eric Raymond; +Cc: John Keeping, git, Junio C Hamano
In-Reply-To: <CAEUsAPaw8EUcZFbODDj9Z-=3Ppd1CC=jvYDvuyntFkX_3V0ynQ@mail.gmail.com>
On Sun, Jan 20, 2013 at 2:17 PM, Chris Rorvick <chris@rorvick.com> wrote:
> On Sun, Jan 20, 2013 at 12:57 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> John Keeping <john@keeping.me.uk> writes:
>>
>>> On Sun, Jan 20, 2013 at 09:22:03AM -0600, Chris Rorvick wrote:
>>>> On Sun, Jan 20, 2013 at 6:58 AM, John Keeping <john@keeping.me.uk> wrote:
>>>>> On Thu, Jan 10, 2013 at 10:27:16PM -0600, Chris Rorvick wrote:
>>>>>> These patchs apply on top of of Eric Raymond's cvsimport patch. 7 of 15
>>>>>> tests in t9600 fail, one of which is fixed w/ a cvsps patch I've sent
>>>>>> to Eric (fixes revision map.)
>>>>>
>>>>> Did you post the fix for the revision map publicly anywhere?
>>>>
>>>> It's in Eric's repo and included in version 3.8:
>>>>
>>>> https://gitorious.org/cvsps/cvsps/commit/abe81e1775a8959291f629029513d1b7160bbde6
>>>
>>> Thanks. For some reason I thought the fix would be to
>>> git-cvsimport-3.py. Obviously I should have read more carefully.
>>>
>>> Sorry for the noise.
>>
>> This is not a noise, though.
>>
>> Chris, how would we want to proceed? I'd prefer at some point to
>> see cvsimport-3 to be in sync when the one patched and tested in
>> Eric's repository is proven enough. Will Eric be the gatekeeper, or
>> will you be sending patches this way as well?
>
> I probably won't be sending any more patches on this. My hope was to
> get cvsimport-3 (w/ cvsps as the engine) in a state such that one
> could transition from the previous version seamlessly. But the break
> in t9605 has convinced me this is not worth the effort--even in this
> trivial case cvsps is broken. The fuzzing logic aggregates commits
> into patch sets that have timestamps within a specified window and
> otherwise matching attributes. This aggregation causes file-level
> commit timestamps to be lost and we are left with a single timestamp
> for the patch set: the minimum for all contained CVS commits. When
> all commits have been processed, the patch sets are ordered
> chronologically and printed.
>
> The problem is that is that a CVS commit is rolled into a patch set
> regardless of whether the patch set's timestamp falls within the
> adjacent CVS file-level commits. Even worse, since the patch set
> timestamp changes as subsequent commits are added (i.e., it's always
> picking the earliest) it is potentially indeterminate at the time a
> commit is added. The result is that file revisions can be reordered
> in resulting Git import (see t9605.) I spent some time last week
> trying to solve this but I coudln't think of anything that wasn't a
> substantial re-work of the code.
>
> I have never used cvs2git, but I suspect Eric's efforts in making it a
> potential backend for cvsimport are a better use of time.
>
> Chris
Hi Eric,
I noticed you were taken off this thread. As I mention above, I
looked into the bug tested in the t9605 patch Junio applied on top of
your cvsimport patch. The test was actually written for master to
test the Perl/cvsps2 import, but with minor modification you can
verify the problem still exists in the 3.x versions of cvsps.
I think the email above explains the problem pretty well. It's not
clear to me what all the nastiness is that you've resolved with cvsps
since taking over; I've been mostly concerned with importing an almost
branchless repository which I thought avoided the types of problems
you were addressing. But this bug can actually cause Git's main
import branch to become inconsistent with CVS HEAD and you don't have
to do anything too weird to get hit by it.
Fixing this seemed like it would require splitting the processing out
into a couple phases and would be a fair amount of work, but maybe I'm
just not looking at the problem right.
Chris
^ permalink raw reply
* Re: [PATCH] unpack-trees: do not abort when overwriting an existing file with the same content
From: Duy Nguyen @ 2013-01-21 1:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7va9s3n1my.fsf@alter.siamese.dyndns.org>
On Mon, Jan 21, 2013 at 1:35 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
>
>> + /*
>> + * If it has the same content that we are going to write down,
>
> write down???
hmm.. "overwrite" then.
>> + * there's no point in complaining. We still overwrite it in the
>> + * end though. Permission is not checked so it may be lost.
>> + */
>
> That is a regression, isn't it? Is it too cumbersome to avoid
> losing the permission bits by stopping in that case?
I'm not sure how to deal with this case. (Lack of) Executable bit can
be easily restored (unlike file content) if we give the user the list
of changed files. On the other hand, not everybody runs git with a
huge scrollback buffer and warnings can be lost. I guess abort is a
safe choice.
--
Duy
^ permalink raw reply
* Re: [PULL] Module fixes, and a virtio block fix.
From: Linus Torvalds @ 2013-01-21 1:45 UTC (permalink / raw)
To: Rusty Russell, Junio C Hamano, Git Mailing List
Cc: LKML, Alexander Graf, Prarit Bhargava, Sasha Levin
In-Reply-To: <87fw1vwcao.fsf@rustcorp.com.au>
On Sun, Jan 20, 2013 at 5:32 PM, Rusty Russell <rusty@rustcorp.com.au> wrote:
>
> Due to the delay on git.kernel.org, git request-pull fails. It *looks*
> like it succeeds, except the warning, but (as we learned last time I
> screwed up), it doesn't put the branchname because it can't know.
I think this should be fixed in modern git versions.
And it sure as hell knows the proper tag name, since you *gave* it the
name and it used it for generating the actual contents. The fact that
some versions then screw that up and re-write the tag-name to
something randomly matching that isn't a tag was just a bug.
> For want of a better solution, I'll now resort to sending pull requests
> with the anti-social gitolite URL in it, like so:
That's even worse, fwiw. It means that the pull request address makes
no sense to anybody who doesn't have a kernel.org address, and then
I'm forced to just edit things by hand instead to not pollute the
kernel changelog history with crap.
Junio, didn't "git request-pull" get fixed so that it *warns* about
missing tagnames/branches, but never actually corrupts the pull
request? Or did it just get "fixed" to be a hard error instead of
corrupting things? Because this is annoying.
Linus
^ permalink raw reply
* Re: [PATCH 0/2] Hiding some refs in ls-remote
From: Duy Nguyen @ 2013-01-21 1:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, spearce, mfick
In-Reply-To: <7v38xxnfv3.fsf@alter.siamese.dyndns.org>
On Sun, Jan 20, 2013 at 2:16 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Duy Nguyen <pclouds@gmail.com> writes:
>
>> Should the client side learn how to list hidden refs too? I'm thinking
>> of an extreme case where upload-pack advertises nothing (or maybe just
>> refs/heads/master) and it's up to the client to ask for the ref
>> selection it's interested in. upload-pack may need more updates to do
>> that, I think.
>
> What you are talking about is a different goal.
>
> Look at this as a mechanism for the repository owner to control the
> clutter in what is shown to the intended audience of what s/he
> publishes in the repository. Network bandwidth reduction of
> advertisement is a side effect of clutter reduction, and not
> necessarily the primary goal.
Probably stupid question: does gitnamespaces.txt attempt to achieve
the same? The document says smart http supports passing namespace,
nothing about git protocol so I guess we need some extension in
upload-pack (or git-daemon) for specifying namespace over git
protocol.
--
Duy
^ permalink raw reply
* Re: git interactive rebase 'consume' command
From: Jeff King @ 2013-01-21 1:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Stephen Kelly, git
In-Reply-To: <7v8v7nli2a.fsf@alter.siamese.dyndns.org>
On Sun, Jan 20, 2013 at 12:23:41PM -0800, Junio C Hamano wrote:
> In any case, the intent of the author timestamp is to record the
> time the author _started_ working on the change and came up with an
> initial, possibly a partial, draft. It does not record the time
> when the commit was finalized. "git commit --amend" preserves the
> original timestamp, doesn't it?
And we have "--reset-author" if you want to do that. It seems like just
doing "git commit --amend --reset-author" at the end[1] would solve the
original problem. Perhaps that is something that we could better
support directly from the instruction sheet.
-Peff
[1] or after an "edit" break in the instruction sheet, if it is in the
middle of a set of commits
^ permalink raw reply
* Re: [PATCH v3 0/2] Make git-svn work with gitdir links
From: Junio C Hamano @ 2013-01-21 1:50 UTC (permalink / raw)
To: Barry Wardell; +Cc: git, Eric Wong, Carlos Martín Nieto
In-Reply-To: <1358731322-44600-1-git-send-email-barry.wardell@gmail.com>
Barry Wardell <barry.wardell@gmail.com> writes:
> These patches fix a bug which prevented git-svn from working with repositories
> which use gitdir links.
>
> Changes since v2:
> - Rebased onto latest master.
> - Added test case which verifies that the problem has been fixed.
> - Fixed problems with git svn (init|clone|multi-init).
> - All git-svn test cases now pass (except two in t9101 which also failed
> before these patches).
>
> Barry Wardell (2):
> git-svn: Add test for git-svn repositories with a gitdir link
> git-svn: Simplify calculation of GIT_DIR
Thanks for your persistence ;-) As this is a pretty old topic, I'll
give two URLs for people who are interested to view the previous
threads:
http://thread.gmane.org/gmane.comp.version-control.git/192133
http://thread.gmane.org/gmane.comp.version-control.git/192127
You would want to mark it as test_expect_failure in the first patch
and then flip it to text_expect_success in the second patch where
you fix the breakage? Otherwise, after applying the first patch,
the testsuite will break needlessly.
I've Cc'ed Eric Wong (git-svn maintainer) and CMN who helped in the
previous round. If the only issue is the above success/failure one,
I think Eric can tweak the patches while applying them (I didn't
look at the changes carefully myself, by the way).
Thanks.
^ permalink raw reply
* Re: [PULL] Module fixes, and a virtio block fix.
From: Junio C Hamano @ 2013-01-21 2:00 UTC (permalink / raw)
To: Linus Torvalds
Cc: Rusty Russell, Git Mailing List, LKML, Alexander Graf,
Prarit Bhargava, Sasha Levin
In-Reply-To: <CA+55aFy1nW859yaGP17epRX8A+TaJ8APvb0-Ww1zw91dCAOhoQ@mail.gmail.com>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Sun, Jan 20, 2013 at 5:32 PM, Rusty Russell <rusty@rustcorp.com.au> wrote:
>>
>> Due to the delay on git.kernel.org, git request-pull fails. It *looks*
>> like it succeeds, except the warning, but (as we learned last time I
>> screwed up), it doesn't put the branchname because it can't know.
>
> I think this should be fixed in modern git versions.
> ...
> Junio, didn't "git request-pull" get fixed so that it *warns* about
> missing tagnames/branches, but never actually corrupts the pull
> request? Or did it just get "fixed" to be a hard error instead of
> corrupting things? Because this is annoying.
What you mean by "corrupt" is not clear to me, but the last change
to the script is from 6 months ago to solve a related (perhaps the
same?) problem, which should be in v1.7.11.2 and later:
request-pull: really favor a matching tag
After tagging the tip of "dev" branch with a "for-linus" tag and
pushing both out, running
$ git request-pull $url $last_release dev
would produce an output asking the 'dev' branch of $url to be
pulled, because that is what the user asked the message to say.
We already detect this situation locally and include the
contents of the tag in the output; if the $url has that tag,
favor that tag (i.e. "for-linus") in the generated message over
the branch name the user gave us (i.e. "dev") from the command
line, to make the output look more consistent.
^ permalink raw reply
* Re: [PULL] Module fixes, and a virtio block fix.
From: Linus Torvalds @ 2013-01-21 2:14 UTC (permalink / raw)
To: Junio C Hamano
Cc: Rusty Russell, Git Mailing List, LKML, Alexander Graf,
Prarit Bhargava, Sasha Levin
In-Reply-To: <7vpq0zi9c7.fsf@alter.siamese.dyndns.org>
On Sun, Jan 20, 2013 at 6:00 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> What you mean by "corrupt" is not clear to me
Some versions would just silently change the actual name you were using.
So if you said "for-linus", it might change it to "linus", just
because that branch happened to have the same SHA1 commit ID.
That's not right.
Other versions would replace the "for-linus" with "**missing-branch**"
because "for-linus" hadn't mirrored out yet.
That's not right either.
Basically, if "git request-pull" is given a branch/tag name, that is
the only valid output (although going from branch->tag *might* be
acceptable). The whole "verify that it actually exists on the remote
side" must never *ever* actually change the message itself, it should
just cause a warning outside of the message.
I can't say from the commit message whether that's the thing that
fixed it or not, but at least some people stopped sending me broken
pull requests after updating to git. I'm just not sure which of the
two different failure cases they happened to have (Rusty seems to have
hit both)
Linus
^ permalink raw reply
* Re: [PATCH 0/3] fixup remaining cvsimport tests
From: Eric S. Raymond @ 2013-01-21 2:43 UTC (permalink / raw)
To: Chris Rorvick; +Cc: John Keeping, git, Junio C Hamano
In-Reply-To: <CAEUsAPYdpsbhCZfp-1w91ZiyqgEa=8TNf2MJihMViqVZmW3sRw@mail.gmail.com>
> > I probably won't be sending any more patches on this. My hope was to
> > get cvsimport-3 (w/ cvsps as the engine) in a state such that one
> > could transition from the previous version seamlessly. But the break
> > in t9605 has convinced me this is not worth the effort--even in this
> > trivial case cvsps is broken. The fuzzing logic aggregates commits
> > into patch sets that have timestamps within a specified window and
> > otherwise matching attributes. This aggregation causes file-level
> > commit timestamps to be lost and we are left with a single timestamp
> > for the patch set: the minimum for all contained CVS commits. When
> > all commits have been processed, the patch sets are ordered
> > chronologically and printed.
> >
> > The problem is that is that a CVS commit is rolled into a patch set
> > regardless of whether the patch set's timestamp falls within the
> > adjacent CVS file-level commits. Even worse, since the patch set
> > timestamp changes as subsequent commits are added (i.e., it's always
> > picking the earliest) it is potentially indeterminate at the time a
> > commit is added. The result is that file revisions can be reordered
> > in resulting Git import (see t9605.) I spent some time last week
> > trying to solve this but I coudln't think of anything that wasn't a
> > substantial re-work of the code.
I've lost who was who in the comment thread, but I think it is rather likely
that the above diagnosis is correct in every respect.
I won't know for certain until I finish the test suite and apply it to
all three tools (cvsps, cvs2git, cvs-fast-export) but what I've seen
of their code indicates that cvsps has the weakest changeset analysis of
the three, even after my fixes.
> > I have never used cvs2git, but I suspect Eric's efforts in making it a
> > potential backend for cvsimport are a better use of time.
Agreed. I didn't add multiengine support to csvsimport at random or
just because Heiko Vogt was bugging me about parsecvs. I was
half-expecting cvsps to manifest a showstopper like this - hoping it
wouldn't, but hedging against the possibility by making alternate
engines easy to plug into git-cvsimport seemed like a *really good
idea* from the beginning of my work on it. Sometimes being that kind
of right really sucks.
While I am going to have a try at modifying cvsps to make Chris's
t9605 case work, I'm going to strictly limit the amount of time I
spend on that effort since (as you imply) it is fairly likely this
would be throwing good money after bad.
> Fixing this seemed like it would require splitting the processing out
> into a couple phases and would be a fair amount of work, but maybe I'm
> just not looking at the problem right.
Actually I think you've called it *exactly* right. The job has to be
done in multiple clique-spitting phases - that's why cvs2git has 7 passes
(though a few of those, perhaps as many as 3, are artifactual).
This is why the next step in my current work plan for CVS-related stuff will
be unbundling my test suite from the cvsps tree and running it to see if
cvs-fast-export dominates cvsps.
I'm expecting that it will, in which case my plan will be to salvage
the CVS client code out of cvsps (*that* part is quite good - fast,
clean, effective) gluing it to the better analysis stage in
cvs-fast-export, and then shooting cvsps through the head and burying
it behind the barn.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply
* Re: [PULL] Module fixes, and a virtio block fix.
From: Rusty Russell @ 2013-01-21 2:57 UTC (permalink / raw)
To: Linus Torvalds, Junio C Hamano, Git Mailing List
Cc: LKML, Alexander Graf, Prarit Bhargava, Sasha Levin
In-Reply-To: <CA+55aFy1nW859yaGP17epRX8A+TaJ8APvb0-Ww1zw91dCAOhoQ@mail.gmail.com>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Sun, Jan 20, 2013 at 5:32 PM, Rusty Russell <rusty@rustcorp.com.au> wrote:
>>
>> Due to the delay on git.kernel.org, git request-pull fails. It *looks*
>> like it succeeds, except the warning, but (as we learned last time I
>> screwed up), it doesn't put the branchname because it can't know.
>
> I think this should be fixed in modern git versions.
>
> And it sure as hell knows the proper tag name, since you *gave* it the
> name and it used it for generating the actual contents. The fact that
> some versions then screw that up and re-write the tag-name to
> something randomly matching that isn't a tag was just a bug.
I'm confused. The default argument is HEAD: what does it know about tag
names?
git request-pull master korg
The bug is that if it can't find that commit at the remote end, it
still generates a valid-looking request (with a warning at the end),
where it guesses you're talking about the master branch.
>> For want of a better solution, I'll now resort to sending pull requests
>> with the anti-social gitolite URL in it, like so:
>
> That's even worse, fwiw. It means that the pull request address makes
> no sense to anybody who doesn't have a kernel.org address, and then
> I'm forced to just edit things by hand instead to not pollute the
> kernel changelog history with crap.
Since I use a wrapper script now for your pull requests I can use sed to
unscrew it:
[alias]
for-linus = !check-commits && TAGNAME=`git symbolic-ref HEAD | cut -d/ -f3`-for-linus && git tag -f -u D1ADB8F1 $TAGNAME HEAD && git push korg tag $TAGNAME && git request-pull master korg | sed s,gitolite@ra.kernel.org:/pub,git://git.kernel.org/pub, && git log --stat --reverse master..$TAGNAME | emails-from-log | grep -v 'rusty@rustcorp' | grep -v 'stable@kernel.org' | sed 's/^/Cc: /'
> Junio, didn't "git request-pull" get fixed so that it *warns* about
> missing tagnames/branches, but never actually corrupts the pull
> request? Or did it just get "fixed" to be a hard error instead of
> corrupting things? Because this is annoying.
Here: git version 1.7.10.4
Cheers,
Rusty.
^ permalink raw reply
* Re: [PULL] Module fixes, and a virtio block fix.
From: Linus Torvalds @ 2013-01-21 3:15 UTC (permalink / raw)
To: Rusty Russell
Cc: Junio C Hamano, Git Mailing List, LKML, Alexander Graf,
Prarit Bhargava, Sasha Levin
In-Reply-To: <871udfw8e0.fsf@rustcorp.com.au>
On Sun, Jan 20, 2013 at 6:57 PM, Rusty Russell <rusty@rustcorp.com.au> wrote:
>
> I'm confused. The default argument is HEAD: what does it know about tag
> names?
Ugh. I actually thought that if you give it the tag name directly (as
the "end") it will use that.
But no. It figures it out with "git describe --exact" internally.
Regardless, if your HEAD is actually tagged, it *will* have the
tag-name in git-request-pull.
And it will have it based on your *local* repo, so the fact that it
hasn't been mirrored out yet doesn't really matter. git request-pull
knows that tag name regardless of mirroring issues.
> The bug is that if it can't find that commit at the remote end, it
> still generates a valid-looking request (with a warning at the end),
> where it guesses you're talking about the master branch.
It really shouldn't do that any more, but you seem to have the older
version with the bug.
At least one of the annoying problems was fixed in the 1.7.11 series,
you have 1.7.10.
The nice thing about git is that it is *really* easy to upgrade. Just
fetch the sources, do "make; make install" all as a normal user, and
you do not need to worry about package management or distro issues or
any crap like that. It installs into your $(HOME)/bin, and as long as
your PATH has that first, you'll get it. I've long suggested that as
the workaround for distros having old versions (some more so than
others).
> Since I use a wrapper script now for your pull requests I can use sed to
> unscrew it:
>
> [alias]
> for-linus = !check-commits && TAGNAME=`git symbolic-ref HEAD | cut -d/ -f3`-for-linus && git tag -f -u D1ADB8F1 $TAGNAME HEAD && git push korg tag $TAGNAME && git request-pull master korg | sed s,gitolite@ra.kernel.org:/pub,git://git.kernel.org/pub, && git log --stat --reverse master..$TAGNAME | emails-from-log | grep -v 'rusty@rustcorp' | grep -v 'stable@kernel.org' | sed 's/^/Cc: /'
Heh. Ok. That will at least hide the breakage. But I suspect you could
fix it by just updating git.
Linus
^ permalink raw reply
* Re: How to setup bash completion for alias of git command
From: Ping Yin @ 2013-01-21 3:55 UTC (permalink / raw)
To: Jonathan Nieder
Cc: git mailing list, Felipe Contreras, Manlio Perillo, Marc Khouzam,
SZEDER Gábor
In-Reply-To: <20130120111424.GG16339@elie.Belkin>
On Sun, Jan 20, 2013 at 7:14 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Hi Ping,
>
> Ping Yin wrote:
>>
>> However, in debian (testing, wheezy), it doesn't work
>>
>> $ gtlg or<TAB>
>> gtlg or-bash: [: 1: unary operator expected
>> -bash: [: 1: unary operator expected
>
> Yes, I can reproduce this. "git bisect" tells me it was introduced
> by v1.7.6-rc0~65^2~4 (completion: remove unnecessary
> _get_comp_words_by_ref() invocations, 2011-04-28). Since then, Felipe
> has done work to make reusing subcommand completion easy again, so you
> can do
>
> __git_complete gtlg _git_log
>
Thanks very much. by following your advice, it works now.
Ping Yin
^ permalink raw reply
* Re: [msysGit] Re: Version 1.8.1 does not compile on Cygwin 1.7.14
From: Torsten Bögershausen @ 2013-01-21 5:20 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Torsten Bögershausen, Ramsay Jones, Mark Levedahl,
Alex Riesen, Junio C Hamano, Jason Pyeron, git,
Stephen & Linda Smith, Eric Blake, msysGit
In-Reply-To: <20130120110618.GF16339@elie.Belkin>
On 20.01.13 12:06, Jonathan Nieder wrote:
> Torsten Bögershausen wrote:
>
>> I wonder, if if we can go one step further:
>>
>> Replace
>> #ifdef WIN32 /* Both MinGW and MSVC */
> [...]
>> with
>> #if defined(_MSC_VER)
>
> I thought Git for Windows was built using mingw, which doesn't define
> _MSC_VER?
>
> Puzzled,
> Jonathan
>
Yes,
After removing these lines in the git-compat-util.h of msysgit
v1.8.1 it still compiled.
So I start to speculate if the comment is still valid for mingw,
or if that was true in the old days and not now any more.
More investigation is needed, sorry for confusion.
/Torsten
^ permalink raw reply
* Fwd: Patch for QEMU errors
From: harryxiyou @ 2013-01-21 5:35 UTC (permalink / raw)
To: git
In-Reply-To: <CAD+1EGNDEF7bfyHKYwA=OSU-JJoGG2L4bfZwKLbO87mCxu-P7g@mail.gmail.com>
Hi all,
We programmed a block storage(HLFS) patch for QEMU. Therefore,
when i patched this driver for QEMU, it happened to me some errors.
Could anyone give me some suggestions, thanks in advance ;-)
You can see this issue i described in details from
http://code.google.com/p/cloudxy/issues/detail?id=21
You can also see our patch for QEMU here.
http://cloudxy.googlecode.com/svn/trunk/hlfs/patches/hlfs_driver_for_qemu.patch
--
Thanks
Harry Wei
^ permalink raw reply
* Re: git-cvsimport-3 and incremental imports
From: Jonathan Nieder @ 2013-01-21 6:42 UTC (permalink / raw)
To: Eric S. Raymond; +Cc: John Keeping, git
In-Reply-To: <20130121010643.GA25437@thyrsus.com>
Eric S. Raymond wrote:
> I have said everything I could about the bad effects of encouraging
> people to continue to use cvsps-2.x, it didn't budge Junio an
> inch, and I'm tired of fighting about it.
What I think you misunderstood is that Junio is not the person you
would have needed to convince. (Nor is it me.)
[...]
> I will continue to do what I can to make cvsps-3.x and cvs-fast-export as
> bug-free as possible, given the innate perverseness of CVS.
That's all anyone could hope for. :) Thanks.
Ciao,
Jonathan
^ permalink raw reply
* Re: git-cvsimport-3 and incremental imports
From: Junio C Hamano @ 2013-01-21 7:28 UTC (permalink / raw)
To: esr; +Cc: Jonathan Nieder, John Keeping, git
In-Reply-To: <20130121010643.GA25437@thyrsus.com>
"Eric S. Raymond" <esr@thyrsus.com> writes:
> Jonathan Nieder <jrnieder@gmail.com>:
>> Junio proposed a transition strategy, but I don't think it's fair to
>> say he has chosen it without discussion or is imposing it on you.
>
> I have said everything I could about the bad effects of encouraging
> people to continue to use cvsps-2.x, it didn't budge Junio an
> inch, and I'm tired of fighting about it. Quibbling about the
> semantics of 'impose' will neither change these facts nor make
> me any less frustrated with the outcome.
I am not quite sure if I follow you.
The primary thing I am aiming for is to rob an excuse from people
and from their distros to block newer Git and cvsps3. I've already
cited a few URLs where we can see cvsps3 is blocked with an excuse
"it does not work with Git yet".
If we ship new version of Git that only works with cvsps3, we will
end up giving an excuse "this version of Git no longer works with
cvsps2" for distro packagers whose cvsps distro maintainer is slower
than others to pick up cvsps3 for whatever reason.
You may care deeply about CVS conversion part of the system, but you
need to realize that majority of Git users do not care a whit about
cvsimport. I do not want to give those distros that ship stale cvsps
an excuse to pin their users at an old version of Git.
By shipping both cvsimport-2 and cvsimport-3, we will rob from these
distros the excuse to block shipping the version of Git that does
support cvsps3 output. They can choose to update cvsps to 3.x and
disable cvsimport-2 altogether at the build time, or if their cvsps
distro maintainer is slow, they can ship both cvsimport-2 and -3 and
let the user install cvsps 3.x under their $HOME if they want.
If you want to abandon cvsps2 users, that is perfectly fine by me.
As long as cvsps3 and cvsimport-3 combo works, Git before this
series will have a _working_ cvsimport as far as I am concerned.
In other words, I am fine to add a paragraph at the top of the
Release Notes saying that
(1) cvsps2 is no longer maintained;
(2) using cvsps3 is the future direction for the users; and
(3) if their distro is slow to adopt cvsps3, however, cvsimport can
still be used with cvsps2, but bugs in it or cvsps2 are not
expected to be fixed.
to nudge distros to adopt cvsps3.
> I will continue to do what I can to make cvsps-3.x and cvs-fast-export as
> bug-free as possible, given the innate perverseness of CVS. They
> won't be perfect; they will be *better*.
Yes, that is what we want.
^ permalink raw reply
* Re: git-cvsimport-3 and incremental imports
From: Junio C Hamano @ 2013-01-21 7:35 UTC (permalink / raw)
To: esr; +Cc: Jonathan Nieder, John Keeping, git
In-Reply-To: <7vr4lfgfkm.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> If you want to abandon cvsps2 users, that is perfectly fine by me.
> As long as cvsps3 and cvsimport-3 combo works, Git before this
> series will have a _working_ cvsimport as far as I am concerned.
The above obviously is "Git _after_ this series".
Git before this series that only has cvsps2 support may be broken
and Git after this series, when used with cvsps2, may be broken, but
is broken the same way as before, so it is not a net loss.
The users of distros that are slow to update cvsps can still use
cvsimport-3 with cvsps3 that is manually installed, and the users of
distros that ship cvsps3 will use cvsimport-3 and they can migrate
away from cvsps2's breakage.
^ permalink raw reply
* Re: [RFC] git rm -u
From: Piotr Krukowiecki @ 2013-01-21 8:09 UTC (permalink / raw)
To: Junio C Hamano
Cc: Matthieu Moy, Jonathan Nieder, Eric James Michael Ritz,
Git Mailing List, Tomas Carnecky
In-Reply-To: <7v1udfn0tm.fsf@alter.siamese.dyndns.org>
On Sun, Jan 20, 2013 at 7:53 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>
>> Implementing "git rm -u" as a tree-wide command would create a
>> discrepancy with "git add -u". Implementing it as a "current directory"
>> command would make the migration harder if we eventually try to change
>> "git add -u". Perhaps "git rm -u" should be forbidden from a
>> subdirectory (with an error message pointing to "git rm -u :/" and "git
>> rm -u ."), waiting for a possible "git add -u" change.
>
> Yeah, that sounds sensible. Start with a "'git rm -u' is forbidden
> without arguments", give advise to use either "." or ":/". And stop
> there.
>
> The first step of "git add -u" migration plan would be to warn when
> no argument is given and update all the existing index entries, and
> give the same advise to use either "." or ":/". Keep this for three
> cycles: 3 * (8 to 10 weeks per cycle) = 27 weeks ~ 1/2 year.
>
> The second step would be to forbid "git add -u", and keep the
> advise. That will make it in-line with "git rm -u".
Do you mean "git add" will be disallowed without "." or ":/" argument?
Or will this change in future and "git add" without argument will me
"whole tree", same as ":/" ?
--
Piotr Krukowiecki
^ permalink raw reply
* [PATCH] mergetools: Add tortoisegitmerge helper
From: Sven Strickroth @ 2013-01-21 8:24 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Sebastian Schuberth, davvid, Jeff King
In-Reply-To: <7v4nibjrg0.fsf@alter.siamese.dyndns.org>
- The TortoiseGit team renamed TortoiseMerge.exe to TortoiseGitMerge.exe
(starting with 1.8.0) in order to make clear that this one has special
support for git and prevent confusion with the TortoiseSVN TortoiseMerge
version.
- The tortoisemerge mergetool does not work with filenames which have
a space in it. Fixing this required changes in git and also in
TortoiseGitMerge; see https://github.com/msysgit/msysgit/issues/57.
The new tortoisegitmerge helper was added so that people can still use
TortoiseMerge from TortoiseSVN (and older TortoiseGit versions).
Signed-off-by: Sven Strickroth <email@cs-ware.de>
Idea-by: Sebastian Schuberth <sschuberth@gmail.com>
---
Documentation/diff-config.txt | 4 ++--
Documentation/git-mergetool.txt | 4 ++--
Documentation/merge-config.txt | 6 +++---
contrib/completion/git-completion.bash | 2 +-
git-mergetool--lib.sh | 2 +-
mergetools/tortoisegitmerge | 17 +++++++++++++++++
6 files changed, 26 insertions(+), 9 deletions(-)
create mode 100644 mergetools/tortoisegitmerge
diff --git a/Documentation/diff-config.txt b/Documentation/diff-config.txt
index 4314ad0..13cbe5b 100644
--- a/Documentation/diff-config.txt
+++ b/Documentation/diff-config.txt
@@ -151,7 +151,7 @@ diff.<driver>.cachetextconv::
diff.tool::
The diff tool to be used by linkgit:git-difftool[1]. This
option overrides `merge.tool`, and has the same valid built-in
- values as `merge.tool` minus "tortoisemerge" and plus
- "kompare". Any other value is treated as a custom diff tool,
+ values as `merge.tool` minus "tortoisemerge"/"tortoisegitmerge" and
+ plus "kompare". Any other value is treated as a custom diff tool,
and there must be a corresponding `difftool.<tool>.cmd`
option.
diff --git a/Documentation/git-mergetool.txt b/Documentation/git-mergetool.txt
index 6b563c5..a80cccd 100644
--- a/Documentation/git-mergetool.txt
+++ b/Documentation/git-mergetool.txt
@@ -28,8 +28,8 @@ OPTIONS
--tool=<tool>::
Use the merge resolution program specified by <tool>.
Valid values include emerge, gvimdiff, kdiff3,
- meld, vimdiff, and tortoisemerge. Run `git mergetool --tool-help`
- for the list of valid <tool> settings.
+ meld, vimdiff, tortoisegitmerge, and tortoisemerge. Run
+ `git mergetool --tool-help` for the list of valid <tool> settings.
+
If a merge resolution program is not specified, 'git mergetool'
will use the configuration variable `merge.tool`. If the
diff --git a/Documentation/merge-config.txt b/Documentation/merge-config.txt
index 9bb4956..a047646 100644
--- a/Documentation/merge-config.txt
+++ b/Documentation/merge-config.txt
@@ -55,9 +55,9 @@ merge.tool::
Controls which merge resolution program is used by
linkgit:git-mergetool[1]. Valid built-in values are: "araxis",
"bc3", "diffuse", "ecmerge", "emerge", "gvimdiff", "kdiff3", "meld",
- "opendiff", "p4merge", "tkdiff", "tortoisemerge", "vimdiff"
- and "xxdiff". Any other value is treated is custom merge tool
- and there must be a corresponding mergetool.<tool>.cmd option.
+ "opendiff", "p4merge", "tkdiff", "tortoisegitmerge", "tortoisemerge",
+ "vimdiff" and "xxdiff". Any other value is treated is custom merge
+ tool and there must be a corresponding mergetool.<tool>.cmd option.
merge.verbosity::
Controls the amount of output shown by the recursive merge
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 14dd5e7..1557d54 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1345,7 +1345,7 @@ _git_mergetool ()
{
case "$cur" in
--tool=*)
- __gitcomp "$__git_mergetools_common tortoisemerge" "" "${cur##--tool=}"
+ __gitcomp "$__git_mergetools_common tortoisegitmerge tortoisemerge" "" "${cur##--tool=}"
return
;;
--*)
diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
index f013a03..47183ef 100644
--- a/git-mergetool--lib.sh
+++ b/git-mergetool--lib.sh
@@ -150,7 +150,7 @@ run_merge_cmd () {
list_merge_tool_candidates () {
if merge_mode
then
- tools="tortoisemerge"
+ tools="tortoisegitmerge tortoisemerge"
else
tools="kompare"
fi
diff --git a/mergetools/tortoisegitmerge b/mergetools/tortoisegitmerge
new file mode 100644
index 0000000..5b802a7
--- /dev/null
+++ b/mergetools/tortoisegitmerge
@@ -0,0 +1,17 @@
+can_diff () {
+ return 1
+}
+
+merge_cmd () {
+ if $base_present
+ then
+ touch "$BACKUP"
+ "$merge_tool_path" \
+ -base="$BASE" -mine="$LOCAL" \
+ -theirs="$REMOTE" -merged="$MERGED"
+ check_unchanged
+ else
+ echo "TortoiseGitMerge cannot be used without a base" 1>&2
+ return 1
+ fi
+}
--
1.8.0.msysgit.0
^ permalink raw reply related
* [PATCH] mergetools: Add tortoisegitmerge helper
From: Sven Strickroth @ 2013-01-21 8:26 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Sebastian Schuberth, davvid, Jeff King
In-Reply-To: <7v4nibjrg0.fsf@alter.siamese.dyndns.org>
- The TortoiseGit team renamed TortoiseMerge.exe to TortoiseGitMerge.exe
(starting with 1.8.0) in order to make clear that this one has special
support for git and prevent confusion with the TortoiseSVN TortoiseMerge
version.
- The tortoisemerge mergetool does not work with filenames which have
a space in it. Fixing this required changes in git and also in
TortoiseGitMerge; see https://github.com/msysgit/msysgit/issues/57.
The new tortoisegitmerge helper was added so that people can still use
TortoiseMerge from TortoiseSVN (and older TortoiseGit versions).
Signed-off-by: Sven Strickroth <email@cs-ware.de>
Idea-by: Sebastian Schuberth <sschuberth@gmail.com>
---
Documentation/diff-config.txt | 4 ++--
Documentation/git-mergetool.txt | 4 ++--
Documentation/merge-config.txt | 6 +++---
contrib/completion/git-completion.bash | 2 +-
git-mergetool--lib.sh | 2 +-
mergetools/tortoisegitmerge | 17 +++++++++++++++++
6 files changed, 26 insertions(+), 9 deletions(-)
create mode 100644 mergetools/tortoisegitmerge
diff --git a/Documentation/diff-config.txt b/Documentation/diff-config.txt
index 4314ad0..13cbe5b 100644
--- a/Documentation/diff-config.txt
+++ b/Documentation/diff-config.txt
@@ -151,7 +151,7 @@ diff.<driver>.cachetextconv::
diff.tool::
The diff tool to be used by linkgit:git-difftool[1]. This
option overrides `merge.tool`, and has the same valid built-in
- values as `merge.tool` minus "tortoisemerge" and plus
- "kompare". Any other value is treated as a custom diff tool,
+ values as `merge.tool` minus "tortoisemerge"/"tortoisegitmerge" and
+ plus "kompare". Any other value is treated as a custom diff tool,
and there must be a corresponding `difftool.<tool>.cmd`
option.
diff --git a/Documentation/git-mergetool.txt b/Documentation/git-mergetool.txt
index 6b563c5..a80cccd 100644
--- a/Documentation/git-mergetool.txt
+++ b/Documentation/git-mergetool.txt
@@ -28,8 +28,8 @@ OPTIONS
--tool=<tool>::
Use the merge resolution program specified by <tool>.
Valid values include emerge, gvimdiff, kdiff3,
- meld, vimdiff, and tortoisemerge. Run `git mergetool --tool-help`
- for the list of valid <tool> settings.
+ meld, vimdiff, tortoisegitmerge, and tortoisemerge. Run
+ `git mergetool --tool-help` for the list of valid <tool> settings.
+
If a merge resolution program is not specified, 'git mergetool'
will use the configuration variable `merge.tool`. If the
diff --git a/Documentation/merge-config.txt b/Documentation/merge-config.txt
index 9bb4956..a047646 100644
--- a/Documentation/merge-config.txt
+++ b/Documentation/merge-config.txt
@@ -55,9 +55,9 @@ merge.tool::
Controls which merge resolution program is used by
linkgit:git-mergetool[1]. Valid built-in values are: "araxis",
"bc3", "diffuse", "ecmerge", "emerge", "gvimdiff", "kdiff3", "meld",
- "opendiff", "p4merge", "tkdiff", "tortoisemerge", "vimdiff"
- and "xxdiff". Any other value is treated is custom merge tool
- and there must be a corresponding mergetool.<tool>.cmd option.
+ "opendiff", "p4merge", "tkdiff", "tortoisegitmerge", "tortoisemerge",
+ "vimdiff" and "xxdiff". Any other value is treated is custom merge
+ tool and there must be a corresponding mergetool.<tool>.cmd option.
merge.verbosity::
Controls the amount of output shown by the recursive merge
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 14dd5e7..1557d54 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1345,7 +1345,7 @@ _git_mergetool ()
{
case "$cur" in
--tool=*)
- __gitcomp "$__git_mergetools_common tortoisemerge" "" "${cur##--tool=}"
+ __gitcomp "$__git_mergetools_common tortoisegitmerge tortoisemerge" "" "${cur##--tool=}"
return
;;
--*)
diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
index f013a03..47183ef 100644
--- a/git-mergetool--lib.sh
+++ b/git-mergetool--lib.sh
@@ -150,7 +150,7 @@ run_merge_cmd () {
list_merge_tool_candidates () {
if merge_mode
then
- tools="tortoisemerge"
+ tools="tortoisegitmerge tortoisemerge"
else
tools="kompare"
fi
diff --git a/mergetools/tortoisegitmerge b/mergetools/tortoisegitmerge
new file mode 100644
index 0000000..5b802a7
--- /dev/null
+++ b/mergetools/tortoisegitmerge
@@ -0,0 +1,17 @@
+can_diff () {
+ return 1
+}
+
+merge_cmd () {
+ if $base_present
+ then
+ touch "$BACKUP"
+ "$merge_tool_path" \
+ -base "$BASE" -mine "$LOCAL" \
+ -theirs "$REMOTE" -merged "$MERGED"
+ check_unchanged
+ else
+ echo "TortoiseGitMerge cannot be used without a base" 1>&2
+ return 1
+ fi
+}
--
1.8.0.msysgit.0
^ permalink raw reply related
* Re: [RFC] git rm -u
From: Matthieu Moy @ 2013-01-21 8:37 UTC (permalink / raw)
To: Piotr Krukowiecki
Cc: Junio C Hamano, Jonathan Nieder, Eric James Michael Ritz,
Git Mailing List, Tomas Carnecky
In-Reply-To: <CAA01Csrv26WrrJDAo-1cr+rW6rYFGQZpYgtafEh=Wgtzswdv_g@mail.gmail.com>
Piotr Krukowiecki <piotr.krukowiecki@gmail.com> writes:
> Do you mean "git add" will be disallowed without "." or ":/" argument?
> Or will this change in future and "git add" without argument will me
> "whole tree", same as ":/" ?
Let's talk conditional, not future, for now.
If the idea is to change the semantics without argument, it has to be
done carefully, and implies disallowing the argumentless version for a
while (or some better idea) to avoid confusion.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* [PATCH v2 00/10] unify appending of sob
From: Brandon Casey @ 2013-01-21 8:40 UTC (permalink / raw)
To: gitster; +Cc: pclouds, git, Brandon Casey
Here's version 2 of the unify-appending-of-sob series. Hopefully this
addresses the comments made on the first series:
http://thread.gmane.org/gmane.comp.version-control.git/210390
The main difference is that the detection of the "(cherry picked from ...)"
line has been relaxed, and the modifications to log-tree.c have been dropped.
Here's the inter-diff of this series against the original series, both built
on top of 2d242fb3fc19fc9ba046accdd9210be8b9913f64 (the actual series in the
following emails is of course built on top of master).
diff --git a/revision.h b/revision.h
index 435a60b..d20defa 100644
--- a/revision.h
+++ b/revision.h
@@ -137,7 +137,7 @@ struct rev_info {
int numbered_files;
char *message_id;
struct string_list *ref_message_ids;
- int add_signoff;
+ int add_signoff;
const char *extra_headers;
const char *log_reencode;
const char *subject_prefix;
diff --git a/sequencer.c b/sequencer.c
index eb93dd6..54b3cb9 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -36,13 +36,18 @@ static int is_rfc2822_line(const char *buf, int len)
return 1;
}
-static int is_cherry_pick_from_line(const char *buf, int len)
+static int is_cherry_picked_from_line(const char *buf, int len)
{
- return (strlen(cherry_picked_prefix) + 41) <= len &&
- !prefixcmp(buf, cherry_picked_prefix);
+ /*
+ * We only care that it looks roughly like (cherry picked from ...)
+ */
+ return !prefixcmp(buf, cherry_picked_prefix) &&
+ (buf[len - 1] == ')' ||
+ (buf[len - 1] == '\n' && buf[len - 2] == ')'));
}
-/* Returns 0 for non-conforming footer
+/*
+ * Returns 0 for non-conforming footer
* Returns 1 for conforming footer
* Returns 2 when sob exists within conforming footer
* Returns 3 when sob exists within conforming footer as last entry
@@ -51,7 +56,7 @@ static int has_conforming_footer(struct strbuf *sb, struct strbuf *sob,
int ignore_footer)
{
int hit = 0;
- int i, k = 0;
+ int i, k;
int len = sb->len - ignore_footer;
const char *buf = sb->buf;
int found_sob = 0;
@@ -76,12 +81,13 @@ static int has_conforming_footer(struct strbuf *sb, struct strbuf *sob,
; /* do nothing */
k++;
- found_rfc2822 = is_rfc2822_line(buf+i, k-i);
+ found_rfc2822 = is_rfc2822_line(buf + i, k - i);
if (found_rfc2822 && sob &&
- !strncasecmp(buf+i, sob->buf, sob->len))
+ !strncmp(buf + i, sob->buf, sob->len))
found_sob = k;
- if (!(found_rfc2822 || is_cherry_pick_from_line(buf+i, k-i)))
+ if (!(found_rfc2822 ||
+ is_cherry_picked_from_line(buf + i, k - i)))
return 0;
}
if (found_sob == i)
@@ -1103,11 +1109,20 @@ void append_signoff(struct strbuf *msgbuf, int ignore_footer, int no_dup_sob)
strbuf_addch(&sob, '\n');
for (i = msgbuf->len - 1 - ignore_footer; i > 0 && msgbuf->buf[i - 1] != '\n'; i--)
; /* do nothing */
- if (msgbuf->buf[i] != '\n' && (!i || !(has_footer =
- has_conforming_footer(msgbuf, &sob, ignore_footer))))
- strbuf_splice(msgbuf, msgbuf->len - ignore_footer, 0, "\n", 1);
+
+ if (msgbuf->buf[i] != '\n') {
+ if (i)
+ has_footer = has_conforming_footer(msgbuf, &sob,
+ ignore_footer);
+
+ if (!has_footer)
+ strbuf_splice(msgbuf, msgbuf->len - ignore_footer, 0,
+ "\n", 1);
+ }
+
if (has_footer != 3 && (!no_dup_sob || has_footer != 2))
strbuf_splice(msgbuf, msgbuf->len - ignore_footer, 0,
sob.buf, sob.len);
+
strbuf_release(&sob);
}
diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh
index c53dc4b..6d00e43 100755
--- a/t/t4014-format-patch.sh
+++ b/t/t4014-format-patch.sh
@@ -1211,16 +1211,17 @@ subject
body
+Reviewed-id: Noone
Tested-by: my@house
Change-id: Ideadbeef
Signed-off-by: C O Mitter <committer@example.com>
-BUG: 1234
+Bug: 1234
EOF
cat >expected <<\EOF &&
4:Subject: [PATCH] subject
8:
10:
-13:Signed-off-by: C O Mitter <committer@example.com>
+14:Signed-off-by: C O Mitter <committer@example.com>
EOF
test_cmp expected actual
'
Brandon Casey (8):
sequencer.c: remove broken support for rfc2822 continuation in footer
t/test-lib-functions.sh: allow to specify the tag name to test_commit
t/t3511: add some tests of 'cherry-pick -s' functionality
sequencer.c: recognize "(cherry picked from ..." as part of s-o-b
footer
sequencer.c: always separate "(cherry picked from" from commit body
sequencer.c: teach append_signoff how to detect duplicate s-o-b
sequencer.c: teach append_signoff to avoid adding a duplicate newline
Unify appending signoff in format-patch, commit and sequencer
Nguyễn Thái Ngọc Duy (2):
t4014: more tests about appending s-o-b lines
format-patch: update append_signoff prototype
builtin/commit.c | 2 +-
builtin/log.c | 13 +--
log-tree.c | 92 ++---------------
revision.h | 2 +-
sequencer.c | 146 +++++++++++++++++---------
sequencer.h | 2 +-
t/t3511-cherry-pick-x.sh | 219 +++++++++++++++++++++++++++++++++++++++
t/t4014-format-patch.sh | 263 +++++++++++++++++++++++++++++++++++++++++++++++
t/test-lib-functions.sh | 9 +-
9 files changed, 595 insertions(+), 153 deletions(-)
create mode 100755 t/t3511-cherry-pick-x.sh
--
1.8.1.1.252.gdb33759
^ permalink raw reply related
* [PATCH v2 01/10] sequencer.c: remove broken support for rfc2822 continuation in footer
From: Brandon Casey @ 2013-01-21 8:40 UTC (permalink / raw)
To: gitster; +Cc: pclouds, git, Brandon Casey, Brandon Casey
In-Reply-To: <1358757627-16682-1-git-send-email-drafnel@gmail.com>
Commit c1e01b0c generalized the detection of the last paragraph
signed-off-by footer and used rfc2822 as a guideline. Support for rfc2822
style continuation lines was also implemented, but not correctly, so it has
never detected a line beginning with space or tab as a continuation of the
previous line.
Since a commit message is not governed by the line length limits imposed
by rfc2822 for email messages, and it does not seem like this functionality
would produce "better" commit messages anyway, let's remove this broken
functionality.
Signed-off-by: Brandon Casey <bcasey@nvidia.com>
---
sequencer.c | 6 ------
1 file changed, 6 deletions(-)
diff --git a/sequencer.c b/sequencer.c
index aef5e8a..fe25ef4 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -1027,7 +1027,6 @@ static int ends_rfc2822_footer(struct strbuf *sb, int ignore_footer)
int hit = 0;
int i, j, k;
int len = sb->len - ignore_footer;
- int first = 1;
const char *buf = sb->buf;
for (i = len - 1; i > 0; i--) {
@@ -1044,11 +1043,6 @@ static int ends_rfc2822_footer(struct strbuf *sb, int ignore_footer)
; /* do nothing */
k++;
- if ((buf[k] == ' ' || buf[k] == '\t') && !first)
- continue;
-
- first = 0;
-
for (j = 0; i + j < len; j++) {
ch = buf[i + j];
if (ch == ':')
--
1.8.1.1.252.gdb33759
^ 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