[ANNOUNCE] GIT 0.99.9g

[Junio C Hamano <junkio@cox.net>]

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
   happens.

 - 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"
     branch.

   - 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
timeframe.


[Footnote]

*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:

        [pull]
                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):

        [pull]
                twohead = resolve
                twohead = recursive

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/