From: Clemens Buchacher <drizzd@aon.at>
To: Jakub Narebski <jnareb@gmail.com>
Cc: git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH] rebase --fix: interactive fixup mode
Date: Sun, 8 Jan 2012 23:19:48 +0100 [thread overview]
Message-ID: <20120108221946.GA22680@ecki.lan> (raw)
In-Reply-To: <m3r4z9eu36.fsf@localhost.localdomain>
On Sun, Jan 08, 2012 at 01:57:03PM -0800, Jakub Narebski wrote:
>
> > In order to determine a suitable range automatically, it is a reasonable
> > heuristic to rebase onto the most recent merge commit.
>
> Why not additionally / instead take into account remote-tracking
> branches for "push" remotes?
For me personally, remote-tracking does not work. I frequently branch
locally, and even if I do branch from a remote branch, it's often not
from a public branch, but rather my own private branch that I
synchronize between repos and machines. So my remote-tracking
configuration is usually an awful mess, and it does not feel like fixing
it up manually would be worth the trouble.
As a result, I don't trust remote-tracking and I do not use any of the
features associated with it. For my uses of rebase --fix it would
therefore be counter-productive to consider remote-tracking information.
What I did consider was adding a comment to the list of "pick <commit>"
that interactive rebase offers saying:
# older commits are already contained in the current upstream branch
Also, I often rewrite commits that are also contained in other branches.
That typically happens when I am reworking a topic that has already been
tested extensively. In that case I like to keep the original branch
around for reference, even if I end up not using it eventually.
next prev parent reply other threads:[~2012-01-08 22:28 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-08 21:31 [PATCH] rebase --fix: interactive fixup mode Clemens Buchacher
2012-01-08 21:57 ` Jakub Narebski
2012-01-08 22:19 ` Clemens Buchacher [this message]
2012-01-08 22:01 ` Jonathan Nieder
2012-01-08 22:25 ` Clemens Buchacher
2012-01-09 1:44 ` Nguyen Thai Ngoc Duy
2012-01-09 8:43 ` Jonathan Nieder
2012-01-08 22:58 ` Junio C Hamano
2012-01-09 20:33 ` Clemens Buchacher
2012-01-09 8:40 ` Michael Haggerty
2012-01-10 19:58 ` Neal Kreitzinger
2012-01-09 9:13 ` Thomas Rast
2012-01-09 20:16 ` Clemens Buchacher
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120108221946.GA22680@ecki.lan \
--to=drizzd@aon.at \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jnareb@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.