git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jens Lehmann <Jens.Lehmann@web.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: Antony Male <antony.male@gmail.com>,
	git@vger.kernel.org, iveqy@iveqy.com
Subject: Re: [PATCH] Submodules always use a relative path to gitdir
Date: Thu, 05 Jan 2012 23:52:54 +0100	[thread overview]
Message-ID: <4F0629C6.9010908@web.de> (raw)
In-Reply-To: <7vhb0csa6w.fsf@alter.siamese.dyndns.org>

Am 03.01.2012 23:17, schrieb Junio C Hamano:
> Jens Lehmann <Jens.Lehmann@web.de> writes:
> 
>> Not if we would implement a "if no worktree is set but we came here via
>> a gitfile, then take the directory the gitfile was found in as worktree"
>> heuristic. And that heuristic looks quite sane to me, as a gitfile can
>> only be found in a work tree, or am I missing something obvious here?
> 
> Like it wouldn't work without changes to the core side?

I totally agree that when just talking about being able to move the
superproject around that approach is more invasive than just adding
a relative core.worktree setting and is just not worth the hassle.

But I was also thinking about moving the submodule around inside the
superproject. Until the gitfile was used that meant just mv'ing the
submodule and changing the path in .gitmodules accordingly. Now you
also have to adjust the core.worktree setting and maybe also the
gitfile content (if you move the submodule out of the directory level
it lived in before).

One solution I can think of is to teach "git mv" about submodules and
let it do the necessary changes to .gitmodules (which seems to be a
good idea anyways), core.worktree and the gitfile. The manipulation of
core.worktree could be obsoleted by not using that setting but instead
implementing the heuristic I described above. And if the gitfile could
be taught somehow that a path in there is relative to the superprojects
root directory, then it would never have to be changed either, restoring
the behavior we had before introducing the gitfile.

So in the long run I suspect we might have to change core git anyways
to make moving submodules easy for the user (surely "git mv" and maybe
also the setup and gitfile code). Does that make more sense?

If not I'm fine with just setting core.worktree to a relative path in
the git-submodule.sh script (like I did for the gitfile). And I'll look
into teaching "git mv" about submodules right after that.

  reply	other threads:[~2012-01-05 22:53 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-29 21:00 [PATCH] Submodules always use a relative path to gitdir Antony Male
2011-12-29 22:40 ` Junio C Hamano
2011-12-31 21:28   ` Phil Hord
2012-01-03 18:45     ` Junio C Hamano
2012-01-03 19:58       ` Junio C Hamano
2012-01-01 14:58   ` Jens Lehmann
2012-01-03 18:27     ` Junio C Hamano
2012-01-03 22:10       ` Jens Lehmann
2012-01-03 22:17         ` Junio C Hamano
2012-01-05 22:52           ` Jens Lehmann [this message]
2012-01-06  0:11             ` Junio C Hamano
2012-01-06 14:26               ` Phil Hord
2012-01-06 15:07                 ` Nguyen Thai Ngoc Duy
2012-01-06 18:53                 ` Junio C Hamano
2011-12-29 22:48 ` Fredrik Gustafsson
2011-12-31 20:31 ` Phil Hord

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=4F0629C6.9010908@web.de \
    --to=jens.lehmann@web.de \
    --cc=antony.male@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=iveqy@iveqy.com \
    /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).