[lkml]   [2008]   [May]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [GIT pull] x86 fixes for 2.6.26
    Theodore Tso <> writes:

    > Basically, this would be the subsystem maintainer sometimes wearing an
    > "end-point-developer" hat, and sometimes wearing a "subsystem
    > maintainer" hat. So rebasing is fine as long as it's clear that it's
    > happening on branches which are not meant as a base for
    > submaintainers.
    > I believe Junio does this himself for his own topic branches while
    > developing git, yes?

    Yes, I used to and I still do sometimes. Anything not merged to 'next'
    yet is a fair game for rebasing. 'pu' is strictly a patch queue in that

    When I am shuffling the topics that are not merged to 'next', I am not
    just wearing an end-point-developer hat, but pretending to be the original
    contributor (iow "how the patch could have been done better than the one
    that I received via e-mail") more often than not these days; I am writing
    less and less new code myself.

    I used to religiously rebase topics that were not in 'next' on top of
    updated 'master' before I rebuilt 'pu' [*1*]. This was partly because
    when the topic eventually becomes 'next' worthy, the commit on 'next' to
    merge the topic will not have a parent that is too stale (and graphically
    the end result would look easier to view that way) if I did so, and partly
    because rebasing is one cheap way to detect and resolve conflicts with
    'master' much earlier before the topic becomes ready to be merged to

    I do not however do that so often anymore.

    Whenever I rebuild 'pu' starting from the tip of 'next', merging these
    uncooked topics, if they have conflicts with 'master' or 'next', I'd
    resolve them right there. Next day, when I rebuild 'pu' again from
    updated 'next', it is very likely that I have to resolve the _same_
    conflicts again, but that process is largely automated because git
    remembers the conflict resolution I did when I merged that topic to 'pu'
    the previous day. After the topics are polished further and when they are
    ready to be merged to 'next', the story is the same. The same conflicts
    need to be resolved but that is largely automated. That is one of the
    reasons I do not rebase topics as often as I used to these days. IOW, I
    rely on and trust "rerere" magic a bit more than I used to.


    *1* My "git day" goes like:

    - advance 'maint' with obviously good patches, merges from completed
    'maintenance' topics, and merges from subsystem trees;

    - merge updated 'maint' to 'master';

    - advance 'master' with obviously good patches, merges from completed
    topics, and merges from subsystem trees;

    - merge updated 'master' to 'next';

    - apply new patches into new topics forked from either 'maint' (if it
    should eventually fix breakage in the maintenance track), 'master', or
    some existing topic (if it has functional dependencies on it);

    - apply update patches to existing topics;

    - possibly rebase topics that have not been in 'next' but are now ready
    for 'next';

    - merge topics that are 'next' worthy to 'next';

    - reset 'pu' to 'next';

    - merge remaining topics to 'pu';

     \ /
      Last update: 2008-05-17 22:29    [W:0.024 / U:31.008 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site