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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.