Re: [git-users] fetching a branch I rebased - how to update the local branch on machine 2.

[Philip Oakley]

On 03/03/13 11:26, Thomas Ferris Nicolaisen wrote:

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.


How about creating a computer-specific branch, instead of both computers
working on "master", you work from home on a branch "wip-home" and at
work you use the branch "wip-work". Then, occasionally, or before you
want to merge your work to master, you create a "wip-prepare" where you
cherry-pick, merge and rebase whatever you want from the wip branches.

Regarding the intuitiveness/documentation of git rebase.. I think that's
basically what separates Git from Mercurial, with their immutable and
static public branches. At this stage, I don't know if there's anything
we can do but say "you just need to fully grok rebase and reset when
using Git extensively". It bothers me, but at the moment I can't think
of an option for this.


In my case the computers are 3 metres (~8ft) apart in adjacent rooms due 
to lack of space so I'm working on them in rapid succession (edit on 
one; compile and test on the other), so a single fixed branch name is 
the most suitable for me in this case.


Though, like you say, if it was a home <-> work transfer things would be 
different, with separate branches, but I'd still expect a reset at some 
point.


Rebase conflates two activities, the first is the 'forward port' or 
'move' activity where you want to move a series to be on top of a new 
place. While the second is the --interactive case where you need to 
tweak, adjust, re-order, or otherwise edit, *in-place*, your existing 
changes _before_ publishing the whiter than white freshly washed patch 
series. It's the latter case of transferring one's dirty washing between 
rooms without others seeing that I was stuck on ;-)


It probably merits a sentence in the 'Recovering from an upstream 
rebase' section to cover a 'simple' case where it isn't 'upstream' that 
rebased, rather it was oneself (origin) simply transferring between 
machines.


Philip

--
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.

Re: [git-users] fetching a branch I rebased - how to update the local branch on machine 2.

[Thomas Ferris Nicolaisen]

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. 
>

How about creating a computer-specific branch, instead of both computers 
working on "master", you work from home on a branch "wip-home" and at work 
you use the branch "wip-work". Then, occasionally, or before you want to 
merge your work to master, you create a "wip-prepare" where you 
cherry-pick, merge and rebase whatever you want from the wip branches.

Regarding the intuitiveness/documentation of git rebase.. I think that's 
basically what separates Git from Mercurial, with their immutable and 
static public branches. At this stage, I don't know if there's anything we 
can do but say "you just need to fully grok rebase and reset when using Git 
extensively". It bothers me, but at the moment I can't think of an option 
for this.

-- 
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.

Re: [git-users] fetching a branch I rebased - how to update the local branch on machine 2.

[Philip Oakley]

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" >
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
out
 > 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
"typical"
 > 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
finds
http://stackoverflow.com/q/4084868/717355
 which appears to cover
my situation
i.e.
# on local branch
git reset --hard remote/branch

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

 >
 > In my current situation I could simply go behind the scenes to
rewrite
 > the contents of the refs/heads/ to match the
 > refs/remote/ 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 ;-)

to

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.

Re: [git-users] fetching a branch I rebased - how to update the local branch on machine 2.

[Thomas Ferris Nicolaisen]

On Saturday, March 2, 2013 12:23:07 AM UTC+1, Philip Oakley wrote:

> From: "Philip Oakley" > 
> 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 out 
> > 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 "typical" 
> > 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 
> finds 
> http://stackoverflow.com/q/4084868/717355 which appears to cover 
> my situation 
> i.e. 
> # on local branch 
> git reset --hard remote/branch 
>
> Maybe I should suggest a doc update for the synchronisation case. I just 
> didn't think of looking at the 'git reset' man page, but browsed 
> checkout, 
> fetch, pull, merge, et and found nothing that appeared to fit. 
>
> > 
> > In my current situation I could simply go behind the scenes to rewrite 
> > the contents of the refs/heads/ to match the 
> > refs/remote/ 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.. 

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 to 

a) store their local work in another branch (than the one you are going to 
overwrite)
b) reset -hard 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. 

-- 
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.

Re: [git-users] fetching a branch I rebased - how to update the local branch on machine 2.

[Philip Oakley]

From: "Philip Oakley" 
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 out 
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 "typical" 
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 
finds

http://stackoverflow.com/q/4084868/717355 which appears to cover
my situation
i.e.
# on local branch
git reset --hard remote/branch

Maybe I should suggest a doc update for the synchronisation case. I just
didn't think of looking at the 'git reset' man page, but browsed 
checkout,

fetch, pull, merge, et and found nothing that appeared to fit.



In my current situation I could simply go behind the scenes to rewrite 
the contents of the refs/heads/ to match the 
refs/remote/ 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


--
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.