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

Reply via email to