[prev in list] [next in list] [prev in thread] [next in thread] 

List:       git
Subject:    Planning for 1.7.5 and 1.8.0
From:       Junio C Hamano <gitster () pobox ! com>
Date:       2011-01-31 17:05:37
Message-ID: 7vwrll57ha.fsf () alter ! siamese ! dyndns ! org
[Download RAW message or body]

Now the 1.7.4 release is out, I'd like people to help thinking about the
next cycle(s).

As a discussion-starter, here are my random wishes.  Even though this does
not attempt to be exhaustive, keeping the number of goals manageably small
may help us focus.

 * The i18n effort Ævar Arnfjörð Bjarmason started two cycles ago has
   stalled. If enough people feel i18n's Porcelain UI is worth having, I
   think we would need a brief calming period in the entire tree in order
   for us to get the minimum support (definition of _() macro that is
   empty is a good start) and _() mark-up of existing strings in, and then
   ask everybody to rebase their ongoing work on top of it.

 * There was a discussion on documentation updates to reduce "here we tell
   you only the basics; see elsewhere for details", and consolidating the
   description of configuration options in one place.

 * Nguyễn has been scratching my longstanding itch by attempting to unify
   two pathspec semantics (the ones based on tree-diff matches only
   leading path while others know globs) to reduce inconsistencies. I
   would really want to see this polished and in the main release.

 * Elijah's fix to "rev-list --objects", together with the updated
   pathspec semantics will allow us to cleanly implement narrow cloning
   (possibly deprecating and replacing the narrow checkout in the
   future).  I am hoping that we can lay groundwork on this inside one
   cycle and the initial end-to-end implementation in another.

 * Shawn Pearce says that the diff implementation JGit uses (histogram
   diff) performs way better than the xdiff implementation we use by
   default. It would be great if somebody can spend time taking a look at
   it and possibly port it back to C-git.


Over the time we have discussed minor glitches and inconsistencies that we
all (or at least most of us anyway) agreed we would have done differently
if we were writing Git from scratch, yet we cannot retroactively introduce
differences not to harm existing users.  We may also want to revisit these
discussions during this round--if there are reasonable number of them that
we can agree the benefit of tweaked semantics/behaviour outweighs the risk
of breaking and having to update ancient scripts that exploited obscure
corner case behaviour of Git, we would want warn the users loudly, bite
the bullet and break them so that we can move forward.  We would however
need to roll such potentially disruptive changes into a big single cycle,
like we did in 1.6.0.

I'll follow-up this message with a couple of example proposals.  Please
send your own, imitating the format of the message, as a reply to this
message.  Do not forget to retitle your message when you do so (iow, I
don't want to see "Re: Planning for 1.7.5 and 1.8.0").

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]