Re: git submodule update --merge

Johan Herland [off-list ref] writes:

I haven't received any replies to my attempt to describe the context in 
which "git submodule update --merge" is useful. A hint as to whether my 
argument is valid, or just crap, would be nice.

FWIW, I didn't find "rebase makes sense but merge doesn't" argument very
convincing to begin with.  Because the configuration variable is about
"update" action, I agree it makes sense to do

  submodule.<name>.update = checkout/rebase (checkout if unset)

from the UI standpoint.

I do not know what the sensible repertoire of options nor what the default
should be, though.  That's up to the submodule using people to sort out.

Hi,

On Mon, 25 May 2009, Junio C Hamano wrote:

Johan Herland [off-list ref] writes:

quoted

I haven't received any replies to my attempt to describe the context 
in which "git submodule update --merge" is useful. A hint as to 
whether my argument is valid, or just crap, would be nice.

FWIW, I didn't find "rebase makes sense but merge doesn't" argument very
convincing to begin with.

Well, that is probably because you are not forced by me to use submodules.

Because in the project I use submodules most heavily, there is one 
recurring theme: you cannot push to the submodules.  And by "you" I mean 
"a regular user".

So virtually all you do in these submodules cannot be pushed at all.  It 
has to be submitted to the respective submodule maintainer.

And guess what happens in such a case when you set that tentative "update" 
variable to "merge"?

Exactly.

FWIW I consider any scenario where the average users have push access to 
the submodule a toy scenario.

The rebase workflow is very useful in my project, so if it does not go 
into git.git, I'll just force my users to install a Git compiled from my 
git tree.

Ciao,
Dscho

On Mon, May 25, 2009 at 2:57 PM, Johannes Schindelin
[off-list ref] wrote:

Because in the project I use submodules most heavily, there is one
recurring theme: you cannot push to the submodules.  And by "you" I mean
"a regular user".

So virtually all you do in these submodules cannot be pushed at all.  It
has to be submitted to the respective submodule maintainer.

And guess what happens in such a case when you set that tentative "update"
variable to "merge"?

Exactly.

FWIW I consider any scenario where the average users have push access to
the submodule a toy scenario.

I have the same problem.  Out of curiosity, how do you handle the case
where you really need to make a change to the submodule and let your
team members see that change, even though the submodule's upstream is
slow and/or doesn't accept the patch?

In that situation, we've had to make local shared mirrors of all the
submodules and point .gitmodules at that.  But that would be your
"toy" scenario - our local users have push access to the submodule.

Thanks,

Avery

Hi,

On Mon, 25 May 2009, Avery Pennarun wrote:

On Mon, May 25, 2009 at 2:57 PM, Johannes Schindelin
[off-list ref] wrote:

quoted

Because in the project I use submodules most heavily, there is one
recurring theme: you cannot push to the submodules.  And by "you" I mean
"a regular user".

So virtually all you do in these submodules cannot be pushed at all.  It
has to be submitted to the respective submodule maintainer.

And guess what happens in such a case when you set that tentative "update"
variable to "merge"?

Exactly.

FWIW I consider any scenario where the average users have push access to
the submodule a toy scenario.

I have the same problem.  Out of curiosity, how do you handle the case
where you really need to make a change to the submodule and let your
team members see that change, even though the submodule's upstream is
slow and/or doesn't accept the patch?

In that situation, we've had to make local shared mirrors of all the
submodules and point .gitmodules at that.  But that would be your
"toy" scenario - our local users have push access to the submodule.

Happily enough, our changes were accepted so far.

For a few branches, though, the patches are not ready to be sent upstream 
(or, from a certain viewpoint, sometimes downstream) yet, so we do have 
local forks for those working on that.

Note, however, that even in this case, it is better to use 'rebase' rather 
than 'merge', for exactly the same (I almost wrote "unconvincing") reason 
as before.

Ciao,
Dscho

P.S.: in some cases, the submodules' "upstreams" are maintained by team 
members, but that is very much on purpose.  They are trusted maintainers, 
and there is no reason to let some young and maybe overly energetic 
friends push to such a trusted repository.

On Monday 25 May 2009, Junio C Hamano wrote:

Johan Herland [off-list ref] writes:

quoted

I haven't received any replies to my attempt to describe the context in
which "git submodule update --merge" is useful. A hint as to whether my
argument is valid, or just crap, would be nice.

FWIW, I didn't find "rebase makes sense but merge doesn't" argument very
convincing to begin with.  Because the configuration variable is about
"update" action, I agree it makes sense to do

quoted

  submodule.<name>.update = checkout/rebase (checkout if unset)

from the UI standpoint.

I do not know what the sensible repertoire of options nor what the
default should be, though.  That's up to the submodule using people to
sort out.

I suggest the default should be whatever "git submodule update" does today, 
which is what I've called 'checkout' above (i.e. it simply checks out the 
submodule commit, which naturally detaches the head).

If you prefer, I can split my previous patch in two; one that fixes the 
config variable, and one that adds "submodule update --merge", so that they 
can be evaluated separately. Hmm?


Have fun! :)

...Johan

-- 
Johan Herland, [off-list ref]
www.herland.net

On Monday 25 May 2009, Johannes Schindelin wrote:

On Mon, 25 May 2009, Avery Pennarun wrote:

quoted

On Mon, May 25, 2009 at 2:57 PM, Johannes Schindelin wrote:

quoted

Because in the project I use submodules most heavily, there is one
recurring theme: you cannot push to the submodules.  And by "you" I
mean "a regular user".

So virtually all you do in these submodules cannot be pushed at all.
 It has to be submitted to the respective submodule maintainer.

And guess what happens in such a case when you set that tentative
"update" variable to "merge"?

Exactly.

FWIW I consider any scenario where the average users have push access
to the submodule a toy scenario.

Well, in the scenario I described earlier, the project developers (your 
"average users") _do_ have push access to the submodules. And that scenario 
is certainly not a toy scenario.

quoted

I have the same problem.  Out of curiosity, how do you handle the case
where you really need to make a change to the submodule and let your
team members see that change, even though the submodule's upstream is
slow and/or doesn't accept the patch?

In that situation, we've had to make local shared mirrors of all the
submodules and point .gitmodules at that.  But that would be your
"toy" scenario - our local users have push access to the submodule.

For the purposes of this discussion, this is pretty close to the use case I 
described earlier in my scenario as well. Thanks, Avery, for presenting the 
argument in a more readable manner.

Happily enough, our changes were accepted so far.

For a few branches, though, the patches are not ready to be sent upstream
(or, from a certain viewpoint, sometimes downstream) yet, so we do have
local forks for those working on that.

Note, however, that even in this case, it is better to use 'rebase'
rather than 'merge', for exactly the same (I almost wrote "unconvincing")
reason as before.

Yes, and I have never argued that your "average users" should use 'merge'. 
Indeed I have not argued that 'merge' is suitable for your workflow _at_ 
_all_.

One of the guiding principles I have learned from earlier submodule 
discussions on this list, is that the git submodule commands should NOT 
impose restrictions on the workflows available to its users. But in this 
case you are using your own workflow to argue what should, and should not be 
part of the git submodule repertoire. I am arguing that there are 
_different_ workflows, with _different_ requirements where 'merge' would be 
a useful addition. Just because you won't ever use it, does not mean that it 
will not be useful to anybody else.

P.S.: in some cases, the submodules' "upstreams" are maintained by team
members, but that is very much on purpose.  They are trusted maintainers,
and there is no reason to let some young and maybe overly energetic
friends push to such a trusted repository.

Do you argue that protecting these "young and maybe overly energetic" 
developers from themselves should be hardcoded into the git submodule 
behaviour, in such a way that it obscures the availability of other 
alternative submodule workflows?


Have fun! :)

...Johan

-- 
Johan Herland, [off-list ref]
www.herland.net