Re: How to contribute VCSInfo back end for fossil

[Frank Terbeck <ft@xxxxxxxxxxxxxxxxxxx>]

Mike Meyer wrote:
>> As you can see, I've removed the code that surrounded the `$fsrev'
>> variable. Specifically, the `fsrevformat' style and the
>> `set-fsrev-format' hook. They didn't add much, as you've got full access
>> to the same data in with the `branchformat' style and the
>> `set-branch-format' hook (I kept the `$fsrev' variable for clarity).
>
> That was modeled after the hgrevformat variable. If that's gone away
> in later versions, then fsrevformat should go away.

Mercurial really is a special case within vcs_info.

`hgrevformat' is still there. But it's there, because mercurial has
*both* a revision number (albeit only local) *and* a hash. And
`hgrevformat' was introduced to by able to control which of those (one
or both) are being used as "%r" in `branchformat'.

> I initially did this without fsrevformat. I changed it because it
> seems slightly cleaner to have vcs-specific variables that control how
> the revision value is presented for each vcs rather than having to
> tweak branchformat for each vcs with a hash-based revision - which
> seems to be required because once you shorten it, zformat can't make
> it longer, so that %r has to be the entire hash, which is unwieldy.
> With fsrevformat, I only have to change branchformat and the various
> VCS's follow automatically, rather than having to change branchformat
> for each VCS using hash-based revisions. Maybe the hook facility
> solves this - I haven't really explored that.

Actually, I'd like to have as little vcs-specific settings as possible.

> Either way is fine with me. I just wanted to present the reason before
> committing to the other way.

Okay.

>> Like this, the only required documentation update would be to name
>> fossil among the supported systems in zshcontrib(1).
>> 
>> If you're okay with those changes, it would be good if you could check
>> whether the above code works or not - I didn't test those changes.
>
> They don't work. You deleted the setting of hook_com prior to setting
> fsrev, which meant fsrev was set to "".  It needs to be set to

Right you are. I'm way too sloppy lately.

> ${fshash}. I think the fshash name is better, as it is the hash
> string. If you want it without fsrevformat, I'll wind up pushing that
> to the repo in any case, but let me know if you'd rather I email you
> that version.

Yeah, mail me. :)

> While I'm here - it seems that the git backend doesn't pay attention
> to branchformat. Is that a bug (possibly fixed later) or intentional?

Yes, that's intentional. The general idea is to do the least possible
work within a backend.

Early in vcs_info's development, there was no support for hashsums at
all. And "%r" in `branchformat' was supposed to be that short revision
number from svn or bzr, which wouldn't hurt (width-wise) if it was
attached to the branch name.

When support for hashsums was introduced, the "%i" replacement in normal
formats was added as well. It should contain either the hash or the
revision number (or the result of the special revision format's
expansion in case of mercurial, which has both). So it kind of
duplicates the information from "%r" but with the benefit of *not* being
attached to "%b" by default.

We could actually get rid of branchformat altogether and solely rely on
"%i", but I don't want to break backwards compatibility.


That being said, using fossil's hash as "%r" in a branchformat kind goes
against the "doesn't-matter-width-wise" idea of "%r". We should probably
drop the branchformat style for fossil, too, and rely use "%i". That
would be consistent with the other backends as well, then. I do realise,
that the default value of `hgrevformat' is inconsistent with that. But
that doesn't mean, that the fossil backend would have to do that too. :)

That would reduce the code of the fossil backend to something very nice
and short:


diff --git a/Functions/VCS_Info/Backends/VCS_INFO_detect_fossil b/Functions/VCS_Info/Backends/VCS_INFO_detect_fossil
new file mode 100644
index 0000000..5515283
--- /dev/null
+++ b/Functions/VCS_Info/Backends/VCS_INFO_detect_fossil
@@ -0,0 +1,13 @@
+## vim:ft=zsh
+## fossil support by: Mike Meyer <mwm@xxxxxxxxx>
+## Distributed under the same BSD-ish license as zsh itself.
+
+setopt localoptions NO_shwordsplit
+
+[[ $1 == '--flavours' ]] && return 1
+
+VCS_INFO_check_com ${vcs_comm[cmd]} || return 1
+vcs_comm[detect_need_file]=_FOSSIL_
+VCS_INFO_bydir_detect . || return 1
+
+return 0
diff --git a/Functions/VCS_Info/Backends/VCS_INFO_get_data_fossil b/Functions/VCS_Info/Backends/VCS_INFO_get_data_fossil
new file mode 100644
index 0000000..fecf044
--- /dev/null
+++ b/Functions/VCS_Info/Backends/VCS_INFO_get_data_fossil
@@ -0,0 +1,23 @@
+## vim:ft=zsh
+## fossil support by: Mike Meyer <mwm@xxxxxxxxx>
+## Distributed under the same BSD-ish license as zsh itself.
+
+setopt localoptions extendedglob
+local a b
+local changed fshash
+local action merging
+local -A fsinfo
+
+${vcs_comm[cmd]} status | while IFS=: read a b; do
+    fsinfo[${a//-/_}]="${b## #}"
+done
+
+fshash=${fsinfo[checkout]%% *}
+changed=${(Mk)fsinfo:#(ADDED|EDITED|DELETED|UPDATED)*}
+merging=${(Mk)fsinfo:#*_BY_MERGE*}
+if [ -n "$merging" ]; then
+   action="merging"
+fi
+
+VCS_INFO_formats "$action" "${fsbranch}" "${fsinfo[local_root]}" '' "$changed" "${fshash}" "${fsinfo[repository]}"
+return 0


If you're okay with that (and if it works this time...), I'd like to
commit the above.

Regards, Frank