Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
When pushing a new branch, if you don't specify -u, your local branch is not automatically set up to track the remote branch. So, a contributor does git push, and then wonders why git pull throws such confusing messages. It would be great if the instructions for project maintainers could be updated, such as:
git checkout -b 7.x-1.x
git push -u origin 7.x-1.x
Comments
Comment #1
dwwBased on another read of the git push man page, sounds like a good change to me. Moving to the queue for the code that generates the "Git instructions" tab on project nodes.
Thanks,
-Derek
Comment #2
helmo CreditAttribution: helmo commentedSeems like a good good idea.
As this part has not landed in code I leave it to eliza411 to fix it in the database.
Comment #3
eliza411 CreditAttribution: eliza411 commentedSee also: #1092576: Setup commands should set upstream tracking
Specifically note: #1092576-1: Setup commands should set upstream tracking:
--set-upstream appeared only in Git 1.7.0.9.
I'm not sure if there is an alternative other then editing the .git file manually in previous Git versions.
Comment #4
helmo CreditAttribution: helmo commentedWhat is the minimal git version we support? As older versions also lack some options for cloning it might be nice to have some faq item for the minimal recommended version.
Comment #5
eliza411 CreditAttribution: eliza411 commented@helmo, I asked sdboyer for an official minimum version number, but we don't have one yet. It's dependent on what's included in major distros, etc.
The Git team chose to include directions that were first included in Git 1.6.5 (git clone --branch), so I'd say until we get something more official, instructions we include should work in 1.6.5 and need not work in earlier versions.
1.7.0.9 just came out in December 2010, and sdboyer says it means you won't have it unless you downloaded and installed Git yourself (that is, without using a package manager), so this is getting marked as Closed (won't fix).
Comment #6
Crell CreditAttribution: Crell commentedI hope you don't mind, but I'm going to refile this to postponed. At some point we can reliably expect Git 1.7 (which in my experience is the "good version" from a UX perspective), and at that point we'll want to update the documentation to leverage that version's hotness.
(And really, December 2010? I could have sworn I was using 1.7 long before that.)
Comment #7
dwwIn fact, I daresay we could consider adding sections at the bottoms of certain doc pages with "Already using Git 1.7? You can also..." wisdom.
Comment #8
Crell CreditAttribution: Crell commented+1 to #7. That would also act as an incentive for people to upgrade when they can. :-)
Even if we don't add -u, isn't there some ugly way to make a branch tracking? That should be included in the instructions as well, otherwise our instructions are telling people to setup an environment that is twice as difficult to use as it needs to be.
Comment #9
eliza411 CreditAttribution: eliza411 commentedI've opened a documentation issue for this since the immediate work has nothing to do with Git instructions. I'm +1 to dww's suggestion as well.
When there's consensus on the best practice for making a tracking branch, I'll include it in Git instructions.
Note, the -u option is not about using 1.7, which indeed came out some time ago. sdboyer can explain why the interim Git releases are confusing, but this specifically requires 1.7.0.9 or newer, as I understand it.
The docs issue is available at #1105532: Create a pattern for newer Git commands in the Git docs
Comment #10
sdboyer CreditAttribution: sdboyer commentedI like the general idea in #7, with the exception of explicitly saying "1.7." As eliza411 points out, it's not about using 1.7. Git's releases are only sequential within patch versions; minor versions see simultaneous releases over a long period of time. Moreover, what about when Git 1.8 comes out? Do we want to go update all our docs? Clearly not. So if we amend it to, "Using a [very] recent version of Git" or somesuch, I'm +1.
======
As for the actual version that's required, I did a bit of pokin about in git.git:
So yeah, the -u option actually WAS available back as of 1.7.0, and ought to be available in all the releases in that list.
Comment #11
sdboyer CreditAttribution: sdboyer commentedThat would set your local
6.x-2.x
branch to trackorigin/6.x-2.x
in the exact waygit push -u origin 6.x-2.x
does.=====
EDIT: no it won't.
git config
is dumb, and even if you quote the branch name, it still chokes on dots. Ugh. Basically, you have to copy/paste a config section in .git/config for it to work. :( :( :(Comment #12
andyceo CreditAttribution: andyceo commentedSubscribe! I even did a duplicate issue #1127800: Use option -u for git push in git instruction settings
Using -u option is very usefull.
Comment #13
eliza411 CreditAttribution: eliza411 commentedI did include it on the branching page for now: http://drupal.org/node/1066342. We'll update as soon as 1.7.0.9 is part of common distros.
Comment #14
Crell CreditAttribution: Crell commentedAs a random extra data point, it looks like GitHub is now including -u in their "copy these instructions" page on which ours is based. They didn't used to. I guess they consider 1.7 widely deployed enough.
Comment #15
eliza411 CreditAttribution: eliza411 commentedAn update: the newer version of Git will be included with the Ubuntu release in a few days. I'll be looking at the major distros again during the first part of May and we should be able to put this out soon.
Comment #16
TR CreditAttribution: TR commentedPosting this so others can find this issue when they search for the cause of the "confusing message" that git pull throws if you don't use -u when you push out your new branch. The message you will see looks something like this:
Comment #17
eliza411 CreditAttribution: eliza411 commented@sdboyer: I'm planning to update the instructions tomorrow unless you have objections. If it causes problems we can always revert and it looks to me like macports and Windows (msysgit) are plenty current.
Comment #18
eliza411 CreditAttribution: eliza411 commentedI've made this update, without any sort of "Didn't work for you." I'll plan to add that if support requests come in.