Re: [PATCH 7/7] push: document --lockref
- From
Johannes Sixt <j6t@kdbg.org>
- Date
- Jul 12, 2013, 17:21 UTC
- Message-ID
- <51E03B18.5040502@kdbg.org>
- In-Reply-To
- <7vzjtspwvo.fsf@alter.siamese.dyndns.org>
Am 12.07.2013 00:14, schrieb Junio C Hamano:
Show 17 quoted lines
> Johannes Sixt <j6t@kdbg.org> writes: > >> Again: Why not just define +refspec as the way to achieve this check? > > What justification do we have to break existing people's > configuration that says something like: > > [remote "ko"] > url = kernel.org:/pub/scm/git/git.git > push = master > push = next > push = +pu > push = maint > > by adding a _new_ requirement they may not be able to satisify? > Notice that the above is a typical "push only" publishing point, > where you do not need any remote tracking branches.
Why would it break? When you do not specify --lockref, there is no change whatsoever.
To achieve any safety at all for these push-only refs, you have to be very explicit by saying --lockref=pu:$myoldpu --lockref=master:$myoldmaster etc, and what is wrong if in this case --lockref semantics are applied, but only pu is allowed to be no-ff?
Show 9 quoted lines
> I am not opposed if your proposal were to introduce a new syntax > element that calls for this new feature, e.g. > > [remote "ko"] > url = kernel.org:/pub/scm/git/git.git > push = *pu > fetch = +refs/heads/*:refs/remotes/ko/* > > but changing what "+" means to something new will simply not fly.
I still do not see why we need two different kinds of ways to spell the same strong kind of override (--force and +refspec) under the presence of --lockref, and why we need a third one (--allow-no-ff) to give a weaker kind of override (that makes sense only when --lockref was given in the first place).
-- Hannes