Proposed config addition: submodules.denyNonFastForward

["R. Tyler Ballance" <tyler@slide.com>]

[-- Attachment #1: Type: text/plain, Size: 2458 bytes --]

In my previous thread regarding submodules "Manasging submodules on
large multi-user projects" I feel that some things were left largely
unresolved. My options given were:

  * Use repo (and retrain users)
  * Use Avery's git-subtree(1) addition (and potentially retrain)

After discussing some of the pitfalls that I've had with submodule
deployment with a kindred spirit in the #github channel, we came to the
conclusion that submodules would be very usable if one could implement a
"submodules.denyNonFastForward" configuration.


THE ERRORCASE:
--------------
The majority of problems with submodules comes from PEBKAC, where users
don't run `git submodule update` and/or the often execute `git commit -a` 
with nary a concern for whether it's a good idea or not. I concede that
these are systemic organizational changes, but I find changing software
to be well within the acheivable, whereas changing people I've
discovered is near-impossible. 

Problems occur in this scenario:

            -sub@A-  -sub@B-
[master] ------*--------*------->
                \        \
        [branch] `--------`---X (commit -a)

In the second merge from master to branch, if the user neglects to
execute `git submodule update` and then executes the commit at 'X' they
will inadvertantly change the index for the submodule to roll it back to
"A" instead of keeping it at "B" where it should be.



THE POTENTIAL SOLUTION (and it's problems)
------------------------------------------
The implementation details behind submodules.denyNonFastForward are
certainly not simple. 
   * Is it a server-side (bare repo) config value or a client side config value? 
     (I'm assuming it fits best client side). 
   * What if you have a submodule and you explicitly need to roll it
     back to a previous version of the submodule?
   * Does this cross the line of separation between super- and
     sub-module? Currently ths super (from my understanding) does not 
     contain or maintain any "knowledge" of the sub-module, it merely 
     is aware of a particular commit to detach the head to.


With the weekend coming up, I have some available coding time, and
certainly have no problems attempting to come up with a patch set to add
this configuration value, but I do need some guidance as to whether it
fits into Git conceptually and whether it's technically feasible.


Cheers

-R. Tyler Ballance
Slide, Inc.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]