v1.5.4 plans

Please do not take this as the final decision made by the Emperor, whose
subjects now must follow.  This is a sanity-check to see if everybody is
on the same page.

I am not the Emperor anyway ;-)

Deprecation and Removal
-----------------------

 * We have already removed svnimport without giving a deprecation notice
   in the release notes of the previous feature release, which was bad.
   Maybe the users will forgive us.  Maybe not.

 * As discussed on the list, v1.5.4 will ship with the dashed form of
   commands (e.g. "git-commit") on users' PATH by default.  However we
   will move them outside the normal PATH (exact location needs to be
   decided by checking FHS first, something like /usr/libexec/git-core)
   in v1.5.5 so the release notes to v1.5.4 will declare deprecation
   (see the top of Documentation/RelNotes-1.5.4.txt).  We might want to
   keep copies of dashed form Porcelains in /usr/bin but that discussion
   is towards v1.5.5 (post v1.5.4, not now).

 * We also will give deprecation warning for the following features and
   commands in the release notes to v1.5.4, and remove them in v1.5.5:

   - lost-found (use fsck --lost-found);
   - post-update hook (use post-receive hook);
   - peek-remote (use ls-remote)


Topics not in 'master' yet but should be in v1.5.4
--------------------------------------------------

I think the following should go in, along with what we already have in
'master':

 * git-commit in C (Kristian and others)
 * git-add --patch (Wincent)
 * git-prune --expire (Dscho)
 * git-add --interactive coloring (Dan Zwell)
 * whitespace error classes in diff and patch, using gitattributes (Bruce and me)
 * cvsserver runs post-receive (Michael Witten)
 * git-rebase -i gives chance to rerere (Dscho)
 * git-rebase gives more appropriate help text (Wincent)
 * make refspec matching logic in git-push and git-fetch saner (Steffen Prohaska)
 * work-tree related minor fixes (Nguyen and Dscho)
 * allow update hook to munge commit (Steven Grimm)

I'd like to explicitly exclude topics about the following, although I
think there might be worthwhile ones among them to think about in the
longer term:

 * removing dashed form from the filesystem
 * teaching diff family about fileglob pathspecs
 * making it possible to omit leading paths from diff family output when
   run from a subdirectory

Does this mean we should be entering feature freeze?
Or at least feature freeze for 'master'?

-- 
Jakub Narebski

On Dec 3, 2007 9:04 AM, Junio C Hamano [off-list ref] wrote:

Please do not take this as the final decision made by the Emperor, whose
subjects now must follow.  This is a sanity-check to see if everybody is
on the same page.

I am not the Emperor anyway ;-)

Topics not in 'master' yet but should be in v1.5.4
--------------------------------------------------

I think the following should go in, along with what we already have in
'master':

Can we add the git-status/git-checkout relative path stuff that's
currently been sitting in 'next'? It would be a good step forward for
usability.


Dave.

"David Symonds" [off-list ref] writes:

On Dec 3, 2007 9:04 AM, Junio C Hamano [off-list ref] wrote:

quoted

Please do not take this as the final decision made by the Emperor, whose
subjects now must follow.  This is a sanity-check to see if everybody is
on the same page.

I am not the Emperor anyway ;-)

quoted

Topics not in 'master' yet but should be in v1.5.4
--------------------------------------------------

I think the following should go in, along with what we already have in
'master':

Can we add the git-status/git-checkout relative path stuff that's
currently been sitting in 'next'? It would be a good step forward for
usability.

I think checkout from subdirectory with relative was merged on November
18th to master, with d577bc58.  Relative path output for git-status is
part of the "git-commit in C" series, which is planned to go in.

But now you mention it, I realize that I ran "git-topic.perl" (found in
my 'todo' branch) without "--all" option when I made that list, and I
missed stuff fully merged to 'next'.  Sorry.

Here is a corrected list.

Topics not in 'master' yet but should be in v1.5.4
--------------------------------------------------

I think the following should go in, along with what we already have in
'master':

 * git-commit in C (Kristian and others)
 * git-add --patch (Wincent)
 * git-prune --expire (Dscho)
 * git-add --interactive coloring (Dan Zwell)
 * whitespace error classes in diff and patch, using gitattributes (Bruce and me)
 * cvsserver runs post-receive (Michael Witten)
 * git-rebase -i gives chance to rerere (Dscho)
 * git-rebase gives more appropriate help text (Wincent)
 * make refspec matching logic in git-push and git-fetch saner (Steffen Prohaska)
 * work-tree related minor fixes (Nguyen and Dscho)
 * allow update hook to munge commit (Steven Grimm)
 * git-fast-export (Dscho)
 * Add commitdiff to gitweb grep page (Denis Cheng)
 * "git pull --rebase" (Dscho)
 * "git config --get-color" (me)
 * "color.diff = true" means "auto" (me)
 * Rewrite "export VAR=VAL" to "VAR=VAL; export VAR" (Dscho)
 * run correct perl in Documentation (me, waiting for Merlyn)

When the len passed was -1, relative paths shortening was broken, resulting
in too long paths.

Signed-off-by: Pierre Habouzit <redacted>
---

    On Sun, Dec 02, 2007 at 11:39:59PM +0000, David Symonds wrote:
    > On Dec 3, 2007 9:04 AM, Junio C Hamano [off-list ref] wrote:
    > > Please do not take this as the final decision made by the Emperor, whose
    > > subjects now must follow.  This is a sanity-check to see if everybody is
    > > on the same page.
    > >
    > > I am not the Emperor anyway ;-)
    > >
    > 
    > > Topics not in 'master' yet but should be in v1.5.4
    > > --------------------------------------------------
    > >
    > > I think the following should go in, along with what we already have in
    > > 'master':
    > 
    > Can we add the git-status/git-checkout relative path stuff that's
    > currently been sitting in 'next'? It would be a good step forward for
    > usability.

    Speaking of which, there is this irritating bug in git status that
    let it show too long paths in the first chunk (the "tracked files"
    one).

    The previous version of the function was avoiding very hard to
    compute "in" length, and had quite convoluted code because of that.
    I now compute it at the beginning. The real issue was the:

 		while (prefix[off] && off < len && prefix[off] == in[off])

    line, when len is negative, the shortening never happens. I could
    have fixed it using ((len < 0 && in[off]) || off < len), but I
    disliked the resulting code, so I went for this.

    -- 
    ·O·  Pierre Habouzit
    ··O                                                madcoder@debian.org
    OOO                                                http://www.madism.org

 wt-status.c |   31 +++++++++++++------------------
 1 files changed, 13 insertions(+), 18 deletions(-)

diff --git a/wt-status.c b/wt-status.c
index 0e0439f..eb2cbea 100644
--- a/wt-status.c
+++ b/wt-status.c

@@ -84,30 +84,25 @@ static void wt_status_print_trailer(struct wt_status *s)
 static char *quote_path(const char *in, int len,
 		struct strbuf *out, const char *prefix)
 {
-	if (len > 0)
-		strbuf_grow(out, len);
+	int pos = 0;
+
+	if (len < 0)
+		len = strlen(in);
+	strbuf_grow(out, len);
 	strbuf_setlen(out, 0);
 
 	if (prefix) {
 		int off = 0;
 		while (prefix[off] && off < len && prefix[off] == in[off])
-			if (prefix[off] == '/') {
-				prefix += off + 1;
-				in += off + 1;
-				len -= off + 1;
-				off = 0;
-			} else
-				off++;
-
-		for (; *prefix; prefix++)
-			if (*prefix == '/')
+			if (prefix[off++] == '/')
+				pos = off;
+		while (prefix[off])
+			if (prefix[off++] == '/')
 				strbuf_addstr(out, "../");
 	}
 
-	for (; (len < 0 && *in) || len > 0; in++, len--) {
-		int ch = *in;
-
-		switch (ch) {
+	for (; pos < len; pos++) {
+		switch (in[pos]) {
 		case '\n':
 			strbuf_addstr(out, "\\n");
 			break;

@@ -115,8 +110,8 @@ static char *quote_path(const char *in, int len,
 			strbuf_addstr(out, "\\r");
 			break;
 		default:
-			strbuf_addch(out, ch);
-			continue;
+			strbuf_addch(out, in[pos]);
+			break;
 		}
 	}
 

-- 
1.5.3.7.2065.g3d18-dirty

On Mon, Dec 03, 2007 at 10:06:52AM +0100, Pierre Habouzit wrote:

    Speaking of which, there is this irritating bug in git status that
    let it show too long paths in the first chunk (the "tracked files"
    one).

It was annoying me, too. See the thread 'quote_path: fix collapsing of
relative paths'.

-Peff

On Sun, 2 Dec 2007, Junio C Hamano wrote:

Please do not take this as the final decision made by the Emperor, whose
subjects now must follow.  This is a sanity-check to see if everybody is
on the same page.

I am not the Emperor anyway ;-)

Emperor of the Rising Sun.  ;-)

Deprecation and Removal
-----------------------

 * We also will give deprecation warning for the following features and
   commands in the release notes to v1.5.4, and remove them in v1.5.5:

   - lost-found (use fsck --lost-found);
   - post-update hook (use post-receive hook);
   - peek-remote (use ls-remote)

Two things I would like to see in the next version (1.5.5) as well, for 
which we could provide early warnings now:

 - repack.usedeltabaseoffset defaulting to true

 - pack.indexversion defaulting to 2


Nicolas

On Dec 3, 2007 7:04 AM, Junio C Hamano [off-list ref] wrote:

 * We have already removed svnimport without giving a deprecation notice
   in the release notes of the previous feature release, which was bad.
   Maybe the users will forgive us.  Maybe not.

Ah, that explains that.  I was in the middle of importing the open2x
project into a git repo.  It's a large tree which looks like it
includes several copies of linux 2.4, and importing is taking several
days.  Occasionally the svn connection times out or something, and I
just restart it and it continues.  In the middle of that I built and
installed git 1.5.3.7 and was surprised when git-svnimport wasn't
there the next time I tried to restart it.  Back to 1.5.3.6 for now.

I see there's a thread about using a git-svnimport tree with git-svn,
so I'll do that.

Oh, and you're forgiven.  :)



-- 
Virus found in this message.