JY> To me your proposed model of "add project" / "remove project" seemed
JY> just too reminiscent of etag's paradigm for managing tag tables.
EZ> There's nothing inherently wrong with that, is there?
JY> Of late I have been using git-new-workspace. In that setting
JY> find-tag forever seems to open the _wrong_ file. More perniciously
JY> it often opens one that looks right though in a different workspace,
JY> thereby slowing me down and making me paranoid.
EZ> I never used git-new-workspace, so I don't really understand what you
EZ> describe here. In any case, this sounds like a problem with the
EZ> program that created the TAGS file, not with find-tag per se: the
EZ> latter just obeys what's in the database.
EZ> And I'd still want to know what are the problems with the stateful
EZ> approach I proposed.
The historic way to use git to do work across different branches within a single code base is to multiplex a single workspace. This means that at any instant one has available only a single branch and a single set of (possibly out of date) tags. Assume then that I have branches B1 and B2, along with tag T defined in file F1 and referenced in file F2. I generate a tags database while I have branch B1 checked out. I later switch to branch B2 though I do not rebuild nor my tags database. I open file F2 open and want to visit the definition of tag T. My tags database, though somewhat out of date (it describes branch B1), correctly opens B2's version of file F1 (the only version available) and if I am lucky still gets me to T's definition.
The git-new-workstation script automates setting up light weight per branch workspaces. (They are light weight primarily in the sense that they share a single history database stored in a common parent workspace.) This arrangement enables multiplexing work across multiple directories merely by opening a different path. Note: no need even to cd to a different directory. So now there are multiple copies of every file, some different, most identical, in congruent directory trees. Going back to my earlier example using git-new-workspace I would now have two workspaces, B1 and B2, corresponding to my two branches, each containing files F1 and F2 and each containing an up to date tags database. I perform some work in B1 with the net effect that I have a loaded tags table describing B1. I then visit B2::F2, do some work involving tag T causing me to want to visit T's definition. At this point C-. takes me to T's definition in B1::F1, not in B2::F1 as I would want. The problem is that both files exist on my disk and are similar if not identical. Thus, unless I am especially vigilant, I edit and save the wrong file.
To reiterate my effort to switch branch contexts was nothing more than C-x C-f or C-x b. Given the current tags implementation getting emacs to use the correct tags database involves explicit manipulation of session state via visit-tags-table. Hence my gripe about statefulness.
I hope that helps,
/john