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 versionThread Previous | Thread Next