* [PATCH 1/2] git-svn.perl: perform deletions before anything else
From: Steven Walter @ 2012-02-09 20:52 UTC (permalink / raw)
To: gitster, normalperson, git; +Cc: Steven Walter, Steven Walter
In-Reply-To: <1328820742-4795-1-git-send-email-stevenrwalter@gmail.com>
From: Steven Walter <swalter@lexmark.com>
If we delete a file and recreate it as a directory in a single commit,
we have to tell the server about the deletion first or else we'll get
"RA layer request failed: Server sent unexpected return value (405
Method Not Allowed) in response to MKCOL request"
Signed-off-by: Steven Walter <stevenrwalter@gmail.com>
---
git-svn.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index eeb83d3..06c9322 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -5374,7 +5374,7 @@ sub DESTROY {
sub apply_diff {
my ($self) = @_;
my $mods = $self->{mods};
- my %o = ( D => 1, R => 0, C => -1, A => 3, M => 3, T => 3 );
+ my %o = ( D => 0, C => 1, R => 2, A => 3, M => 4, T => 5 );
foreach my $m (sort { $o{$a->{chg}} <=> $o{$b->{chg}} } @$mods) {
my $f = $m->{chg};
if (defined $o{$f}) {
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH] gitweb: Harden parse_commit and parse_commits
From: Jakub Narebski @ 2012-02-09 20:14 UTC (permalink / raw)
To: rajesh boyapati; +Cc: git
In-Reply-To: <CA+EqV8xiLYo8XE--c1QfuXdhentUFpHqfPYXHt72eCpEA_hCNQ@mail.gmail.com>
Please do not remove git@vger.kernel.org (git mailing list) from Cc,
i.e. please use "Reply to all" instead of just "Reply to author".
On Wed, 8 Feb 2012, rajesh boyapati wrote:
> 2012/2/8 Jakub Narebski <jnareb@gmail.com>
[...]
> > Does the following patch help, and does it fix the issue?
> >
> > (Nb. you can try to simply change filename, and apply it with fuzz
> > against index.cgi file).
> > -- >8 -- ----- ----- ----- ----- ----- -- >8 --
> > From: Jakub Narebski <jnareb@gmail.com>
> > Subject: [PATCH] gitweb: Harden parse_commit and parse_commits
[...]
> When I applied the above patch and also the patch from your previous
> e-mail, I am getting this error
> >>>>>>>>>>>>>
> [2012-02-08 14:09:58,396] ERROR
> com.google.gerrit.httpd.gitweb.GitWebServlet : CGI: fatal: bad revision
> 'HEAD'
> [2012-02-08 14:10:06,732] ERROR
> com.google.gerrit.httpd.gitweb.GitWebServlet : CGI: fatal: bad revision
> 'HEAD'
> [2012-02-08 14:10:11,404] ERROR
> com.google.gerrit.httpd.gitweb.GitWebServlet : CGI: fatal: bad revision
> 'HEAD'
> [2012-02-08 14:10:15,270] ERROR
> com.google.gerrit.httpd.gitweb.GitWebServlet : CGI: fatal: Not a valid
> object name HEAD
> <<<<<<<<<<<<<<
> With these patches, the previous errors at line numbers are gone.
Thanks for information.
This final issue will be a bit harder to fix. This error message
fatal: bad revision 'HEAD'
comes from git (I think from "git rev-list" command), and not from gitweb.
It is printed on STDERR of git command. What has to be done to fix it is
to capture stderr of a process, or silence it.
Unfortunately it is not that easy. We use list form of open, which avoids
using a shell interpreter to run command, and is safer wrt. shell escaping.
The only place where gitweb cares about redirecting standard error from git
command is git_object(). It is a bit hacky, and might be not entirely safe.
To fix this issue we would have to do the same in parse_commit*() as in
git_object(), or provide some kind of wrapper like IPC::Run provides
for redirecting stderr of called command.
Note that this issue was not considered very important, because this message
doesn't goes into web server logs when running gitweb via mod_cgi with
Apache... and probably also with other web servers. Gerrit (or rather
whatever it uses for serving CGI scripts) might be exception here.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH v2 1/2] submodules: always use a relative path to gitdir
From: Jens Lehmann @ 2012-02-09 20:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Antony Male, Phil Hord
In-Reply-To: <7vd39nx0br.fsf@alter.siamese.dyndns.org>
Am 09.02.2012 20:40, schrieb Junio C Hamano:
> Jens Lehmann <Jens.Lehmann@web.de> writes:
>
>> Since recently a submodule with name <name> has its git directory in the
>
> I understand that "recently" refers to efc5fb6a77 and this is potentially
> a maint material for v1.7.8.X; am I correct?
That's correct.
>> The first version was whitespace damaged, please use this one instead.
>
> Thanks.
>
> When applied to v1.7.8.x maintenance track, this failed the first step in
> t5526, but with the earlier jl/submodule-re-add topic everything seems to
> pass just fine.
Ah, I only tested these patches on current master. But you are right,
this belongs on top of jl/submodule-re-add for maint.
^ permalink raw reply
* Re: [PATCH 1/2] git-svn.perl: perform deletions before anything else
From: Junio C Hamano @ 2012-02-09 20:08 UTC (permalink / raw)
To: Steven Walter; +Cc: normalperson, git
In-Reply-To: <1328813725-16638-1-git-send-email-stevenrwalter@gmail.com>
Steven Walter <stevenrwalter@gmail.com> writes:
> - my %o = ( D => 1, R => 0, C => -1, A => 3, M => 3, T => 3 );
> + my %o = ( D => -2, R => 0, C => -1, A => 3, M => 3, T => 3 );
I know this code arrangement dates back to cf52b8f (git-svn: fix several
corner-case and rare bugs with 'commit', 2006-02-20), but somehow I find
it extremely hard to follow. The absolute values do not matter (this is
only used to sort the classes of operations), and the fact that A/M/T
shares the same value does not help a stable sort result (as it is used as
a key to sort {} that is not given any key other than $o{$ab->{chg}} to
tie-break). I suspect that writing it this way
my %o = (D => 0, C => 1, R => 2, A => 3, M => 4, T => 5)
or even
my $ord = 0;
my %o = map { $_ => $ord++ } qw(D C R A M T);
would make it much easier to follow.
^ permalink raw reply
* Re: git merge <tag>: Spawning an editor can't be disabled
From: Junio C Hamano @ 2012-02-09 19:54 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Jonathan Nieder, Guido Günther, git
In-Reply-To: <4F34158D.3030903@kdbg.org>
Johannes Sixt <j6t@kdbg.org> writes:
> It should behave as if the editor was spawned and the user did not
> change the content of the commit message.
> ...
> Contrived? Dunno.
No, just "Sane".
Thanks. And I think Jonathan's original patch is just fine as-is; the
commented verification result should be stripspace()'ed out when we make
the final commit if we do so ourselves, and will stay if the user ends up
having to help resolving the merge.
^ permalink raw reply
* Re: [PATCH v2 1/2] submodules: always use a relative path to gitdir
From: Junio C Hamano @ 2012-02-09 19:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jens Lehmann, Git Mailing List, Antony Male, Phil Hord
In-Reply-To: <7vd39nx0br.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> When applied to v1.7.8.x maintenance track, this failed the first step in
> t5526, but with the earlier jl/submodule-re-add topic everything seems to
> pass just fine.
What I meant to say is that "this and the other topic need to be merged to
that maintenance track together"; I didn't mean to say there is any
breakage in this patch.
Sorry for a potentially confusing statement.
^ permalink raw reply
* [RFC/PATCH] tag: make list exclude !<pattern>
From: Tom Grennan @ 2012-02-09 19:43 UTC (permalink / raw)
To: git; +Cc: gitster, peff
In-Reply-To: <1328816616-18124-1-git-send-email-tmgrennan@gmail.com>
Use the "!" prefix to ignore tags of the given pattern.
This has precedence over other matching patterns.
For example,
$ git tag -l \!*-rc? v1.7.8*
v1.7.8
v1.7.8.1
v1.7.8.2
v1.7.8.3
v1.7.8.4
$ git tag -l v1.7.8* \!*-rc?
v1.7.8
v1.7.8.1
v1.7.8.2
v1.7.8.3
v1.7.8.4
This is equivalent to,
$ git tag -l v1.7.8* | grep -v '\-rc.'
v1.7.8
v1.7.8.1
v1.7.8.2
v1.7.8.3
v1.7.8.4
Signed-off-by: Tom Grennan <tmgrennan@gmail.com>
---
builtin/tag.c | 13 +++++++++----
1 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/builtin/tag.c b/builtin/tag.c
index 31f02e8..b9ef718 100644
--- a/builtin/tag.c
+++ b/builtin/tag.c
@@ -32,13 +32,18 @@ struct tag_filter {
static int match_pattern(const char **patterns, const char *ref)
{
+ int ret;
+
/* no pattern means match everything */
if (!*patterns)
return 1;
- for (; *patterns; patterns++)
- if (!fnmatch(*patterns, ref, 0))
- return 1;
- return 0;
+ for (ret = 0; *patterns; patterns++)
+ if (**patterns == '!') {
+ if (!fnmatch(*patterns+1, ref, 0))
+ return 0;
+ } else if (!fnmatch(*patterns, ref, 0))
+ ret = 1;
+ return ret;
}
static int in_commit_list(const struct commit_list *want, struct commit *c)
--
1.7.8
^ permalink raw reply related
* [RFC/PATCH] tag: make list exclude !<pattern>
From: Tom Grennan @ 2012-02-09 19:43 UTC (permalink / raw)
To: git; +Cc: gitster, peff
Please see the following patch which filters the tag list of "!" prefaced
patterns. If this is deemed desirable and correct, I'll resubmit with updated
documentation and unit tests.
Thanks,
Tom Grennan (1):
tag: make list exclude !<pattern>
builtin/tag.c | 13 +++++++++----
1 files changed, 9 insertions(+), 4 deletions(-)
--
1.7.8
^ permalink raw reply
* Re: [PATCH v2 1/2] submodules: always use a relative path to gitdir
From: Junio C Hamano @ 2012-02-09 19:40 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Git Mailing List, Antony Male, Phil Hord
In-Reply-To: <4F33814E.7050404@web.de>
Jens Lehmann <Jens.Lehmann@web.de> writes:
> Since recently a submodule with name <name> has its git directory in the
I understand that "recently" refers to efc5fb6a77 and this is potentially
a maint material for v1.7.8.X; am I correct?
> The first version was whitespace damaged, please use this one instead.
Thanks.
When applied to v1.7.8.x maintenance track, this failed the first step in
t5526, but with the earlier jl/submodule-re-add topic everything seems to
pass just fine.
^ permalink raw reply
* Re: [PATCH 0/2] config includes, take 2
From: Jeff King @ 2012-02-09 19:33 UTC (permalink / raw)
To: Jakub Narebski; +Cc: David Aguilar, git
In-Reply-To: <201202092024.43381.jnareb@gmail.com>
On Thu, Feb 09, 2012 at 08:24:42PM +0100, Jakub Narebski wrote:
> > So the patch would look something like this. However, is the actual
> > filename really what callers want? It seems like in David's case, an
> > annotation of "repo", "global", or "system" (possibly in addition to the
> > filename) would be the most useful (because in the git-cola UI, it is
> > still nice to list things as "repo" or "global" instead of spewing the
> > whole filename at the user -- but you would still want the individual
> > filename for handling updates of includes).
>
> I'm not sure if "system" / "global" / "local" or "repo" would be a good
> idea.
>
> First, in the case of includes you would have to provide pathnames of
> included files. This would introduce inconsistency. Is "system"
> the '/etc/gitconfig' file, or 'system' file in '.git' directory?
Yeah, it would have to be syntactically unambiguous with the filename.
I was thinking something of just including both, like this:
global:/home/peff/.gitconfig<TAB>include.path=other-file
global:/home/peff/other-file<TAB>some.key=value
That is, give a "context" (repo, global, system) to each lookup, and
then mention the individual file as well (either because it is the root
of that context, or because it was included). So a config editor could
present the context to the user as a purely decorative thing (i.e., tell
the user "these options affect all of your repos"), but use the filename
to actually update the values (i.e., "git config -f
/home/peff/other-file some.key newvalue").
> Second, people can have different build configuration, e.g. the prefix
> might differ, so that "system" is not always '/etc/gitconfig'. If you
> want to edit config you would want to know which file to edit... and though
> there is "git config --system --edit" it depends on having editor
> configured correctly.
Without includes, something like git-cola could possibly get away with:
git config --system some.key value
but that doesn't work for included files; for those, you'd want to have
the actual filename.
-Peff
^ permalink raw reply
* A note on modern git plus ancient meld ("wrong number of arguments")
From: Jeff Epler @ 2012-02-09 19:17 UTC (permalink / raw)
To: git
I note this just in case it helps someone else track down a similar
problem, not because I think any change needs to be made to git, as a
version of meld new enough to not be affected by this problem is 5 years
old.
At $DAYJOB, I recently encountered a problem after upgrading from (don't
laugh) git 1.7.1 to 1.7.8.3: one developer stated that meld failed to
run, instead displaying the error 'Wrong number of arguments (Got 5)'.
We determined that this user was running a very old version of meld
(1.1.1) from his home directory, as opposed to the also very old system
version of meld (1.1.5). It turns out that the check added in
f61bd9c mergetools/meld: Use '--output' when available
fails on meld 1.1.1, leading git to incorrectly believe the --output
flag is supporrted:
$ meld-1.1.1 --output /dev/null --help >/dev/null 2>&1; echo $?
0 # i.e., detected as supported
The test as written gives the correct ("not supported") result with meld
1.1.5:
$ meld-1.1.5 --output /dev/null --help >/dev/null 2>&1; echo $?
2 # i.e., detected as supported
so if you encounter the message 'Wrong number of arguments (Got 5)' from
meld, then check whether you have an ancient version of meld. If for
some reason you can't upgrade to at least 1.1.5, maybe you'd find the
following configuration flags useful:
[merge]
tool = ancientmeld
[mergetool "ancientmeld"]
cmd = meld-1.1.1 \"$LOCAL\" \"$MERGED\" \"$REMOTE\"
Jeff
^ permalink raw reply
* Re: [PATCH 0/2] config includes, take 2
From: Jakub Narebski @ 2012-02-09 19:24 UTC (permalink / raw)
To: Jeff King; +Cc: David Aguilar, git
In-Reply-To: <20120209033059.GA4347@sigill.intra.peff.net>
On Thu, 9 Feb 2012, Jeff King wrote:
> On Tue, Feb 07, 2012 at 11:16:47AM -0800, Jakub Narebski wrote:
> > Jeff King <peff@peff.net> writes:
> >
> > [...]
> > > Git-config could potentially help with that (and even simplify the
> > > current code) by allowing something like:
> > >
> > > $ git config --list-with-sources
> > > /home/peff/.gitconfig user.name=Jeff King
> > > /home/peff/.gitconfig user.email=peff@peff.net
> > > .git/config core.repositoryformatversion=0
> > > .git/config core.bare=false
> > > [etc]
> > >
> > > (you would use the "-z" form, of course, and the filenames would be
> > > NUL-separated, but I made up a human-readable output format above for
> > > illustration purposes).
> >
> > That would be _very_ nice to have (even without includes support).
> >
> > Filenames would be git-quoted like in ls-tree / diff-tree output without -z,
> > isn't it? And is that TAB or SPC as a separator?
>
> So the patch would look something like this. However, is the actual
> filename really what callers want? It seems like in David's case, an
> annotation of "repo", "global", or "system" (possibly in addition to the
> filename) would be the most useful (because in the git-cola UI, it is
> still nice to list things as "repo" or "global" instead of spewing the
> whole filename at the user -- but you would still want the individual
> filename for handling updates of includes).
I'm not sure if "system" / "global" / "local" or "repo" would be a good
idea.
First, in the case of includes you would have to provide pathnames of
included files. This would introduce inconsistency. Is "system"
the '/etc/gitconfig' file, or 'system' file in '.git' directory?
Second, people can have different build configuration, e.g. the prefix
might differ, so that "system" is not always '/etc/gitconfig'. If you
want to edit config you would want to know which file to edit... and though
there is "git config --system --edit" it depends on having editor
configured correctly.
Just my two cents.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [StGit PATCH] Parse commit object header correctly
From: Junio C Hamano @ 2012-02-09 19:04 UTC (permalink / raw)
To: Catalin Marinas
Cc: Karl Hasselström, Andy Green (林安廸), git
In-Reply-To: <CAHkRjk6dr=5wxm+iSC2_CSB-q3k2WG_Um+X7dwsy-H8tL508EA@mail.gmail.com>
Catalin Marinas <catalin.marinas@gmail.com> writes:
> On 8 February 2012 07:33, Junio C Hamano <gitster@pobox.com> wrote:
>> To allow parsing the header produced by versions of Git newer than the
>> code written to parse it, all commit parsers are expected to skip unknown
>> header lines, so that newer types of header lines can be added safely.
>> The only three things that are promised are:
>>
>> (1) the header ends with an empty line (just an LF, not "a blank line"),
>> (2) unknown lines can be skipped, and
>> (3) a header "field" begins with the field name, followed by a single SP
>> followed by the value.
>
> Thanks for looking into this. Is this the same as an email header? If
> yes, we could just use the python's email.Header.decode_header()
> function (I haven't tried yet).
If you are thinking about feeding everything up to the first empty line to
whatever is designed to parse email header, please don't. I do not think
they obey "skip unknown lines without barfing" rule [*1*], so we would be
back to square one if you did so.
The fix posted in this thread is necessary because the change to StGit
between v0.15 and v0.16 made to ignore lines starting with "encoding " was
a wrong way to work around the broken parser in v0.15 in the first place.
The parser assumed that (1) all whitespaces around the header lines can be
stripped, (2) the result after such stripping will always have at least
one whitespace so that line.split(None, 1) will never barf, and (3)
between the field name and its value there may be arbitrary number of
whitespace characters that can be ignored so that line.split(None, 1) is a
safe way to split it into a (key,value) pair. None of which is a safe
thing to assume. The rule for safe parsing is to ignore all lines it does
not understand without assuming anything, and I wrote the patch in this
thread to make sure it makes no such unwarranted assumption.
> BTW, does Git allow custom headers to be inserted by tools like StGit?
The header format is designed in such a way that it is safe for a parser
to silently ignore unknown cruft, but that also means tools that work on
an existing commit and produce a similar one, like "commit --amend", are
free to either ignore and drop them when creating a new commit out of the
original one, or replay it verbatim without adjusting them to the new
context they appear in. In that sense, they are technically "allowed",
but depending on the nature of the information you are putting there, it
semantically may or may not produce the desired result [*2*]. I would say
it is strongly discouraged to invent new types of header lines without
first consulting the people who maintain tools you must interoperate with,
so that they will also be aware of them, and hopefully their tools can be
adjusted to help you use them.
Sorry for the breakage and making you to deal with this post release. We
observed that recent StGit did not barf after we added "encoding " field
to Git, and assumed that StGit correctly ignored lines that it did not
understand, without inspecting its code.
At least we should have Cc'ed you guys directly when the change was being
discussed on the list.
[Footnote]
*1* I also suspect that it will handle a line that begins with a single SP
differently if you use email parsing rules. In a commit object header, the
content of such a line is appended to the value of the previous field
after turning that leading single SP into a LF, and the resulting value
will be a string that consists of multiple lines. The header folding rule
used for e-mail in RFC2822 is a way to represent a (logically) single line
as physically multiple lines, so the result of unfolding will become a
single line. This difference may not matter for the purpose of the
current StGit that understands nothing but tree/parent/author/committer,
but because we are discussing a forward-looking fix for its parser, I
wouldn't recommend "it does not matter because we do not currently care"
approach.
*2* For example, a line that begins with "gpgsig " is a field that records
the GPG signature of a commit itself (using "git commit -S"), and it
should not survive across "commit --amend". A line that begins with
"mergetag " is a field that records the tag information that was merged
from a side branch, and amending such a merge does not change what was
merged, so it should survive across "commit --amend".
^ permalink raw reply
* Re: git merge <tag>: Spawning an editor can't be disabled
From: Jonathan Nieder @ 2012-02-09 19:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Guido Günther, Johannes Sixt, git
In-Reply-To: <7vzkcrx4f2.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> If the editor is not spawned, there is no way for the user to review the
> result of signature verification before deciding to accept the merge.
> "git merge --no-edit v1.7.2" could error out saying "you cannot create
> this merge without reviewing". Or it could behave as if it was asked to
> "git merge --no-edit v1.7.2^0", dropping the signature verification and
> recording part altogether.
Others might want to read the tag message and check its signature,
even though the original committer was in a non-interactive rush.
Here's a toy patch (untested) to avoid wasting time verifying a
signature only to throw away the result. It's not actually a no-op,
since if conflicts are encountered, the operator who intervenes won't
get to see whether the signature was valid when her editor of choice
is launched.
diff --git i/builtin.h w/builtin.h
index 857b9c8a..62dffbdc 100644
--- i/builtin.h
+++ w/builtin.h
@@ -17,6 +17,7 @@ extern void prune_packed_objects(int);
struct fmt_merge_msg_opts {
unsigned add_title:1;
+ unsigned skip_tag_verification:1;
int shortlog_len;
};
diff --git i/builtin/fmt-merge-msg.c w/builtin/fmt-merge-msg.c
index c81a7fef..e99030d3 100644
--- i/builtin/fmt-merge-msg.c
+++ w/builtin/fmt-merge-msg.c
@@ -316,7 +316,8 @@ static void fmt_tag_signature(struct strbuf *tagbuf,
strbuf_add_lines(tagbuf, "# ", sig->buf, sig->len);
}
-static void fmt_merge_msg_sigs(struct strbuf *out)
+static void fmt_merge_msg_sigs(struct strbuf *out,
+ struct fmt_merge_msg_opts *opts)
{
int i, tag_number = 0, first_tag = 0;
struct strbuf tagbuf = STRBUF_INIT;
@@ -332,8 +333,8 @@ static void fmt_merge_msg_sigs(struct strbuf *out)
goto next;
len = parse_signature(buf, size);
- if (size == len)
- ; /* merely annotated */
+ if (size == len || opts->skip_tag_verification)
+ ; /* merely annotated, or caller disabled signature check */
else if (verify_signed_buffer(buf, len, buf + len, size - len, &sig)) {
if (!sig.len)
strbuf_addstr(&sig, "gpg verification failed.\n");
@@ -400,7 +401,7 @@ int fmt_merge_msg(struct strbuf *in, struct strbuf *out,
fmt_merge_msg_title(out, current_branch);
if (origins.nr)
- fmt_merge_msg_sigs(out);
+ fmt_merge_msg_sigs(out, opts);
if (opts->shortlog_len) {
struct commit *head;
diff --git i/builtin/merge.c w/builtin/merge.c
index c401106e..75e027b6 100644
--- i/builtin/merge.c
+++ w/builtin/merge.c
@@ -1295,6 +1295,10 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
opts.add_title = !have_message;
opts.shortlog_len = shortlog_len;
+ assert(0 <= option_edit);
+ if (option_commit && !option_edit)
+ opts.skip_tag_verification = 1;
+
fmt_merge_msg(&merge_names, &merge_msg, &opts);
if (merge_msg.len)
strbuf_setlen(&merge_msg, merge_msg.len - 1);
^ permalink raw reply related
* [PATCH 1/2] git-svn.perl: perform deletions before anything else
From: Steven Walter @ 2012-02-09 18:55 UTC (permalink / raw)
To: normalperson, git; +Cc: Steven Walter
If we delete a file and recreate it as a directory in a single commit,
we have to tell the server about the deletion first or else we'll get
"RA layer request failed: Server sent unexpected return value (405
Method Not Allowed) in response to MKCOL request"
---
git-svn.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 570d83d..520b02b 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -5391,7 +5391,7 @@ sub DESTROY {
sub apply_diff {
my ($self) = @_;
my $mods = $self->{mods};
- my %o = ( D => 1, R => 0, C => -1, A => 3, M => 3, T => 3 );
+ my %o = ( D => -2, R => 0, C => -1, A => 3, M => 3, T => 3 );
foreach my $m (sort { $o{$a->{chg}} <=> $o{$b->{chg}} } @$mods) {
my $f = $m->{chg};
if (defined $o{$f}) {
--
1.7.9.4.ge7a0d
^ permalink raw reply related
* [PATCH 2/2] git-svn.perl: fix a false-positive in the "already exists" test
From: Steven Walter @ 2012-02-09 18:55 UTC (permalink / raw)
To: normalperson, git; +Cc: Steven Walter
In-Reply-To: <1328813725-16638-1-git-send-email-stevenrwalter@gmail.com>
open_or_add_dir checks to see if the directory already exists or not.
If it already exists and is not a directory, then we fail. However,
open_or_add_dir did not previously account for the possibility that the
path did exist as a file, but is deleted in the current commit.
In order to prevent this legitimate case from failing, open_or_add_dir
needs to know what files are deleted in the current commit.
Unfortunately that information has to be plumbed through a couple of
layers.
---
git-svn.perl | 43 ++++++++++++++++++++++++++-----------------
1 files changed, 26 insertions(+), 17 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 520b02b..351e9e3 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -5147,7 +5147,7 @@ sub rmdirs {
}
sub open_or_add_dir {
- my ($self, $full_path, $baton) = @_;
+ my ($self, $full_path, $baton, $deletions) = @_;
my $t = $self->{types}->{$full_path};
if (!defined $t) {
die "$full_path not known in r$self->{r} or we have a bug!\n";
@@ -5156,7 +5156,7 @@ sub open_or_add_dir {
no warnings 'once';
# SVN::Node::none and SVN::Node::file are used only once,
# so we're shutting up Perl's warnings about them.
- if ($t == $SVN::Node::none) {
+ if ($t == $SVN::Node::none || defined($deletions->{$full_path})) {
return $self->add_directory($full_path, $baton,
undef, -1, $self->{pool});
} elsif ($t == $SVN::Node::dir) {
@@ -5171,17 +5171,18 @@ sub open_or_add_dir {
}
sub ensure_path {
- my ($self, $path) = @_;
+ my ($self, $path, $deletions) = @_;
my $bat = $self->{bat};
my $repo_path = $self->repo_path($path);
return $bat->{''} unless (length $repo_path);
+
my @p = split m#/+#, $repo_path;
my $c = shift @p;
- $bat->{$c} ||= $self->open_or_add_dir($c, $bat->{''});
+ $bat->{$c} ||= $self->open_or_add_dir($c, $bat->{''}, $deletions);
while (@p) {
my $c0 = $c;
$c .= '/' . shift @p;
- $bat->{$c} ||= $self->open_or_add_dir($c, $bat->{$c0});
+ $bat->{$c} ||= $self->open_or_add_dir($c, $bat->{$c0}, $deletions);
}
return $bat->{$c};
}
@@ -5238,9 +5239,9 @@ sub apply_autoprops {
}
sub A {
- my ($self, $m) = @_;
+ my ($self, $m, $deletions) = @_;
my ($dir, $file) = split_path($m->{file_b});
- my $pbat = $self->ensure_path($dir);
+ my $pbat = $self->ensure_path($dir, $deletions);
my $fbat = $self->add_file($self->repo_path($m->{file_b}), $pbat,
undef, -1);
print "\tA\t$m->{file_b}\n" unless $::_q;
@@ -5250,9 +5251,9 @@ sub A {
}
sub C {
- my ($self, $m) = @_;
+ my ($self, $m, $deletions) = @_;
my ($dir, $file) = split_path($m->{file_b});
- my $pbat = $self->ensure_path($dir);
+ my $pbat = $self->ensure_path($dir, $deletions);
my $fbat = $self->add_file($self->repo_path($m->{file_b}), $pbat,
$self->url_path($m->{file_a}), $self->{r});
print "\tC\t$m->{file_a} => $m->{file_b}\n" unless $::_q;
@@ -5269,9 +5270,9 @@ sub delete_entry {
}
sub R {
- my ($self, $m) = @_;
+ my ($self, $m, $deletions) = @_;
my ($dir, $file) = split_path($m->{file_b});
- my $pbat = $self->ensure_path($dir);
+ my $pbat = $self->ensure_path($dir, $deletions);
my $fbat = $self->add_file($self->repo_path($m->{file_b}), $pbat,
$self->url_path($m->{file_a}), $self->{r});
print "\tR\t$m->{file_a} => $m->{file_b}\n" unless $::_q;
@@ -5280,14 +5281,14 @@ sub R {
$self->close_file($fbat,undef,$self->{pool});
($dir, $file) = split_path($m->{file_a});
- $pbat = $self->ensure_path($dir);
+ $pbat = $self->ensure_path($dir, $deletions);
$self->delete_entry($m->{file_a}, $pbat);
}
sub M {
- my ($self, $m) = @_;
+ my ($self, $m, $deletions) = @_;
my ($dir, $file) = split_path($m->{file_b});
- my $pbat = $self->ensure_path($dir);
+ my $pbat = $self->ensure_path($dir, $deletions);
my $fbat = $self->open_file($self->repo_path($m->{file_b}),
$pbat,$self->{r},$self->{pool});
print "\t$m->{chg}\t$m->{file_b}\n" unless $::_q;
@@ -5357,9 +5358,9 @@ sub chg_file {
}
sub D {
- my ($self, $m) = @_;
+ my ($self, $m, $deletions) = @_;
my ($dir, $file) = split_path($m->{file_b});
- my $pbat = $self->ensure_path($dir);
+ my $pbat = $self->ensure_path($dir, $deletions);
print "\tD\t$m->{file_b}\n" unless $::_q;
$self->delete_entry($m->{file_b}, $pbat);
}
@@ -5392,10 +5393,18 @@ sub apply_diff {
my ($self) = @_;
my $mods = $self->{mods};
my %o = ( D => -2, R => 0, C => -1, A => 3, M => 3, T => 3 );
+ my %deletions;
+
+ foreach my $m (@$mods) {
+ if ($m->{chg} eq "D") {
+ $deletions{$m->{file_b}} = 1;
+ }
+ }
+
foreach my $m (sort { $o{$a->{chg}} <=> $o{$b->{chg}} } @$mods) {
my $f = $m->{chg};
if (defined $o{$f}) {
- $self->$f($m);
+ $self->$f($m, \%deletions);
} else {
fatal("Invalid change type: $f");
}
--
1.7.9.4.ge7a0d
^ permalink raw reply related
* Re: git merge <tag>: Spawning an editor can't be disabled
From: Johannes Sixt @ 2012-02-09 18:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonathan Nieder, Guido Günther, git
In-Reply-To: <7vzkcrx4f2.fsf@alter.siamese.dyndns.org>
Am 09.02.2012 19:11, schrieb Junio C Hamano:
> If the editor is not spawned, there is no way for the user to review the
> result of signature verification before deciding to accept the merge.
> "git merge --no-edit v1.7.2" could error out saying "you cannot create
> this merge without reviewing". Or it could behave as if it was asked to
> "git merge --no-edit v1.7.2^0", dropping the signature verification and
> recording part altogether.
It should behave as if the editor was spawned and the user did not
change the content of the commit message.
Use case: First, you merge ordinarily, that is, you review the signature
and the contents, and you are satisfied. Shortly later, you discover
that a fix should be applied before the merge. So you rewind the branch
before the merge, and commit the fix. Now you can repeat the merge with
--no-edit because you have already seen the contents.
Contrived? Dunno.
-- Hannes
^ permalink raw reply
* Re: [PATCH] Fix build problems related to profile-directed optimization
From: Junio C Hamano @ 2012-02-09 18:22 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Ted Ts'o, git
In-Reply-To: <4F338242.8080907@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Am 2/8/2012 19:53, schrieb Ted Ts'o:
>> Junio, any comments on my most recent spin of this patch? Any changes
>> you'd like to see?
>
> I need the following to unbreak my build on Windows.
Thanks; will apply.
> --- >8 ---
> From: Johannes Sixt <j6t@kdbg.org>
> Subject: [PATCH] Makefile: fix syntax for older make
>
> It is necessary to write the else branch as a nested conditional. Also,
> write the conditions with parentheses because we use them throughout the
> Makefile.
>
> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
> ---
> Makefile | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index bfc5daa..01a3c77 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1784,16 +1784,18 @@ endif
> # data gathering
> PROFILE_DIR := $(CURDIR)
>
> -ifeq "$(PROFILE)" "GEN"
> +ifeq ("$(PROFILE)","GEN")
> CFLAGS += -fprofile-generate=$(PROFILE_DIR) -DNO_NORETURN=1
> EXTLIBS += -lgcov
> export CCACHE_DISABLE=t
> V=1
> -else ifneq "$(PROFILE)" ""
> +else
> +ifneq ("$(PROFILE)","")
> CFLAGS += -fprofile-use=$(PROFILE_DIR) -fprofile-correction -DNO_NORETURN=1
> export CCACHE_DISABLE=t
> V=1
> endif
> +endif
>
> # Shell quote (do not use $(call) to accommodate ancient setups);
^ permalink raw reply
* Re: git merge <tag>: Spawning an editor can't be disabled
From: Junio C Hamano @ 2012-02-09 18:11 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Guido Günther, git
In-Reply-To: <20120209160803.GA5742@burratino>
Jonathan Nieder <jrnieder@gmail.com> writes:
>> as of 1.7.9 merging in a tag unconditionally spawns an editor. I tried
>> turning this of with --no-edit but to no avail. This is a behaviour
>> change that breaks tools like git-buildpackage. I wonder if this should
>> be turned off by default?
>
> Thanks. I can confirm this: ever since commit fab47d05 (merge: force
> edit and no-ff mode when merging a tag object, 2011-11-07), running
> "git checkout github/maint-1.5.6 && git merge --no-edit v1.7.2"
> launches an editor window despite the caller's request. And I agree
> that it is counter-intuitive.
Thanks; it is unquestionably a bug that "git merge --no-edit v1.7.2"
spawns an editor.
The real question is what should happen.
If the editor is not spawned, there is no way for the user to review the
result of signature verification before deciding to accept the merge.
"git merge --no-edit v1.7.2" could error out saying "you cannot create
this merge without reviewing". Or it could behave as if it was asked to
"git merge --no-edit v1.7.2^0", dropping the signature verification and
recording part altogether.
^ permalink raw reply
* Re: Merging tags does not fast-forward with git 1.7.9
From: Junio C Hamano @ 2012-02-09 18:05 UTC (permalink / raw)
To: Domenico Andreoli; +Cc: git
In-Reply-To: <20120209095415.GA19230@glitch>
Domenico Andreoli <cavokz@gmail.com> writes:
> with the recent changes in tag merging (I updated git to 1.7.9),
> my usual "git merge v3.X-rcY" command does not fast-forward any more.
Making "merge $tag" always record the signed tag information was the whole
point of the change in 1.7.9, so asking to merge a tag will *not* fast
forward by default anymore. "git merge v3.X-rcY^0" is a usable workaround
in the meantime; we are also cooking a fix for a typical case where you
ask for "git merge --ff-only v3.X-rcY" explicitly. This errored out
incorrectly, which was discovered and fixed early this week and is cooking
in the 'next' branch. We would like to push it out as part of 1.7.9.1, and
we would need help testing it. The more people test it sooner, the likelier
people will see more solid 1.7.9.1 release sooner.
> The editor is instead fired off and I have to fill the details of a
> merge commit, diverging from mainline as soon as I save and exit.
Yes, that "diverging from mainline" is really bad, and that is why we need
the fix to honor "--ff-only" (which is the way to make sure you do not
diverge) tested quicly so that we can push 1.7.9.1 out.
Thanks.
^ permalink raw reply
* Re: [StGit PATCH] Parse commit object header correctly
From: Jonathan Nieder @ 2012-02-09 17:51 UTC (permalink / raw)
To: Catalin Marinas
Cc: Junio C Hamano, Karl Hasselström,
Andy Green (林安廸), git
In-Reply-To: <CAHkRjk6dr=5wxm+iSC2_CSB-q3k2WG_Um+X7dwsy-H8tL508EA@mail.gmail.com>
Hi Catalin,
Catalin Marinas wrote:
> Thanks for looking into this. Is this the same as an email header? If
> yes, we could just use the python's email.Header.decode_header()
> function (I haven't tried yet).
They look like this:
encoding ISO8859-1
> BTW, does Git allow custom headers to be inserted by tools like StGit?
No. There is one list of supported headers, and this list is the
standards body that maintains it[*]. So if you end up needing an
extension to the commit object format, that can be done, but it needs
to be accepted here (and ideally checked by "git fsck", though it's
lagging a bit in that respect lately).
By the way, headers have a standard order to avoid spurious changes in
commit names from reordering. Additions so far have always happened
at the end, which is what makes checks by "git fsck" possible --- it
can't rule out an unrecognized header line being a standard field from
a future version of git, but it would be allowed to complain about
unrecognized fields before 'encoding', for example.
Thanks,
Jonathan
[*] http://thread.gmane.org/gmane.comp.version-control.git/138848/focus=138892
^ permalink raw reply
* Re: Merging tags does not fast-forward with git 1.7.9
From: Andreas Schwab @ 2012-02-09 16:30 UTC (permalink / raw)
To: Domenico Andreoli; +Cc: Dan Johnson, git
In-Reply-To: <20120209160419.GA28718@glitch>
Domenico Andreoli <cavokz@gmail.com> writes:
> This is Debian unstable, out-of-the-box git package 1.7.9-1.
>
> $ git reset --hard v3.3-rc2
> HEAD is now at 62aa2b5 Linux 3.3-rc2
> $ git merge --ff-only v3.3-rc3
> fatal: Not possible to fast-forward, aborting.
> $
Workaround:
$ git merge v3.3-rc3^{}
Updating 62aa2b5..d65b4e9
Fast-forward
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: Merging tags does not fast-forward with git 1.7.9
From: Domenico Andreoli @ 2012-02-09 16:18 UTC (permalink / raw)
To: Carlos Martín Nieto; +Cc: git
In-Reply-To: <1328803601.3416.0.camel@centaur.lab.cmartin.tk>
On Thu, Feb 09, 2012 at 05:06:41PM +0100, Carlos Martín Nieto wrote:
> On Thu, 2012-02-09 at 10:54 +0100, Domenico Andreoli wrote:
> > Hi,
> >
> > with the recent changes in tag merging (I updated git to 1.7.9),
> > my usual "git merge v3.X-rcY" command does not fast-forward any more.
> > Of course the initial head is something like "v3.X-rcZ" without any
> > change so that it should (and usually did) fast-forward to the new head.
> >
> > The editor is instead fired off and I have to fill the details of a
> > merge commit, diverging from mainline as soon as I save and exit.
> >
> > Is there any simple and clear explanation for this? Thank you.
> >
> > cheers,
> > Domenico
> >
> > ps: I admit I didn't follow the details about tag signatures so probably
> > I missed something that I shouldn't.
>
> This was discussed recently
>
> http://thread.gmane.org/gmane.comp.version-control.git/189825
The command I was looking for is:
$ git merge --ff-only v3.X-rcY^0
thanks,
Domenico
^ permalink raw reply
* Re: git merge <tag>: Spawning an editor can't be disabled
From: Jonathan Nieder @ 2012-02-09 16:08 UTC (permalink / raw)
To: Guido Günther; +Cc: git, Junio C Hamano
In-Reply-To: <20120209153431.GA24033@godiug.sigxcpu.org>
Hi,
Guido Günther wrote[1]:
> as of 1.7.9 merging in a tag unconditionally spawns an editor. I tried
> turning this of with --no-edit but to no avail. This is a behaviour
> change that breaks tools like git-buildpackage. I wonder if this should
> be turned off by default?
Thanks. I can confirm this: ever since commit fab47d05 (merge: force
edit and no-ff mode when merging a tag object, 2011-11-07), running
"git checkout github/maint-1.5.6 && git merge --no-edit v1.7.2"
launches an editor window despite the caller's request. And I agree
that it is counter-intuitive.
Here's a quick band-aid. Unlike the case of [2], this does not
suppress the pulling-signed-tag magic when it kicks in, so the
resulting commit will record the signature and message of the tag you
merged, even though you have not carefully looked it over. Not sure
if that's a good or bad thing yet.
Patch relies on "merge: use editor by default in interactive sessions"
from master. If this looks like a sane approach, I can resend with a
proposed log message and a test for t/t7600-merge.sh. (Or if someone
else wants to do it first, even better.)
Hmm?
Jonathan
[1] http://bugs.debian.org/659255
[2] http://thread.gmane.org/gmane.comp.version-control.git/189825/focus=189989
diff --git i/builtin/merge.c w/builtin/merge.c
index 62c7b681..c401106e 100644
--- i/builtin/merge.c
+++ w/builtin/merge.c
@@ -1323,7 +1323,8 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
if (merge_remote_util(commit) &&
merge_remote_util(commit)->obj &&
merge_remote_util(commit)->obj->type == OBJ_TAG) {
- option_edit = 1;
+ if (option_edit < 0)
+ option_edit = 1;
allow_fast_forward = 0;
}
}
^ permalink raw reply related
* Re: Merging tags does not fast-forward with git 1.7.9
From: Carlos Martín Nieto @ 2012-02-09 16:06 UTC (permalink / raw)
To: Domenico Andreoli; +Cc: git
In-Reply-To: <20120209095415.GA19230@glitch>
[-- Attachment #1: Type: text/plain, Size: 823 bytes --]
On Thu, 2012-02-09 at 10:54 +0100, Domenico Andreoli wrote:
> Hi,
>
> with the recent changes in tag merging (I updated git to 1.7.9),
> my usual "git merge v3.X-rcY" command does not fast-forward any more.
> Of course the initial head is something like "v3.X-rcZ" without any
> change so that it should (and usually did) fast-forward to the new head.
>
> The editor is instead fired off and I have to fill the details of a
> merge commit, diverging from mainline as soon as I save and exit.
>
> Is there any simple and clear explanation for this? Thank you.
>
> cheers,
> Domenico
>
> ps: I admit I didn't follow the details about tag signatures so probably
> I missed something that I shouldn't.
This was discussed recently
http://thread.gmane.org/gmane.comp.version-control.git/189825
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox