On 2015-05-13, at 7:54 AM, Roman Neuhauser <neuhau...@sigpipe.cz> wrote:
> # keybou...@gmail.com / 2015-05-13 07:37:34 -0700:
>>> These modes are selected by a special command line option: --soft,
>>> --hard or --mixed, with the latter being the default.
>>> The --soft option only repositions the branch's tip,
>> This is problem number one. That's pretty much what happened -- the
>> branch ("animalAging") was reset, but the documentation ("man
>> git-reset") claims something else.
>> Does not touch the index file or the working tree at all
>> (but resets the head to <commit>, just like all modes do).
>> This leaves all your changed files "Changes to be committed",
>> as git status would put it.
> i don't see any disagreement there.
>> It reset the head to commit, yes.
>> It also reset the branch tip pointer.
> those two sentences say the same thing. HEAD *is* "the branch tip pointer",
> unless it's detached.
Alright, maybe this is my first point of confusion.
I thought "HEAD" is where you are at -- which of those letters you are pointing
And, it may also be where a branch tip is pointing.
If I make a commit while on a branch, then HEAD -- which letter I'm at --
updates, and the branch tip pointer also updates.
If I'm detached, then which letter I'm at updates, but the branch tips do not.
Based on that, I thought that "git reset --soft" would change which letter I'm
pointing at, and leave the branch pointers unchanged.
What you seem to be saying, if I understand correctly, is that being at a
branch tip does not mean, "I am pointing to a letter, and the branch tip is
here as well", but "I am pointing at a branch tip, and the branch tip is
If that is the case, then the first thing I would need to do to make "git reset
--soft" behave the way I think it does is to first go to detached head at the
same letter (so I am now pointing at the letter that the branch tip points to,
rather than pointing to the branch tip pointer), then I can move head without
moving branch tips.
>> I found out about the --soft option by asking this list, how do I
>> change where a commit will go without altering any of my files -- I've
>> got files on branch X, but they should actually go onto master.
> that depends on your topology. let's say you've got master at C,
> topic at F:
> A -- B -- C
> D -- F
> % git checkout master
> % git merge --ff-only topic
> # OR
> % git reset --hard topic
> if this is your topology:
> A -- B -- C
> D -- F
> % git checkout topic
> % git rebase master
> that will give you the above, linear topology and you can apply the
> same commands.
Now, lets say your topic branch is really, really messy, with lots of commits,
tests, commits, tests, undo, test, change, test, repeat. And I really don't
want to toss that in as a fast forward. And, apparently, using "no-ff" breaks
bisect and blame (1). That means either a squash commit (which I've managed to
mess up once in two uses), or something else. As this was just a single file, I
thought this would be a simple way to move one file cleanly onto master.
Also: Every tutorial on branching I've seen says to branch from as far back in
history as makes sense; what you said seems to be the opposite, branch from the
tip of history, not from back in history. What am I misunderstanding?
Meanwhile, got any user-friendly tutorials on the proper use of rebase?
(1): Understanding git workflow: https://sandofsky.com/blog/git-workflow.html
Entertaining minecraft videos
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.