[TYPO3-v4] Git: what to do when a branch "diverges"?

[Ernesto Baschny [cron IT]]

François Suter schrieb am 08.03.2011 09:43:
> Hi,
> 
>> fetch doesn't make a commit, so after fetch your last commit is still
>> behind the HEAD.
>> pull does a fetch + commit, so this is the way i do always to be up to
>> date. Don't be afraid, you can do this many times.
>> If pull doesn't solve it, try pull --rebase
> 
> Thanks for trying to help, but that's not what I was asking about at
> all. Maybe I wasn't clear enough, let me try again. Here's the "history":
> 
> 1) a couple of day ago I prepared a patch. I created a branch based on
> origin/master, wrote my patch and committed it.
> 2) I didn't push the change back then, because I had access problems to
> Gerrit.
> 3) today (a couple of days later), I want to try and push again because
> I have some reasons to believe that my access problems are solved.
> 4) since I know that I'm probably out of date by now, I did a "git fetch
> --all".
> 5) when I do a "git status" now, I get the following information:
> 
>> # On branch issue_17815
>> # Your branch and 'origin/master' have diverged,
>> # and have 1 and 11 different commit(s) each, respectively.
>> #
>> nothing to commit (working directory clean)
> 
> Hence my question: may I go ahead and push? Or do I need to worry about
> the divergence mentioned by git?

Steffen answered you already. Yes, lots of new terminology, but I feel
that we are all gaining lots of knowledge these days just by
experimenting and feeling more and more comfortable with it.

Keep in mind that "git fetch" doesn't do anything to your commits or
your history. It only downloads objects and refs from other repositories
in your own. It won't merge, it won't rebase, it won't fast forward.

It will only allow you to have a new view on the SHA objects that are in
the "wild": so in your case it now *knows* that you have one commit in
your branch and the master origin has 11 commits (you "diverged").

                     A---B  (issue_17815)
                    /
               D---E---F.. 11 commits...---O (master)

You could now either merge stuff from master ("git merge master"),
getting a new commit for the merge ("P", which has two parents "B" and "O"):

                     A---B-------------------P  (issue_17815)
                    /                       /
               D---E---F.. 11 commits...---O (master)

Or you "git rebase master issue_17815":

                                             A---B  (issue_17815)
                                            /
               D---E---F.. 11 commits...---O (master)

Please note that I am *not* (yet) a git expert, so someone might want to
correct me. It has been told that "rebase" is dangerous (as it rewrites
history, in this case the commits "A" and "B" are rewritten), but in
this tiny bug fixes I find it convenient. Probably more dangerous if you
are working on a huge feature which includes fixes which already been
committed to origin/master. To quote a site [1]:

"Imagine riding a unicycle while juggling four meat cleavers and you'll
have the idea. Really, and I mean really impressive to watch, but one
false move and you're screwed."

Take a look at "git rebase --help" for info about its strategy, it
sounds pretty intelligent. :)

One lesson to learn with git: You never have to think of "patch" and
"diff" files. You think of SHA's which are based on each other and form
a history of the current state.

Cheers,
Ernesto

[1]
http://www.travisswicegood.com/2008/04/17/the-meat-cleaver-that-cuts-git-rebase/