From: Marc Branchaud <marcnarc@xiplink.com>
To: Jens Lehmann <Jens.Lehmann@web.de>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 0/2] Tests for some submodule corner cases.
Date: Tue, 31 May 2011 17:06:31 -0400 [thread overview]
Message-ID: <4DE55857.3090706@xiplink.com> (raw)
In-Reply-To: <4DE541EC.7010202@web.de>
On 11-05-31 03:30 PM, Jens Lehmann wrote:
> Am 30.05.2011 23:51, schrieb Marc Branchaud:
>> Ran across some submodule behavior that seems wrong to me. I don't have the
>> chops to fix the issues, so I thought I'd just point them out with some unit
>> tests.
>
> Thanks for bringing these issues to our attention this way, having a way
> to easily reproduce them is very much appreciated.
>
>> Patch 1 tests the case where "submodule add" fails if the path to the
>> submodule repo is relative (i.e. starts with "../"). This currently fails
>> with "remote (origin) does not have a url defined in .git/config". Maybe
>> there's a reason to fail? If so, a better error message would be appreciated.
>
> I stumbled across this behavior now and then too, but according to the
> commit it added (f31a522a2d) it is intended that adding a relative path
> behaves differently than using an absolute path (it resolves relative to
> the superproject's origin, not the filesystem, and to be able to do that
> the superproject's .git/config has to have an url defined for it). But
> you are right about the error message, it really isn't that helpful ...
>
>> Patch 2 exposes an anomaly in "submodule status", which reports that a
>> submodule is OK even though it has deleted files. "git status" inside
>> the submodule (and in the super-repo) both identify any deleted files, but
>> "submodule status" doesn't prefix the submodule's HEAD SHA-ID with a "+".
>
> That is documented behavior. "git submodule status" only cares about the
> commit recorded in the superproject vs the HEAD in the submodule, work
> tree modifications are never shown by it.
>
> But try a "git status" in the superproject, that will give you the following
> output:
> # modified: init (modified content)
I understand. My apologies for not reading the man page closely enough.
I know there's been a lot of recent work on making "git status"
submodule-friendly, but would there be any interest in having another prefix
for submodule status to cover this case? Maybe ! could indicate that the
submodule's HEAD is correct, but the working directory doesn't match it exactly.
M.
next prev parent reply other threads:[~2011-05-31 21:06 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-30 21:51 [PATCH 0/2] Tests for some submodule corner cases Marc Branchaud
2011-05-30 21:51 ` [PATCH 1/2] Added a test for "submodule add" using a ../relative/path/to/the/submodule/repo Marc Branchaud
2011-05-30 21:51 ` [PATCH 2/2] Added a test for "submodule status" when the submodule's working directory has deleted files Marc Branchaud
2011-05-31 19:30 ` [PATCH 0/2] Tests for some submodule corner cases Jens Lehmann
2011-05-31 20:00 ` [PATCH] submodule add: improve message when resolving a relative url fails Jens Lehmann
2011-05-31 20:57 ` Marc Branchaud
2011-05-31 21:34 ` [PATCH v2] " Jens Lehmann
2011-05-31 22:04 ` [PATCH] " Phil Hord
2011-06-01 15:55 ` Marc Branchaud
2011-07-27 19:00 ` Phil Hord
2011-07-29 20:10 ` Marc Branchaud
2011-05-31 23:23 ` Junio C Hamano
2011-06-01 15:56 ` [PATCH] Clarified how "git submodule add" handles relative paths Marc Branchaud
2011-06-01 16:59 ` Junio C Hamano
2011-06-01 19:55 ` Jens Lehmann
2011-06-02 17:14 ` Junio C Hamano
2011-06-03 19:51 ` Jens Lehmann
2011-06-03 23:16 ` Junio C Hamano
2011-06-04 2:23 ` Mark Levedahl
2011-06-04 15:39 ` Jens Lehmann
2011-06-04 16:19 ` Jens Lehmann
2011-06-05 18:27 ` Junio C Hamano
2011-06-06 19:56 ` [PATCH 0/3] submodule add: allow relative repository path even when no url is set Jens Lehmann
2011-06-06 19:57 ` [PATCH 1/3] submodule add: test failure when url is not configured in superproject Jens Lehmann
2011-06-06 19:58 ` [PATCH 2/3] submodule add: allow relative repository path even when no url is set Jens Lehmann
2011-06-06 20:49 ` [PATCH 0/2] Improve "git submodule add" documentation Marc Branchaud
2011-06-06 20:49 ` [PATCH 1/2] More precisely described how "git submodule add" handles relative submodule URLs Marc Branchaud
2011-06-06 20:49 ` [PATCH 2/2] Moved paragraph describing the utility of " Marc Branchaud
2011-06-06 19:58 ` [PATCH 3/3] submodule add: clean up duplicated code Jens Lehmann
2011-06-06 21:00 ` [PATCH 0/3] submodule add: allow relative repository path even when no url is set Junio C Hamano
2011-06-06 21:23 ` Marc Branchaud
2011-06-06 21:39 ` Jens Lehmann
2011-06-07 21:03 ` Jens Lehmann
2011-06-08 13:16 ` Phil Hord
2011-06-02 14:21 ` [PATCHv2] Clarified how "git submodule add" handles relative paths Marc Branchaud
2011-05-31 21:06 ` Marc Branchaud [this message]
2011-05-31 21:26 ` [PATCH 0/2] Tests for some submodule corner cases Jens Lehmann
2011-06-01 16:11 ` Marc Branchaud
2011-06-01 17:44 ` Junio C Hamano
2011-06-01 19:26 ` Jens Lehmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4DE55857.3090706@xiplink.com \
--to=marcnarc@xiplink.com \
--cc=Jens.Lehmann@web.de \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).