From: Junio C Hamano <gitster@pobox.com>
To: git@vger.kernel.org
Subject: Unresolved issues
Date: Mon, 17 Mar 2008 18:12:02 -0700 [thread overview]
Message-ID: <7v7ig096ot.fsf@gitster.siamese.dyndns.org> (raw)
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.
next reply other threads:[~2008-03-18 1:13 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-18 1:12 Junio C Hamano [this message]
2008-03-18 1:26 ` Unresolved issues Jeff King
2008-03-18 1:56 ` Linus Torvalds
2008-03-19 22:48 ` Sam Vilain
2008-03-19 0:27 ` [PATCH] remote show: do not show symbolic refs Johannes Schindelin
-- strict thread matches above, loose matches on Subject: below --
2008-04-19 8:19 Unresolved issues Junio C Hamano
2007-02-20 7:28 Junio C Hamano
[not found] ` <Pine.LNX.4.64.07022009 34270.20368@woody.linux-foundation.org>
2007-02-20 8:57 ` Andy Parkins
2007-02-20 17:41 ` Linus Torvalds
2007-02-20 21:43 ` Junio C Hamano
2007-02-21 0:21 ` Linus Torvalds
2007-02-21 0:25 ` Junio C Hamano
2007-02-21 0:39 ` Johannes Schindelin
2007-02-21 0:56 ` Linus Torvalds
2007-02-21 0:51 ` David Lang
2007-02-21 1:12 ` Johannes Schindelin
2007-02-21 1:51 ` Nicolas Pitre
2007-02-21 2:03 ` Linus Torvalds
2007-02-21 16:32 ` Robin Rosenberg
2007-02-21 1:49 ` Theodore Tso
2007-02-21 10:42 ` Martin Waitz
2007-02-21 12:55 ` Johannes Schindelin
2007-02-21 16:57 ` Brian Gernhardt
2007-02-21 17:05 ` Shawn O. Pearce
2007-02-26 1:33 ` Julian Phillips
2007-02-26 3:39 ` Junio C Hamano
2007-02-26 5:10 ` Julian Phillips
2007-02-26 5:33 ` Junio C Hamano
2007-02-27 20:10 ` Johannes Schindelin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7v7ig096ot.fsf@gitster.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).