Merge lp:~vila/bzr/284038-push-strict into lp:~bzr/bzr/trunk-old
- 284038-push-strict
- Merge into trunk-old
Status: | Merged | ||||||||
---|---|---|---|---|---|---|---|---|---|
Merged at revision: | not available | ||||||||
Proposed branch: | lp:~vila/bzr/284038-push-strict | ||||||||
Merge into: | lp:~bzr/bzr/trunk-old | ||||||||
Diff against target: | 235 lines | ||||||||
To merge this branch: | bzr merge lp:~vila/bzr/284038-push-strict | ||||||||
Related bugs: |
|
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
John A Meinel | Needs Fixing | ||
Review via email: mp+8005@code.launchpad.net |
Commit message
Description of the change
Vincent Ladeuil (vila) wrote : | # |
John A Meinel (jameinel) wrote : | # |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Vincent Ladeuil wrote:
> Vincent Ladeuil has proposed merging lp:~vila/bzr/284038-push-strict into lp:bzr.
>
> Requested reviews:
> bzr-core (bzr-core)
>
> This complements my first attempt to fix the bug while also fixing bugs #322808 and #65286,
> by making --strict defaults to true.
>
> Changing the default value revealed a bug in the previous implementation as push can be used without
> a working tree.
>
> Also the --strict option is meaningless if the --revision option is used.
>
> Previous reviews mentioned introducing:
> - a way to query config files for a bool option,
> - a new method on working tree for checking changes.
>
> Since both are also needed for bug #206577, I'd like to postpone these modifications until both fixes
> have landed.
>
To start with, I don't remember an agreement that strict should be the
default.
+ The ``push_strict`` option can be declared in a configuration
+ file. option is used.
^- The news entry needs a bit of updating. Something like:
The configuration option ``push_strict`` can be used to set the default
for this behavior.
...
+ if (tree is not None and revision_id is None
+ and (strict is None or strict)): # Default to True:
+ changes = tree.changes_
+ if changes.
+ raise errors.
Rather than doing 'strict is None', just set:
def run(..., strict=True):
if we want that to be the default.
So provided that there was actually agreement that strict should be the
default, the patch seems ok with some small tweaks.
I'll note that "commit" is not strict by default, and I've often used
push before commit, especially if I'm about to switch.
I could agree that strict=True is the 'safer' default for most people,
so having to edit a config to turn it off is the "power-user" approach.
I suppose we could land it and see what we think...
vote needs_fixing
Mostly I want to make sure that we did actually agree that we should
default to strict.
John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://
iEYEARECAAYFAkp
S9EAoJ90HFDdgbz
=uiFO
-----END PGP SIGNATURE-----
Vincent Ladeuil (vila) wrote : | # |
>>>>> "jam" == John A Meinel <email address hidden> writes:
<snip/>
jam> To start with, I don't remember an agreement that strict
jam> should be the default.
https:/
https:/
https:/
I interpreted that as an agreement, I also agree with the idea
that it may be confusing for new users if left off by default.
jam> + The ``push_strict`` option can be declared in a configuration
jam> + file. option is used.
jam> ^- The news entry needs a bit of updating. Something like:
jam> The configuration option ``push_strict`` can be used to set the default
jam> for this behavior.
Right.
jam> ...
jam> + if (tree is not None and revision_id is None
jam> + and (strict is None or strict)): # Default to True:
jam> + changes = tree.changes_
jam> + if changes.
jam> + raise errors.
jam> Rather than doing 'strict is None', just set:
jam> def run(..., strict=True):
jam> if we want that to be the default.
No, because if we do that, we can't distinguish anymore between
the config file variable and the command-line option (the later
should still override the former).
jam> So provided that there was actually agreement that strict should be the
jam> default, the patch seems ok with some small tweaks.
jam> I'll note that "commit" is not strict by default, and
jam> I've often used push before commit, especially if I'm
jam> about to switch.
Feel free to add 'push_strict=False' in your bazaar.conf file,
you're not a *new* user :-)
jam> I could agree that strict=True is the 'safer' default
jam> for most people, so having to edit a config to turn it
jam> off is the "power-user" approach.
Indeed.
Since my other merge proposal (for send/bundle --strict) will
raise, at least, the exact same questions, I'll wait for your
answer here before landing.
Vincent
Vincent Ladeuil (vila) wrote : | # |
>>>>> "jam" == John A Meinel <email address hidden> writes:
<snip/>
jam> To start with, I don't remember an agreement that strict
jam> should be the default.
https:/
https:/
https:/
I interpreted that as an agreement, I also agree with the idea
that it may be confusing for new users if left off by default.
jam> + The ``push_strict`` option can be declared in a configuration
jam> + file. option is used.
jam> ^- The news entry needs a bit of updating. Something like:
jam> The configuration option ``push_strict`` can be used to set the default
jam> for this behavior.
Right.
jam> ...
jam> + if (tree is not None and revision_id is None
jam> + and (strict is None or strict)): # Default to True:
jam> + changes = tree.changes_
jam> + if changes.
jam> + raise errors.
jam> Rather than doing 'strict is None', just set:
jam> def run(..., strict=True):
jam> if we want that to be the default.
No, because if we do that, we can't distinguish anymore between
the config file variable and the command-line option (the later
should still override the former).
jam> So provided that there was actually agreement that strict should be the
jam> default, the patch seems ok with some small tweaks.
jam> I'll note that "commit" is not strict by default, and
jam> I've often used push before commit, especially if I'm
jam> about to switch.
Feel free to add 'push_strict=False' in your bazaar.conf file,
you're not a *new* user :-)
jam> I could agree that strict=True is the 'safer' default
jam> for most people, so having to edit a config to turn it
jam> off is the "power-user" approach.
Indeed.
Since my other merge proposal (for send/bundle --strict) will
raise, at least, the exact same questions, I'll wait for your
answer here before landing.
Vincent
John A Meinel (jameinel) wrote : | # |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Vincent Ladeuil wrote:
> Vincent Ladeuil has proposed merging lp:~vila/bzr/284038-push-strict into lp:bzr.
>
> Requested reviews:
> bzr-core (bzr-core)
>
> This complements my first attempt to fix the bug while also fixing bugs #322808 and #65286,
> by making --strict defaults to true.
>
> Changing the default value revealed a bug in the previous implementation as push can be used without
> a working tree.
>
> Also the --strict option is meaningless if the --revision option is used.
>
> Previous reviews mentioned introducing:
> - a way to query config files for a bool option,
> - a new method on working tree for checking changes.
>
> Since both are also needed for bug #206577, I'd like to postpone these modifications until both fixes
> have landed.
>
Also...
We should *definitely* be checking:
tree.last_
And possibly consider what to do in the case of bound branches and
heavyweight checkouts.
I'm not *as* concerned about the latter, but because in the former case,
IIRC we will actually be pushing "tree.branch.
tree.last_
So certainly '--strict' should fail if the tree and branch aren't at the
same rev.
John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://
iEYEARECAAYFAkp
3e4AniMO3HZD1Sg
=Qf45
-----END PGP SIGNATURE-----
Vincent Ladeuil (vila) wrote : | # |
>>>>> "jam" == John A Meinel <email address hidden> 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
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 certainly '--strict' should fail if the tree and
jam> branch aren't at the same rev.
I'm not sure I agree with you (nor that I disagree), but I think
that's worth filing a different bug.
Vincent
John A Meinel (jameinel) wrote : | # |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Vincent Ladeuil wrote:
>>>>>> "jam" == John A Meinel <email address hidden> 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
> 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...
So I can agree that it is a different bug except:
1) I think 'bzr push --strict' is about 'push should push the state I
*think* I have'. And uncommitted changes, (uncommitted merges), and a
tree last revision being out of sync with the branch's revision, are all
cases where the push isn't pushing what the user expected.
2) I think the source of '--strict' is MySQL fallout from switching from
BK where a merge had autocommit so "bk merge; bk push" did something,
while with bzr you need "bzr merge; bzr commit; bzr push".
The fact that they haven't run into issues with a workingtree being out
of sync with the branch is more luck than noticing that we have a
serious flaw.
3) The fix is fairly trivial, the bug is somewhat serious, and you're
already working on the code. Yes it is feature creep, but it is a small
amount for something worthwhile (IMO).
>
> jam> So certainly '--strict' should fail if the tree and
> jam> branch aren't at the same rev.
>
> I'm not sure I agree with you (nor that I disagree), but I think
> that's worth filing a different bug.
>
> Vincent
>
I read your links, and while there wasn't a general discussion on it,
Martin at least seems to agree it should be the default. I'm just a bit
extra sensitive to commandline behavioral changes. Since suddenly
something that used to work won't anymore.
Also, note that "UncommittedCha
that they can use "--no-strict" in order to push anyway. I don't know if
that matters or not. But since we are explictly changing a behavior, it
is good to help users find out how to get their old behavior back.
Anyway, you can probably merge this as is, though I'd like it if you
added a tree.last_
John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://
iEYEARECAAYFAkp
dioAoLoZtL3GnDb
=a+Cd
-----END PGP SIGNATURE-----
Vincent Ladeuil (vila) wrote : | # |
>>>>> "jam" == John A Meinel writes:
jam> Vincent Ladeuil wrote:
>>>>>>> "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
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 ...
John A Meinel (jameinel) wrote : | # |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Vincent Ladeuil wrote:
>>>>>> "jam" == John A Meinel writes:
>
> jam> Vincent Ladeuil wrote:
> >>>>>>> "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
> 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 whi...
Preview Diff
1 | === modified file 'NEWS' |
2 | --- NEWS 2009-06-30 05:34:47 +0000 |
3 | +++ NEWS 2009-06-30 08:35:22 +0000 |
4 | @@ -21,9 +21,10 @@ |
5 | New Features |
6 | ************ |
7 | |
8 | -* ``bzr push`` now checks if uncommitted changes are present in the working |
9 | - tree if the ``--strict`` option is used. |
10 | - (Vincent Ladeuil, #284038) |
11 | +* ``bzr push`` now aborts if uncommitted changes (including pending merges) |
12 | + are present in the working tree (if one is present) and no revision is |
13 | + speficied. The ``push_strict`` option can be declared in a configuration |
14 | + file. option is used. (Vincent Ladeuil, #284038, #322808, #65286) |
15 | |
16 | |
17 | Bug Fixes |
18 | |
19 | === modified file 'bzrlib/builtins.py' |
20 | --- bzrlib/builtins.py 2009-06-26 03:44:30 +0000 |
21 | +++ bzrlib/builtins.py 2009-06-30 08:35:22 +0000 |
22 | @@ -1057,16 +1057,17 @@ |
23 | strict = bools[strict.lower()] |
24 | except KeyError: |
25 | strict = None |
26 | - if strict: |
27 | - changes = tree.changes_from(tree.basis_tree()) |
28 | - if changes.has_changed(): |
29 | - raise errors.UncommittedChanges(tree) |
30 | # Get the tip's revision_id |
31 | revision = _get_one_revision('push', revision) |
32 | if revision is not None: |
33 | revision_id = revision.in_history(br_from).rev_id |
34 | else: |
35 | revision_id = None |
36 | + if (tree is not None and revision_id is None |
37 | + and (strict is None or strict)): # Default to True: |
38 | + changes = tree.changes_from(tree.basis_tree()) |
39 | + if changes.has_changed() or len(tree.get_parent_ids()) > 1: |
40 | + raise errors.UncommittedChanges(tree) |
41 | |
42 | # Get the stacked_on branch, if any |
43 | if stacked_on is not None: |
44 | |
45 | === modified file 'bzrlib/tests/blackbox/test_push.py' |
46 | --- bzrlib/tests/blackbox/test_push.py 2009-06-22 08:14:24 +0000 |
47 | +++ bzrlib/tests/blackbox/test_push.py 2009-06-30 08:35:22 +0000 |
48 | @@ -35,6 +35,28 @@ |
49 | from bzrlib.transport import memory |
50 | |
51 | |
52 | +def load_tests(standard_tests, module, loader): |
53 | + """Multiply tests for the push command.""" |
54 | + result = loader.suiteClass() |
55 | + |
56 | + # one for each king of change |
57 | + changes_tests, remaining_tests = tests.split_suite_by_condition( |
58 | + standard_tests, tests.condition_isinstance(( |
59 | + TestPushStrictWithChanges, |
60 | + ))) |
61 | + changes_scenarios = [ |
62 | + ('uncommitted', |
63 | + dict(_changes_type= '_uncommitted_changes')), |
64 | + ('pending_merges', |
65 | + dict(_changes_type= '_pending_merges')), |
66 | + ] |
67 | + tests.multiply_tests(changes_tests, changes_scenarios, result) |
68 | + # No parametrization for the remaining tests |
69 | + result.addTests(remaining_tests) |
70 | + |
71 | + return result |
72 | + |
73 | + |
74 | class TestPush(tests.TestCaseWithTransport): |
75 | |
76 | def test_push_error_on_vfs_http(self): |
77 | @@ -569,72 +591,112 @@ |
78 | class TestPushStrict(tests.TestCaseWithTransport): |
79 | |
80 | def make_local_branch_and_tree(self): |
81 | - tree = self.make_branch_and_tree('local') |
82 | + self.tree = self.make_branch_and_tree('local') |
83 | self.build_tree_contents([('local/file', 'initial')]) |
84 | - tree.add('file') |
85 | - tree.commit('adding file', rev_id='from-1') |
86 | - return tree |
87 | - |
88 | - def make_local_branch_and_tree_with_changes(self): |
89 | - tree = self.make_local_branch_and_tree() |
90 | - # Make some changes |
91 | + self.tree.add('file') |
92 | + self.tree.commit('adding file', rev_id='added') |
93 | self.build_tree_contents([('local/file', 'modified')]) |
94 | - return tree |
95 | + self.tree.commit('modify file', rev_id='modified') |
96 | |
97 | - def set_config_push_strict(self, tree, value): |
98 | + def set_config_push_strict(self, value): |
99 | # set config var (any of bazaar.conf, locations.conf, branch.conf |
100 | # should do) |
101 | - conf = tree.branch.get_config() |
102 | + conf = self.tree.branch.get_config() |
103 | conf.set_user_option('push_strict', value) |
104 | |
105 | - def assertPushFails(self, location, *args): |
106 | + def assertPushFails(self, args): |
107 | self.run_bzr_error(['Working tree ".*/local/"' |
108 | ' has uncommitted changes.$',], |
109 | - ['push', '../' + location] + list(args), |
110 | + ['push', '../to'] + args, |
111 | working_dir='local', retcode=3) |
112 | |
113 | - def assertPushSucceeds(self, location, *args): |
114 | - self.run_bzr(['push', '../' + location] + list(args), |
115 | + def assertPushSucceeds(self, args, pushed_revid=None): |
116 | + self.run_bzr(['push', '../to'] + args, |
117 | working_dir='local') |
118 | - tree_to = workingtree.WorkingTree.open(location) |
119 | + if pushed_revid is None: |
120 | + pushed_revid = 'modified' |
121 | + tree_to = workingtree.WorkingTree.open('to') |
122 | repo_to = tree_to.branch.repository |
123 | - self.assertTrue(repo_to.has_revision('from-1')) |
124 | - self.assertEqual(tree_to.branch.last_revision_info()[1], 'from-1') |
125 | - |
126 | - def test_push_default(self): |
127 | - tree = self.make_local_branch_and_tree_with_changes() |
128 | - self.assertPushSucceeds('to') |
129 | - |
130 | - def test_push_no_strict_with_changes(self): |
131 | - tree = self.make_local_branch_and_tree_with_changes() |
132 | - self.assertPushSucceeds('to', '--no-strict') |
133 | + self.assertTrue(repo_to.has_revision(pushed_revid)) |
134 | + self.assertEqual(tree_to.branch.last_revision_info()[1], pushed_revid) |
135 | + |
136 | + |
137 | + |
138 | +class TestPushStrictWithoutChanges(TestPushStrict): |
139 | + |
140 | + def setUp(self): |
141 | + super(TestPushStrictWithoutChanges, self).setUp() |
142 | + self.make_local_branch_and_tree() |
143 | + |
144 | + def test_push_default(self): |
145 | + self.assertPushSucceeds([]) |
146 | + |
147 | + def test_push_strict(self): |
148 | + self.assertPushSucceeds(['--strict']) |
149 | + |
150 | + def test_push_no_strict(self): |
151 | + self.assertPushSucceeds(['--no-strict']) |
152 | + |
153 | + def test_push_config_var_strict(self): |
154 | + self.set_config_push_strict('true') |
155 | + self.assertPushSucceeds([]) |
156 | + |
157 | + def test_push_config_var_no_strict(self): |
158 | + self.set_config_push_strict('false') |
159 | + self.assertPushSucceeds([]) |
160 | + |
161 | + |
162 | +class TestPushStrictWithChanges(TestPushStrict): |
163 | + |
164 | + _changes_type = None # Set by load_tests |
165 | + |
166 | + def setUp(self): |
167 | + super(TestPushStrictWithChanges, self).setUp() |
168 | + getattr(self, self._changes_type)() |
169 | + |
170 | + def _uncommitted_changes(self): |
171 | + self.make_local_branch_and_tree() |
172 | + # Make a change without committing it |
173 | + self.build_tree_contents([('local/file', 'in progress')]) |
174 | + |
175 | + def _pending_merges(self): |
176 | + self.make_local_branch_and_tree() |
177 | + # Create 'other' branch containing a new file |
178 | + other_bzrdir = self.tree.bzrdir.sprout('other') |
179 | + other_tree = other_bzrdir.open_workingtree() |
180 | + self.build_tree_contents([('other/other-file', 'other')]) |
181 | + other_tree.add('other-file') |
182 | + other_tree.commit('other commit', rev_id='other') |
183 | + # Merge and revert, leaving a pending merge |
184 | + self.tree.merge_from_branch(other_tree.branch) |
185 | + self.tree.revert(filenames=['other-file'], backups=False) |
186 | + |
187 | + def test_push_default(self): |
188 | + self.assertPushFails([]) |
189 | + |
190 | + def test_push_with_revision(self): |
191 | + self.assertPushSucceeds(['-r', 'revid:added'], pushed_revid='added') |
192 | + |
193 | + def test_push_no_strict(self): |
194 | + self.assertPushSucceeds(['--no-strict']) |
195 | |
196 | def test_push_strict_with_changes(self): |
197 | - tree = self.make_local_branch_and_tree_with_changes() |
198 | - self.assertPushFails('to', '--strict') |
199 | - |
200 | - def test_push_strict_without_changes(self): |
201 | - tree = self.make_local_branch_and_tree() |
202 | - self.assertPushSucceeds('to', '--strict') |
203 | + self.assertPushFails(['--strict']) |
204 | |
205 | def test_push_respect_config_var_strict(self): |
206 | - tree = self.make_local_branch_and_tree_with_changes() |
207 | - self.set_config_push_strict(tree, 'true') |
208 | - self.assertPushFails('to') |
209 | + self.set_config_push_strict('true') |
210 | + self.assertPushFails([]) |
211 | |
212 | def test_push_bogus_config_var_ignored(self): |
213 | - tree = self.make_local_branch_and_tree_with_changes() |
214 | - self.set_config_push_strict(tree, "I don't want you to be strict") |
215 | - self.assertPushSucceeds('to') |
216 | + self.set_config_push_strict("I don't want you to be strict") |
217 | + self.assertPushFails([]) |
218 | |
219 | def test_push_no_strict_command_line_override_config(self): |
220 | - tree = self.make_local_branch_and_tree_with_changes() |
221 | - self.set_config_push_strict(tree, 'yES') |
222 | - self.assertPushFails('to') |
223 | - self.assertPushSucceeds('to', '--no-strict') |
224 | + self.set_config_push_strict('yES') |
225 | + self.assertPushFails([]) |
226 | + self.assertPushSucceeds(['--no-strict']) |
227 | |
228 | def test_push_strict_command_line_override_config(self): |
229 | - tree = self.make_local_branch_and_tree_with_changes() |
230 | - self.set_config_push_strict(tree, 'oFF') |
231 | - self.assertPushFails('to', '--strict') |
232 | - self.assertPushSucceeds('to') |
233 | + self.set_config_push_strict('oFF') |
234 | + self.assertPushFails(['--strict']) |
235 | + self.assertPushSucceeds([]) |
This complements my first attempt to fix the bug while also fixing bugs #322808 and #65286,
by making --strict defaults to true.
Changing the default value revealed a bug in the previous implementation as push can be used without
a working tree.
Also the --strict option is meaningless if the --revision option is used.
Previous reviews mentioned introducing:
- a way to query config files for a bool option,
- a new method on working tree for checking changes.
Since both are also needed for bug #206577, I'd like to postpone these modifications until both fixes
have landed.