Re: [RFC/PATCH] Implement poor-man's submodule support in pre-commit hook

2 messages, 2 authors, 2016-08-11 · open the first message on its own page

Re: [RFC/PATCH] Implement poor-man's submodule support in pre-commit hook

From: Junio C Hamano <hidden>
Date: 2016-08-11 20:25:39

Andy Parkins [off-list ref] writes:
Problems:
 - git-prune in the submodule could destroy supermodule-referenced
   commits
 - no checkout support
 - no merge support (other than what git provides for the .gitmodule
   file)
 - no check for dirty submodule before commit

Signed-off-by: Andy Parkins <redacted>
I do not think these are insurmountable.

As you fix them and enhance the support, I suspect you would
want a separate command to manage .gitmodule file and submodules
referenced by it.  I think it would be better to keep the patch
to the template to the minimum (for example, run "git submodule
update" if there is .gitmodules file at the toplevel), and
implement the body of the processing in "git-submodule.sh", or
something like that.

Re: [RFC/PATCH] Implement poor-man's submodule support in pre-commit hook

From: Andy Parkins <hidden>
Date: 2016-06-15 22:42:46

On Wednesday 2006 December 20 19:37, Junio C Hamano wrote:
I do not think these are insurmountable.
Me either.  I wasn't really sure how warmly these patches would be received, 
so thought some small patches that make the feature highly might be more 
palatable.  I actually don't think that the hook templates is the right place 
for this work; submodule support is not something you would customise 
per-repository, and so the hook scripts are manifestly the wrong place for 
this.
As you fix them and enhance the support, I suspect you would
want a separate command to manage .gitmodule file and submodules
referenced by it.  I think it would be better to keep the patch
to the template to the minimum (for example, run "git submodule
update" if there is .gitmodules file at the toplevel), and
implement the body of the processing in "git-submodule.sh", or
something like that.
That's an interesting idea.  I was thinking that git-commit itself would have 
been the final target; but I certainly don't have any problem with a separate 
command.


Andy
-- 
Dr Andy Parkins, M Eng (hons), MIEE
andyparkins@gmail.com
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help