Re: git-branch, older repos and more confusion

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 4/12/07, Jeff King <peff@xxxxxxxx> wrote:
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"?

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.

> 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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]