[RFC] I want to disable submit_branch on my computer for all branches. How can I do that?

Alexander Belchenko bialix at ukr.net
Thu May 12 12:51:16 UTC 2011


vila пишет:
>>>>>> Alexander Belchenko <bialix at ukr.net> writes:
> 
>     > For me *personally* submit_branch location stored in the
>     > branch.conf in 99% of cases is the wrong thing or simply useless,
> 
> For me it's right in 90% of the cases, still the remaining 10% have been
> painful on occasion.
> 
>     > and because it affects what bzr-explorer tries to show me in
>     > submit pane, I want it disabled at all.
> 
> Well, you want it to be *right* :)
> 
> <snip/>
> 
>     > submit_branch could be useful only for feature branches, but in
>     > the most cases submit_branch is the same as
>     > parent_branch.
> 
> I think the truth is that it *defaults* to parent_location if it's not
> set.
> 
>     > Therefore it's should be enough to use just parent_branch.
> 
>     > The problem here is that submit_branch only set by merge,
> 
> That's indeed the source of the problems.
> 
>     > but used by send command (and in the explorer).
> 
> And, more importantly for me, used to implement '-rsubmit:' ! 'bzr diff
> -rsubmit:' always shows me what I will propose (submit) to the branch
> I'm targeting.

Ah, soory, I indeed forgot about diff -rsubmit:. So, you're right -- I 
want to have the right submit_branch then, but I don't see how can bzr 
knows what is correct for me?

> 
> This is really different from the parent branch (while identical in many
> cases) and is also a useful default source for merge (in many
> workflows).
> 
>     > And this is confusing a bit. If merge remember the last location
>     > where from it merged first(last) time why such location is not
>     > named as merge_branch or merge_from_branch?
> 
> Indeed. I think it should be named this way but in this case some use
> cases of submit_branch will break (so we probably want to add
> merge_branch and fix the fallouts).
> 
>     > I don't use send command for my work, just because LP merge
>     > proposals are awesome. So submit_branch for me is not needed as a
>     > way to provide a hint for send.
> 
> Same here, but I use 'bzr diff -rsubmit:' before creating the merge
> proposal to do my own review.
> 
>     > 1) For trunk branches of my projects like qbzr and explorer I
>     > often merge changes from other branches I reviewed. Of course for
>     > the sake of review I get the copy of other branches on my local
>     > computer and then merge them into trunk. Therefore submit_branch
>     > was set after first merge, and then I delete/move merged branch
>     > and submit_branch always points to non-existent
>     > location. Therefore it's just waste.
> 
> I use the following trick for my "trunks" to fix merge aggressive
> setting:
> 
>   bzr config submit_branch=lp:<project>
> 
> And since I have only one trunk by project, the issue is addressed. I
> agree that this is not ideal but... wfm.
> 
> <snip/>
> 
>     > 2) I often merge into feature branches changes from other
>     > branches, but it does not mean I will submit my current branch
>     > into the branch where from I've merged. Therefore setting
>     > submit_branch on that branch is incorrect thing.
> 
> I use the following^W *same* trick here.
> 
>     > 3) Furthermore, if I merge unrelated branch as `merge -r0..-1`
>     > then I definitely never will submit my current branch into that
>     > one. Therefore submit_branch is simply useless.
> 
> 
> But there is:
> 
> 4) I merge trunk in my branch to ensure I can still land it. In this
> case, submit_branch is right.

Your case 4 is in fact my first unnumbered case about feature branch. 
But it will only work if you have set submit_branch correctly or if you 
didn't merged into your feature branch another unrelated branches, as I 
mentioned in 1-3.

> 
> I think that's the use case that was considered when making merge
> remember submit_branch.
> 
> In this case the merge source *is* the submit target and often the
> parent branch too...
> 
>     > So, as a matter of backward compatibility I don't think
>     > submit_branch can be removed at all. But I can't prevent merge to
>     > store the location to branch.conf even if I use --no-remember
>     > command-line option,
> 
> Should be fixed.
> 
> Alternatively you can use:
> 
>   bzr config --remove submit_branch
> 
> or just set it correctly:
> 
>   bzr config submit_branch=<here-and-nowhere-else-thank-you>
> 
>     > although bzr never complains about that option. It just ignores it
>     > and does what it does.
> 
> That's another bug, I think --remember works but -=no-remember doesn't
> (that's the bug).
> 
>     > I can just rework bzr-explorer to be able to configure it to
>     > avoid using submit_branch at all, but anyway submit_branch will
>     > be remembered and will appear in the output of `bzr info`. And I
>     > prefer to not see it there.
> 
>     > So, what could be better way to workaround that? Teach merge to
>     > properly handle --no-remember
> 
> Yes.
> 
>     > or have global option in bazaar.conf to do the same but from
>     > inside bzrlib?
> 
> There are certainly several ways to fix the whole issue including
> accepting a default value for submit_branch defaulting to trunk (local
> or remote), but let's start by finding what the broken workflows are.
> 
> You started with 3 of them, I added one, others may have encountered the
> same problem.
> 
>     > Or just give up/take it easy and only concentrate on what I want
>     > from explorer?
> 
> I think it's worth fixing in bzr in a way that can accommodate the
> various workflows and that includes working from bzr-explorer or from
> the command-line, so let's try to fix it in core ;)
> 
>     Vincent
> 
> 
> 
> 


-- 
All the dude wanted was his rug back



More information about the bazaar mailing list