diff: https://chiselapp.com/user/patmaddox/repository/fossil-scm/vdiff?branch=patmaddox/search-branches

Tells me:

/vdiff: No such artifact: "patmaddox/search-branches](https://chiselapp.com/user/patmaddox/repository/fossil-scm/vdiff?branch=patmaddox/search-branches)"

and the patmaddox/search-branches branch doesn't show up in /brlist.

😭

Perhaps that branch is private?

It also fixes what I think is a bug: Fossil currently only searches trunk, but generates a link to the configured branch name.

That definitely looks like a bug. We'll look into that very soon.

Edit: i don't believe that %T is the right modifier there, as that will transform many characters to hex. IMO it needs to be symbolic_name_to_rid(%Q) (without quotes - %Q adds those).

hrm… try again? Maybe chisel was having an issue when you tried? I clicked the same link on a different browser, I’m not logged in to the fossil instance or chisel, and it’s showing up fine.

Oh that’s a super weird error. It seems like it is passing markdown when you click the link?

Anyway, here’s the link without markdown involved: https://chiselapp.com/user/patmaddox/repository/fossil-scm/vdiff?branch=patmaddox/search-branches

Oh that’s a super weird error. It seems like it is passing markdown when you click the link?

And if i'd paid closer attention that should have been obvious to me :/. The link works now for me.

i probably followed the link from the email notification, rather than the forum post, which would explain the mangling.

the patmaddox/search-branches branch doesn't show up in /brlist.

Are you looking at my chisel repo? Because I can’t commit to fossil-scm.org of course

https://chiselapp.com/user/patmaddox/repository/fossil-scm/brlist

https://chiselapp.com/user/patmaddox/repository/fossil-scm/timeline?r=patmaddox/search-branches

Are you looking at my chisel repo?

i thought i had followed the "branches" link from the chiselapp repo, but... that all happened pre-coffee this morning, so all bets are off :/.

It also fixes what I think is a bug: Fossil currently only searches trunk, but generates a link to the configured branch name.

Can you confirm whether src:/info/f4fdd7d3 fixes the problem for you?

I missed this, but given that it's essentially the same change as my fix then I'm assuming yes :)

Any interest in merging this?

Any interest in merging this?

My apologies, that fell through/between/around the proverbial cracks. The "searching the wrong branch" fix is now merged to trunk.

Regarding the comma-separated list of branches: my only concern, but this admittedly very possibly a non-concern in practice, is that a comma is a legal character in a branch name. For that matter, just about any character is legal in a branch name. AFAIK, we don't have any specific limitations on branch names:

$ f new branches.f 
...
$ f branch new "😀,😁" trunk -R branches.f 
New branch: 693d80a5ada05af2f6544dbe475df90aeee2938ac74ef8bb9ababb15e606f622
$ f branch new '🤓?😎!:;' trunk -R branches.f 
New branch: ed7f3ee564d4dd447b876884ef4d72b2ec792602367e847e3e38155d3327ba74
$ f branch new '🤓|😎|`' trunk -R branches.f 
New branch: ac023974f3e5f5e12f76ebdadd0674df494c12c2d6efd778160fffb1b662962e
$ f br ls -R branches.f 
   trunk
   😀,😁
   🤓?😎!:;
   🤓|😎|`

If we had a contributor waiver on file for you (hint, hint!) i'd ask you to put it in a branch on the main project repo and poke the /chat room for opinions on it. We can't accept non-trivial patches from folks without such a waiver on file (hint, hint!), but we can (and sometimes do) use them as a blueprint for an equivalent patch. With that latter point in mind...

Before making that change (or a compatible one) i'd be interested in hearing opinions from other contributors, in particular regarding the separator. (Suggestions that the separator be configurable will be silently ignored 😀!)

If we had a contributor waiver on file for you...

I can do that. Admittedly, I had mentally filed this under "trivial change". Where it previously operated on one input, it now loops. Credit goes to db_multi_exec for making that trivial.

Before making that change (or a compatible one) i'd be interested in hearing opinions from other contributors

Understood.

in particular regarding the separator

A single space? Whitespace?

Admittedly, I had mentally filed this under "trivial change".

It is trivial enough that it would be painless to reformulate to avoid any licensing issues, but i personally like to encourage folks who have taken the time to actually write the code to "formalize" that with a contribution waiver and their own check-ins :). If you'd rather avoid that step, that's no big deal: it won't rule out your change because it's not big enough to require a large development effort on someone else's part to reimplement it.

A single space? Whitespace?

They're also legal ;). To be clear, though: commas and/or spaces are very likely perfectly legitimate candidates¹, but experience suggests that there's always that one outlier user who will do things their own way, and it would be a shame if such a change broke things for them which (A) otherwise worked fine and (B) for which there would be no workaround for them beyond renaming their branches. It's absolutely possible that i am being over-cautious in that regard, and i'll gladly defer to the group's wider judgement on this nitpick.

1. ^{^} Glob lists typically support both spaces and commas in the same list, such that foo.*, bar.* behaves intuitively.

Would requiring url encoding of branch names work? E.G. branches=foo%20bar,a%20branch%2Cwith%20comma. I not sure if the code that would parse this on commas sees the url encoded terms or if they are decoded before that point.

I not sure if the code that would parse this on commas sees the url encoded terms or if they are decoded before that point.

That particular setting is not passed around in URLs, but is set statically by the admin, so URL en/decoding doesn't come into play for it. Yes, we could use %20, or similar, as a delimiter, but it would be awkward in that context.

Because working with spaces in branch names would be clumsy in daily use, it seems fair to assume that "nobody" (for a given value of "nobody") is using spaces in their branch names, and my concern about the delimiter is almost certainly unnecessary.

It seems that we already list many branches in a different context.

(from the /brlist page, we can select many branches to see them together in the timeline.)

In that case, it use comma (%2C).

So I guess comma in a branch name already break something.

So I guess comma in a branch name already break something

Fair point, so let's use a comma.

I figure a reasonable interface is to comma-separate the branch names in the search configuration, e.g. trunk,ref.

If you would, please try out src:/timeline?r=doc-branch-multi. That works for me by using a doc-branch value of:

trunk, bv-corrections01

and searching docs (as opposed to checkins or wiki pages) for "Microsoft".

The branch list may be space- and/or comma-delimited.

It works for full-text search. It doesn't work for sqlite search ("create a full text index" button on search config). That's a separate code path.

It doesn't work for ...

Please try again with the current tip of that branch. That seems to do the trick for me.

Looks good!