Daniel Pittman <daniel@xxxxxxxxxxxx> writes:
> The general question was: in git, how do I identify where this branch
> came from?
In general, you cannot. In specific cases, you can.
See below for details.
> Specifically, this was about 'git svn', but also generally how to
> identify this information in git.
>
> So, with a repository branch layout like this:
>
> master (local)
> testing (local)
> trunk (remote)
> v100 (remote)
>
> How would I find out which remote branch master and trunk came from?
>
>
> To restate that, because I am not sure if that is clear, given this
> layout of branches:
>
> trunk (remote)
> |
> o---o---o---o---o branch master
> \
> \
> o---o---o---o branch testing
> |
> v100 (remote)
>
> How can I identify that 'testing' came from the 'v100' branch, and that
> master came from the 'trunk' branch?
>
>
> Ideally, I would like to work this out on the command line, without
> needing to reference gitk or another graphical tool, but even a solution
> that used them would be fine.
[...]
> ...and, finally, is the reason that I am finding it hard to explain this
> because I have an expectation of how things work that doesn't match up
> with git? In other words, is the question actually meaningless?
On the plumbing level, or on the level of graph of commits, git does
not store information "where this branch came from". For git, from
the point of view of commit objects, the following two pictures are
totally equivalent (by design):
/-o---o branch a
/
o---*---o---o---o branch b
and
o---*---o---o branch a
\
\-o---o---o branch b
What you _can_ get on this level is to find common ancestor (or common
ancestors) of branches 'a' and 'b', using "git merge-base a b"; this
would return commit marked '*'.
However, when creating a branch, you can tell git that you want for
newly created branch to track branch you are based on (with --track)
option. By default saving tracking information is done when branching
off remote-tracking branches.
>From git-branch(1):
When a local branch is started off a remote branch, git sets up the
branch so that 'git-pull' will appropriately merge from
the remote branch. This behavior may be changed via the global
`branch.autosetupmerge` configuration flag. That setting can be
overridden by using the `--track` and `--no-track` options.
[...]
--track::
When creating a new branch, set up configuration so that 'git-pull'
will automatically retrieve data from the start point, which must be
a branch. Use this if you always pull from the same upstream branch
into the new branch, and if you don't want to use "git pull
<repository> <refspec>" explicitly. This behavior is the default
when the start point is a remote branch. Set the
branch.autosetupmerge configuration variable to `false` if you want
'git-checkout' and 'git-branch' to always behave as if '--no-track' were
given. Set it to `always` if you want this behavior when the
start-point is either a local or remote branch.
And git-config(1)
branch.<name>.remote::
When in branch <name>, it tells 'git-fetch' which remote to fetch.
If this option is not given, 'git-fetch' defaults to remote "origin".
branch.<name>.merge::
When in branch <name>, it tells 'git-fetch' the default
refspec to be marked for merging in FETCH_HEAD. The value is
handled like the remote part of a refspec, and must match a
ref which is fetched from the remote given by
"branch.<name>.remote".
The merge information is used by 'git-pull' (which at first calls
'git-fetch') to lookup the default branch for merging. Without
this option, 'git-pull' defaults to merge the first refspec fetched.
Specify multiple values to get an octopus merge.
If you wish to setup 'git-pull' so that it merges into <name> from
another branch in the local repository, you can point
branch.<name>.merge to the desired branch, and use the special setting
`.` (a period) for branch.<name>.remote
In this case you can get _name_ of the branch this branch "came from"
with "git config branch.<branchname>.merge".
HTH.
--
Jakub Narebski
Poland
ShadeHawk on #git
--
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
