I am trying to understand git rebase.

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.

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)

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?

====

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 git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to