On Wed, Dec 11, 2013 at 03:16:24PM -0800, Junio C Hamano wrote:
> Jens Lehmann <jens.lehm...@web.de> writes:
> >> I think this is closely related to Martin's list of wishes we
> >> earlier saw in the thread: remind the user to push necessary
> >> submodule tip before the top-level commit that needs that commit in
> >> the submodule is pushed out. Giving projects a way to implement
> >> such a policy decision would be good, and having a default policy,
> >> if we can find one that would be reasonable for any submodule users,
> >> would be even better. Would adding a generic pre-push hook at the
> >> top-level sufficient for that kind of thing, I have to wonder.
> > That could call "git push --dry-run --recurse-submodules=check" to
> > deny the push if the submodule commit isn't on a remote branch.
> > that would only work for a single hardcoded remote, as the remote
> > itself does not seem to be passed to the pre-push hook.
> > So me thinks adding a configuration option for the --recurse-submodule
> > option of push is the best way to achieve that. This could be set to
> > "check" ...
> Yes, that uses only a single hard-coded decision, and making the
> branch name or remote name customizable is not enough, as you are
> still hardcoding "if ... isn't on" part. It is not far-fetched to
> imagine a project wants to add more restrictions to what commit in
> the submodule history can be bound to a tree of a published commit
> in the top-level project (e.g. "must be a tagged release point",
> "must be older at least by more than two weeks", "must be signed by
> one of these developers' keys", etc.).
> So I am not yet convinced that a simple "option" that supplies a few
> parameters to a single hard-coded policy is sufficient in the long
Well, for the implementation of --recurse-submodules=check on push we
tried to be as dumb as possible and just try to find out whether the
commit is on any remote. The reason is that when someone works on a
branch and pushes it for demonstration/backup/before holiday the most
common mistake is that he forgets to push the submodule when pushing the
superproject. So "some remote" seems to be the most common denominator
for push here. At least its better than no check at all.
For extended rules that answer questions like: "When am I allowed to
merge in master?" we need some kind of workflow definition from which we
can deduct such rules. A pre-push hook would allow to define rules but
how about an approach that is easier for the user and can maybe guide
him to the correct workflow.
I find workflow guidance is a general problem in git and even though we
use hooks at $dayjob they are not always sufficient. E.g. we enforce an
"all commits have to be reviewed first before they enter master" policy
which is correct in most situations. But for more lightweight projects I
would like to loosen this rule. The problem relies in the automatic
distribution of hooks or options for them by project instead of by
One idea: We could distribute a default set of enabled hooks that
implement several typical workflow options which can then be enabled by
simply choosing one option. The configuration should be distributeable
via the project e.g. a .githookconfig or .gitworkflowconfig ?
The git tools could then adapt their defaults depending on such a
workflow definition. But it also means we would first have to collect
and define some typical workflows.
What do others think? There probably have been other ideas about
workflow definitions already, no?
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html