jam> Vincent Ladeuil wrote:
>>>>>>> "jam" == John A Meinel writes:
>>
>> <snip/>
>>
jam> Also...
jam> We should *definitely* be checking:
jam> tree.last_revision() == tree.branch.last_revision()
jam> And possibly consider what to do in the case of bound
jam> branches and heavyweight checkouts. I'm not *as*
jam> concerned about the latter, but because in the former
jam> case, IIRC we will actually be pushing
jam> "tree.branch.last_revision()" *not*
jam> tree.last_revision()...
>>
>> Hmm, so far --strict is defined as triggering if there are
>> *uncommitted* changes, you're stretching the definition here...
jam> So I can agree that it is a different bug except:
jam> 1) I think 'bzr push --strict' is about 'push should
jam> push the state I *think* I have'.
I understood that :)
jam> And uncommitted changes, (uncommitted merges), and a
jam> tree last revision being out of sync with the branch's
jam> revision, are all cases where the push isn't pushing
jam> what the user expected.
Right. You're right. I agree with the rationale, but... I don't
clearly understand when a user can find itself in this
situation... I can see one case for a bound branch, except that I
can't commit in that situation so I have nothing to push... Or
maybe you mean a commit --local ? But in that case push should
already fail with "diverged branches" (strict or no strict) no ?
jam> 2) I think the source of '--strict' is MySQL fallout
jam> from switching from BK where a merge had autocommit so
jam> "bk merge; bk push" did something, while with bzr you
jam> need "bzr merge; bzr commit; bzr push".
<snip/>
I agree here too, mysql workflow wasn't my main reason for
agreeing about making --strict the default. In fact my first fix
addressed mysql workflow *without* making it he default.
I think the default should be strict because uneducated users
will easily forget to commit before pushing, and even experienced
ones may prefer, for some branches, to work in strict mode.
jam> 3) The fix is fairly trivial, the bug is somewhat
jam> serious, and you're already working on the code. Yes it
jam> is feature creep, but it is a small amount for something
jam> worthwhile (IMO).
I don't have a problem with working more on that, but I just
don't know how to write the tests (the what, not the how).
jam> I read your links, and while there wasn't a general
jam> discussion on it, Martin at least seems to agree it
jam> should be the default.
Sorry to have jumped to that conclusion without discussing it
first then.
jam> I'm just a bit extra sensitive to commandline behavioral
jam> changes. Since suddenly something that used to work
jam> won't anymore.
Well, I thought about that and I came to the conclusion that it's
pretty rare than one find itself in the situation to push while
having uncommitted changes. At least to me, it sounds like
advanced usage and I don't mind having to add an option in that
case, even if I didn't have to do it before, especially since I
can configure that behavior at any level.
jam> Also, note that "UncommittedChanges" has no help text to
jam> tell the user that they can use "--no-strict" in order
jam> to push anyway. I don't know if that matters or not. But
jam> since we are explictly changing a behavior, it is good
jam> to help users find out how to get their old behavior
jam> back.
Hmm, good point. First they need to be directed to 'bzr status'
and then to 'push --no-strict' though. I'll add something in that
direction before landing then, feel free to propose a better one,
there will be a follow-up submission obviously.
jam> Anyway, you can probably merge this as is, though I'd
jam> like it if you added a tree.last_revision() check.
Then let's discuss that after I land that patch because I just
don't know how to address your concern otherwise.
>>>>> "jam" == John A Meinel writes:
jam> Vincent Ladeuil wrote: revision( ) == tree.branch. last_revision( )
>>>>>>> "jam" == John A Meinel writes:
>>
>> <snip/>
>>
jam> Also...
jam> We should *definitely* be checking:
jam> tree.last_
jam> And possibly consider what to do in the case of bound last_revision( )" *not* revision( )...
jam> branches and heavyweight checkouts. I'm not *as*
jam> concerned about the latter, but because in the former
jam> case, IIRC we will actually be pushing
jam> "tree.branch.
jam> tree.last_
>>
>> Hmm, so far --strict is defined as triggering if there are
>> *uncommitted* changes, you're stretching the definition here...
jam> So I can agree that it is a different bug except:
jam> 1) I think 'bzr push --strict' is about 'push should
jam> push the state I *think* I have'.
I understood that :)
jam> And uncommitted changes, (uncommitted merges), and a
jam> tree last revision being out of sync with the branch's
jam> revision, are all cases where the push isn't pushing
jam> what the user expected.
Right. You're right. I agree with the rationale, but... I don't
clearly understand when a user can find itself in this
situation... I can see one case for a bound branch, except that I
can't commit in that situation so I have nothing to push... Or
maybe you mean a commit --local ? But in that case push should
already fail with "diverged branches" (strict or no strict) no ?
jam> 2) I think the source of '--strict' is MySQL fallout
jam> from switching from BK where a merge had autocommit so
jam> "bk merge; bk push" did something, while with bzr you
jam> need "bzr merge; bzr commit; bzr push".
<snip/>
I agree here too, mysql workflow wasn't my main reason for
agreeing about making --strict the default. In fact my first fix
addressed mysql workflow *without* making it he default.
I think the default should be strict because uneducated users
will easily forget to commit before pushing, and even experienced
ones may prefer, for some branches, to work in strict mode.
jam> 3) The fix is fairly trivial, the bug is somewhat
jam> serious, and you're already working on the code. Yes it
jam> is feature creep, but it is a small amount for something
jam> worthwhile (IMO).
I don't have a problem with working more on that, but I just
don't know how to write the tests (the what, not the how).
jam> I read your links, and while there wasn't a general
jam> discussion on it, Martin at least seems to agree it
jam> should be the default.
Sorry to have jumped to that conclusion without discussing it
first then.
jam> I'm just a bit extra sensitive to commandline behavioral
jam> changes. Since suddenly something that used to work
jam> won't anymore.
Well, I thought about that and I came to the conclusion that it's
pretty rare than one find itself in the situation to push while
having uncommitted changes. At least to me, it sounds like
advanced usage and I don't mind having to add an option in that
case, even if I didn't have to do it before, especially since I
can configure that behavior at any level.
jam> Also, note that "UncommittedCha nges" has no help text to
jam> tell the user that they can use "--no-strict" in order
jam> to push anyway. I don't know if that matters or not. But
jam> since we are explictly changing a behavior, it is good
jam> to help users find out how to get their old behavior
jam> back.
Hmm, good point. First they need to be directed to 'bzr status'
and then to 'push --no-strict' though. I'll add something in that
direction before landing then, feel free to propose a better one,
there will be a follow-up submission obviously.
jam> Anyway, you can probably merge this as is, though I'd revision( ) check.
jam> like it if you added a tree.last_
Then let's discuss that after I land that patch because I just
don't know how to address your concern otherwise.