More help with "pull" please

I've actually given up on using "git pull" at all, preferring to fetch first, examine in gitk, and then decide whether to merge or whatever.

The problem I have is that it seems to always want to merge "something" with the current checked-out branch. It always throws the remote HEAD into the mix, or if fetch lines are set up in the configuration file, takes the first thing on there regardless of which branch I'm currently checked out. Maybe I'm wrong, but I just re-read the man page, forward and backwards, and am more bewildered than ever.

Anyway, I want to help out a co-worker who has a more specialized situation that may be right for a pull. Also, I'll talk him through cloning the remote from the beginning, so the config files won't be all strange or not setup from the previous users.

The only remaining issue is the remote in question: it is not a bare repository, and may be in use locally as well, at least for maintenance. So I can't trust its HEAD to be anything reasonable at any given time.

This person wants to track a remote branch tip. When that advances or otherwise changes on the remote, update the working tree to match. It will always use the same branch, let's call it ReleaseCandidate for this discussion.

My question is: What is the easiest way to create this local repository and operate it so that he can just keep it following that branch on the remote?

Thanks, --John (excuse the footer; it's not my idea)

TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.
  If you received this in error, please contact the sender and delete the material from any computer.

On Apr 1, 2009, at 9:28 PM, John Dlugosz wrote:

When you create a branch, you can tell git which remote branch it tracks, like this:

$ git branch --track mynext origin/next

So whenever you are on brach 'mynext' and do a git-pull, it will fetch and merge origin/next.

You can do the same with the git-checkout command:

$ git checkout --track origin/next

This will create a local branch 'next' which tracks 'origin/next'

$ git clone $url XXX $ cd XXX $ git checkout --trach origin/ReleaseCandidate ... $ git pull # will automatically fetch and merge origin/ReleaseCandidate

tom

OK, that works by adding something to the config file, right? The docs don't say, but does mention "having Pull: <refspec> lines for a <repository>". Does tracking add Pull: lines, or is that another feature?

origin/ReleaseCandidate

According to the manpage on pull, "While git-pull run without any explicit <refspec> parameter takes default <refspec>s from Pull: lines, it merges only the first <refspec> found into the current branch, after fetching all the remote refs."

Also, "When no refspec was given on the command line ... If branch.<name>.merge configuration for the current branch <name> exists, that is the name of the branch at the remote site that is merged." So is that yet again different from having Pull: lines? If so, I'm fine if no "Pull:" lines exist, or it would merge the first refspec found there.

Also, "Normally the branch merged in is the HEAD of the remote repository, but the choice is determined by the branch.<name>.remote and branch.<name>.merge options; see git-config(1) for details." That agrees with the previous. If branch.<name>.merge configuration exists, I don't need to worry about the remote HEAD.

That command does not work. It compains that --track can only be used with -b, etc.

I think 
	git checkout -b origin/ReleaseCandidate

is the correct shortcut?  

	git checkout -b ReleaseCandidate origin/ReleaseCandidate

did work. I know that --track is automatic if the second argument is remote.

--John

TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.
  If you received this in error, please contact the sender and delete the material from any computer.

On Apr 2, 2009, at 12:53 AM, John Dlugosz wrote:

I think Pull: lines are not used anymore in newer repositories. Tracking is done through the 'branch.<name>.remote' and 'branch.<name>.merge' config options (which are automatically set by git-branch/git-checkout when you use --track).

I'd say forget about Pull: because you won't see any of that in newer repositories. Instead, just use --track when checking out a branch you intend to follow. And, more as an implementation detail than anything else, remember that the tracking is done through the above mentioned config options (which you can set/change using git-config or directly by editing the .git/config file).

Maybe it's because I'm using a fairly recent version (1.6.2.1.307.g91408).

tom

...

OK, the documentation is clear if I ignore that. I expect it to be "well behaved" if I'm on a tracking branch and give it no arguments, or if the single refspec argument is the correct remote for the branch I'm on. Otherwise (not a tracking branch) the docs just say "It's complicated, backward compatibility" and presumably involves those non-existent Pull: lines and the state of the remote's HEAD.

I'm running git version (1.6.2.msysgit.0.186.gf7512), and I assume my coworker's was a bit older.

--John

TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.
  If you received this in error, please contact the sender and delete the material from any computer.

Tomas Carnecky <tom@dbservice.com> writes:

If your repository is using .git/remotes/origin to name the "origin" remote, they are still honored. But you are correct to point out that branch.<name>.remote and with the remote.<name>.* variables in .git/config are used to control these more recent features. So in that sense the documentation is still correct.

I don't have a directory under .git called remotes. A new repository made using clone describes origin in the config file. Is that an old way of doing things?

A related question: is the name "origin" hard-coded as the default, or does each repository remember specifically which is the upstream repository regardless of what you named it? From what I see in the config file, it would have to be per-branch. I suppose in other cases it's implicit in where the label was found under remotes.

--John

TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.
  If you received this in error, please contact the sender and delete the material from any computer.

On Apr 2, 2009, at 4:45 PM, John Dlugosz wrote:

Yep. Earlier git versions used one config file per remote. Newer git versions use the .git/config file.

'origin' is the default name for the remote you cloned from. But there is nothing special to it other than being a default name used throughout git. You can manually add remotes under a different name if you like.

$ git clone $url ./xyz

is roughly the same as:

$ mkdir ./xyz && cd ./xyz $ git init $ git remote add origin $url $ git fetch origin $ git checkout -b master origin/master

tom