From: Junio C Hamano <hidden> Date: 2016-06-15 22:44:24
Paul Gardiner [off-list ref] writes:
I need a command that will find the remote branch from which
the currently checked out branch was started. I don't know
git very well, and the only way I can think to do it so far
is to iterate over the remote branches and find the one
for which git-rev-list <branch>..HEAD gives the smallest
number of objects. I'm guessing there must be a better
way. Any ideas?
There will be _no_ way. It is simply impossible.
$ git checkout -b my-new-branch origin/somerandombranch~27^2^2~23
is a perfectly valid way to create a new branch.
You would probably want to re-think in a bigger picture, _why_
you would want to find such information, in other words, how you would
want to use the information (if such a thing were possible) to solve
_what_ problem. That true problem you did not mention (and assumed that
"the remote branch the branch was branched from" would be a good tool to
solve it) might have a better solution.
On Fri, Mar 21, 2008 at 5:13 AM, Junio C Hamano [off-list ref] wrote:
Paul Gardiner [off-list ref] writes:
> I need a command that will find the remote branch from which
> the currently checked out branch was started. I don't know
> git very well, and the only way I can think to do it so far
> is to iterate over the remote branches and find the one
> for which git-rev-list <branch>..HEAD gives the smallest
> number of objects. I'm guessing there must be a better
> way. Any ideas?
There will be _no_ way. It is simply impossible.
$ git checkout -b my-new-branch origin/somerandombranch~27^2^2~23
is a perfectly valid way to create a new branch.
You would probably want to re-think in a bigger picture, _why_
you would want to find such information, [...]
I frequently want to do this. Basically, I start from "some version"
of the upstream program, and I put together some patches, then I want
to use rebase to reorder and recombine them before I send them in.
In order to do this, however, I'm forced to remember where I got my
"original" version from, which isn't even that important. As the
developer of a particular patch, all I *really* should have to know
is: a) here are the things I added since I made my topic branch, and
b) here is the branch I want to rebase them onto so I can submit my
cleaned patches upstream.
If git would explicitly track the rev at which my branch was created,
it would mostly solve *my* problem here, even though I wouldn't know
the *name* of the branch I branched from.
Alternatively, we could avoid tracking anything extra at all. If git
could suggest a branch or tag that mine is "currently closest to",
ie., the one that has as many of the commits from my branch as
possible (even if it has additional commits that I don't have), then
that might be the branch I'm interested in. If not, I could use this
comment repeatedly to produce a "chain of parent branches", one of
which is probably the one I'm interested in.
Have fun,
Avery
From: Charles Bailey <hidden> Date: 2016-06-15 22:44:24
On Fri, Mar 21, 2008 at 01:39:11PM -0400, Avery Pennarun wrote:
On Fri, Mar 21, 2008 at 5:13 AM, Junio C Hamano [off-list ref] wrote:
quoted
Paul Gardiner [off-list ref] writes:
> I need a command that will find the remote branch from which
> the currently checked out branch was started. I don't know
> git very well, and the only way I can think to do it so far
> is to iterate over the remote branches and find the one
> for which git-rev-list <branch>..HEAD gives the smallest
> number of objects. I'm guessing there must be a better
> way. Any ideas?
There will be _no_ way. It is simply impossible.
$ git checkout -b my-new-branch origin/somerandombranch~27^2^2~23
is a perfectly valid way to create a new branch.
You would probably want to re-think in a bigger picture, _why_
you would want to find such information, [...]
I frequently want to do this. Basically, I start from "some version"
of the upstream program, and I put together some patches, then I want
to use rebase to reorder and recombine them before I send them in.
So you're looking to do a git rebase -i?
In order to do this, however, I'm forced to remember where I got my
"original" version from, which isn't even that important. As the
developer of a particular patch, all I *really* should have to know
is: a) here are the things I added since I made my topic branch, and
b) here is the branch I want to rebase them onto so I can submit my
cleaned patches upstream.
Why are you forced to remember?
If you don't want to transplant the patches onto where the remote
branch is now, then you just need to pick a commit on your current
branch that is before any commit that you want to reorder/recombine
and do a git rebase -i <sha1>. (It should be easy to pick a commit
from git log. Perhaps it's the first one with and author that isn't
you. Alternatively, if you don't want to look at the log and you know
you haven't made more than N commits you could just git rebase -i
HEAD~N.)
If you want to rebase them on to the latest version of the remote
branch then it's even simpler. You just do:
git rebase -i remote/branch
I'm not sure I understand why you need to know where your original
branch was made from?
Charles.
On Fri, Mar 21, 2008 at 2:32 PM, Charles Bailey [off-list ref] wrote:
> In order to do this, however, I'm forced to remember where I got my
> "original" version from, which isn't even that important. As the
> developer of a particular patch, all I *really* should have to know
> is: a) here are the things I added since I made my topic branch, and
> b) here is the branch I want to rebase them onto so I can submit my
> cleaned patches upstream.
Why are you forced to remember?
If you don't want to transplant the patches onto where the remote
branch is now, then you just need to pick a commit on your current
branch that is before any commit that you want to reorder/recombine
and do a git rebase -i <sha1>. (It should be easy to pick a commit
from git log. Perhaps it's the first one with and author that isn't
you. [...]
All these things work, but they're unnecessarily tedious manual
remembering. If I have a lot of topic branches on the go at once,
things start getting a little messy and it's hard to remember which
patches came from where, particularly if I'm aggregating, reviewing,
and cleaning up patches from several people at work before sending
them upstream (in which case I don't always recognize the checkin
messages presented in git-rebase -i).
svn has "svn log --stop-on-copy", which is useful in exactly this
situation. A git branch is not really a "copy", of course, so the
actual implementation can't be the same.
"git show-branch" has logic very close to what we need here: if you
give it the names of your current branch and its parent, it'll show
you just the changes on both branches since the branchpoint. But I
don't really want to know about additional changes on the parent, only
on the branch I'm working with, and I often prefer the output to be in
git-log's (very flexible) format instead of git-show-branch.
Have fun,
Avery
On Fri, Mar 21, 2008 at 9:48 PM, Avery Pennarun [off-list ref] wrote:
"git show-branch" has logic very close to what we need here: if you
give it the names of your current branch and its parent, it'll show
you just the changes on both branches since the branchpoint. But I
don't really want to know about additional changes on the parent, only
on the branch I'm working with, and I often prefer the output to be in
git-log's (very flexible) format instead of git-show-branch.
I believe that
git log parent-branch..local-branch
should give you exactly what you want, i.e. all changes on your local
branch since it was copied from the parent branch.
Dmitry
From: Daniel Barkalow <hidden> Date: 2016-06-15 22:44:24
On Fri, 21 Mar 2008, Dmitry Potapov wrote:
On Fri, Mar 21, 2008 at 9:48 PM, Avery Pennarun [off-list ref] wrote:
quoted
"git show-branch" has logic very close to what we need here: if you
give it the names of your current branch and its parent, it'll show
you just the changes on both branches since the branchpoint. But I
don't really want to know about additional changes on the parent, only
on the branch I'm working with, and I often prefer the output to be in
git-log's (very flexible) format instead of git-show-branch.
I believe that
git log parent-branch..local-branch
should give you exactly what you want, i.e. all changes on your local
branch since it was copied from the parent branch.
Then you need to remember what the parent branch was. But:
git log local-branch ^maybe-parent-1 ^maybe-parent-2 ...
should give you what you want.
-Daniel
*This .sig left intentionally blank*
From: J. Bruce Fields <hidden> Date: 2016-06-15 22:44:24
On Fri, Mar 21, 2008 at 04:22:11PM -0400, Daniel Barkalow wrote:
On Fri, 21 Mar 2008, Dmitry Potapov wrote:
quoted
On Fri, Mar 21, 2008 at 9:48 PM, Avery Pennarun [off-list ref] wrote:
quoted
"git show-branch" has logic very close to what we need here: if you
give it the names of your current branch and its parent, it'll show
you just the changes on both branches since the branchpoint. But I
don't really want to know about additional changes on the parent, only
on the branch I'm working with, and I often prefer the output to be in
git-log's (very flexible) format instead of git-show-branch.
I believe that
git log parent-branch..local-branch
should give you exactly what you want, i.e. all changes on your local
branch since it was copied from the parent branch.
Then you need to remember what the parent branch was. But:
git log local-branch ^maybe-parent-1 ^maybe-parent-2 ...
should give you what you want.
From: Paul Gardiner <hidden> Date: 2016-06-15 22:44:24
Avery Pennarun wrote:
Alternatively, we could avoid tracking anything extra at all. If git
could suggest a branch or tag that mine is "currently closest to",
ie., the one that has as many of the commits from my branch as
possible (even if it has additional commits that I don't have), then
that might be the branch I'm interested in.
Yes, that's exactly what I need too. I need to produce it
programatically. I notice gitk displays, for each commit,
the branches that include it. If I knew a command for
deriving that, I could iterate through HEAD, HEAD~1, HEAD~2...
until I see a remote branch.
P.
From: Jeff King <hidden> Date: 2016-06-15 22:44:24
On Sat, Mar 22, 2008 at 12:12:16PM +0000, Paul Gardiner wrote:
Yes, that's exactly what I need too. I need to produce it
programatically. I notice gitk displays, for each commit,
the branches that include it. If I knew a command for
deriving that, I could iterate through HEAD, HEAD~1, HEAD~2...
until I see a remote branch.
How about:
git name-rev --refs='refs/remotes/*' $COMMIT
?
-Peff
From: Paul Gardiner <hidden> Date: 2016-06-15 22:44:24
Jeff King wrote:
On Sat, Mar 22, 2008 at 12:12:16PM +0000, Paul Gardiner wrote:
quoted
Yes, that's exactly what I need too. I need to produce it
programatically. I notice gitk displays, for each commit,
the branches that include it. If I knew a command for
deriving that, I could iterate through HEAD, HEAD~1, HEAD~2...
until I see a remote branch.
How about:
git name-rev --refs='refs/remotes/*' $COMMIT