Johannes Sixt writes:
> Am 7/3/2013 21:53, schrieb Junio C Hamano:
>> Johannes Sixt writes:
>>
>>> I don't think that is necessary. We already have *two* options to
>>> force-push a ref: the + in front of refspec, and --force.
>>
>> They mean exactly the same thing; the only difference being t
Am 7/3/2013 21:53, schrieb Junio C Hamano:
> Johannes Sixt writes:
>
>> I don't think that is necessary. We already have *two* options to
>> force-push a ref: the + in front of refspec, and --force.
>
> They mean exactly the same thing; the only difference being that "+"
> prefix is per target r
Junio C Hamano writes:
> Jonathan del Strother writes:
>
>> I'm struggling to think of instances where I wouldn't want this
>> CAS-like behaviour. Wouldn't it be better to make it the default when
>> pushing, and allowing the current behaviour with "git push
>> --blind-force" or something?
>
>
Johannes Sixt writes:
> I don't think that is necessary. We already have *two* options to
> force-push a ref: the + in front of refspec, and --force.
They mean exactly the same thing; the only difference being that "+"
prefix is per target ref, while "--force" covers everything, acting
as a mere
Jonathan del Strother writes:
> I'm struggling to think of instances where I wouldn't want this
> CAS-like behaviour. Wouldn't it be better to make it the default when
> pushing, and allowing the current behaviour with "git push
> --blind-force" or something?
Not until we run this in the wild f
Johan Herland writes:
>> I'll leave the name open but tentatively use this name in the
>> following, primarily to see how well it sits on the command line
>> examples.
>
> I agree that neither --expect nor --validate are very good. I also
> don't like --lockref, mostly because there is no locking
Am 7/3/2013 12:50, schrieb Michael Haggerty:
> On 07/03/2013 12:11 PM, Johan Herland wrote:
>> On Wed, Jul 3, 2013 at 12:06 PM, Jonathan del Strother
>> wrote:
>>> I'm struggling to think of instances where I wouldn't want this
>>> CAS-like behaviour. Wouldn't it be better to make it the default
On 3 July 2013 11:00, Johan Herland wrote:
> On Wed, Jul 3, 2013 at 10:49 AM, Junio C Hamano wrote:
>> Johan Herland writes:
>>> Overnight, it occured to me that --force-if-expected could be
>>> simplified by leveraging the existing --force option; for the above
>>> two examples, respectively:
>
On 07/03/2013 12:11 PM, Johan Herland wrote:
> On Wed, Jul 3, 2013 at 12:06 PM, Jonathan del Strother
> wrote:
>> I'm struggling to think of instances where I wouldn't want this
>> CAS-like behaviour. Wouldn't it be better to make it the default when
>> pushing, and allowing the current behaviour
On Wed, Jul 3, 2013 at 12:06 PM, Jonathan del Strother
wrote:
> I'm struggling to think of instances where I wouldn't want this
> CAS-like behaviour. Wouldn't it be better to make it the default when
> pushing, and allowing the current behaviour with "git push
> --blind-force" or something?
I be
On Wed, Jul 3, 2013 at 10:49 AM, Junio C Hamano wrote:
> Johan Herland writes:
>> Overnight, it occured to me that --force-if-expected could be
>> simplified by leveraging the existing --force option; for the above
>> two examples, respectively:
>>
>> $ git push --force --expect
>> # validate
Johan Herland writes:
> Overnight, it occured to me that --force-if-expected could be
> simplified by leveraging the existing --force option; for the above
> two examples, respectively:
>
> $ git push --force --expect
> # validate foo @ origin == @{upstream} before pushing
>
> and
>
> $ git
On Wed, Jul 3, 2013 at 12:55 AM, Johan Herland wrote:
> I assume that in most cases the expected value of the remote ref would
> equal the current value of the corresponding remote-tracking ref in
> the user's repo, so why not use that as the default expected value?
> E.g.:
>
> $ git config push
On Tue, Jul 2, 2013 at 10:57 PM, Junio C Hamano wrote:
[...]
> (2) Add --compare-and-swap=dst:expect parameters, e.g.
>
> $ git push --cas=master:deadbabecafe --cas=next:cafebabe ":"
>
> This removes the "reservation" I expressed against (1) above
> (i.e. we are doing a "matc
Consider these two scenarios.
1. If you are collaborating with others and you have arranged with
the participants to rewind a shared branch, you would do
something like this:
$ git fetch origin branch
... fetch everything so that we won't lose anything ...
$ git chec
15 matches
Mail list logo
