On Mon, Feb 6, 2017 at 11:13 AM, Richard Hipp <d...@sqlite.org> wrote:
> > > > > After the second "fossil commit --branch myfirstbranch" no new branch is > > created, commited to the same branch as the after the first "fossil > commit > > --branch myfirstbranch" > > Actually, it did create a new branch off of the first branch. But as > both branches have the same name, you don't notice it on the timeline. > If you were to change the name of the first branch, you would notice > that the second branch name remained unaltered. That's the only way > you could tell that you did in fact create a new branch. This is where what I'm seeing doesn't line up with what you're telling me. The "fossil ui" *visually* shows 2 branches with the same name after "fossil branch new" and the first "fossil commit --branch". Additionally, If I perform a "fossil branch ls" at this point only "myfirstbranch" and "trunk" show up. This is inconsistent. After the second "fossil commit --branch" there are sill visually 2 branches on the web ui. If what you're telling me was true and consistent then I should visually see 3 branches after the second "fossil commit --branch". But that isn't the case, there is an inconsistency in the behavior. > > > > After fossil merge myfirstbranch, then commit, only the branch created > with > > "fossil commit" is merged to trunk and there is still an open leaf on a > > branch with name "myfirstbranch" > > > > Listing branches still shows that myfirstbranch exists. > > > > Trying to merge again gives the message of "no-op", a force merely tries > to > > merge the branch created by "fossil commit" again. > > > > The open leafed branch cannot be merged. > > > > I believe this is a bug. I'm bewildered as to how to resolve this > > situation. > > This isn't really a problem that needs resolving, in the sense that > Fossil does not care. You might want to close some of the branch > heads just to keep your repository tidy, but that is an aesthetic > concern that (while important to human readers) does not affect the > integrity of the repository. > > I got a little confused with your description. If you can share your > repository, someone can probably guide you toward how to mark the > unwanted branches as "closed" and thus resolve the situation. > How is this not a bug? After following the steps above I have a named branch in my repo, seen with "fossil branch ls" and "fossil ui" that can't be closed via "fossil merge" by using its name. I should note I can merge the branch if I use the SHA1 hash. If I'm able to merge the second branch created using "fossil merge myfirstbranch" and there is still a branch open named "myfirstbranch", as seen with both ls and ui, why doesn't "fossil merge myfirstbranch" not close this branch as as well? This is inconsistent behavior, which I would call a bug. Having more than one branch open at the same time with the same name is ambiguous and creates confusion not only for the user but, as I have shown by example, for the software as well. You say that the "recommended solution" is not creating branches with the same name. If it's already viewed as a bad idea which can cause confusion why allow it all. I advocate that a user should not be allowed to open a new branch by the same name at the same time. If two different users unknowingly create a branch by the same name and try to sync to the same repo the naming conflict needs to be resolved. I would bet unless the effort was coordinated that neither user would want the ambiguity of having two branches open by the same name. In conclusion, I believe Fossil has both a bug (due to inconsistent behavior) and has made a design decision regarding branch name rules which causes confusion and which risks more bugs in the future. I could upload my repo by I believe it is more effective to follow the steps I have provided as evidence of the issue. If you have any confusion please walk through the example with the web ui open, it should clear your confusion up.
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
