git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <peff@peff.net>
To: "Björn Steinbrink" <B.Steinbrink@gmx.de>
Cc: Michael J Gruber <git@drmicha.warpmail.net>,
	Pete Wyckoff <pw@padd.com>,
	git@vger.kernel.org
Subject: Re: tracking branch for a rebase
Date: Sat, 5 Sep 2009 02:12:50 -0400	[thread overview]
Message-ID: <20090905061250.GA29863@coredump.intra.peff.net> (raw)
In-Reply-To: <20090904185949.GA21583@atjola.homenet>

On Fri, Sep 04, 2009 at 08:59:49PM +0200, Björn Steinbrink wrote:

> "git pull --rebase" is not the same as:
> "git fetch origin && git rebase origin/foo", but:
> 
> git fetch origin && git rebase --onto origin/foo $reflog_merge_base
> 
> Where $reflog_merge_base is the first merge base is found between the
> current branch head, and the reflog entries for origin/foo.

Thanks, I didn't know about the trick (not being, as I mentioned, a pull
--rebase user). I can see arguments for or against a rebase-default
using that feature. On one hand, it simplifies the explanation for
people going between "pull --rebase" and "fetch && rebase". And I think
it should generally Do What You Mean in the case that upstream hasn't
rebased. Are there cases you know of where it will do the wrong thing?

I don't know if people would be confused that "git rebase" does not
exactly default to "git rebase $upstream", which is at least easy to
explain.

> > The biggest question is whether it should respect branch.*.merge, or
> > just branch.*.rebase (I never use the latter simply because I never use
> > "git pull", but I think it is probably reasonable to restrict it to
> > cases where you said you are interested in rebasing in general).
> 
> Hm, you'll probably want "git merge" to pickup the default as well then,
> right? And that should only do so if branch.*.rebase is not set. So
> effectively, you still have to use the right command, but can skip the
> argument. Having to deal a lot with git-svn, I also regulary use its
> "git svn rebase --local", which means "just rebase, don't fetch".

I hadn't considered whether "git merge" should get a default. To be
honest, my intended use case was not really to replace pull, but as a
shorthand for running "git rebase -i". Upstream has the published
commits, so it is a nice shortcut to say "let me munge all of the
commits that I haven't published yet".

Of course the "published" status of those commits is not guaranteed
(they might have been published in another branch, your
tracking refs might not be up to date, etc) but I think it's a good rule
of thumb.

And by automating the shorthand we reduce the chance of errors. For
example, I usually base my topic branches from origin/master. But the
other day I happened to be building a new branch, jk/date, off of
lt/approxidate, salvaged from origin/pu. I did "git rebase -i
origin/master" and accidentally rewrote the early part of
lt/approxidate.

> Now, basically "git svn rebase" is pretty much git-svn's "pull". Maybe
> its idea could be taken, so we get "git pull --local" to just skip the
> fetch part, but keep "git rebase" and "git merge" 'dumb', requiring
> explicit arguments.

That wouldn't help me, because you can't "pull -i". :)

-Peff

  reply	other threads:[~2009-09-05  6:13 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-04 13:54 tracking branch for a rebase Pete Wyckoff
2009-09-04 14:31 ` Michael J Gruber
2009-09-04 18:18   ` Jeff King
2009-09-04 18:59     ` Björn Steinbrink
2009-09-05  6:12       ` Jeff King [this message]
2009-09-05 14:01         ` Björn Steinbrink
2009-09-05 14:28           ` Jeff King
2009-09-07  5:05             ` Junio C Hamano
2009-09-07  8:14               ` Michael J Gruber
2009-09-07  8:25                 ` Junio C Hamano
2009-09-07  8:44                   ` Jeff King
2009-09-07  9:06                     ` Michael J Gruber
2009-09-07  8:43               ` Jeff King
2009-09-07  9:29                 ` Johannes Schindelin
2009-09-07  9:53                   ` Michael J Gruber
2009-09-08 23:17                     ` Julian Phillips
2009-09-09 10:45                   ` Jeff King
2009-09-10  6:42                     ` Junio C Hamano
2009-09-10  7:47                       ` Johannes Schindelin
2009-09-10  9:36                         ` [PATCH] Introduce <branch>@{tracked} as shortcut to the tracked branch Johannes Schindelin
2009-09-10  9:44                           ` Michael J Gruber
2009-09-10 10:14                             ` Johannes Schindelin
2009-09-10 10:18                             ` Johan Herland
2009-09-10 10:59                               ` Michael J Gruber
2009-09-10 12:29                                 ` Johan Herland
2009-09-10 13:35                                   ` Johannes Schindelin
2009-09-10 14:17                                     ` Michael J Gruber
2009-09-10 11:11                               ` Jeff King
2009-09-10 18:29                                 ` Junio C Hamano
2009-10-02 14:54                                   ` Björn Steinbrink
2009-09-10 14:16                           ` Jeff King
2009-09-10 14:26                             ` Jeff King
2009-09-10 15:24                               ` Johannes Schindelin
2009-09-10 15:25                                 ` [PATCH v2] Introduce <branch>@{upstream} " Johannes Schindelin
2009-09-10 15:55                                   ` Jeff King
2009-09-10 16:18                                     ` Johannes Schindelin
2009-09-10 15:22                             ` [PATCH] Introduce <branch>@{tracked} " Johannes Schindelin
2009-09-11  4:54                         ` tracking branch for a rebase Junio C Hamano
2009-09-05 17:59           ` Junio C Hamano

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090905061250.GA29863@coredump.intra.peff.net \
    --to=peff@peff.net \
    --cc=B.Steinbrink@gmx.de \
    --cc=git@drmicha.warpmail.net \
    --cc=git@vger.kernel.org \
    --cc=pw@padd.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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).