On Sat, Dec 29, 2012 at 11:33 PM, Michael Richter <ttmrich...@gmail.com> wrote:
> On 30 December 2012 13:23, Nico Williams <n...@cryptonector.com> wrote:
>>
>> A "rebase" operation takes a branch (typically the current one) and
>> two commits (oldbase and newbase) in the repository and then a)
>> computes the set of commits that are in the branch since <oldbase>
>> then b) creates a new line of commits that consists of <newbase> plus
>> the commit set computed in (a), each commit in that set applied as a
>> delta onto <newbase>, merging as needed.
>
>
> And why would I want to do this?  Explain as you would to, say, a small
> child.

Short version: because upstream tells you to.

Longer version: first because upstream wants patches that apply
cleanly, but if you don't have commit D in the new-feature branch and
your commits a, b, and/or c require merging with D, then the upstream
will tell you to update your patches (it's *your* job to do such
merges), second because upstream may want you to re-organize your work
(as I've explained before; no need to repeat).

>>
>> So, if we have a branch called "trunk" with this history:
>>
>> A---B---C---D
>>
>> and a branch called "new-feature" with these commits
>>
>> A---B---C---a---b---c
>>
>> where commits a, b, and c are in the new-feature branch but not in
>> trunk, and clearly we're missing commit D from trunk in new-feature,
>> we want to end up with:
>>
>> A---B---C---D---a'---b'---c'
>>
>> Where a', b', and c' are each based on commits a, b, and c, but merged
>> onto D.
>
>
> Why not, for example, just merge c into D or vice versa?  I really don't see
> what modifying history does here.  Possibly because I lack the imagination
> to put any concrete examples into A, B, C, D, a, b, c, a', b', c' where this
> would be a desirable feature.  Could you be more specific?

Because D is already upstream, therefore to remove D from upstream
would be a destructive operation.

The goal is to produce new commits that apply cleanly to trunk upstream.

Again, if I send a, b, and c upstream and D was missing in my branch
then my commits may not apply cleanly.  Even if they do the commit
hashes will change as in the upstream the parent of a will be D, not
C.

>> A---B---C---D---a'---c'---b'  (re-order commits, not merely change the
>> base of commit a)
>
>
> Why?

Because upstream may ask for it.  For example, if I wrote a test
first, committed it, then a bug fix -- my mistake, but I should have
done it the other way around (though I might not have known the
upstream maintainer's order preferences upfront).

>>
>> A---B---C---D---a'---c'  (drop a commit, not merely change the base of a)
>
>
> Why?

Because it turns out that commit b was lame.  Or because upstream
decided to reject commit b but commits a and c still stood on their
own.

>>
>> A---B---C---D---abc' (merge all three of a, b, and c, into abc')
>
>
> Why?

Because upstream thought these three belong as one.  (E.g., b might
fix a bug introduced by a, and c might fix a typo in b.)

>>
>> A---B---C---D---ac'---b' (re-order and merge some)
>
>
> Why?

Commit c might fix a typo in commit a, while commit b might be
unrelated.  Squashing (git term) c into a then helps keep history
clean upstream.  Upstream likes clean history in official repos.

>>
>> A---B---C---D---a1'---a2'---b'---c' (split a and rebase)
>
>
> Why?

Because commit a did two separable things and upstream wants them
separated so that, for example, a1' can be pulled into an older
release's bugfix branch without pulling in a2'.

>>
>> A---B---C---abc'  (no rebase, just merge the top three commits)
>
>
> Why?

Here I'm not contributing abc' just yet.  I'm still working but I know
upstream wants commits a, b, and c merged.  Eventually I'll have to
rebase onto D, but I want to do that later.

>> These are things that upstream maintainers of large projects quite
>> often insist upon.
>
> And why do they do this?  I kinda/sorta get the mechanism.  I just don't see
> the motivation.  (And "upstream maintainers insist upon this" is not
> motivation, it's just moving the question of motivation around.)

Because they want clean history.  If commit b fixes a bug introduced
by commit a then why should that bug -which had never been upstream to
begin with- exist upstream in the middle of the history?  Not only is
there no reason to want that upstream, but having it upstream will
only add to the burden of someone reviewing the history to understand
it or specific changes in it.

Nico
--
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Reply via email to