On Thu, Aug 20, 2020 at 04:59:53PM -0700, Jacob Keller wrote: > > The relevant commit is 2467a4fa03 (Remove duplicate ref matches in > > fetch, 2007-10-08), I think. We may end up with multiple refspecs > > requesting a particular ref. E.g.: > > > > git fetch origin refs/heads/master refs/heads/* > > > > I don't think the order should matter. If we apply negative refspecs > > first, then we'd either remove both copies or leave both untouched (and > > if the latter, then de-dup to a single). If we apply negative refspecs > > after de-duping, then we'd either remove the single or leave it in > > place. But the result is the same either way. > > I'm not sure this is quite true in the case where destinations are > supplied. Suppose this case: Oh, you're right. I was too focused on the de-duping of identical refs, but this is also handling colliding destinations. > git fetch refs/heads/*:refs/remotes/origin/* > refs/other/mybranch:refs/remotes/origin/mybranch > > This would ofcourse error out due to de-duping where we determine that > both would fetch to the same place.. however if you also added a > negative refspec: > > git fetch refs/heads/*:refs/remotes/origin/* > refs/other/mybranch:refs/remotes/origin/mybranch ^refs/heads/mybranch > > then shouldn't this work? meaning we should de-dupe only after we > apply negative refspecs in this case? Yes, I'd agree we should be applying the negative refspecs first, and then de-duping / looking for collisions. Which I think is what the patch is doing currently. -Peff
