git-branch, older repos and more confusion

Thanks to Peff for helping me out earlier with my git-branch usage.
Alas, I seem to be in trouble again.

My git tracking repo is still using the .git/remotes/origin
infrastructure, and now it turns out I can't seem to do a git-pull and
then a git-format-patch of my local 'master' for patches to go on top
of junio's master. I am using 1.5.1.106.ga32037

I'll get a new checkout, but I'm a bit miffed that this is broken -- I
wanted to use git-format-patch to migrate unmerged patches to the new
checkout.

<rant>
This is all a bit confusing, and "the right way to do it" is changing
too fast. And with the changes, all the little things that make it
easy to manage it are lost, and all the wiki pages and documentation
bits are old and wrong. The simple master/origin scheme works well, is
dead easy to teach, and has worked well for my team of ~14 developers
working on maybe ~40 custom branches. It's pretty safe from errors too
;-)

Alas - I think support for it seems to be going the away... what I am
missing is a clear way to say git-clone <repo>#branch that has the
same properties that `cg-clone <repo>#branch` has. Namely, once you
are done, there are clear names for your "local tip" and "remote tip",
and push and pull do the right thing without extra params.

cheers,


martin

On Thu, Apr 12, 2007 at 04:14:06PM +1200, Martin Langhoff wrote:

My git tracking repo is still using the .git/remotes/origin
infrastructure, and now it turns out I can't seem to do a git-pull and
then a git-format-patch of my local 'master' for patches to go on top
of junio's master. I am using 1.5.1.106.ga32037

What doesn't work? IIRC, you might have some problems with doing a
'pull' with no parameters, since you don't have the right magic in
.git/config. Have you tried an explicit "git-pull origin master"?

Alas - I think support for it seems to be going the away... what I am
missing is a clear way to say git-clone <repo>#branch that has the
same properties that `cg-clone <repo>#branch` has. Namely, once you
are done, there are clear names for your "local tip" and "remote tip",
and push and pull do the right thing without extra params.

I don't think there is a way to clone _just_ that branch, but if you're
OK with fetching all of the branches, then you should be able to do
just:

git-clone <repo>
git-branch --track branch origin/branch
git-checkout branch

Yours is 'branch' and remote is 'origin/branch'. If that branch is
master, then I believe git-clone should set you up already (and you can
even still refer to 'origin', which is a synonym for origin/HEAD).

Or am I not understanding your problem?

-Peff

Jeff King wrote:

quoted

Alas - I think support for it seems to be going the away... what I am
missing is a clear way to say git-clone <repo>#branch that has the
same properties that `cg-clone <repo>#branch` has. Namely, once you
are done, there are clear names for your "local tip" and "remote tip",
and push and pull do the right thing without extra params.
    

I don't think there is a way to clone _just_ that branch, but if you're
OK with fetching all of the branches, then you should be able to do
just:

git-clone <repo>
git-branch --track branch origin/branch
git-checkout branch
  

You can;

 mkdir moodle
 cd moodle
 git-init
 git-remote add -t mdl-topnz -f origin \
    git://git.catalyst.net.nz/moodle.git

But yes, not as easy as "cg-clone git://...#branch"

I sent a patch for 'git remote prune -c' recently that would help in the
transition between the two remotes formats.

Sam.

On 4/12/07, Jeff King [off-list ref] wrote:

On Thu, Apr 12, 2007 at 04:14:06PM +1200, Martin Langhoff wrote:

quoted

My git tracking repo is still using the .git/remotes/origin
infrastructure, and now it turns out I can't seem to do a git-pull and
then a git-format-patch of my local 'master' for patches to go on top
of junio's master. I am using 1.5.1.106.ga32037

What doesn't work? IIRC, you might have some problems with doing a
'pull' with no parameters, since you don't have the right magic in
.git/config. Have you tried an explicit "git-pull origin master"?

Sorry - I should have been clearer here... what I can't seem to do is
git-format-patch origin/master..master - but I've resolved that.

quoted

Alas - I think support for it seems to be going the away... what I am
missing is a clear way to say git-clone <repo>#branch that has the
same properties that `cg-clone <repo>#branch` has. Namely, once you
are done, there are clear names for your "local tip" and "remote tip",
and push and pull do the right thing without extra params.

I don't think there is a way to clone _just_ that branch, but if you're
OK with fetching all of the branches, then you should be able to do
just:

git-clone <repo>
git-branch --track branch origin/branch
git-checkout branch

True - that's the hint you gave me yesterday. It doesn't work on 1.4.x
or 1.5.0 either. Requires 1.5.1+, which is a bit awkward -- I can (and
will) move my team to using this, but we have git installs we don't
control directly, like external collaborators, remote servers where we
use git to manage deployments, etc.

Which means I'll have to write a little list that goes "if your git is
version X, do this, if it's version Y do that". :-(

Yours is 'branch' and remote is 'origin/branch'. If that branch is
master, then I believe git-clone should set you up already (and you can
even still refer to 'origin', which is a synonym for origin/HEAD).

Or am I not understanding your problem?

No. You're spot on. Using this trick however, a few idioms that used
to work for us don't quite work anymore.

For example, creating a new "custom" branch on the repo used to be
trivial and left us with a setup that was simple and safe. For
example, if you wanted to work on a custom v1.9:

 - cg-clone <repo>#v1.9-maint mydir
 - cd mydir
 - cg-branch-chg origin <repo>#1.9-clientname
 - cg-push     ## this creates the new head on the repo
 - cg-branch-add v1.9-maint <repo>#v1.9-maint mydir

and from there onwards cg-update / cg-push worked on the custom
branch, and cg-update v1.9-maint would merge from the maint branch.

Any hints as to how to run such workflow on v1.5.x?

cheers,



m

On 4/12/07, Sam Vilain [off-list ref] wrote:

I sent a patch for 'git remote prune -c' recently that would help in the
transition between the two remotes formats.

Good one. BTW, if you are hacking git-remote, it's missing a "delete"
command ;-)



m

On Thu, Apr 12, 2007 at 05:05:24PM +1200, Martin Langhoff wrote:

Which means I'll have to write a little list that goes "if your git is
version X, do this, if it's version Y do that". :-(

Yes, that is frustrating. If you are just working with master/origin, I
think you can get away with it due to the default configuration created,
but otherwise I'm not sure it's avoidable. I seem to recall a thread
about this a few months ago (between me and Bill Lear, maybe?), but I
don't recall that there was any especially good conclusion.

For example, creating a new "custom" branch on the repo used to be
trivial and left us with a setup that was simple and safe. For
example, if you wanted to work on a custom v1.9:

- cg-clone <repo>#v1.9-maint mydir
- cd mydir
- cg-branch-chg origin <repo>#1.9-clientname
- cg-push     ## this creates the new head on the repo
- cg-branch-add v1.9-maint <repo>#v1.9-maint mydir

and from there onwards cg-update / cg-push worked on the custom
branch, and cg-update v1.9-maint would merge from the maint branch.

Any hints as to how to run such workflow on v1.5.x?

This will seem like repetition, but it's like this:

  git-clone <repo> mydir
  cd mydir
  git-checkout --track -b v1.9-clientname origin/v1.9-maint
  git-push origin v1.9-clientname    # to create the new head remotely

When you do a git-pull without arguments from the v1.9-clientname
branch, it will first do a fetch of origin (grabbing the entire state,
including the v1.9-maint branch) and then merge in origin's v1.9-maint.

When you do a push without arguments, it will push every head you have
in common with origin. Because we pushed the v1.9-clientname branch
once, it was created and will be part of subsequent pushes.

-Peff

On 4/12/07, Jeff King [off-list ref] wrote:

quoted

Any hints as to how to run such workflow on v1.5.x?

This will seem like repetition, but it's like this:

Thanks for bearing with me ;-)

  git-clone <repo> mydir
  cd mydir
  git-checkout --track -b v1.9-clientname origin/v1.9-maint
  git-push origin v1.9-clientname    # to create the new head remotely

When you do a git-pull without arguments from the v1.9-clientname
branch, it will first do a fetch of origin (grabbing the entire state,
including the v1.9-maint branch) and then merge in origin's v1.9-maint.

Almost what I am after, but not quite. In my Cogito workflow,
cg-update will by default pull from  v1.9-clientname, which is what
you want most of the time (collaborating with other developers on that
branch). We do cg-update/cg-push all the time, and cg-update
<maintbranch> is a less frequent operation.

On my own I had gotten almost to the same sequence you show above, but
couldn't get it right. With what you are showing me now, I'd say

 git-clone <repo> mydir
 cd mydir
 git-checkout -b tmpbranch origin/v1.9-maint
 git-push origin v1.9-clientname    # to create the new head remotely
 git-checkout --track -b v1.9-clientname origin/v1.9-clientname
 git-deletebranch tmpbranch # this command doesn't exist!

And then git-pull / git-push will "do the right thing". And `git-pull
origin/v1.9-maint` will trigger a fetch & merge.

When you do a push without arguments, it will push every head you have
in common with origin.

That's interesting!

cheers,


m

On 4/12/07, Martin Langhoff [off-list ref] wrote:

On my own I had gotten almost to the same sequence you show above, but
couldn't get it right. With what you are showing me now, I'd say

And I think I got it sussed out with:

   git-clone <repo> mydir
   cd mydir
   git-push origin origin/v1.9-maint:refs/heads/v1.9-clientname
   git-checkout --track -b v1.9-clientname origin/v1.9-clientname

cheers,


martin