develooper Front page | perl.perl5.porters | Postings from April 2010

Re: [perl #74706] [PATCH] Eliminate `git pull upstream blead` infavor of remote.*.pushurl

Thread Previous | Thread Next
From:
karl williamson
Date:
April 28, 2010 08:53
Subject:
Re: [perl #74706] [PATCH] Eliminate `git pull upstream blead` infavor of remote.*.pushurl
Message ID:
4BD859D6.30700@khwilliamson.com
karl williamson wrote:
> Ævar Arnfjörð Bjarmason wrote:
>> On Wed, Apr 28, 2010 at 13:33, David Golden <xdaveg@gmail.com> wrote:
>>> On Tue, Apr 27, 2010 at 3:46 PM, Ævar Arnfjörð Bjarmason
>>> <perlbug-followup@perl.org> wrote:
>>>> # New Ticket Created by  "Ævar Arnfjörð Bjarmason"
>>>> # Please include the string:  [perl #74706]
>>>> # in the subject line of all future correspondence about this issue.
>>>> # <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=74706 >
>>>>
>>>>
>>>> remote.*.pushurl was introduced in v1.6.4 and makes managing cases
>>>> like these much easier. Users hip enough to use GitHub are probably
>>>> hip enough to have Git 1.6.4 or later.
>>> My personal bias is that we want to give instructions that favor
>>> clarity over brevity.
>>>
>>> I would rather see "git pull" and "git push" have explicit remotes and
>>> branches listed in a guide like this. If people want to apply their
>>> own git expertise to take shortcuts, that's fine, but if we want the
>>> documentation to be as helpful as possible to people with a very wide
>>> range of expertise, being explicit is a better teaching tool.
>>>
>>> I'd support pointing people to some external documentation about
>>> taking shortcuts, but wouldn't want them to be in the perlrepository.
>>
>> Understood. But for what it's worth I think using pushurl is
>> clearer. The rationale is the following:
>>
>> If you're reading the "Submitting a patch via GitHub" you want to be
>> submitting patches to the latest version of upstream blead. If you
>> "fork" mirrors/perl you get a snapshot of GitHub's (usually 1/2 day
>> out of date) mirror.
>>
>> Its very easy to forget to do `git pull upstream blead` before you
>> start working on your patch, in almost all other cases with git you
>> start with `git pull` before doing work. In this case that doesn't do
>> the right thing.
>>
>> Using url/pushurl allows you to forget that you're funneling patches
>> between two repositories. As far as you're concerned you have a
>> commitbit, your pushes just magically go somewhere else.
>>
>>> Also -- if consensus winds up in favor -- I have a concern that the
>>> patch as given depends on the exact ordering of the git config
>>> statements.  I would suggest using a literal for the configuration of
>>> remote.origin.pushurl rather than picking it up from the previously
>>> configured value.
>>
>> The reason I wrote that is because you can't have a literal that
>> doesn't require editing. We know you want remote.origin.pushurl to be
>> git@github.com:USERNAME/perl.git, for some value of USERNAME.
>>
>> Since everything else in that paragraph of commands (and indeed, in
>> most of the documentation), depends on the exact order in which
>> commands are executed, I thought having something you could copy-paste
>> without further editing was the best way to do it.
>>
> +1
> 
Actually, in thinking about this some more, why not give both sets of 
directions? One each, depending on your git version; perhaps the 
cookbook could even say how to determine one's git version

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About