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.