On 02/03/13 12:08, Thomas Ferris Nicolaisen wrote:
On Saturday, March 2, 2013 12:23:07 AM UTC+1, Philip Oakley wrote:

    From: "Philip Oakley" <philip...@iee.org <javascript:>>
    Sent: Friday, March 01, 2013 10:36 PM
     >I have two PCs, one running Windows Msysgit & Git for Windows, which
     >I'm familiar with, and the other a laptop with Ubuntu (still not
     >familiar). I have a repo hosted on GitHub.
     > I rebased a branch on my windows PC and pushed it to Github with a
     > forced update.
     > I've now fetched the branch to my laptop (Ubuntu) and want to update
     > that branch to the remote branch tip. The [old] branch is checked
     > on the laptop, but the remote/branch is +/- 3 commits different
     > because of the rebase I did on the Windows PC.So how to
    sychronise to
     > the remote?
     > I'm sort of wanting the ability to do a 'git pull --ff-only
    --force '
     > or perhaps 'git pull --ff-force' (if they existed)  in this
     > real user situation. Such that there is no merge in my branch's
     > 'tree'. The 'recovering from rebase' section of rebase(1) doesn't
     > appear to cover this typical(?) case.

    No sooner than I send in the email that little bit of extra googling
    <http://stackoverflow.com/q/4084868/717355> which appears to cover
    my situation
    # on local branch
    git reset --hard remote/branch

    Maybe I should suggest a doc update for the synchronisation case. I
    didn't think of looking at the 'git reset' man page, but browsed
    fetch, pull, merge, et and found nothing that appeared to fit.

     > In my current situation I could simply go behind the scenes to
     > the contents of the refs/heads/<branch> to match the
     > refs/remote/<branch> sha1 pointer, and then do a 'git reset
    --hard' to
     > update the work tree.
     > My question is, is there a short simple, or single, command sequence
     > that uses the poreclain commands to do this typical update? (and
    is it
     > documented somewhere)
     > Philip

Yeah, this is basically the main reason why rebasing is "evil", or at
least highly confusing. Imagine if that had happened with a whole team
of developers and not just a single machine..

In this case it was just me, and the problem is synchronising between my different working machines, so when I do a rebase, I do need such a mechanism.

This use case appears to be part of the natural use of rebase - I'm preparing a patch series and as part of its development I need to re-order patches, add in comments to commit messages etc as I review how well it reads after the fact, but I don't really want hundreds of personal temporary branches, so I use rebase.

However I also need to synchronise this branch between machines with different OS's (one has the Msysgit DAG, while the other Junio's DAG, so they have a common root but different working branches).

Plus, for researching the issue, its tricky deciding on what search words are needed for googling for this particular problem.

I'm sure the resolving of the 'team' rebase could be made easier (for those who don't have local work) if these simple commands (in retrospect) were more obvious in the documentation.

One of the 'evil' problems of rebase is that it doesn't leave a transferable marker of where it's old head was so the recipient would know if they had extra commits relative to the pre-rebase branch (I don't think it can in a distributed system anyway)

These are one of those things you pick up along the way: If you ever
have to do a forced push, make sure you warn your collaborators
  (I don't have any in this case ;-)

a) store their local work in another branch (than the one you are going
to overwrite)
b) reset -hard
I think it's this invocation that needs documenting for this use case.

after you have force pushed to correct their local repository

After using Git in a team for a couple of years, I think we've had to go
through this only a couple of times.  In nearly all cases, it's not
worth it.

The confusion there would be public vs private branches (never publish to a public branch that _will_ be used by team mates). But I would still expect that individual developers would need to fixup and rework their private branches before publishing to a public branch. And if they have two machines they need to be able to synchronise their private branch between the machines, which is my use case as I get to grips with Linux/Ubuntu.

Thanks for the comments and discussion.

Philip Oakley

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/groups/opt_out.

Reply via email to