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

Johannes Schindelin [off-list ref] writes:

On Sun, 15 Nov 2009, Thomas Rast wrote:

quoted

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?

Hi,

On Mon, 16 Nov 2009, Junio C Hamano wrote:

Johannes Schindelin [off-list ref] writes:

quoted

On Sun, 15 Nov 2009, Thomas Rast wrote:

quoted

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.

quoted

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.

I meant the following: if "rebase -s ours" refuses to run, but my boss has 
written this cunning merge strategy "superduper" which is equally unlikely 
to yield a sensible result, "rebase -s superduper" should still refuse to 
run, no?

Now, this scenario might be too rare to take care of, but maybe it shows 
that we have a design flaw here?

Ciao,
Dscho

P.S.: Please note that I do not make a case against Thomas' patch series.  
As gitzilla once said "I cannot provide alternative patches, so that's 
that".

Johannes Schindelin wrote:
[...]

As gitzilla once said "I cannot provide alternative patches, so that's 
that".

I'm not sure I actually said that [*1*] but I did point out that when 
there is an active discussion about which of multiple ways a feature can 
be implemented, the party that produces code usually gets their way.

[*1*] There was beer involved and I was jet-lagged so maybe I did say 
that when I meant what I wrote above.