From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?ISO-8859-1?Q?Santi_B=E9jar?= Subject: Re: [PATCHv3 1/4] parse-remote: function to get the tracking branch to be merge Date: Tue, 9 Jun 2009 10:07:22 +0200 Message-ID: References: <1244451651-22651-2-git-send-email-santi@agolina.net> <7v8wk2wbfs.fsf@alter.siamese.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: git@vger.kernel.org To: Junio C Hamano X-From: git-owner@vger.kernel.org Tue Jun 09 10:07:36 2009 Return-path: Envelope-to: gcvg-git-2@gmane.org Received: from vger.kernel.org ([209.132.176.167]) by lo.gmane.org with esmtp (Exim 4.50) id 1MDwMp-00052x-PN for gcvg-git-2@gmane.org; Tue, 09 Jun 2009 10:07:36 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755692AbZFIIH0 convert rfc822-to-quoted-printable (ORCPT ); Tue, 9 Jun 2009 04:07:26 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1759091AbZFIIHZ (ORCPT ); Tue, 9 Jun 2009 04:07:25 -0400 Received: from mail-bw0-f213.google.com ([209.85.218.213]:55432 "EHLO mail-bw0-f213.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759111AbZFIIHW convert rfc822-to-8bit (ORCPT ); Tue, 9 Jun 2009 04:07:22 -0400 Received: by bwz9 with SMTP id 9so3613683bwz.37 for ; Tue, 09 Jun 2009 01:07:23 -0700 (PDT) Received: by 10.204.31.215 with SMTP id z23mr7523348bkc.83.1244534842840; Tue, 09 Jun 2009 01:07:22 -0700 (PDT) In-Reply-To: Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: 2009/6/9 Santi B=E9jar : > 2009/6/9 Junio C Hamano : >> Santi B=E9jar writes: >> >>> The only user of get_remote_refs_for_fetch was "git pull --rebase" = and >>> it only wanted the tracking branch to be merge. So, add a simple >>> function with this new meaning. >>> >>> No behavior changes. >> >> I am all for code reduction, but after following the original logic = that >> uses remote_refs_for_fetch (which knows about things like "git pull = there >> +refs/heads/master:refs/heads/origin tag v1.6.0" from the command li= ne) >> that in turn calls canon_refs_list_for_fetch (which returns a list e= =2Eg. >> +refs/heads/master:refs/heads/origin refs/tags/v1.6.0:refs/tags/v1.6= =2E0), >> and do not quite see how you can casually say "No behaviour changes.= " > > Ups, you are right. But even in you case the only important branch is > the first, so the only possible change in behavior is: > > git pull --rebase tags v1.6.0 In fact: git pull --rebase remote tags v1.6.0 But this still works because oldremoteref defaults to defaults_merge. So the only behavior change is when a remote branch is rebased/retagged, and you have worst problems then. I think noone used the rebased functionality in this way, so I don't think it is worth to support it. But if someone think it is important I'll do it. Santi