Unresolved issues
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Mar 18, 2008, 01:12 UTC
- Message-ID
- <7v7ig096ot.fsf@gitster.siamese.dyndns.org>
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/72243This 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.