From: "Michael" <[email protected]>
I am trying to understand git rebase.
You have my sympathy. It can be confusing, especially because it's
syntax and options are backward compatible with the original usage which
pre-dates the use of formal "remotes". That said, there are now many
options that avoid the need for an upstream.
I am completely confused by the manual page. It starts by saying that
there has to be a valid upstream or it aborts, yet none of the examples
even describes how upstream affects anything. That's my first point of
confusion.
The original use was that you would fetch from an upstream buddy (e.g.
Linus), and then 'forward port' your changes to be on top of that
fetched branch. That was the 'git rebase' that needed no parameters
I don't understand the difference between "A...B", and just "A B" for
describing the changes from A to B ... are they equivalent, or what?
(This doesn't even begin to understand the two-dot syntax in the third
paragraph when the manual is explaining what it does, before it even
gets into how to use it)
The key is that "three dots" finds the point that the branch leading to
A diverged from the branch leading to B (say commit C). When used in the
original scheme this will transfer your work C..A [that's two dots] onto
(on top of) B, making your code linear again.
If you have a short series C..A but need to move it to somewhere else
(because you don't have a particular 'upstream', or you have a
triangular workflow) then use the --onto option (which feels to be two
thirds the way down the manual page..)
When the manual says,
That is exactly what interactive rebase is for: use it after plenty of
"a"s and "b"s, by rearranging and editing commits, and squashing
multiple commits into one.
that is a perfect fit for what I want to do. I've generally done a good
job of keeping different work topics on different branches, but I have
done lots of little bug fixing.
Finally, the warnings about recovering from upstream rebasing ...
It looks like recovering from simple rebasing (the manual calls this
the easy case) requires unedited commits, yet the manual also says that
interactive rebase and editing commits is the intended usage ... help?
I hope that general view is of help.
Why not create a simple test repo, or even clone you current repo and
try a
'git rebase -i --onto <destination> <start> <end>'
if <end> is omited, then HEAD is assumed.
Philip
====
Here is what I think I want to do (please tell me if this makes sense,
or if there is a better way to do this).
1. I want to take a series of commits from a branch off master, at some
point in the past.
2. I want to rebase that sequence to the head of master.
3. I want to squash it down to a single edit, showing the changes made
in that side branch.
4. And then, I want to commit that single change, in a way that makes it
clear to someone looking at the history that "This one commit represents
the final result of a tested branch" (#1) when that branch was a lot of
edits, cleanups, and fixes.
As a side case, right now #1 is all a single author, but in the future
once I learn how there may be someone else working on that branch as
well (git is distributed, right? Once I learn it well enough to actually
collaborate with someone else, then you can sick the "Colbert/Stewart
police" on me ;=).
So ideally, the final commit should properly identify which author is
responsible for which section ("git blame"), even if it's a single
commit (is that even possible?)
--
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 to [email protected].
For more options, visit https://groups.google.com/d/optout.
--
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
to [email protected].
For more options, visit https://groups.google.com/d/optout.
