Re: [RFC PATCH] proposal for refs/tracking/* hierarchy

Marc Branchaud writes: > OTOH, we shouldn't need to do any conflict resolution on these > "tracking" refs: The remote side should update the refs > properly. Nobody should make local changes to these refs. > > I guess I'm advocating that git should only allow "tracking"

Re: [RFC PATCH] proposal for refs/tracking/* hierarchy

On 2017-06-23 04:54 PM, Junio C Hamano wrote: Jacob Keller writes: 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//*" will include the complete ref, such that

Re: [RFC PATCH] proposal for refs/tracking/* hierarchy

On Fri, Jun 23, 2017 at 1:54 PM, Junio C Hamano wrote: > Jacob Keller writes: > >> 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//*" will

Re: [RFC PATCH] proposal for refs/tracking/* hierarchy

Jacob Keller writes: > 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//*" will include the complete ref, such that > dropping the "tracking/" part will give the

Re: [RFC PATCH] proposal for refs/tracking/* hierarchy

On Fri, Jun 23, 2017 at 6:52 AM, Jacob Keller wrote: > From: Jacob Keller > > Historically, git has tracked the status of remote branches (heads) in > refs/remotes//*. This is necessary and useful as it allows users > to track the difference

[RFC PATCH] proposal for refs/tracking/* hierarchy

From: Jacob Keller Historically, git has tracked the status of remote branches (heads) in refs/remotes//*. 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