I tagged 1.5.5-rc0 Sunday night (my time, obviously).
Our contributors have been busy inventing new features and reinventing old
ones in C during the 1.5.5 cycle, and we have a fair number of known
breakages. Here is a short list of issues I know (or I think I've heard)
about, that we would like to address (either "resolve", or "declare to
postpone") before the final release, but I am sure I missed some things.
Let's hope contributors are as responsive in fixing their own mess as they
are responsive in scratching their own itch, and we can resolve most of
them shortly.
* synopsys: use {} instead of () for grouping alternatives (Jari Aalto)
$gmane/72243
This was discussed during 1.5.4 pre-freeze timeframe but never
materialized.
* "git remote" showing remotes/origin/HEAD as a candidate for pruning,
and pruning it results in removal of what is pointed at by it.
Pointers? This may not be a regression but bug-to-bug compatibility
with the older implementation, but this should better be fixed.
* fetch with "refs/*:refs/*" errors out erroneously
$gmane/77335
Breakage exposed by recent git allowing "mirror" layout with "git remote
add --mirror".
* fetch with tag following uses smudged object database
$gmane/74141
Regression introduced by recent C-rewrite of git-fetch.
* "git fetch" does not exit with non-zero status when it failed to update
some refs due to non-ffness
$gmane/77178
Regression introduced by recent C-rewrite of git-fetch.
* "git fetch" shows error when dangling symref exists at the remote
but does not really error out
$gmane/76658
I am not sure what the right course of action is. Maybe we should
ignore dangling symrefs in upload-pack?
* D/F conflict to merge a tree with D into a tree with F
$gmane/77352
Needs more info.
* revision.c::limit_list() breakage
$gmane/72324
t/t6009
When you run "git rev-list A..B C", and there is a commit in the chain
between A and B whose timestamp is much older than its parent, sometimes
we fail to mark C as reachable from A (hence not interesting) even when
it actualy is. This is very expensive to solve in general, and we are
not going to introduce "generation number" field to the commit objects,
so we may have to settle with a heuristic.
* "[alias] st = status" and "cd .git && git st" (Jeff King)
$gmane/72327
This shows everything as deleted, I believe it hasn't resolved. I am
not sure if this is worth resolving, though.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
