On Fri, Jun 23, 2017 at 6:52 AM, Jacob Keller <jacob.e.kel...@intel.com> wrote: > From: Jacob Keller <jacob.kel...@gmail.com> > > Historically, git has tracked the status of remote branches (heads) in > refs/remotes/<name>/*. This is necessary and useful as it allows users > to track the difference between their local work and the last known > status of the remote work. > > Unfortunately this hierarchy is limited in that it only tracks branches. > Additionally, it is not feasible to extend it directly, because the > layout would become ambiguous. For example, if a user happened to have > a local branch named "notes" it could be confusing if you tried to add > "refs/remotes/origin/notes/<remote notes refs" as this would collide > with the already existing refs/remotes/origin/notes branch that existed. > > Instead, lets add support for a new refs/tracking/* hierarchy which is > laid out in such a way to avoid this inconsistency. All refs in > "refs/tracking/<remote>/*" will include the complete ref, such that > dropping the "tracking/<remote>" part will give the exact ref name as it > is found in the upstream. Thus, we can track any ref here by simply > fetching it into refs/tracking/<remote>/*. > > Add support to tell a new remote to start tracking remote hierarchies > via "--follow" which will track all refs under that section, ie: > > git remote add --follow notes origin <url> will cause > > +refs/notes/*:refs/tracking/origin/notes/* to be added as a fetch > refspec for this remote. > > This ensures that any future refs which want a method of sharing the > current remote status separate from local status could use > refs/tracking > > A long term goal might be to deprecate refs/remotes/ in favor of > refs/tracking (possibly adding in magic to convert refs/remotes directly > into refs/tracking so that old stuff still works?). > > Things not yet thought through: > > 1) maybe we should create a configurable default so that some known set > of default refs get pulled (ie: notes, grafts, replace, etc?) > Possibly with some sort of easy way to add or subtract from the list > in config... > > 2) so far, there's no work done to figure out how to remove > refs/tracking when a remote is dropped. I *think* we can just delete > all refs under refs/tracking/<name> but I'm not completely certain > > 3) adding magic to complete refs under tracking, such as for git-notes > or similar may wish to understand shorthand for referencing the > remote version of notes > > 4) adding support for clone.. (this is weird because git-clone and > git-remote don't both use the same flow for setup.. oops??) > > 5) tests, documentation etc. (This is primarily an RFC, with the goal of > providing a known location for remote references such as notes to > reside) > > 6) we probably want to enable notes and grafts and other similar things > to use the remote tracking data if its available. > > 7) what about tags? Currently we fetch all tags into refs/tags directly, > which is a bit awkward, if for example you create a local tag and > a remote creates a tag with the same name, you simply don't get that > new version. This is good, but now you have no idea how to tell if > your tags are out of date or not. refs/tracking can partially resolve > this since remote tags will always be "exactly" what the remote has. > Unfortunately, I don't know how we'd resolve them into local tags... >
Oops: 8) if we decided to go with "all refs always get tracked in refs/tracking" we probably want to either add a way to say "all refs except refs/tracking ones" or we want a way for servers to (by default) not advertise refs/tracking when clients fetch from them. That's partially why I went with the easier "only some hierarchies will get pulled by default" Otherwise, two remotes that fetch from each other could create a never ending cycle of refs/tracking/origin/tracking/origin/tracking/origin/ adding a new layer every time they fetched. Thanks, Jake
