From: "Felipe Contreras" <felipe.contreras@xxxxxxxxx>
To: "Philip Oakley" <philipoakley@xxxxxxx>
Cc: "John Keeping" <john@xxxxxxxxxxxxx>; "Junio C Hamano"
<gitster@xxxxxxxxx>; <git@xxxxxxxxxxxxxxx>; "Andreas Krey"
<a.krey@xxxxxx>
Sent: Sunday, September 08, 2013 9:16 AM
Subject: Re: [PATCH 0/3] Reject non-ff pulls by default
On Sun, Sep 8, 2013 at 3:01 AM, Philip Oakley <philipoakley@xxxxxxx>
wrote:
From: "Felipe Contreras" <felipe.contreras@xxxxxxxxx>
Sent: Sunday, September 08, 2013 3:34 AM
On Thu, Sep 5, 2013 at 3:06 AM, John Keeping <john@xxxxxxxxxxxxx>
wrote:
On Wed, Sep 04, 2013 at 03:59:18PM -0700, Junio C Hamano wrote:
Are there cases where you do not want to either rebase nor merge?
If so what do you want to do after "git pull" fetches from the
other
side? Nothing?
One other thing that I can see being useful occasionally is:
git rebase @{u}@{1} --onto @{u}
which allows local commits to be replayed onto a rewritten upstream
branch.
Although I agree with your side note below that people doing this
may be
better off fetching and then updating their local branch,
particularly
if @{1} is not the correct reflog entry for the upstream when they
created the branch.
That's why after recognizing the fact the you can't find the branch
point of a branch in Git, I decided to write patches to support the
@{tail} shorthand, which is basically the point where the branch was
created, or rebased to:
https://github.com/felipec/git/commits/fc/base
And if 'git rebase' was fixed to ignore the commits already in the
rebased onto branch, almost always what you would want to do is 'git
rebase @{tail} --onto @{upstream}'.
The use case that trips me up (i.e. doesn't fit the above) is when I
have a
branch that may need rebasing on (onto) pu, or may need rebasing on
master,
or next, depending on what others have been doing.
Yes, so you would do:
% git rebase --onto pu
Which would be translated to:
% git rebase @{tail} --onto pu
What's the problem?
The 'problem' is (would be) that I don't yet know that I would need
the --onto pu until I discover (how?) that the default rebase would
result in conflicts.
As a Distributed VCS (i.e. others doing work independently), a rebase
always
has the possibility that the world has moved on and one has to adapt
to the
new world order by moving location (--onto somewhere new), not just
fixing
up the house (patch conflicts). When the update order is unknown
there is no
guaranteed solution (IIUC).
Yeah, but almost always you want to rebase onto @{upstream}.
Yeah, but almost always you want to "check" first *before* starting.
That is, 'git rebase --abort' should not be required from the (user's
selected /git's) default invocation.
--
Philip Oakley
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html