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" refs to
> be updated by a
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
dropping the "tracking/" part wi
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 include the complete ref, such that
>> dropping t
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 exact ref name as it
> is fou
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 between their local work and the last known
> status of
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 hierarchy is limited in tha
6 matches
Mail list logo
