* Re: Bug: git add with absolute path fails if repo root dir is a symlink
From: Carlo Marcelo Arenas Belon @ 2010-12-27 8:13 UTC (permalink / raw)
To: Alexander Gladysh; +Cc: git
In-Reply-To: <AANLkTimPxhqwMebfTw9oHucuvABmSBynpZgG1zp6uwVz@mail.gmail.com>
On Mon, Dec 27, 2010 at 10:23:12AM +0300, Alexander Gladysh wrote:
>
> > I can't run git add with absolute path if the repository's root
> > directory is a symlink.
>
> Note that this issue is also triggered if *any* of the directories in
> path above of my repo are symlinks.
When using absolute path names, git will compare the path given with the
git work tree and any name that is referred through a symlink in that
will trigger a mismatch.
> Is there a way to quickly workaround this somehow?
use relative paths (implemented below through an alias named "myadd") :
[alias]
myadd = "!sh -c 'cd `dirname \"$1\"` && git add `basename \"$1\"`' -"
so in your workflow you would use "myadd" instead of "add" to convert your
absolute paths (with symlinks) into relative paths
Carlo
^ permalink raw reply
* False positives in git diff-index
From: Alexander Gladysh @ 2010-12-27 8:49 UTC (permalink / raw)
To: git
Hi, list!
I wrote about the related issue earlier:
http://lists-archives.org/git/731516-false-positives-from-git-diff-index-when-used-with-git-dir.html
Now I've got a case when I can reproduce this problem each time I try to.
Unfortunately I can not share it or create a minimal example — the
case is triggered by a custom complicated automated build process on a
private repository.
Anyway, I'm ready to debug this issue if someone will guide me.
Workflow:
<...change files in /path/dir1/...>
(cd /path && git add </path/dir1/>)
(cd /path && git commit -m <message1>)
... repeat change-add-commit several times for various directories
(can be the same directory or not) ...
<...generate file /path/dirN/foo...>
# Accidentally the file is generated the same as it was
(cd /path && git add </path/dirN/>)
(cd /path && git status) # Refresh index
(cd /path && git diff-index --exit-code --quiet HEAD -- /path/dirN) #
Incorrectly reports that there are some changes
(cd /path && git commit -m <messageN>) # fails, saying that there is
nothing to commit
If I insert sleep 10 between git status and git diff-index, the
problem goes away.
Any help?
Alexander.
^ permalink raw reply
* Re: cherry-pick / pre-commit hook?
From: Jonathan Nieder @ 2010-12-27 9:37 UTC (permalink / raw)
To: Dave Abrahams; +Cc: git
In-Reply-To: <m2d3oo9cwr.wl%dave@boostpro.com>
Dave Abrahams wrote:
> if you're going to have a "pre-commit hook" concept,
> but not run that hook for some kinds of commits, then that fact needs
> to be documented.
True, and thanks for a reminder. Suggested wording?
The current githooks(5) says
pre-commit
This hook is invoked by git commit, and can be bypassed with
--no-verify option.
and leaves the question of whether it is invoked by git cherry-pick
unanswered.
^ permalink raw reply
* [PATCH] setup: translate symlinks in filename when using absolute paths
From: Carlo Marcelo Arenas Belon @ 2010-12-27 10:54 UTC (permalink / raw)
To: git
otherwise, comparison to validate against work tree will fail when
the path includes a symlink and the name passed is not canonical.
Signed-off-by: Carlo Marcelo Arenas Belon <carenas@sajinet.com.pe>
---
setup.c | 11 +++++++----
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/setup.c b/setup.c
index 91887a4..e7c0d4d 100644
--- a/setup.c
+++ b/setup.c
@@ -7,10 +7,13 @@ static int inside_work_tree = -1;
char *prefix_path(const char *prefix, int len, const char *path)
{
const char *orig = path;
- char *sanitized = xmalloc(len + strlen(path) + 1);
- if (is_absolute_path(orig))
- strcpy(sanitized, path);
- else {
+ char *sanitized;
+ if (is_absolute_path(orig)) {
+ const char *temp = make_absolute_path(path);
+ sanitized = xmalloc(len + strlen(temp) + 1);
+ strcpy(sanitized, temp);
+ } else {
+ sanitized = xmalloc(len + strlen(path) + 1);
if (len)
memcpy(sanitized, prefix, len);
strcpy(sanitized + len, path);
--
1.7.3.4.626.g73e7b.dirty
^ permalink raw reply related
* Re: [PATCH 3/3] Fixes bug: GIT_PS1_SHOWDIRTYSTATE is no not respect diff.ignoreSubmodules config variable
From: Jens Lehmann @ 2010-12-27 11:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Zapped, git, Johannes Schindelin
In-Reply-To: <7vd3ooz6qd.fsf@alter.siamese.dyndns.org>
Am 26.12.2010 20:14, schrieb Junio C Hamano:
> Jens Lehmann <Jens.Lehmann@web.de> writes:
>
>> So are there any reasons for the plumbing diff commands not to honor
>> the diff.ignoreSubmodules setting?
Thank you for explaining those reasons in detail.
> One class of plumbing users is scripts that is about automation and
> mechanization that want to control what they do precisely (think cron
> jobs) without getting affected by the user preference stored in the
> repository configuration. This class could either:
>
> (1) state what they want explicitly from the command line; or
> (2) rely on built-in defaults not changing underneath them.
>
> The behaviour of diff recursively inspecting submodule dirtiness has an
> unfortunate history, in that the behaviour changed over time, and in each
> step when we made a change, we thought we were making an unquestionable
> improvement. Originally we only said "submodule HEAD is different from
> what we have in the index/superproject HEAD". Later we added different
> kind of dirtiness like untracked files or modified contents in submodules,
> decided perhaps mistakenly that majority of users do want to see them as
> dirtiness and made that the default and allowed them to be ignored by an
> explicit request. At that point, in order not to break existing scripts
> (mostly of the "mechanization" class, written back when there was no such
> extra dirtyness hence with no "explicit refusal" route available to them
> without rewriting), hence "no configuration should affect plumbing
> randomly" policy.
Good point. But unfortunately the diff plumbing commands are affected by
the "submodule.<name>.ignore" ignore settings I introduced in August in
aee9c7d6 and 302ad7a9. Maybe we should revert the part of these patches
that changed the plumbing commands?
> On the other hand, you may write user facing Porcelain in scripts and run
> plumbing from there. This class of plumbing users could either:
>
> (1) inspect the config itself, interpret the customization and pass
> an explicit command line flag; or
>
> (2) allow the plumbing honor the end user configuration stored in the
> repository or user configuration files.
>
> It is argurably more convenient for these users if the plumbing blindly
> honored the configurations, as it would have allowed the latter
> implementation. That way, we can be more lazy when writing our scripts,
> and ignore having to worry about new kinds of customization added to
> underlying git after a script is written---but new kinds of customization
> may break your script's expectation of what will and what will not be made
> customizable, and you would end up giving an explicit "do not use that
> feature" in some cases, so the being able to be lazy is not necessarily
> always a win.
Agreed.
> Things may have been a bit different if the original feature change to
> inspect submodules deeper, command line flags to control that behaviour
> and configuration to default the flags came at the same time, but
> unfortunately they happend over time. I think we have been slowly getting
> better at this, but in the case of this particular feature, the original
> introduction of --ignore-submodules was in May 2008, deeper submodule
> inspection and the richer --ignore-submodules=<kind> option came much
> later in June 2010, and the configuration was invented later in August
> 2010, which would mean that allowing the plumbing to honor configuration
> would have broken scripts written in the 2 years and 3 months period.
>
> And no, this does not call for a blanket "do / do not honor configuration"
> option to plumbing commands. A more selective "do / do not honor these
> configuration variables" option might be an option, though.
What about a new "--ignore-submodules=config" option to tell the plumbing
that it should honor the config?
And it looks like the PS1 problem that started this discussion is a
valid example for mixed usage of porcelain and plumbing commands. In a
first attempt to fix the problem by using "git diff --cached" instead
of "git diff-index --cached" I noticed that those two commands give
different results when new submodules were created and had been added
to the index. "git diff --cached" ignores them while "git diff-index
--cached" shows them. Anything I am missing here?
^ permalink raw reply
* Re: Commiting automatically (2)
From: Jakub Narebski @ 2010-12-27 12:04 UTC (permalink / raw)
To: Maaartin-1; +Cc: git
In-Reply-To: <4D1190A6.4070201@seznam.cz>
On Wed, 22 Dec 2010, Maaartin-1 wrote:
> On 10-12-21 14:06, Jakub Narebski wrote:
>>
>> Please try to not cull Cc list (use 'reply via email', if possible)
>
> I don't know what "cull" means and
> http://dictionary.reference.com/browse/cull
> doesn't help me at all. Could you explain?
http://en.wiktionary.org/wiki/cull
to cull
[...]
3. To select animals from a group and then kill them in order to
reduce the numbers of the group in a controlled manner.
In the context ("to cull Cc list") it means removing entries from Cc
list (courtesy copy, copy-to), i.e. not replying to all people
participating in given (sub)thread.
>> Maaartin <grajcar1@seznam.cz> writes:
>>
>>> I let the snapshot point to the current head, which is where I get a problem now:
>>>
>>> git show-ref HEAD
>>>
>>> returns nothing,
>>>
>>> git show-ref --head
>>>
>>> returns HEAD and all branches and tags. Isn't it a bug? How can I get the HEAD
>>> reference? I'm using git version 1.7.2.3 on cygwin.
[...]
>> As for `git show-ref HEAD` - git-show-ref uses its own way of pattern
>> matching; in new enough version of git-show-ref manpage you can read
>> that:
>>
>> <pattern>...::
>>
>> Show references matching one or more patterns. Patterns are matched from
>> the end of the full name, and only complete parts are matched, e.g.
>> 'master' matches 'refs/heads/master', 'refs/remotes/origin/master',
>> 'refs/tags/jedi/master' but not 'refs/heads/mymaster' nor
>> 'refs/remotes/master/jedi'.
>>
>> So `git show-ref HEAD` would match 'refs/.../HEAD`, e.g. `refs/remotes/origin/HEAD`,
>> but not `HEAD` which is outside `refs/`.
>
> IMHO, it's quite broken. Alone it would be fine, but should really
> git-show-ref behave that different from git-symbolic-ref?
git-symbolic-ref is about querying and manipulating _single_ symbolic
reference, using fully qualified branch names (ref names).
git-show-ref is about querying multiple refs; I think the design goal
behind its strange pattern matching semantic is to make it easy to get
all refs with the same short name.
> Moreover, git-show-ref --head shows all branches and tags, this can't be
> right, can it? According to your above explanation, getting HEAD using a
> pattern is impossible, so I'd say that's what is "--head" good for.
>
> Moreover, "git-show-ref --heads" shows less than "git-show-ref --head",
> despite the plural.
"git show-ref --head" is strange in that it doesn't play well
with '--heads' and '--tags' and '<pattern>'.
I think it is a bit of misdesign, but I don't know how it should be
fixed; current output of "git show-ref --head" has to be kept because
of backward compatibility - git-show-ref is plumbing.
>> I tripped over strange git-show-ref <pattern> semantic too.
>>
>> P.S. there is also git-for-each-ref.
I don't know why there is git-show-ref when we have git-for-each-ref
for scripting; I guess they were added nearly at the same time...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [RFC/PATCH] diff: funcname and word patterns for perl
From: Junio C Hamano @ 2010-12-27 17:18 UTC (permalink / raw)
To: Jakub Narebski
Cc: Jonathan Nieder, git, J.H., John 'Warthog9' Hawley,
Thomas Rast, Jeff King
In-Reply-To: <201012270014.09962.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> 2. sub foo {
> FOO: while (1) {
> ...
> }
> }
>
> which should be marked with 'sub foo {', I think
I do not think Jonathan's patterns would be fooled by this; it wants to
catch only "package <anything>;" and "sub <anything> {".
Jonathan's pattern set allows them to be indented, and followed by some
garbage at the end., which we might want to tighten. How many people
start 'package' and the outermost 'sub' indented?
userdiff.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/userdiff.c b/userdiff.c
index fc2afe3..79569c4 100644
--- a/userdiff.c
+++ b/userdiff.c
@@ -62,8 +62,10 @@ PATTERNS("pascal",
"|<>|<=|>=|:=|\\.\\."
"|[^[:space:]]|[\x80-\xff]+"),
PATTERNS("perl",
- "^[ \t]*package .*;\n"
- "^[ \t]*sub .* \\{",
+ "^package .*;\n"
+ "^sub .* \\{\n"
+ "^[A-Z]+ \\{\n" /* BEGIN, END, ... */
+ "^=head[0-9] ", /* POD */
/* -- */
"[[:alpha:]_'][[:alnum:]_']*"
"|0[xb]?[0-9a-fA-F_]*"
^ permalink raw reply related
* Re: cherry-pick / pre-commit hook?
From: Junio C Hamano @ 2010-12-27 20:58 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Dave Abrahams, git
In-Reply-To: <20101227093729.GB1201@burratino>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Dave Abrahams wrote:
>
>> if you're going to have a "pre-commit hook" concept,
>> but not run that hook for some kinds of commits, then that fact needs
>> to be documented.
>
> True, and thanks for a reminder. Suggested wording?
>
> The current githooks(5) says
>
> pre-commit
> This hook is invoked by git commit, and can be bypassed with
> --no-verify option.
>
> and leaves the question of whether it is invoked by git cherry-pick
> unanswered.
Huh? Isn't it very clear that "git commit" calls it and "git status" or
anything that is not "git commit" doesn't?
^ permalink raw reply
* Re: [RFC/PATCH] cherry-pick/revert: add support for -X/--strategy-option
From: Jonathan Nieder @ 2010-12-27 21:25 UTC (permalink / raw)
To: git
Cc: Christian Couder, Justin Frankel, Bert Wesarg, Eyvind Bernhardsen,
Kevin Ballard, Junio C Hamano
In-Reply-To: <20101211005144.GA6634@burratino>
Jonathan Nieder wrote:
> For example, this would allow cherry-picking or reverting patches from
> a piece of history with a different end-of-line style, like so:
>
> $ git revert -Xrenormalize old-problematic-commit
>
> Currently that is possible with manual use of merge-recursive but the
> cherry-pick/revert porcelain does not expose the functionality.
>
> While at it, document the existing support for --strategy.
>
> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
> ---
> Thoughts?
Ping? I use this with -Xpatience fairly often. Am I the only one who
has wanted such a thing?
^ permalink raw reply
* Re: cherry-pick / pre-commit hook?
From: Dave Abrahams @ 2010-12-27 21:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonathan Nieder, git
In-Reply-To: <7vipyfx79g.fsf@alter.siamese.dyndns.org>
On Mon, Dec 27, 2010 at 11:58 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:
>
>> Dave Abrahams wrote:
>>
>>> if you're going to have a "pre-commit hook" concept,
>>> but not run that hook for some kinds of commits, then that fact needs
>>> to be documented.
>>
>> True, and thanks for a reminder. Suggested wording?
>>
>> The current githooks(5) says
>>
>> pre-commit
>> This hook is invoked by git commit, and can be bypassed with
>> --no-verify option.
>>
>> and leaves the question of whether it is invoked by git cherry-pick
>> unanswered.
>
> Huh? Isn't it very clear that "git commit" calls it and "git status" or
> anything that is not "git commit" doesn't?
Not to me. And is it really true? What about rebase? What about merge?
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
^ permalink raw reply
* Re: [RFC/PATCH] cherry-pick/revert: add support for -X/--strategy-option
From: Martin von Zweigbergk @ 2010-12-27 15:38 UTC (permalink / raw)
To: Jonathan Nieder
Cc: git, Christian Couder, Justin Frankel, Bert Wesarg,
Eyvind Bernhardsen, Kevin Ballard, Junio C Hamano
In-Reply-To: <20101227212515.GA32352@burratino>
On Mon, 27 Dec 2010, Jonathan Nieder wrote:
> Jonathan Nieder wrote:
>
> > For example, this would allow cherry-picking or reverting patches from
> > a piece of history with a different end-of-line style, like so:
> >
> > $ git revert -Xrenormalize old-problematic-commit
> >
> > Currently that is possible with manual use of merge-recursive but the
> > cherry-pick/revert porcelain does not expose the functionality.
> >
> > While at it, document the existing support for --strategy.
> >
> > Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
> > ---
> > Thoughts?
>
> Ping? I use this with -Xpatience fairly often. Am I the only one who
> has wanted such a thing?
FWIW, I have wanted it for the end-of-line scenario you describe
above.
/Martin
^ permalink raw reply
* Re: [PATCH 3/3] Fixes bug: GIT_PS1_SHOWDIRTYSTATE is no not respect diff.ignoreSubmodules config variable
From: Johannes Schindelin @ 2010-12-27 22:06 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Junio C Hamano, Zapped, git
In-Reply-To: <4D187511.3090104@web.de>
Hi Jens,
On Mon, 27 Dec 2010, Jens Lehmann wrote:
> [...]
>
> And it looks like the PS1 problem that started this discussion is a
> valid example for mixed usage of porcelain and plumbing commands.
The distinction between porcelain and plumbing commands is not as
clear-cut as some people would like it to be (just call "git grep 'git
log'" in a git.git checkout). IMHO the reason is that a distinction
between porcelain and plumbing makes sense in the world of sanitary
engineering, but not necessarily in the world of software (a distinction
between assembler vs source code, or GUI vs library makes sense, but not
between "programs to be called by humans" and "programs to be called by
other programs").
Note: I do not think that the "plumbing" concept was not well-intended,
but I doubt that the concept holds up in the face of reality.
I fear, though, that we cannot simply abolish the notion "plumbing vs
porcelain" from git.git...
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC/PATCH] cherry-pick/revert: add support for -X/--strategy-option
From: Justin Frankel @ 2010-12-27 22:07 UTC (permalink / raw)
To: Jonathan Nieder
Cc: git, Christian Couder, Bert Wesarg, Eyvind Bernhardsen,
Kevin Ballard, Junio C Hamano
In-Reply-To: <20101227212515.GA32352@burratino>
I think this is a good thing -- all commands that use an underlying
merge should support these options.
Would it make sense at some level to allow some other means of cleanly
passing this information around? Perhaps an environment variable for
merge options?
Jonathan Nieder wrote:
> Jonathan Nieder wrote:
>
>> For example, this would allow cherry-picking or reverting patches from
>> a piece of history with a different end-of-line style, like so:
>>
>> $ git revert -Xrenormalize old-problematic-commit
>>
>> Currently that is possible with manual use of merge-recursive but the
>> cherry-pick/revert porcelain does not expose the functionality.
>>
>> While at it, document the existing support for --strategy.
>>
>> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
>> ---
>> Thoughts?
>
> Ping? I use this with -Xpatience fairly often. Am I the only one who
> has wanted such a thing?
^ permalink raw reply
* Re: [PATCH 3/3] Fixes bug: GIT_PS1_SHOWDIRTYSTATE is no not respect diff.ignoreSubmodules config variable
From: Casey Dahlin @ 2010-12-27 22:43 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jens Lehmann, Junio C Hamano, Zapped, git
In-Reply-To: <alpine.DEB.1.00.1012272256560.1794@bonsai2>
On Mon, Dec 27, 2010 at 11:06:38PM +0100, Johannes Schindelin wrote:
> Note: I do not think that the "plumbing" concept was not well-intended,
> but I doubt that the concept holds up in the face of reality.
>
I've always felt that plumbing commands existed to expose the C portion of git
to the bash portion of git. As the latter shrinks plumbing commands make less
sense (and offering those commands as a library makes more sense, which is
unfortunately close to impossible in the current git source).
--CJD
^ permalink raw reply
* Re: [RFC/PATCH] diff: funcname and word patterns for perl
From: Jakub Narebski @ 2010-12-27 22:44 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jonathan Nieder, git, J.H., John 'Warthog9' Hawley,
Thomas Rast, Jeff King
In-Reply-To: <7vmxnrxhgm.fsf@alter.siamese.dyndns.org>
On Mon, 27 Dec 2010, Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
> > 2. sub foo {
> > FOO: while (1) {
> > ...
> > }
> > }
> >
> > which should be marked with 'sub foo {', I think
>
> I do not think Jonathan's patterns would be fooled by this; it wants to
> catch only "package <anything>;" and "sub <anything> {".
All right.
> Jonathan's pattern set allows them to be indented, and followed by some
> garbage at the end., which we might want to tighten. How many people
> start 'package' and the outermost 'sub' indented?
>
> userdiff.c | 6 ++++--
> 1 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/userdiff.c b/userdiff.c
> index fc2afe3..79569c4 100644
> --- a/userdiff.c
> +++ b/userdiff.c
> @@ -62,8 +62,10 @@ PATTERNS("pascal",
> "|<>|<=|>=|:=|\\.\\."
> "|[^[:space:]]|[\x80-\xff]+"),
> PATTERNS("perl",
> - "^[ \t]*package .*;\n"
> - "^[ \t]*sub .* \\{",
> + "^package .*;\n"
Note that in future Perl 5.14 there would be 'package NAME {' form,
so perhaps it would be better to future-proof and use
+ "^package .*[;{]\n"
> + "^sub .* \\{\n"
Using "sub foo {" is just a recommended programming convention (like e.g.
GNU convention or K&R convention for C code). I think it would be better
to relax it a bit, either
+ "^sub "
or
+ "^sub .*( \\{)?\n"
> + "^[A-Z]+ \\{\n" /* BEGIN, END, ... */
We won't list possible block here?
> + "^=head[0-9] ", /* POD */
> /* -- */
> "[[:alpha:]_'][[:alnum:]_']*"
> "|0[xb]?[0-9a-fA-F_]*"
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [RFC/PATCH] diff: funcname and word patterns for perl
From: Jeff King @ 2010-12-28 3:52 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jakub Narebski, Jonathan Nieder, git, J.H.,
John 'Warthog9' Hawley, Thomas Rast
In-Reply-To: <7vmxnrxhgm.fsf@alter.siamese.dyndns.org>
On Mon, Dec 27, 2010 at 09:18:17AM -0800, Junio C Hamano wrote:
> Jonathan's pattern set allows them to be indented, and followed by some
> garbage at the end., which we might want to tighten. How many people
> start 'package' and the outermost 'sub' indented?
FWIW, I sometimes do:
{
my $static;
sub foo {
... use $static ...
}
}
so perhaps allowing whitespace in front of the keyword is worthwhile
there. I have never indented "package", though.
-Peff
^ permalink raw reply
* git-svn bug: Could not unmemoize function `lookup_svn_merge' ...
From: George V. Reilly @ 2010-12-28 5:37 UTC (permalink / raw)
To: git
Using git version 1.7.3.2 on OS X 10.6.5 against the Subversion
repository at work, I got
georger@George-Reillys-MacBook-Pro-17:~/src/wc-git$ git svn rebase
M CoBranding/Resources/USA7/Resources.resx
M CoBranding/Resources/Resources.csproj
Byte order is not compatible at ../../lib/Storable.pm (autosplit
into ../../lib/auto/Storable/_retrieve.al) line 380, at
/System/Library/Perl/5.10.0/Memoize/Storable.pm line 21
Could not unmemoize function `lookup_svn_merge', because it was
not memoized to begin with at /usr/local/git/libexec/git-core/git-svn
line 3194
END failed--call queue aborted at
/usr/local/git/libexec/git-core/git-svn line 39.
The error was repeatable.
I managed to get past it by using the git-svn Perl script from Git 1.6.5.7,
per http://kerneltrap.org/mailarchive/git/2010/1/13/20137, and invoking it thus:
$ perl -I /usr/local/git/lib/perl5/site_perl/ ~/temp/git-svn.pl rebase
--
/George V. Reilly george@reilly.org Twitter: @georgevreilly
http://www.georgevreilly.com/blog http://blogs.cozi.com/tech
^ permalink raw reply
* Unable to delete remote branch with a strange name
From: Jingzhao Ou @ 2010-12-28 7:06 UTC (permalink / raw)
To: git
Hi, all,
When I checked out a git repository, it has the following remote branches:
$ git br -r
origin/HEAD -> origin/master
origin/master
origin/dev/main
origin/remotes/origin/dev/main
I tried to delete the last branch with a strange long name. Using "git push" to
delete it would fail.
$ git push origin :remotes/origin/dev/main
Pushing to jou@xx.xx.xx.xx:gsfw/omu_fw
error: dst refspec remotes/origin/dev/main matches more than one.
error: failed to push some refs to 'jou@xx.xx.xx.xx:gsfw/omu_fw'
However, I can create a new branch from it:
$ git co -b jou.temp origin/remotes/origin/dev/main
Branch jou.temp3 set up to track remote branch remotes/origin/dev/main
from origin.
Switched to a new branch 'jou.temp3'
But again, I cannot push any changes in "jou.temp3" branch to that weird branch:
$ git push origin HEAD:remotes/origin/dev/main
error: dst refspec remotes/origin/dev/main matches more than one.
error: failed to push some refs to 'jou@xx.xx.xx.xx:gsfw/omu_fw'
I guess somehow, git is confused by "origin/dev/main" and
"origin/remotes/origin/dev/main". Especially, it cannot identify the latter
properly.
I wonder if any one can give me some suggestions on how to deal with this
situation.
Thanks a lot!
Jingzhao
^ permalink raw reply
* Re: Unable to delete remote branch with a strange name
From: Andreas Schwab @ 2010-12-28 8:40 UTC (permalink / raw)
To: Jingzhao Ou; +Cc: git
In-Reply-To: <loom.20101228T080344-503@post.gmane.org>
Jingzhao Ou <jingzhao.ou@gmail.com> writes:
> I guess somehow, git is confused by "origin/dev/main" and
> "origin/remotes/origin/dev/main". Especially, it cannot identify the latter
> properly.
Try fully qualifying the remote branch (beginning with refs/heads/).
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
* [RFC/PATCH 0/4] improving svn-fe error handling
From: Jonathan Nieder @ 2010-12-28 10:45 UTC (permalink / raw)
To: git; +Cc: David Barr, Ramkumar Ramachandra, Sverre Rabbelier
Hi,
Currently malformed streams (e.g., ending early) and input errors when
reading a dump file can cause svn-fe to dereference a NULL pointer or
otherwise act in a confusing way. Especially since incremental
imports work now, I think a saner behavior is to error out with a
clear error message; the operator can then fix the problem and resume.
This series is an attempt in that direction.
Still to do:
- add tests (reading /dev/full? how else to provoke an input error?)
- change buffer_read_string to disallow short reads, to simplify
I am sending it out now because patches 1, 2, and 3 make API changes
that I find convenient, so I'd be interested in your thoughts before
I commit too heavily to a bad idea.
Patch 1 introduces buffer_ferror, to check if errors were encountered
reading from the line_buffer. Unlike buffer_deinit, this can be used
after any operation so it can be used early, when errno is still valid.
Patches 2 and 3 make operations that can be partially completed
still return some indication of success or failure.
Patch 4 is an example application, using the new API to make svn-fe
a little better at detecting malformed dump files.
Thoughts?
Jonathan Nieder (4):
vcs-svn: allow input errors to be detected promptly
vcs-svn: make buffer_skip_bytes return length read
vcs-svn: make buffer_copy_bytes return length read
vcs-svn: improve reporting of input errors
vcs-svn/fast_export.c | 13 +++++++++-
vcs-svn/line_buffer.c | 36 ++++++++++++++++++-------------
vcs-svn/line_buffer.h | 6 +++-
vcs-svn/line_buffer.txt | 3 +-
vcs-svn/svndump.c | 53 +++++++++++++++++++++++++++++++++++++---------
5 files changed, 80 insertions(+), 31 deletions(-)
^ permalink raw reply
* [PATCH 1/4] vcs-svn: allow input errors to be detected promptly
From: Jonathan Nieder @ 2010-12-28 10:47 UTC (permalink / raw)
To: git; +Cc: David Barr, Ramkumar Ramachandra, Sverre Rabbelier
In-Reply-To: <20101228104503.GA5422@burratino>
Date: Sun, 10 Oct 2010 21:51:21 -0500
The line_buffer library silently flags input errors until
buffer_deinit time; unfortunately, by that point usually errno is
invalid. Expose the error flag so callers can check for and
report errors early for easy debugging.
some_error_prone_operation(...);
if (buffer_ferror())
return error("input error: %s", strerror(errno));
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Has been in use for a while, but still I'd be interested to know
if this is sane.
vcs-svn/line_buffer.c | 5 +++++
vcs-svn/line_buffer.h | 1 +
2 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/vcs-svn/line_buffer.c b/vcs-svn/line_buffer.c
index 1543567..1b5ac8a 100644
--- a/vcs-svn/line_buffer.c
+++ b/vcs-svn/line_buffer.c
@@ -35,6 +35,11 @@ int buffer_deinit(void)
return err;
}
+int buffer_ferror(void)
+{
+ return ferror(infile);
+}
+
/* Read a line without trailing newline. */
char *buffer_read_line(void)
{
diff --git a/vcs-svn/line_buffer.h b/vcs-svn/line_buffer.h
index 9c78ae1..5a19873 100644
--- a/vcs-svn/line_buffer.h
+++ b/vcs-svn/line_buffer.h
@@ -3,6 +3,7 @@
int buffer_init(const char *filename);
int buffer_deinit(void);
+int buffer_ferror(void);
char *buffer_read_line(void);
char *buffer_read_string(uint32_t len);
void buffer_copy_bytes(uint32_t len);
--
1.7.2.3.554.gc9b5c.dirty
^ permalink raw reply related
* [PATCH 2/4] vcs-svn: make buffer_skip_bytes return length read
From: Jonathan Nieder @ 2010-12-28 10:48 UTC (permalink / raw)
To: git; +Cc: David Barr, Ramkumar Ramachandra, Sverre Rabbelier
In-Reply-To: <20101228104503.GA5422@burratino>
Date: Sun, 10 Oct 2010 21:44:21 -0500
Currently there is no way to detect when input ended if it ended
early during buffer_skip_bytes. Tell the calling program how many
bytes were actually skipped for easier debugging.
Existing callers will still ignore early EOF.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
vcs-svn/line_buffer.c | 13 +++++++------
vcs-svn/line_buffer.h | 2 +-
vcs-svn/line_buffer.txt | 3 ++-
3 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/vcs-svn/line_buffer.c b/vcs-svn/line_buffer.c
index 1b5ac8a..58e076f 100644
--- a/vcs-svn/line_buffer.c
+++ b/vcs-svn/line_buffer.c
@@ -86,14 +86,15 @@ void buffer_copy_bytes(uint32_t len)
}
}
-void buffer_skip_bytes(uint32_t len)
+uint32_t buffer_skip_bytes(uint32_t nbytes)
{
- uint32_t in;
- while (len > 0 && !feof(infile) && !ferror(infile)) {
- in = len < COPY_BUFFER_LEN ? len : COPY_BUFFER_LEN;
- in = fread(byte_buffer, 1, in, infile);
- len -= in;
+ uint32_t done = 0;
+ while (done < nbytes && !feof(infile) && !ferror(infile)) {
+ uint32_t len = nbytes - done;
+ uint32_t in = len < COPY_BUFFER_LEN ? len : COPY_BUFFER_LEN;
+ done += fread(byte_buffer, 1, in, infile);
}
+ return done;
}
void buffer_reset(void)
diff --git a/vcs-svn/line_buffer.h b/vcs-svn/line_buffer.h
index 5a19873..b9dd929 100644
--- a/vcs-svn/line_buffer.h
+++ b/vcs-svn/line_buffer.h
@@ -7,7 +7,7 @@ int buffer_ferror(void);
char *buffer_read_line(void);
char *buffer_read_string(uint32_t len);
void buffer_copy_bytes(uint32_t len);
-void buffer_skip_bytes(uint32_t len);
+uint32_t buffer_skip_bytes(uint32_t len);
void buffer_reset(void);
#endif
diff --git a/vcs-svn/line_buffer.txt b/vcs-svn/line_buffer.txt
index 8906fb1..a08ad8a 100644
--- a/vcs-svn/line_buffer.txt
+++ b/vcs-svn/line_buffer.txt
@@ -52,7 +52,8 @@ Functions
`buffer_skip_bytes`::
Discards `len` bytes from the input stream (stopping early
- if necessary because of an error or eof).
+ if necessary because of an error or eof). Return value is
+ the number of bytes successfully read.
`buffer_reset`::
Deallocates non-static buffers.
--
1.7.2.3.554.gc9b5c.dirty
^ permalink raw reply related
* [PATCH 3/4] vcs-svn: make buffer_copy_bytes return length read
From: Jonathan Nieder @ 2010-12-28 10:49 UTC (permalink / raw)
To: git; +Cc: David Barr, Ramkumar Ramachandra, Sverre Rabbelier
In-Reply-To: <20101228104503.GA5422@burratino>
Currently buffer_copy_bytes does not report to its caller whether
it encountered an early end of file.
Add a return value representing the number of bytes read (but not
the number of bytes copied). This way all three unusual conditions
can be distinguished: input error with buffer_ferror, output error
with ferror(outfile), input error or early end of input by checking
the return value.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Intuitive?
vcs-svn/line_buffer.c | 18 +++++++++---------
vcs-svn/line_buffer.h | 3 ++-
2 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/vcs-svn/line_buffer.c b/vcs-svn/line_buffer.c
index 58e076f..36f177c 100644
--- a/vcs-svn/line_buffer.c
+++ b/vcs-svn/line_buffer.c
@@ -71,19 +71,19 @@ char *buffer_read_string(uint32_t len)
return ferror(infile) ? NULL : s;
}
-void buffer_copy_bytes(uint32_t len)
+uint32_t buffer_copy_bytes(uint32_t nbytes)
{
- uint32_t in;
- while (len > 0 && !feof(infile) && !ferror(infile)) {
- in = len < COPY_BUFFER_LEN ? len : COPY_BUFFER_LEN;
+ uint32_t done = 0;
+ while (done < nbytes && !feof(infile) && !ferror(infile)) {
+ uint32_t len = nbytes - done;
+ uint32_t in = len < COPY_BUFFER_LEN ? len : COPY_BUFFER_LEN;
in = fread(byte_buffer, 1, in, infile);
- len -= in;
+ done += in;
fwrite(byte_buffer, 1, in, stdout);
- if (ferror(stdout)) {
- buffer_skip_bytes(len);
- return;
- }
+ if (ferror(stdout))
+ return done + buffer_skip_bytes(nbytes - done);
}
+ return done;
}
uint32_t buffer_skip_bytes(uint32_t nbytes)
diff --git a/vcs-svn/line_buffer.h b/vcs-svn/line_buffer.h
index b9dd929..7766636 100644
--- a/vcs-svn/line_buffer.h
+++ b/vcs-svn/line_buffer.h
@@ -6,7 +6,8 @@ int buffer_deinit(void);
int buffer_ferror(void);
char *buffer_read_line(void);
char *buffer_read_string(uint32_t len);
-void buffer_copy_bytes(uint32_t len);
+/* Returns number of bytes read (not necessarily written). */
+uint32_t buffer_copy_bytes(uint32_t len);
uint32_t buffer_skip_bytes(uint32_t len);
void buffer_reset(void);
--
1.7.2.3.554.gc9b5c.dirty
^ permalink raw reply related
* [PATCH 4/4] vcs-svn: improve reporting of input errors
From: Jonathan Nieder @ 2010-12-28 10:54 UTC (permalink / raw)
To: git; +Cc: David Barr, Ramkumar Ramachandra, Sverre Rabbelier
In-Reply-To: <20101228104503.GA5422@burratino>
Catch input errors and exit early enough to print a reasonable
diagnosis based on errno.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Patches 1 and 2 first appeared in the svndiff0 series[1] (and that
is the application I have in mind in sending them now).
This patch #4 is just a demo. Untested, I'm afraid. I would be
very interested in ideas for automatically testing it --- how to
easily stimulate error paths?
Good night,
Jonathan
[1] http://thread.gmane.org/gmane.comp.version-control.git/158731
vcs-svn/fast_export.c | 13 ++++++++++-
vcs-svn/svndump.c | 53 ++++++++++++++++++++++++++++++++++++++----------
2 files changed, 53 insertions(+), 13 deletions(-)
diff --git a/vcs-svn/fast_export.c b/vcs-svn/fast_export.c
index 256a052..dc0ae4e 100644
--- a/vcs-svn/fast_export.c
+++ b/vcs-svn/fast_export.c
@@ -62,14 +62,23 @@ void fast_export_commit(uint32_t revision, uint32_t author, char *log,
printf("progress Imported commit %d.\n\n", revision);
}
+static void die_short_read(void)
+{
+ if (buffer_ferror())
+ die_errno("error reading dump file");
+ die("invalid dump: unexpected end of file");
+}
+
void fast_export_blob(uint32_t mode, uint32_t mark, uint32_t len)
{
if (mode == REPO_MODE_LNK) {
/* svn symlink blobs start with "link " */
- buffer_skip_bytes(5);
len -= 5;
+ if (buffer_skip_bytes(5) != 5)
+ die_short_read();
}
printf("blob\nmark :%d\ndata %d\n", mark, len);
- buffer_copy_bytes(len);
+ if (buffer_copy_bytes(len) != len)
+ die_short_read();
fputc('\n', stdout);
}
diff --git a/vcs-svn/svndump.c b/vcs-svn/svndump.c
index 630eeb5..09bcebd 100644
--- a/vcs-svn/svndump.c
+++ b/vcs-svn/svndump.c
@@ -107,20 +107,37 @@ static void init_keys(void)
keys.content_length = pool_intern("Content-length");
}
+static void die_short_read(void)
+{
+ if (buffer_ferror())
+ die_errno("error reading dump file");
+ die("invalid dump: unexpected end of file");
+}
+
static void read_props(void)
{
uint32_t len;
uint32_t key = ~0;
char *val = NULL;
- char *t;
- while ((t = buffer_read_line()) && strcmp(t, "PROPS-END")) {
+ for (;;) {
+ char *t = buffer_read_line();
+ if (!t)
+ die_short_read();
+ if (!strcmp(t, "PROPS-END"))
+ return;
if (!strncmp(t, "K ", 2)) {
len = atoi(&t[2]);
- key = pool_intern(buffer_read_string(len));
- buffer_read_line();
+ t = buffer_read_line();
+ if (!t)
+ die_short_read();
+ if (strlen(t) != len)
+ die("invalid dump: incorrect key length");
+ key = pool_intern(t);
} else if (!strncmp(t, "V ", 2)) {
len = atoi(&t[2]);
val = buffer_read_string(len);
+ if (!t)
+ die_short_read();
if (key == keys.svn_log) {
/* Value length excludes terminating nul. */
rev_ctx.log = log_copy(len + 1, val);
@@ -135,7 +152,11 @@ static void read_props(void)
node_ctx.type = REPO_MODE_LNK;
}
key = ~0;
- buffer_read_line();
+ t = buffer_read_line();
+ if (!t)
+ die_short_read();
+ if (*t)
+ die("invalid dump: incorrect value length");
}
}
}
@@ -176,10 +197,12 @@ static void handle_node(void)
if (node_ctx.propLength == LENGTH_UNKNOWN && node_ctx.srcMode)
node_ctx.type = node_ctx.srcMode;
- if (node_ctx.mark)
+ if (node_ctx.mark) {
fast_export_blob(node_ctx.type, node_ctx.mark, node_ctx.textLength);
- else if (node_ctx.textLength != LENGTH_UNKNOWN)
- buffer_skip_bytes(node_ctx.textLength);
+ } else if (node_ctx.textLength != LENGTH_UNKNOWN) {
+ if (buffer_skip_bytes(node_ctx.textLength) != node_ctx.textLength)
+ die_short_read();
+ }
}
static void handle_revision(void)
@@ -250,7 +273,11 @@ void svndump_read(const char *url)
node_ctx.propLength = atoi(val);
} else if (key == keys.content_length) {
len = atoi(val);
- buffer_read_line();
+ t = buffer_read_line();
+ if (!t)
+ die_short_read();
+ if (*t)
+ die("invalid dump: expected blank line after content length header");
if (active_ctx == REV_CTX) {
read_props();
} else if (active_ctx == NODE_CTX) {
@@ -258,10 +285,13 @@ void svndump_read(const char *url)
active_ctx = REV_CTX;
} else {
fprintf(stderr, "Unexpected content length header: %d\n", len);
- buffer_skip_bytes(len);
+ if (buffer_skip_bytes(len) != len)
+ die_short_read();
}
}
}
+ if (buffer_ferror())
+ die_short_read();
if (active_ctx == NODE_CTX)
handle_node();
if (active_ctx != DUMP_CTX)
@@ -270,7 +300,8 @@ void svndump_read(const char *url)
void svndump_init(const char *filename)
{
- buffer_init(filename);
+ if (buffer_init(filename))
+ die_errno("cannot open dump file: %s", filename);
repo_init();
reset_dump_ctx(~0);
reset_rev_ctx(0);
--
1.7.2.3.554.gc9b5c.dirty
^ permalink raw reply related
* Re[2]: [PATCH 3/3] Fixes bug: GIT_PS1_SHOWDIRTYSTATE is no not respect diff.ignoreSubmodules config variable
From: Алексей Шумкин @ 2010-12-28 12:14 UTC (permalink / raw)
To: Jens Lehmann; +Cc: git, Johannes Schindelin
In-Reply-To: <4D15E48A.9050805@web.de>
Hi, all.
Well, I rolled back my so-called patch which rose up such a
discussion, and what I did see? Annoying behaviuor is vanished and perfomance of $PS1 is
acceptable (as fast as with the "patch").
I guess, as I said, something changed in Git since I discovered
and solved the problem such a weird way.
So, it seems to me, this patch might be considered unnecessary?
^ 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