[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.062 / U:2.228 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site