On Tue, Nov 27, 2007 at 11:14:47AM -0500, Nicolas Pitre wrote:
> On Tue, 27 Nov 2007, J. Bruce Fields wrote:
> > No, their work isn't always based on origin/master@{1}. Often they've
> > got more than one project going. If they try
> >
> > git checkout project-1
> > git pull -s rebase
> > git checkout project-2
> > git pull -s rebase
> >
> > what's going to happen? What if project-2 has been on the back burner
> > for a few months and they're just getting around to rebasing it now?
>
> I don't see the problem. They'll just have a possibly harder rebase due
> to increased chances for conflicts than if they rebased more often, but
> that's to be expected even with a merge.
Well, fair enough. It can be much worse than a merge, though--consider
what happens when upstream drops a commit, or replaces a patch by
another patch (or patches) that solves the problem in a different way.
> > What if their various projects are based on different upstream branches,
> > but the fetch done by git-pull updates them all at once?
> > What if they
> > did a git fetch earlier just to peek at current development and are only
> > now getting around to updating their own branches?
>
> You are not _forced_ to use origin/master@{1} in that case -- I used
> that notation only to illustrate the concept in Git terms. What I tell
> people to do is to tag their new base after the rebase is done, and to
> use that tag after the next fetch to rebase again.
That's fine, but it's not an automated process any more.
> I honnestly don't use such a tag myself because I think I know what I'm
> doing when using Git, and therefore I know when origin/master@{1} refers
> to what I really want. But the point is that either that usage of
> origin/master@{1}, or a dedicated tag, or whatever other means to
> retrieve the previous base, could be handled implicitly by the porcelain
> and the user wouldn't have to care as much.
OK, so you're imagining a version of "git pull -s rebase" that also
allows specifying the previous base of your series? What would the
syntax be? You could do something like stg does and keep extra
information under .git that records the base of each "patch series".
Then you have to figure out how to manage that information and how it
should interact with the varoius branch management commands.
> Thinking about it, there should be a way to find the proper base even
> without explicitly recording it with a tag. If it isn't
> origin/master@{1}, it has to be the first of origin/master@{n} for
> n = [1, ...] reachable from the local work branch before rebasing.
That'll work in some cases. You're almost using the reflog as another
piece of history to find the "real" merge-base.
That's a little fragile, since reflogs aren't quite "real" history. It
doesn't work reliably in the "project that was put on the back burner"
case (because the reflog entries may have expired). It doesn't work if
work is done in multiple repositories.
> > And I don't think any of those are crazy corner cases; I know at least
> > that I do all of those things.
>
> Sure. In which case you certainly fall into the "know what you're
> doing" category too and certainly can find your way towards the proper
> base ref to use.
Beginners are will try those things too, so we'd have to explain the
limitations up front.
> But again I think that can be automated.
I'd want to see the algorithm spelled out, and a very convincing
description of exactly which cases it handles.
My other objection is that "rebase" just isn't a merge strategy. I
think of a merge strategy takes some HEADs in a produces a single merge
commit that connects them.
If we really want a fetch+rebase script, OK, but call it something other
than pull.
--b.
-
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
