Re: [PATCH 3/3] rebase: refuse to rebase with -s ours

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:

> On Sun, 15 Nov 2009, Thomas Rast wrote:
>
>> Using the "ours" strategy with rebase just discards all changes, turning 
>> <branch> into <upstream> (or <newbase> if given).  This is unlikely to 
>> be what the user wants, so simply refuse to do it.
>
> "Unlikely" or "impossible"?

It is more like "very likely to be a mistake".

Our tradition has been to give them long enough rope, but the recent trend
is to consider ourselves experienced enough with various git workflows to
be capable of identifying not just "cannot possibly a meaningful request"
but also "almost always a mistake" cases, and tighten the rope to help
people from stumbling, I think.

But it needs more careful thought to avoid forbidding useful use cases,
and your input is hugely appreciated if you have doubts (even better, an
example of useful use case that will become impossible).

> Besides, I find it rather arbitrary that the "ours" strategy is refused, 
> but none of the user-provided merge strategies.  IOW disallowing "ours" 
> may very well foster unreasonable expectations.

I cannot read this quite clearly.  Unreasonable expectations being...?

 * "ours" is disallowed but anything else including user-provided ones are
   Ok, so we are allowed to circumvent this restriction by adding a
   synonym for "ours" as a user-defined one, and are encouraged to do
   so. ---that is a wrong message to send.  Is that what you mean?

 * strategy X, unlike "ours", is allowed, so users will have rights to
   expect use of X as a rebase strategy would yield useful result, but
   that is wrong---Dscho knows that merge strategy X (I cannot read which
   one you had in mind if this is what you are talking about) does not
   work well in this and that cases.  Is this what you mean, and if so
   what is X?

Perhaps you had something other than the above two in mind?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]