On Fri, Jul 15, 2011 at 7:09 AM, Pete Wyckoff <pw@xxxxxxxx> wrote:
> At work, our primary SCM is perforce (p4), but many of us use git
> in front of that for day-to-day work. The build system requires
> information about what part of the P4 repository it is building.
> I've cobbled together changes to make this work with git, and
> have been using "git merge-base HEAD @{upstream}" to find the
> top-most git-p4 commit.
>
> But @{upstream} is not automatically inherited by branches. It
> is fine when a local branch is a normal tracking branch of
> origin/master, like:
>
> $ git checkout master
> $ git rev-parse --symbolic-full-name @{upstream}
> refs/remotes/origin/master
>
> But I'd also like this to work:
>
> $ git branch feature
> $ git checkout feature
> $ git rev-parse --symbolic-full-name @{upstream}
> error: No upstream branch found for ''
> @{upstream}
> error: No upstream branch found for ''
> fatal: ambiguous argument '@{upstream}': unknown revision or path not in the working tree.
> Use '--' to separate paths from revisions
>
> I know I can do:
>
> $ git branch --set-upstream feature origin/master
>
> but that is a pain. And I know I can track the local master, but
> that is not what I want.
>
> I'm looking for something like "branch.autosetupupstream" that
> would cause the upstream of new branches to be copied from the
> old branch (when it exists). Does this make sense?
Yeah, this is something I'd like to fix:
http://thread.gmane.org/gmane.comp.version-control.git/168157
j.
--
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