Subject: Unresolved issues

From: Junio C Hamano <[email-masked]>
Date: Mon, 17 Mar 2008 18:12:02 -0700

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.