Re: [PATCH 3/3 v2] Make "git-remote rm" delete refs acccording to fetch specs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



"Shawn O. Pearce" <spearce@xxxxxxxxxxx> writes:

>  This is a longer, but better version of this patch.  Instead of
>  blindly deleting the refs we remove them only if this is the last
>  remote that would write to the local tracking ref.

If this is a better version than the previous one, then probably "git
remote prune" patch to unconditionally remove ones that do not exist in
one of the remotes that fetch into the tracking namespace also needs to be
rethought, doesn't it?  Another remote may still have it but you obviously
do not know that until you check.

Admittedly, next fetch from the other remote may or may not resurrect them
and either way it is not a big deal.

I think this is exactly the same issue as this improvement in [3/3] deals
with.  If "git remote rm" of one remote removed the shared tracked refs,
next fetch from the other remote would resurrect them if the other remote
still exists.  It may probably feel better to be extra careful like this
improved patch, but I doubt it would matter in practice.  After all,
people who creates such a configuration would know what they are doing.

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux