From: Junio C Hamano <hidden> Date: 2016-06-15 22:46:24
"John Dlugosz" [off-list ref] writes:
I made a mistake. Big deal, now that I know that git storage is
immutable and changes just add to what's already there.
A quick look at
git reflog show topic
tells me that {1} is the one I want. So, how do I rewind branch topic
to point to topic@{1} ?
I did it by making a tag, and then in gitk pointing to it and picking
"reset to here" from the context menu.
A while back I was looking for the right/easy way to simply repoint my
branch to where I wanted. The best answer was to use push.
The answer was best only because in your previous question you wanted to
ensure fast-forwardness, i.e. "git push . origin/dev:dev" without plus in
front to cause it to fail if it is not fast-forward.
If you know you have one unwanted commit you would want to discard at the
tip of topic, you do not want fast-foward safety to kick in.
(1) if you are on the topic branch, you can say "git reset --hard HEAD^";
or
(2) if you are not, you can obviously check out topic and do the above,
or "git branch -f topic topic^".
If the garbage you have at the tip of the topic is not just a single
commit, you can replace HEAD^ and topic^ in the above with whatever commit
you would want to point the tip at.
From: John Dlugosz <hidden> Date: 2016-06-15 22:46:24
=== Re: ===
The answer was best only because in your previous question you wanted to
ensure fast-forwardness, i.e. "git push . origin/dev:dev" without plus
in
front to cause it to fail if it is not fast-forward.
=== end ===
No, I don't want to ensure ff. The remote may have been changed in
other ways. Though in that case I will avoid doing so; when it is not
the case it's even more important to see that your local copy is
different, and understand the tree, rather than blindly pulling.
=== Re: ===
If you know you have one unwanted commit you would want to discard at
the
tip of topic, you do not want fast-foward safety to kick in.
(1) if you are on the topic branch, you can say "git reset --hard
HEAD^";
or
=== end ===
It was a rebase, so the old value is not under the current, or even
visible on the tree. That's why I needed the reflog to find it.
Tagging it let it appear in gitk.
=== Re: ===
(2) if you are not, you can obviously check out topic and do the above,
or "git branch -f topic topic^".
=== end ===
As documented, this destroys the existing branch and makes a new one.
That would, by design, blow away the reflog for that branch. What I
want is a way to re-point it, and record that repointing =in= the
reflog. That is, a command-line version that does what I can do with
the GUI, but isn't limited to what I can point to with the mouse.
--John
(please excuse the footer, yadda yadda)
TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.
If you received this in error, please contact the sender and delete the material from any computer.
=== Re: ===
(2) if you are not, you can obviously check out topic and do the above,
or "git branch -f topic topic^".
=== end ===
As documented, this destroys the existing branch and makes a new one.
That would, by design, blow away the reflog for that branch.
Does it? If so I think you have an incorrect documentation.
$ rm -fr /tmp/gomi && mkdir /tmp/gomi
$ cd /tmp/gomi
$ git init
$ echo hello >world
$ git add world
$ git commit -m initial
$ seq 1 100 | while read num; do echo $num >world; git commit -a -m $num; done
$ git checkout -b side master~60
$ git branch -f master master@{20}
$ git log --oneline -g master | head -n 10
0acf8c1 master@{0}: branch: Reset from master@{20}
945c3ee master@{1}: commit: 100
54fcb36 master@{2}: commit: 99
b314a1e master@{3}: commit: 98
e91d999 master@{4}: commit: 97
0d88853 master@{5}: commit: 96
0124315 master@{6}: commit: 95
5df2cc5 master@{7}: commit: 94
14bb58e master@{8}: commit: 93
0813a46 master@{9}: commit: 92
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
From: Junio C Hamano <hidden> Date: 2016-06-15 22:46:24
Nanako Shiraishi [off-list ref] writes:
Quoting John Dlugosz [off-list ref]:
quoted
=== Re: ===
(2) if you are not, you can obviously check out topic and do the above,
or "git branch -f topic topic^".
=== end ===
As documented, this destroys the existing branch and makes a new one.
That would, by design, blow away the reflog for that branch.
Does it? If so I think you have an incorrect documentation.
$ rm -fr /tmp/gomi && mkdir /tmp/gomi
$ cd /tmp/gomi
$ git init
$ echo hello >world
$ git add world
$ git commit -m initial
$ seq 1 100 | while read num; do echo $num >world; git commit -a -m $num; done
$ git checkout -b side master~60
$ git branch -f master master@{20}
$ git log --oneline -g master | head -n 10
0acf8c1 master@{0}: branch: Reset from master@{20}
945c3ee master@{1}: commit: 100
54fcb36 master@{2}: commit: 99
b314a1e master@{3}: commit: 98
e91d999 master@{4}: commit: 97
0d88853 master@{5}: commit: 96
0124315 master@{6}: commit: 95
5df2cc5 master@{7}: commit: 94
...
0813a46 master@{9}: commit: 92
I didn't even notice there was another question buried. Thanks.
Documentation/git-branch.txt says this:
-f::
Force the creation of a new branch even if it means deleting
a branch that already exists with the same name.
which does imply that it first destroys the branch altogether and
recreates as if there was no such branch.
But that is actually not what the code does to reflog, and I think the
behaviour makes a lot more sense than "destroy and create" the
documentation implies. branch.c::create_branch() has this:
if (forcing)
snprintf(msg, sizeof msg, "branch: Reset from %s",
start_name);
else
snprintf(msg, sizeof msg, "branch: Created from %s",
start_name);
The message for your master@{0} example came from the "forcing" codepath.
The documentation is indeed wrong. It is more like "create a new branch,
or if the named branch already exists, reset the tip of it". If we want
to sound alarmist, we could add "even if it means making the existing
history unreachable from the new tip of the branch", but I think "reset"
already means that and it would be redundant.
The create_branch() function does another thing, though. It sets up the
tracking information _if asked_. Because one branch cannot track more
than one "other things" at once, it inevitably overwrites the previous
tracking information if you say "branch --track -f dev origin/dev" if dev
were tracking something else. But if you do not let it set up tracking,
the old tracking configuration is _not_ discarded. I am not sure if that
was intended (the branch.<name>.remote nor branch.<name>.merge variables
are not something I use myself), but it makes sort of sense. If you do
"git branch -f dev dev~2" to rewind its tip, you do not want to lose its
tracking information, so the current behaviour makes sense in that
respect.
I am not sure about how branch.autsetupmerge does interact with this in
the current code, nor how it should interact with it in the ideal world,
though. That's for interested parties (I suspect Jay and Paolo?) to
figure out.
From: Michael J Gruber <hidden> Date: 2016-06-15 22:46:24
'git branch -f a b' resets a to b when a exists, rather then deleting a.
Say so in the documentation.
Signed-off-by: Michael J Gruber <redacted>
---
Something like this?
BTW, I noticed that 'git-subcmd' is used everywhere in here which does
not feel right, but I followed the existing style, leaving a consistent
clean-up for a later patch. Also, typesetting is inconsistent:
We have <branch> as well as `<branch>` when the text talks about the
options. Do we have a style guide or such?
Documentation/git-branch.txt | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
@@ -76,8 +76,8 @@ OPTIONS based sha1 expressions such as "<branchname>@\{yesterday}". -f::- Force the creation of a new branch even if it means deleting- a branch that already exists with the same name.+ Reset <branchname> to <startpoint> if <branchname> exists+ already. Without `-f` 'git-branch' refuses to change an existing branch. -m:: Move/rename a branch and the corresponding reflog.
From: John Dlugosz <hidden> Date: 2016-06-15 22:46:24
The documentation is indeed wrong. It is more like "create a new
branch,
or if the named branch already exists, reset the tip of it".
Awesome. Then git branch -f name newpos is exactly what I need.
I wondered why something that should be so simple, and is available from
every GUI, is not easy from the command line.
--John
TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.
If you received this in error, please contact the sender and delete the material from any computer.