Re: [PATCH 0/5] Fix 'url.*.insteadOf' for submodule URLs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Johan Herland <johan@xxxxxxxxxxx> writes:

> 1. Consistency: Other git commands in the supermodule does _not_ require the 
> URL rewriting rule to reside in the global config. Why should 'git 
> submodule' be different.

When it comes to "submodules", I do not think such consistency argument
makes much sense.  "git submodule" command crosses module boundary, normal
commands don't.  They are naturally different and they should be.

Your kind of consistency means breaking the separation between module
boundary, doesn't it?

Having said that...

> 2. I believe there are valid use cases for adding URL rewriting rules to the 
> repo config instead of the global config. You may want to check out Fred's 
> version of project X (including submodules), without making your other 
> clones of project X start cloning/fetching from Fred.

I think you are referring to the example given in an earlier thread to
peek what your neighbor did between you two, without affecting other
people.

Personally I think it is partly showing the shortcoming of the current
"git submodule" that minimally supports the workflow to follow what the
canonical repository does, and partly showing that it is an abuse of that
interface to rewrite config file to temporarily switch to peek somewhere
else in such a workflow.

Let's step back and think what we would do if there is no submodule
involved.  That is, you usually follow origin, but you temporarily want to
peek at what Fred did.  How would you do this?

	$ git fetch $fred $branch_fred_wants_you_to_review
        $ git checkout FETCH_HEAD ;# this detaches HEAD.

And you take a look around.  Perhaps you like the change and decide to
merge that to your branch.  Perhaps you create your own branch on top of
that state, build a few fix-up commits, and give the result back to Fred.

Shouldn't peeking what Fred did in the whole submodule hierarchy be
essentially the same thing?  That is,

	$ git submodule for-each-submodule sh -c '
                git fetch "$fred/$1" $branch_fred_wants_you_to_review &&
                git checkout FETCH_HEAD
	' -

where "for-each-submodule" would iterate over the submodules in the
current superproject that you are interested in (that is, you actually
have corresponding repositories there), and runs any given command with
the path to the submodule in that directory.

Hmm?

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux