[lkml]   [2005]   [Nov]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Subject[ANNOUNCE] GIT 0.99.9g
    GIT 0.99.9g is found at usual places.  There are a couple of
    important changes, as the slow march towards 1.0 continues.

    - The RPM package has been split into a few packages by Jim
    Radford. Unfortunately I am not equipped sufficiently to
    test the resulting RPMs, so please feed me updates and
    corrections as needed. I think archimport part needs to be
    split out just like its svn/cvs cousins, and perhaps
    documentation into another separate package.

    - Fredrik Kuivinen's merge-recursive strategy is now the
    default merge strategy for two-head merge that happens after
    git-pull. I do not expect this to cause major disruptions,
    but if this breaks things there is a workaround to override
    this [*1*].

    Although I did not hear anybody jumping up-and-down to merge
    svnimport updates from Yaacov Akiba Slama, I did not hear it
    broke things either, so it graduated to the master branch and
    included in this release. It obviously improved things for
    Yaacov, and I am hoping this would not cause disruptions for
    people's existing setup.

    Also included are unexciting bits of fixes here and there.

    On the "proposed updates" front, things finally seem to be
    calming down.

    - One important newcomer is git-pack-redundant. It is still in
    "pu" not because I doubt what it does is useful, but simply
    because I have not had a chance to study how it does its
    thing. I expect to fully merge it into "master" before 1.0

    - Among my own toys in the "pu" branch:

    - Determination of merge base for Octopus merge was quite
    pessimistic, and a proposed fix is in there; since I will
    be regularly and frequently doing Octopus merges, I'll soon
    know if this change breaks things; otherwise it will
    graduate to "master" shortly.

    - merge-base computation done by show-branch was a bit loose
    compared to the real merge-base, as pointed out by Linus on
    the list, although it does not seem to matter too much in
    practice. Also I plan to look into merge-base to see if I
    can fix the horizon effect cheaply but that work has not
    started yet (it is triggered by fairly pathological case).

    - I got tired of not being able to get the committer date
    (except the raw format which is unreadable) out of git-log,
    and added --pretty=fuller format. This should not break
    people's existing setup, so I expect it to move to "master"
    soon, maybe with a name change if somebody can suggest a
    better name for it.

    - Change merge-one-file to handle the case where two sides
    add the same path differently. Instead of punting, try to
    do two-file merge from both sides. This _might_ turn out
    to be useful, but I do not know yet, so it won't graduate
    to "master" unless somebody convinces me (and the
    community) that it is useful in some use-case scenario.

    - Add git-lost+found. Currently the implementation stores
    found refs under .git/lost+found/{commit,other}
    directories, but writing out their object names to the
    standard output and let the users decide what to do with
    them was suggested on the list by Daniel, which makes sense
    as well. There are pros and cons so until we know if it is
    useful and if so in what form, it will not come out of "pu"

    - I do not consider either git-shallow-pack and git-changes
    "master" material. The former is a hack to create
    deliberately broken repository. The latter is supporting a
    wrong workflow, as Linus described the other day. You can
    temporarily fetch what you want to compare into local
    repository and run git-log or git-whatchanged normally.

    Oh, and we will not be moving things out of /usr/bin/ during 1.0


    *1* If for whatever reason you would prefer to keep using the
    'resolve' strategy as before when you run 'git-pull', you can
    either do 'git-pull -s resolve <remote> <refspec>...' on the
    command line, or add the following in your .git/config file:

    twohead = resolve

    On the other hand, if you like to try resolve and then
    recursive, you can have this instead (the order does matter, the
    first one is tried first):

    twohead = resolve
    twohead = recursive

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-11-10 12:03    [W:0.022 / U:8.060 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site