* Re: crash on git diff-tree -Ganything <tree> for new files with textconv filter
From: Jeff King @ 2012-10-29 6:18 UTC (permalink / raw)
To: Peter Oberndorfer; +Cc: git, Junio C Hamano
In-Reply-To: <20121029060524.GB4457@sigill.intra.peff.net>
On Mon, Oct 29, 2012 at 02:05:24AM -0400, Jeff King wrote:
> > i have a file with exactly 12288(0x3000) bytes in the repository.
> > When the file is loaded, the data is placed luckily so the data end
> > falls at a page boundary.
> > Later diff_grep() calls regexec() which calls strlen() on the loaded buffer
> > and ends up reading beyond the actual data into the next page
> > which is not allocated and causes a pagefault.
> > Or it could possibly (randomly) match the regex on data that is not
> > actually part of a file...
>
> Yuck. For the most part, we treat blob content (and generally most
> object content) as a sized buffer. However, there are some spots which,
> either through laziness or because a code interface expects a string, we
> pass the value as a string. This works because the object-reading code
> puts an extra NUL at the end of our buffer to handle just such an
> instance. So we might prematurely end if the object contains embedded
> NULs, but we would never read past the end.
>
> The code to read the output of a textconv filter does not do this
> explicitly. I would think it would get it for free by virtue of reading
> into a strbuf, though. I'll try to investigate.
I can't seem to replicate the problem here, even under valgrind. Do you
have a minimal test case?
-Peff
^ permalink raw reply
* Re: crash on git diff-tree -Ganything <tree> for new files with textconv filter
From: Jeff King @ 2012-10-29 6:05 UTC (permalink / raw)
To: Peter Oberndorfer; +Cc: git, Junio C Hamano
In-Reply-To: <508D8DF7.7040007@arcor.de>
On Sun, Oct 28, 2012 at 08:56:39PM +0100, Peter Oberndorfer wrote:
> > The patch below should fix it. I added tests, but please try your
> > real-world test case on it to double-check.
>
> I tested your patch, but now it crashes for another reason :-)
Well, that's progress, right? :)
> i have a file with exactly 12288(0x3000) bytes in the repository.
> When the file is loaded, the data is placed luckily so the data end
> falls at a page boundary.
> Later diff_grep() calls regexec() which calls strlen() on the loaded buffer
> and ends up reading beyond the actual data into the next page
> which is not allocated and causes a pagefault.
> Or it could possibly (randomly) match the regex on data that is not
> actually part of a file...
Yuck. For the most part, we treat blob content (and generally most
object content) as a sized buffer. However, there are some spots which,
either through laziness or because a code interface expects a string, we
pass the value as a string. This works because the object-reading code
puts an extra NUL at the end of our buffer to handle just such an
instance. So we might prematurely end if the object contains embedded
NULs, but we would never read past the end.
The code to read the output of a textconv filter does not do this
explicitly. I would think it would get it for free by virtue of reading
into a strbuf, though. I'll try to investigate.
-Peff
^ permalink raw reply
* Re: [PATCH] pathspec.c: Fix some sparse warnings
From: Jeff King @ 2012-10-29 5:55 UTC (permalink / raw)
To: Ramsay Jones; +Cc: Nguyen Thai Ngoc Duy, git, GIT Mailing-list
In-Reply-To: <508D9EFF.3040900@ramsay1.demon.co.uk>
On Sun, Oct 28, 2012 at 09:09:19PM +0000, Ramsay Jones wrote:
> I asked Adam to squash this patch into his 'as/check-ignore' branch
> when he next re-rolled the branch. However, it appears that you
> resubmitted that branch instead ... :-D
>
> I don't know if this branch is ready to progress to next yet, but
> could somebody (yourself, Adam or Jeff?) please squash this into
> commit 1a88ae42 ("pathspec.c: move reusable code from builtin/add.c")
> before it hits next.
I squashed it into my version of as/check-ignore, but if we are
expecting a re-roll, please everybody remember to include it.
-Peff
^ permalink raw reply
* Re: [PATCH] builtin/config.c: Fix a sparse warning
From: Jeff King @ 2012-10-29 5:47 UTC (permalink / raw)
To: Ramsay Jones; +Cc: GIT Mailing-list
In-Reply-To: <508D9E15.1040105@ramsay1.demon.co.uk>
On Sun, Oct 28, 2012 at 09:05:25PM +0000, Ramsay Jones wrote:
> Sparse issues an "Using plain integer as NULL pointer" warning while
> checking a 'struct strbuf_list' initializer expression. The initial
> field of the struct has pointer type, but the initializer expression
> is given as '{0}'. In order to suppress the warning, we simply replace
> the initializer with '{NULL}'.
I slightly disagree with sparse here, as the 0 here is not about
explicitly setting the pointer, but is an idiomatic shorthand for
requesting static-like initialization (and it is purely a style thing,
not a bug, as 0 is a fine null pointer, even on platforms without
all-bits-zero null pointers).
But I think it is still worth changing in the name of
sparse-cleanliness. Thanks.
> I try to catch these types of warnings while the patches are still
> in the pu branch. I don't know how I missed this one, but I don't
> remember your 'jk/config-ignore-duplicates' branch being in pu.
>
> Sorry about that.
Not your fault. The time during which it would have been in pu was after
Junio left but before I had pushed out my pu. I did have it locally in
pu for a bit, but it ended up on next the first time it was published,
because the series had already received favorable review on the list in
the meantime.
But I forgot that some people may first see the new code via the
published pu, not the list (e.g., if they are pulling and building pu
routinely with sparse). I'll try to be better about making sure stuff
is actually published in pu for a cycle before merging to next.
-Peff
^ permalink raw reply
* Re: [PATCH v3 0/8] Fix GIT_CEILING_DIRECTORIES that contain symlinks
From: Lars Damerow @ 2012-10-29 5:34 UTC (permalink / raw)
To: David Aguilar
Cc: Junio C Hamano, Michael Haggerty, Jiang Xin, Lea Wiemann,
David Reiss, Johannes Sixt, git, Jeff King, Marc Jordan
In-Reply-To: <CAJDDKr4ki+NjSeuZpAU6bM=YAQ_3mdHCtawstdCqe9Ewvp=arQ@mail.gmail.com>
>From David Aguilar <davvid@gmail.com>, Sun, Oct 28, 2012 at 05:15:29PM -0700:
>
> In 8030e44215fe8f34edd57d711a35f2f0f97a0423 Lars added
> GIT_ONE_FILESYSTEM to fix a related issue.
> Do you guys have GIT_CEILING_DIRECTORIES set too?
Once GIT_DISCOVERY_ACROSS_FILESYSTEM (the eventual name for GIT_ONE_FILESYSTEM) was accepted, we stopped setting GIT_CEILING_DIRECTORIES in our environment.
Even so, the way our filesystems work, stat() or lstat() calls on the paths that we used to have in GIT_CEILING_DIRECTORIES wouldn't have caused a problem.
I don't personally have an objection to patches that explicitly access the GIT_CEILING_DIRECTORIES paths, but it seems like other folks' configurations could be harmed by them.
-lars
--
lars r. damerow :: button pusher :: pixar animation studios
^ permalink raw reply
* Re: Mistake in git-reset documentation
From: Jeff King @ 2012-10-29 5:38 UTC (permalink / raw)
To: Krzysztof Mazur; +Cc: Andreas Schwab, Bojan Petrović, git
In-Reply-To: <20121028141327.GB16686@shrek.podlesie.net>
On Sun, Oct 28, 2012 at 03:13:27PM +0100, Krzysztof Mazur wrote:
> The --mixed mode is also described as second mode, and saying that --mixed
> is default earlier may save some time wasted on reading --soft
> description.
>
> There is also small inconsequence in what <mode> is, just "mixed" or
> "--mixed".
Yeah, agreed on both.
> -- >8 --
> Subject: [PATCH] doc: git-reset: make "<mode>" optional
>
> The git-reset's "<mode>" is an optional argument, however it was
> documented as required.
>
> The "<mode>" is documented as one of: --soft, --mixed, --hard, --merge
> or --keep, so "<mode>" should be used instead of "--<mode>".
>
> Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net>
Thanks, this looks good to me.
-Peff
^ permalink raw reply
* Re: [PATCH v2] git-submodule add: Add -r/--record option.
From: Jeff King @ 2012-10-29 5:34 UTC (permalink / raw)
To: W. Trevor King; +Cc: Shawn Pearce, Jens Lehmann, Git, Nahor, Phil Hord
In-Reply-To: <20121028223431.GF26675@odin.tremily.us>
On Sun, Oct 28, 2012 at 06:34:31PM -0400, W. Trevor King wrote:
> On Sun, Oct 28, 2012 at 02:59:33PM -0700, Shawn Pearce wrote:
> > Looks like the Gerrit meaning is basically the same as Ævar's. Gerrit
> > updates the parent project as if you had done:
> >
> > $ git submodule foreach 'git checkout $(git config --file
> > $toplevel/.gitmodules submodule.$name.branch) && git pull'
> > $ git commit -a -m "Updated submodules"
> > $ git push
>
> Ah, good, then we *are* all using the option for the same thing.
That makes me more comfortable. Your patch adds support for setting the
variable initially. Does it need any special magic for maintenance, or
is it something that would always be updated by hand?
Right now, the variable is not an official git-submodule thing and it is
OK to say "you are on your own by setting and using it from external
tools". But as soon as we support setting it in the first place, it is
reasonable to claim it as a bug if we do not keep it up to date for
certain operations.
I'm not familiar enough with the workflows around branching submodules
to know whether any such operations actually exist.
-Peff
^ permalink raw reply
* Re: gitweb
From: Jeff King @ 2012-10-29 5:28 UTC (permalink / raw)
To: rh; +Cc: Jakub Narebski, git
In-Reply-To: <20121028165647.b79fe3fcb6784c4ae547439e@lavabit.com>
On Sun, Oct 28, 2012 at 04:56:47PM -0700, rh wrote:
> I'm not using gitweb I was thinking about using it and was looking at the
> cgi and saw this in this file:
> https://github.com/git/git/blob/master/gitweb/gitweb.perl
>
> I think I understand the intention but the outcome is wrong.
>
> our %highlight_ext = (
> # main extensions, defining name of syntax;
> # see files in /usr/share/highlight/langDefs/ directory
> map { $_ => $_ }
> qw(py c cpp rb java css php sh pl js tex bib xml awk bat ini spec tcl sql make),
> # alternate extensions, see /etc/highlight/filetypes.conf
> 'h' => 'c',
> map { $_ => 'sh' } qw(bash zsh ksh),
> map { $_ => 'cpp' } qw(cxx c++ cc),
> map { $_ => 'php' } qw(php3 php4 php5 phps),
> map { $_ => 'pl' } qw(perl pm), # perhaps also 'cgi'
> map { $_ => 'make'} qw(mak mk),
> map { $_ => 'xml' } qw(xhtml html htm),
> );
Yeah, this is wrong. The first map will eat the rest of the list, and
you will get "h => h", "cxx => cxx", and so forth. I do not know this
chunk of code, but that does not seem like it is the likely intent.
You could fix it with extra parentheses:
our %he = (
(map { $_ => $_ } qw(py c cpp ...)),
'h' => 'c',
(map { $_ => 'sh' } qw(bash zsh ksh)),
... etc ...
);
> I think the intent is better met with this, (the print is for show)
>
> our %he = ();
> $he{'h'} = 'c';
> $he{$_} = $_ for (qw(py c cpp rb java css php sh pl js tex bib xml awk bat ini spec tcl sql make));
> $he{$_} = 'cpp' for (qw(cxx c++ cc));
> $he{$_} = 'php' for (qw(php3 php4 php5 phps));
> $he{$_} = 'pl' for (qw(cgi perl pm));
> $he{$_} = 'make' for (qw(mak mk));
> $he{$_} = 'xml' for (qw(xhtml html htm));
> $he{$_} = 'sh' for (qw(bash zsh ksh));
That is more readable to me (though it does lose the obviousness that it
is a variable initialization).
Looks like this was broken since 592ea41 (gitweb: Refactor syntax
highlighting support, 2010-04-27). I do not use gitweb (nor highlight)
at all, but I'd guess the user-visible impact is that "*.h" files are
not correctly highlighted (unless highlight does this extension mapping
itself, but then why are we doing it here?).
Jakub, can you confirm the intent and a fix like the one above makes
things better?
-Peff
^ permalink raw reply
* Re: [PATCH v3 0/8] Fix GIT_CEILING_DIRECTORIES that contain symlinks
From: Michael Haggerty @ 2012-10-29 5:10 UTC (permalink / raw)
To: David Aguilar
Cc: Junio C Hamano, Jiang Xin, Lea Wiemann, David Reiss,
Johannes Sixt, git, Lars R. Damerow, Jeff King, Marc Jordan
In-Reply-To: <CAJDDKr4ki+NjSeuZpAU6bM=YAQ_3mdHCtawstdCqe9Ewvp=arQ@mail.gmail.com>
On 10/29/2012 01:15 AM, David Aguilar wrote:
> On Sat, Oct 20, 2012 at 11:51 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Michael Haggerty <mhagger@alum.mit.edu> writes:
>>
>>> This patch series has the side effect that all of the directories
>>> listed in GIT_CEILING_DIRECTORIES are accessed *unconditionally* to
>>> resolve any symlinks that are present in their paths. It is
>>> admittedly odd that a feature intended to avoid accessing expensive
>>> directories would now *intentionally* access directories near the
>>> expensive ones. In the above scenario this shouldn't be a problem,
>>> because /home would be the directory listed in
>>> GIT_CEILING_DIRECTORIES, and accessing /home itself shouldn't be
>>> expensive.
>>
>> Interesting observation. In the last sentence, "accessing /home"
>> does not exactly mean accessing /home, but accessing / to learn
>> about "home" in it, no?
>>
>>> But there might be other scenarios for which this patch
>>> series causes a performance regression.
>>
>> Yeah, after merging this to 'next', we should ask people who care
>> about CEILING to test it sufficiently.
>>
>> Thanks for rerolling.
>
> GIT_CEILING_DIRECTORIES was always about trying to avoid
> hitting them at all; they can be (busy) NFS volumes there.
>
> Here's the description from the 1.6.0 release notes:
>
> * A new environment variable GIT_CEILING_DIRECTORIES can be used to stop
> the discovery process of the toplevel of working tree; this may be useful
> when you are working in a slow network disk and are outside any working tree,
> as bash-completion and "git help" may still need to run in these places.
>
> In 8030e44215fe8f34edd57d711a35f2f0f97a0423 Lars added
> GIT_ONE_FILESYSTEM to fix a related issue.
> Do you guys have GIT_CEILING_DIRECTORIES set too?
>
> We use GIT_CEILING_DIRECTORIES and I'm pretty sure
> we don't want every git command hitting them, so this would
> be a regression when seen from the POV of our current usage
> of this variable, which would be a bummer.
I would certainly withdraw the patch series if it causes a performance hit.
The log message of the original commit (0454dd93bf) described the
following scenario: a /home partition under which user home directories
are automounted, and setting GIT_CEILING_DIRECTORIES=/home to avoid
hitting /home/.git, /home/.git/objects, and /home/objects (which would
attempt to automount those directories). I believe that this scenario
would not be slowed down by my patches.
How do you use GIT_CEILING_DIRECTORIES that the proposed changes cause a
slowdown?
> Is there another way to accomplish this without the performance hit?
> Maybe something that can be solved with configuration?
Without doing the symlink expansion there is no way for git to detect
that GIT_CEILING_DIRECTORIES contains symlinks and is therefore
ineffective. So the user has no warning about the misconfiguration
(except that git runs slowly).
On 10/29/2012 02:42 AM, Junio C Hamano wrote:
> Perhaps not canonicalize elements on the CEILING list ourselves? If
> we make it a user error to put symlinked alias in the variable, and
> document it clearly, wouldn't it suffice?
There may be no other choice. (That, and fix the test suite in another
way to tolerate a $PWD that involves symlinks.)
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: git push tags
From: Chris Rorvick @ 2012-10-29 2:15 UTC (permalink / raw)
To: Philip Oakley; +Cc: Johannes Sixt, Angelo Borsotti, git
In-Reply-To: <4B8097A9D6854CDFA27E7CF6574B37BA@PhilipOakley>
On Sun, Oct 28, 2012 at 4:49 PM, Philip Oakley <philipoakley@iee.org> wrote:
> From: "Chris Rorvick" <chris@rorvick.com> Sent: Sunday, October 28, 2012
> 7:59 PM
>
>> On Sun, Oct 28, 2012 at 1:15 PM, Johannes Sixt <j6t@kdbg.org> wrote:
>>>
>>> Tags are refs, just like branches. "Tags don't move" is just a
>>> convention, and git doesn't even respect it (except possibly in one
>>> place[1]). You can't reseat tags unless you use -f, which is exactly the
>>> same with branches, which you can't reseat unless you use -f.
>>>
>>> [1] By default, git fetch does not fetch tags that it already has.
>>
>>
>> Also, git checkout <tag> puts you on a detached HEAD. This seems
>> pretty significant with regard to Git respecting a "tags don't move"
>> convention.
>
>
> Surely the convention is the other way around. That is, it is branches that
> are _expected_ to move, hence unless you are checkout a branch (movable) you
> will be on a detached head at a fixed place/sha1 [aka not on a branch].
>
> The checking out of a tag action doesn't make it more or less significant.
Ah, that makes sense. Thanks. So it sounds like the solution should
be something more general than checking if the prefix is "refs/tags"
if I understand your point correctly.
Also, setting the status to REF_STATUS_REJECT_NONFASTFORWARD even when
it would be a fast-forward (does that terminology apply to non-branch
refs?) is confusing. It's already confusing that a failure to push a
tag tells me I need to fetch and merge in the changes.
Chris
^ permalink raw reply
* Re: [PATCH v3 0/8] Fix GIT_CEILING_DIRECTORIES that contain symlinks
From: Junio C Hamano @ 2012-10-29 1:42 UTC (permalink / raw)
To: David Aguilar
Cc: Michael Haggerty, Jiang Xin, Lea Wiemann, David Reiss,
Johannes Sixt, git, Lars R. Damerow, Jeff King, Marc Jordan
In-Reply-To: <CAJDDKr4ki+NjSeuZpAU6bM=YAQ_3mdHCtawstdCqe9Ewvp=arQ@mail.gmail.com>
David Aguilar <davvid@gmail.com> wrote:
>Is there another way to accomplish this without the performance hit?
Perhaps not canonicalize elements on the CEILING list ourselves? If we make it a user error to put symlinked alias in the variable, and document it clearly, wouldn't it suffice?
^ permalink raw reply
* Re: [PATCH v3 0/8] Fix GIT_CEILING_DIRECTORIES that contain symlinks
From: David Aguilar @ 2012-10-29 0:15 UTC (permalink / raw)
To: Junio C Hamano
Cc: Michael Haggerty, Jiang Xin, Lea Wiemann, David Reiss,
Johannes Sixt, git, Lars R. Damerow, Jeff King, Marc Jordan
In-Reply-To: <7v7gqkgvxe.fsf@alter.siamese.dyndns.org>
On Sat, Oct 20, 2012 at 11:51 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Michael Haggerty <mhagger@alum.mit.edu> writes:
>
>> This patch series has the side effect that all of the directories
>> listed in GIT_CEILING_DIRECTORIES are accessed *unconditionally* to
>> resolve any symlinks that are present in their paths. It is
>> admittedly odd that a feature intended to avoid accessing expensive
>> directories would now *intentionally* access directories near the
>> expensive ones. In the above scenario this shouldn't be a problem,
>> because /home would be the directory listed in
>> GIT_CEILING_DIRECTORIES, and accessing /home itself shouldn't be
>> expensive.
>
> Interesting observation. In the last sentence, "accessing /home"
> does not exactly mean accessing /home, but accessing / to learn
> about "home" in it, no?
>
>> But there might be other scenarios for which this patch
>> series causes a performance regression.
>
> Yeah, after merging this to 'next', we should ask people who care
> about CEILING to test it sufficiently.
>
> Thanks for rerolling.
GIT_CEILING_DIRECTORIES was always about trying to avoid
hitting them at all; they can be (busy) NFS volumes there.
Here's the description from the 1.6.0 release notes:
* A new environment variable GIT_CEILING_DIRECTORIES can be used to stop
the discovery process of the toplevel of working tree; this may be useful
when you are working in a slow network disk and are outside any working tree,
as bash-completion and "git help" may still need to run in these places.
In 8030e44215fe8f34edd57d711a35f2f0f97a0423 Lars added
GIT_ONE_FILESYSTEM to fix a related issue.
Do you guys have GIT_CEILING_DIRECTORIES set too?
We use GIT_CEILING_DIRECTORIES and I'm pretty sure
we don't want every git command hitting them, so this would
be a regression when seen from the POV of our current usage
of this variable, which would be a bummer.
Is there another way to accomplish this without the performance hit?
Maybe something that can be solved with configuration?
I'd be happy to lend a hand if you guys have some ideas
on how we can help keep it fast. Thoughts?
Original patches for those just joining us:
http://thread.gmane.org/gmane.comp.version-control.git/208102
--
David
^ permalink raw reply
* gitweb
From: rh @ 2012-10-28 23:56 UTC (permalink / raw)
To: git
I'm not using gitweb I was thinking about using it and was looking at the
cgi and saw this in this file:
https://github.com/git/git/blob/master/gitweb/gitweb.perl
I think I understand the intention but the outcome is wrong.
our %highlight_ext = (
# main extensions, defining name of syntax;
# see files in /usr/share/highlight/langDefs/ directory
map { $_ => $_ }
qw(py c cpp rb java css php sh pl js tex bib xml awk bat ini spec tcl sql make),
# alternate extensions, see /etc/highlight/filetypes.conf
'h' => 'c',
map { $_ => 'sh' } qw(bash zsh ksh),
map { $_ => 'cpp' } qw(cxx c++ cc),
map { $_ => 'php' } qw(php3 php4 php5 phps),
map { $_ => 'pl' } qw(perl pm), # perhaps also 'cgi'
map { $_ => 'make'} qw(mak mk),
map { $_ => 'xml' } qw(xhtml html htm),
);
I think the intent is better met with this, (the print is for show)
our %he = ();
$he{'h'} = 'c';
$he{$_} = $_ for (qw(py c cpp rb java css php sh pl js tex bib xml awk bat ini spec tcl sql make));
$he{$_} = 'cpp' for (qw(cxx c++ cc));
$he{$_} = 'php' for (qw(php3 php4 php5 phps));
$he{$_} = 'pl' for (qw(cgi perl pm));
$he{$_} = 'make' for (qw(mak mk));
$he{$_} = 'xml' for (qw(xhtml html htm));
$he{$_} = 'sh' for (qw(bash zsh ksh));
print "$he{$_} $_\n" for(sort {$he{$a} cmp $he{$b}} keys %he);
But then again maybe I misunderstood the intent. And maybe everyone's happy
with it as-is.
^ permalink raw reply
* Re: git push tags
From: Drew Northup @ 2012-10-28 23:58 UTC (permalink / raw)
To: Philip Oakley
Cc: Chris Rorvick, Johannes Sixt, Angelo Borsotti, git, Kacper Kornet
In-Reply-To: <4B8097A9D6854CDFA27E7CF6574B37BA@PhilipOakley>
On Sun, Oct 28, 2012 at 5:49 PM, Philip Oakley <philipoakley@iee.org> wrote:
> If I read it right it was where two users can tag two different commits with
> the same tag name [e.g. 'Release_V3.3'] and the last person to push wins, so
> anyone in the team can change what is to be the released version!
Philip,
Please look at Kacper's patch and Angelo's response to it. He seems to
be asking that tags not be permitted to be pushed as if doing so were
a "fast-forward" update.
This weekend I was, in part, trying to figure out what the correct CC
list for that patch would be, what the documentation change would be,
what changes would need to be made to the advice, what test would need
to be included, and so on to build a proper patch bundle. All of that
while tring to keep the house from "falling in" (I've been doing some
cleaning) and prepare for the Northeastern USA Coast to be doused and
blasted by Sandy in about a day and a half. If we decide to continue
in the path that Kacper and I have stumbled upon (with Angelo's
prodding) I'd appreciate a little help putting all of this together to
mesh with the aforementioned patch. (Heck, if there's somebody better
than me to take this over I'd be game for that too...)
--
-Drew Northup
--------------------------------------------------------------
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59
^ permalink raw reply
* [PATCH] Teach rm to remove submodules when given with a trailing '/'
From: Jens Lehmann @ 2012-10-28 23:28 UTC (permalink / raw)
To: Git Mailing List; +Cc: Jeff King
Doing a "git rm submod/" on a submodule results in an error:
fatal: pathspec 'submod/' did not match any files
This is really inconvenient as e.g. using TAB completion in a shell on a
submodule automatically adds the trailing '/' when it completes the path
of the submodule directory. The user has then to remove the '/' herself to
make a "git rm" succeed. Doing a "git rm -r somedir/" is working fine, so
there is no reason why that shouldn't work for submodules too.
Teach git rm to not error out when a '/' is appended to the path of a
submodule. Achieve this by chopping off trailing slashes from the path
names given if they represent directories. Add tests to make sure that
logic only applies to directories and not to files.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
---
This patch applies on top of the jl/submodule-rm branch merged into
current next.
builtin/rm.c | 7 +++++++
t/t3600-rm.sh | 17 +++++++++++++++++
2 files changed, 24 insertions(+)
diff --git a/builtin/rm.c b/builtin/rm.c
index 2aea3b5..5381d3f 100644
--- a/builtin/rm.c
+++ b/builtin/rm.c
@@ -234,6 +234,13 @@ int cmd_rm(int argc, const char **argv, const char *prefix)
if (read_cache() < 0)
die(_("index file corrupt"));
+ /* Remove trailing '/' from directories to find submodules in the index */
+ for (i = 0; i < argc; i++) {
+ size_t pathlen = strlen(argv[i]);
+ if (pathlen && is_directory(argv[i]) && (argv[i][pathlen - 1] == '/'))
+ argv[i] = xmemdupz(argv[i], pathlen - 1);
+ }
+
pathspec = get_pathspec(prefix, argv);
refresh_index(&the_index, REFRESH_QUIET, pathspec, NULL, NULL);
diff --git a/t/t3600-rm.sh b/t/t3600-rm.sh
index 97254e8..06f6384 100755
--- a/t/t3600-rm.sh
+++ b/t/t3600-rm.sh
@@ -302,6 +302,23 @@ test_expect_success 'rm removes work tree of unmodified submodules' '
test_cmp expect actual
'
+test_expect_success 'rm removes a submodule with a trailing /' '
+ git reset --hard &&
+ git submodule update &&
+ git rm submod/ &&
+ test ! -d submod &&
+ git status -s -uno --ignore-submodules=none > actual &&
+ test_cmp expect actual
+'
+
+test_expect_success 'rm fails when given a file with a trailing /' '
+ test_must_fail git rm empty/
+'
+
+test_expect_success 'rm succeeds when given a directory with a trailing /' '
+ git rm -r frotz/
+'
+
test_expect_success 'rm of a populated submodule with different HEAD fails unless forced' '
git reset --hard &&
git submodule update &&
--
1.8.0.42.g3346551
^ permalink raw reply related
* Re: [PATCH] pathspec.c: Fix some sparse warnings
From: Adam Spiers @ 2012-10-28 23:31 UTC (permalink / raw)
To: Ramsay Jones; +Cc: Nguyen Thai Ngoc Duy, Jeff King, GIT Mailing-list
In-Reply-To: <508D9EFF.3040900@ramsay1.demon.co.uk>
On Sun, Oct 28, 2012 at 9:09 PM, Ramsay Jones
<ramsay@ramsay1.demon.co.uk> wrote:
> Sparse issues a warning for all six external symbols defined in this
> file. In order to suppress the warnings, we include the 'pathspec.h'
> header file, which contains the relevant extern declarations for these
> symbols.
>
> Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
> ---
>
> Hi Nguyen,
>
> I asked Adam to squash this patch into his 'as/check-ignore' branch
> when he next re-rolled the branch. However, it appears that you
> resubmitted that branch instead ... :-D
>
> I don't know if this branch is ready to progress to next yet, but
> could somebody (yourself, Adam or Jeff?) please squash this into
> commit 1a88ae42 ("pathspec.c: move reusable code from builtin/add.c")
> before it hits next.
Noted - thanks a lot Ramsay. My diary is a bit gentler this week so
I'm hoping to get some attention back on these patch series.
^ permalink raw reply
* Re: [PATCH v2] git-submodule add: Add -r/--record option.
From: W. Trevor King @ 2012-10-28 22:34 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Jens Lehmann, W. Trevor King, Git, Nahor, Phil Hord
In-Reply-To: <CAJo=hJt_A5FCCcvR=sZ5Ni+-ZGq+MjxqkONbh9k+A46xBH9jzA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1605 bytes --]
On Sun, Oct 28, 2012 at 02:59:33PM -0700, Shawn Pearce wrote:
> Looks like the Gerrit meaning is basically the same as Ævar's. Gerrit
> updates the parent project as if you had done:
>
> $ git submodule foreach 'git checkout $(git config --file
> $toplevel/.gitmodules submodule.$name.branch) && git pull'
> $ git commit -a -m "Updated submodules"
> $ git push
Ah, good, then we *are* all using the option for the same thing.
> On Tue, Oct 23, 2012 at 2:57 PM, W. Trevor King <wking@tremily.us> wrote:
> > I'm not clear on what that means, but they accept special values like
> > '.', so their usage is not compatible with Ævar's proposal.
>
> "." is a special value to mean use the parent project's branch name.
> So its more like this:
>
> $ git submodule foreach 'git checkout $(git --git-dir $toplevel/.git
> read-ref HEAD | sed s,^refs/heads/,,) && git pull'
> $ git commit -a -m "Updated submodules"
> $ git push
>
> We use "." in Gerrit to make branching an entire forest of projects
> easier. Setting up dev-fix-yy in the parent project will automatically
> track dev-fix-yy in each submodule.
Ok. If we wanted "." expansion to be a general submodule thing, it
would add a special case to Phil's submodule_<var-name> export. I
don't think such a special case would be worth the mental overhead,
but obviously the Gerrit folks think it is. I don't care either way
on this one.
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v2] git-submodule add: Add -r/--record option.
From: Shawn Pearce @ 2012-10-28 21:59 UTC (permalink / raw)
To: Jens Lehmann; +Cc: W. Trevor King, Git, Nahor, Phil Hord
In-Reply-To: <508D9A12.6010104@web.de>
On Sun, Oct 28, 2012 at 1:48 PM, Jens Lehmann <Jens.Lehmann@web.de> wrote:
> Am 23.10.2012 22:55, schrieb W. Trevor King:
>> As Phil pointed out, doing anything with this variable is ambiguous:
>>
>> On Mon, Oct 22, 2012 at 06:03:53PM -0400, Phil Hord wrote:
>>> Some projects now use the 'branch' config value to record the tracking
>>> branch for the submodule. Some ascribe different meaning to the
>>> configuration if the value is given vs. undefined. For example, see
>>> the Gerrit submodule-subscription mechanism. This change will cause
>>> those workflows to behave differently than they do now.
>
> I don't have a problem with the amount or complexity of the code being
> added, But by adding that option we may be giving the impression that it
> is officially sanctioned, or that it will be kept up to date by further
> submodule commands. I added Shawn to the CC, maybe he can comment on how
> the "branch" setting is used in Gerrit and what he thinks about adding
> code to set that with "git submodule add -r <branch> ..." to core git.
Looks like the Gerrit meaning is basically the same as Ævar's. Gerrit
updates the parent project as if you had done:
$ git submodule foreach 'git checkout $(git config --file
$toplevel/.gitmodules submodule.$name.branch) && git pull'
$ git commit -a -m "Updated submodules"
$ git push
and it does this automatically each time the submodule's branch is
modified by the Gerrit server.
On Tue, Oct 23, 2012 at 2:57 PM, W. Trevor King <wking@tremily.us> wrote:
> I'm not clear on what that means, but they accept special values like
> '.', so their usage is not compatible with Ævar's proposal.
"." is a special value to mean use the parent project's branch name.
So its more like this:
$ git submodule foreach 'git checkout $(git --git-dir $toplevel/.git
read-ref HEAD | sed s,^refs/heads/,,) && git pull'
$ git commit -a -m "Updated submodules"
$ git push
We use "." in Gerrit to make branching an entire forest of projects
easier. Setting up dev-fix-yy in the parent project will automatically
track dev-fix-yy in each submodule.
^ permalink raw reply
* Re: git push tags
From: Philip Oakley @ 2012-10-28 21:49 UTC (permalink / raw)
To: Chris Rorvick, Johannes Sixt; +Cc: Angelo Borsotti, git
In-Reply-To: <CAEUsAPYREy=CvPxy_Mzh5icVQo3=NV-AMC096Op0WWODLPH47Q@mail.gmail.com>
From: "Chris Rorvick" <chris@rorvick.com> Sent: Sunday, October 28, 2012
7:59 PM
> On Sun, Oct 28, 2012 at 1:15 PM, Johannes Sixt <j6t@kdbg.org> wrote:
>> Tags are refs, just like branches. "Tags don't move" is just a
>> convention, and git doesn't even respect it (except possibly in one
>> place[1]). You can't reseat tags unless you use -f, which is exactly
>> the
>> same with branches, which you can't reseat unless you use -f.
>>
>> [1] By default, git fetch does not fetch tags that it already has.
>
> Also, git checkout <tag> puts you on a detached HEAD. This seems
> pretty significant with regard to Git respecting a "tags don't move"
> convention.
Surely the convention is the other way around. That is, it is branches
that are _expected_ to move, hence unless you are checkout a branch
(movable) you will be on a detached head at a fixed place/sha1 [aka not
on a branch].
The checking out of a tag action doesn't make it more or less
significant.
I think Angelo's original post should be reviewed to see if the issue
can now be restated in a manner that shows up the implied conflict.
If I read it right it was where two users can tag two different commits
with the same tag name [e.g. 'Release_V3.3'] and the last person to push
wins, so anyone in the team can change what is to be the released
version!
Philip
>
^ permalink raw reply
* [PATCH] submodule status: remove unused orig_* variables
From: Jens Lehmann @ 2012-10-28 21:37 UTC (permalink / raw)
To: Phil Hord; +Cc: Git Mailing List, phil.hord, Jeff King
In-Reply-To: <508AE4AB.4070209@web.de>
When renaming orig_args to orig_flags in 98dbe63d (submodule: only
preserve flags across recursive status/update invocations) the call site
of the recursive cmd_status was forgotten. At that place orig_args is
still passed into the recursion, which is always empty since then. This
did not break anything because the orig_flags logic is not needed at all
when a function from the submodule script is called with eval, as that
inherits all the variables set by the option parsing done in the first
level of the recursion.
Now that we know that orig_flags and orig_args aren't needed at all,
let's just remove them from cmd_status().
Thanks-to: Phil Hord <hordp@cisco.com>
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
---
Am 26.10.2012 21:29, schrieb Jens Lehmann:
> Am 26.10.2012 21:13, schrieb Phil Hord:
>> A test in t7404-submodule-foreach purports to test that
>> the --cached flag is properly noticed by --recursive calls
>> to the foreach command as it descends into nested
>> submodules. However, the test really does not perform this
>> test since the change it looks for is in a top-level
>> submodule handled by the first invocation of the command.
>> To properly test for the flag being passed to recursive
>> invocations, the change must be buried deeper in the
>> hierarchy.
>>
>> Move the change one level deeper so it properly verifies
>> the recursive machinery of the 'git submodule status'
>> command.
>
> Me thinks we should definitely do this.
And I also think this patch should go on top of Phil's patch after what
we learned so far.
I'm currently checking if we can also safely remove orig_flags from
cmd_update(). At least the test suite runs fine without it ...
git-submodule.sh | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index ab6b110..c287464 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -926,7 +926,6 @@ cmd_summary() {
cmd_status()
{
# parse $args after "submodule ... status".
- orig_flags=
while test $# -ne 0
do
case "$1" in
@@ -950,7 +949,6 @@ cmd_status()
break
;;
esac
- orig_flags="$orig_flags $(git rev-parse --sq-quote "$1")"
shift
done
@@ -990,7 +988,7 @@ cmd_status()
prefix="$displaypath/"
clear_local_git_env
cd "$sm_path" &&
- eval cmd_status "$orig_args"
+ eval cmd_status
) ||
die "$(eval_gettext "Failed to recurse into submodule path '\$sm_path'")"
fi
--
1.8.0.42.g2ea983b
^ permalink raw reply related
* Re: Removing unreachable objects in the presence of broken links?
From: Andreas Schwab @ 2012-10-28 21:34 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: git
In-Reply-To: <CAMuHMdUqUtDspOP2kE9wtGEr9aJHGGBG=HRomdY6NRa8gxar4A@mail.gmail.com>
Geert Uytterhoeven <geert@linux-m68k.org> writes:
> Is there a way to force removing unreachable objects in the presence of broken
> links?
Does it help to forcibly expire the reflogs?
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
* Removing unreachable objects in the presence of broken links?
From: Geert Uytterhoeven @ 2012-10-28 21:21 UTC (permalink / raw)
To: git
Hi,
I managed to have a few missing objects in my development Linux kernel
repository, which uses another Linux kernel clone as an alternate.
Fortunately nothing is lost, as all missing objects are unreachable.
Probably they were in a branch that has been rebased, and the objects existed
for a small timespan in the alternate when I tried whether a patch created
in the development tree applied cleanly.
Is there a way to force removing unreachable objects in the presence of broken
links?
"git prune" doesn't do it, as it aborts when encountering the first
missing object.
Same with "git repack -[aA]d".
"git fsck" reported
broken link from tree 1330855dc33c1042b80d4c8ecbb6d56a19557ee8
to tree b6c8c53b804662d6a6435c62b6dec1612bfbeb46
broken link from tree f182e2fa155b9684b79ff6e17159d03d4de9a773
to blob d41f9ed0e2aba47ef62b4b4dd211b91cfe474ff8
missing blob d41f9ed0e2aba47ef62b4b4dd211b91cfe474ff8
missing tree b6c8c53b804662d6a6435c62b6dec1612bfbeb46
"git fsck --unreachable HEAD $(git for-each-ref
--format="%(objectname)" refs/heads)"
told me about lots of unreachable objects, including the tree objects that
contain the two broken links.
BTW, every time I now do a rebase that triggers a gc (after the actual rebase
operation has completed), I end up with "(no branch)", so I have to do:
git banch -D <branch>
git branch <branch>
git checkout <branch>
to get back on the branch.
This is with git version 1.7.0.4 (1:1.7.0.4-1ubuntu0.2).
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v2] git-submodule add: Add -r/--record option.
From: W. Trevor King @ 2012-10-28 21:16 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Git, Nahor, Phil Hord, Shawn O. Pearce
In-Reply-To: <508D9A12.6010104@web.de>
[-- Attachment #1: Type: text/plain, Size: 2764 bytes --]
On Sun, Oct 28, 2012 at 09:48:18PM +0100, Jens Lehmann wrote:
> Am 25.10.2012 02:53, schrieb W. Trevor King:
> > On Wed, Oct 24, 2012 at 09:15:32PM +0200, Jens Lehmann wrote:
> >> I still fail to see what adding that functionality to the submodule
> >> command buys us (unless we also add code which really uses the branch
> >> setting). What's wrong with doing a simple:
> >>
> >> git config -f .gitmodules submodule.<path>.branch <record_branch>
> >>
> >> on the command line when you want to use the branch setting for your
> >> own purposes? You could easily wrap that into a helper script, no?
> >
> > Sure. But why maintain my own helper script if I can edit
> > git-submodules.sh? It seems like a number of people are using this
> > config option, and they generally store the same name in it that they
> > use to create the submodule. This way I can save them time too.
>
> But people are already using the "branch" setting in *different* ways:
And they are usually storing the same string. Now, more easily. If
they want a different string, it is also easier. If they don't want
to use --record, they can do things however they were already doing
them. I don't see the problem.
> Am 23.10.2012 22:55, schrieb W. Trevor King:
> > As Phil pointed out, doing anything with this variable is ambiguous:
> >
> > On Mon, Oct 22, 2012 at 06:03:53PM -0400, Phil Hord wrote:
> >> Some projects now use the 'branch' config value to record the tracking
> >> branch for the submodule. Some ascribe different meaning to the
> >> configuration if the value is given vs. undefined. For example, see
> >> the Gerrit submodule-subscription mechanism. This change will cause
> >> those workflows to behave differently than they do now.
>
> I don't have a problem with the amount or complexity of the code being
> added, But by adding that option we may be giving the impression that it
> is officially sanctioned, or that it will be kept up to date by further
> submodule commands.
Storing something there will be officially sanctioned. Using it for
anything in particular will not be officially sanctioned. Phil's
submodule_<var-name> export in foreach will expose the variable so the
user can do whatever they think is appropriate with it, but it's still
up to the user to give the option some kind of semantic meaning.
> I added Shawn to the CC, maybe he can comment on how the "branch"
> setting is used in Gerrit and what he thinks about adding code to
> set that with "git submodule add -r <branch> ..." to core git.
Good idea.
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH] pathspec.c: Fix some sparse warnings
From: Ramsay Jones @ 2012-10-28 21:09 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git, Jeff King, GIT Mailing-list
Sparse issues a warning for all six external symbols defined in this
file. In order to suppress the warnings, we include the 'pathspec.h'
header file, which contains the relevant extern declarations for these
symbols.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
---
Hi Nguyen,
I asked Adam to squash this patch into his 'as/check-ignore' branch
when he next re-rolled the branch. However, it appears that you
resubmitted that branch instead ... :-D
I don't know if this branch is ready to progress to next yet, but
could somebody (yourself, Adam or Jeff?) please squash this into
commit 1a88ae42 ("pathspec.c: move reusable code from builtin/add.c")
before it hits next.
Thanks!
ATB,
Ramsay Jones
pathspec.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/pathspec.c b/pathspec.c
index a9c5b5b..efdabe4 100644
--- a/pathspec.c
+++ b/pathspec.c
@@ -1,5 +1,6 @@
#include "cache.h"
#include "dir.h"
+#include "pathspec.h"
void validate_path(const char *prefix, const char *path)
{
--
1.8.0
^ permalink raw reply related
* [PATCH] builtin/config.c: Fix a sparse warning
From: Ramsay Jones @ 2012-10-28 21:05 UTC (permalink / raw)
To: Jeff King; +Cc: GIT Mailing-list
Sparse issues an "Using plain integer as NULL pointer" warning while
checking a 'struct strbuf_list' initializer expression. The initial
field of the struct has pointer type, but the initializer expression
is given as '{0}'. In order to suppress the warning, we simply replace
the initializer with '{NULL}'.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
---
Hi Jeff,
I try to catch these types of warnings while the patches are still
in the pu branch. I don't know how I missed this one, but I don't
remember your 'jk/config-ignore-duplicates' branch being in pu.
Sorry about that.
ATB,
Ramsay Jones
builtin/config.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/config.c b/builtin/config.c
index f881053..e796af4 100644
--- a/builtin/config.c
+++ b/builtin/config.c
@@ -165,7 +165,7 @@ static int collect_config(const char *key_, const char *value_, void *cb)
static int get_value(const char *key_, const char *regex_)
{
int ret = CONFIG_GENERIC_ERROR;
- struct strbuf_list values = {0};
+ struct strbuf_list values = {NULL};
int i;
if (use_key_regexp) {
--
1.8.0
^ 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