Re: [PATCH v2] cache-tree: invalidate i-t-a paths after generating trees

[Nguyen Thai Ngoc Duy]

On Mon, Dec 10, 2012 at 1:50 PM, Junio C Hamano  wrote:
> Nguyễn Thái Ngọc Duy   writes:
>
>> diff --git a/cache-tree.c b/cache-tree.c
>> index 28ed657..989a7ff 100644
>> --- a/cache-tree.c
>> +++ b/cache-tree.c
>> @@ -248,6 +248,7 @@ static int update_one(struct cache_tree *it,
>>   int missing_ok = flags & WRITE_TREE_MISSING_OK;
>>   int dryrun = flags & WRITE_TREE_DRY_RUN;
>>   int i;
>> + int to_invalidate = 0;
>>
>>   if (0 <= it->entry_count && has_sha1_file(it->sha1))
>>   return it->entry_count;
>> @@ -324,7 +325,13 @@ static int update_one(struct cache_tree *it,
>>   if (!sub)
>>   die("cache-tree.c: '%.*s' in '%s' not found",
>>   entlen, path + baselen, path);
>> - i += sub->cache_tree->entry_count - 1;
>> + i--; /* this entry is already counted in "sub" */
>> + if (sub->cache_tree->entry_count < 0) {
>> + i -= sub->cache_tree->entry_count;
>> + to_invalidate = 1;
>> + }
>> + else
>> + i += sub->cache_tree->entry_count;
>
> Hrm.  update_one() is prepared to see a cache-tree whose entry count
> is zero (see the context lines in the previous hunk) and the
> invariant for the rest of the code is "if 0 <= entry_count, the
> cached tree is valid; invalid cache-tree has -1 in entry_count.
> More importantly, entry_count negated does not in general express
> how many entries there are in the subtree and does not tell us how
> many index entries to skip.

Yeah I use entry_count for two different things here. In the previous
(unsent) version of the patch I had "entry_count = -1" right after "i
-= entry_count"

>> + if (sub->cache_tree->entry_count < 0) {
>> + i -= sub->cache_tree->entry_count;
>> + sub->cache_tree->entry_count = -1;
>> + to_invalidate = 1;
>> + }


which makes it clearer that the use of negative entry count is only
valid within update_one. Then I changed my mind because it says
'negative means "invalid"' in cache-tree.h. So, put "entry_count = -1"
back or just add another field  to struct cache_tree for this?
-- 
Duy
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] git(1): remove a defunct link to "list of authors"

[Nguyen Thai Ngoc Duy]

On Mon, Dec 10, 2012 at 1:31 PM, Junio C Hamano  wrote:
> Nguyen Thai Ngoc Duy  writes:
>
>> On Sat, Dec 8, 2012 at 12:59 AM, Junio C Hamano  wrote:
  * If somebody has a working replacement URL, we could use that
instead, of course.  Takers?
>>>
>>> A possible alternative could be 
>>> https://www.ohloh.net/p/git/contributors/summary
>>
>> Nice charts!
>
> Yup.
>
> Their numbers seem to be just 'any commit by the author, with
> mailmap applied', and I am of two minds with it.  Counting without
> "shortlog --no-merges", depending on the management style of the
> project, tends to credit the integrator too much.  Even though
> vetting the patches and choosing when to merge the topics is a
> significant contribution, it isn't *that* big compared to the work
> done by the contributor who took initiative to scratch that itch.
>
> With or without "--no-merges", the big picture you can get out of
> "git shortlog -s -n --since=1.year" does not change very much, but
> the headline numbers give a wrong impression.

These numbers are approximate anyway. Commit counts or the number of
changed lines do not accurately reflect the effort in many cases. And
about merges, in this particular case of Git where the maintainer imo
has done an excellent job as a guard, I'd say it's the credit for
reviewing, not simply merging.

But not using the link is fine too. We can wait for Jeff's patch to be merged.

> And of course, application of the mailmap is very important, if you
> want to get meaningful numbers out of shortlog over a longer period.
-- 
Duy
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv2] mingw_rmdir: do not prompt for retry when non-empty

[Erik Faye-Lund]

in ab1a11be ("mingw_rmdir: set errno=ENOTEMPTY when appropriate"),
a check was added to prevent us from retrying to delete a directory
that is both in use and non-empty.

However, this logic was slightly flawed; since we didn't return
immediately, we end up falling out of the retry-loop, but right into
the prompting-loop.

Fix this by setting errno, and guarding the prompting-loop with an
errno-check.

Signed-off-by: Erik Faye-Lund 
---

Here's the second version of this patch, sorry for the slight delay.

 compat/mingw.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/compat/mingw.c b/compat/mingw.c
index 1eb974f..440224c 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -260,6 +260,8 @@ int mingw_rmdir(const char *pathname)
 
while ((ret = _wrmdir(wpathname)) == -1 && tries < ARRAY_SIZE(delay)) {
if (!is_file_in_use_error(GetLastError()))
+   errno = err_win_to_posix(GetLastError());
+   if (errno != EACCES)
break;
if (!is_dir_empty(wpathname)) {
errno = ENOTEMPTY;
@@ -275,7 +277,7 @@ int mingw_rmdir(const char *pathname)
Sleep(delay[tries]);
tries++;
}
-   while (ret == -1 && is_file_in_use_error(GetLastError()) &&
+   while (ret == -1 && errno == EACCES && 
is_file_in_use_error(GetLastError()) &&
   ask_yes_no_if_possible("Deletion of directory '%s' failed. "
"Should I try again?", pathname))
   ret = _wrmdir(wpathname);
-- 
1.8.0.msysgit.0.3.gafa53b0.dirty

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

Re: [PATCHv2] mingw_rmdir: do not prompt for retry when non-empty

[Junio C Hamano]

Erik Faye-Lund  writes:

> in ab1a11be ("mingw_rmdir: set errno=ENOTEMPTY when appropriate"),
> a check was added to prevent us from retrying to delete a directory
> that is both in use and non-empty.
>
> However, this logic was slightly flawed; since we didn't return
> immediately, we end up falling out of the retry-loop, but right into
> the prompting-loop.
>
> Fix this by setting errno, and guarding the prompting-loop with an
> errno-check.
>
> Signed-off-by: Erik Faye-Lund 
> ---
>
> Here's the second version of this patch, sorry for the slight delay.

Is this meant for me, or is it to be applied to msysgit and later
somehow fed to me in different form?

I can s/_wrmdir/rmdir/;s/wpathname/pathname/ if that is what you
want me to do, but otherwise this patch does not apply.

>
>  compat/mingw.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/compat/mingw.c b/compat/mingw.c
> index 1eb974f..440224c 100644
> --- a/compat/mingw.c
> +++ b/compat/mingw.c
> @@ -260,6 +260,8 @@ int mingw_rmdir(const char *pathname)
>  
>   while ((ret = _wrmdir(wpathname)) == -1 && tries < ARRAY_SIZE(delay)) {
>   if (!is_file_in_use_error(GetLastError()))
> + errno = err_win_to_posix(GetLastError());
> + if (errno != EACCES)
>   break;
>   if (!is_dir_empty(wpathname)) {
>   errno = ENOTEMPTY;
> @@ -275,7 +277,7 @@ int mingw_rmdir(const char *pathname)
>   Sleep(delay[tries]);
>   tries++;
>   }
> - while (ret == -1 && is_file_in_use_error(GetLastError()) &&
> + while (ret == -1 && errno == EACCES && 
> is_file_in_use_error(GetLastError()) &&
>  ask_yes_no_if_possible("Deletion of directory '%s' failed. "
>   "Should I try again?", pathname))
>  ret = _wrmdir(wpathname);
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Makefile: whitespace style fixes in macro definitions

[Junio C Hamano]

Stefano Lattarini  writes:

> Consistently use a single space before and after the "=" (or ":=", "+=",
> etc.) in assignments to make macros.  Granted, this was not a big deal,
> but I did find the needless inconsistency quite distracting.
>
> Signed-off-by: Stefano Lattarini 
> ---

Makes sense to do this kind of clean-up when these files are
quiescent (and they are).

Thanks.

>  Makefile  | 56 
>  config.mak.in |  2 +-
>  t/Makefile|  2 +-
>  3 files changed, 30 insertions(+), 30 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 4ad6fbd..736ecd4 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -374,7 +374,7 @@ htmldir = share/doc/git-doc
>  ETC_GITCONFIG = $(sysconfdir)/gitconfig
>  ETC_GITATTRIBUTES = $(sysconfdir)/gitattributes
>  lib = lib
> -# DESTDIR=
> +# DESTDIR =
>  pathsep = :
>  
>  export prefix bindir sharedir sysconfdir gitwebdir localedir
> @@ -575,9 +575,9 @@ endif
>  export PERL_PATH
>  export PYTHON_PATH
>  
> -LIB_FILE=libgit.a
> -XDIFF_LIB=xdiff/lib.a
> -VCSSVN_LIB=vcs-svn/lib.a
> +LIB_FILE = libgit.a
> +XDIFF_LIB = xdiff/lib.a
> +VCSSVN_LIB = vcs-svn/lib.a
>  
>  LIB_H += xdiff/xinclude.h
>  LIB_H += xdiff/xmacros.h
> @@ -1139,7 +1139,7 @@ ifeq ($(uname_S),NetBSD)
>  endif
>  ifeq ($(uname_S),AIX)
>   DEFAULT_PAGER = more
> - NO_STRCASESTR=YesPlease
> + NO_STRCASESTR = YesPlease
>   NO_MEMMEM = YesPlease
>   NO_MKDTEMP = YesPlease
>   NO_MKSTEMPS = YesPlease
> @@ -1147,7 +1147,7 @@ ifeq ($(uname_S),AIX)
>   NO_NSEC = YesPlease
>   FREAD_READS_DIRECTORIES = UnfortunatelyYes
>   INTERNAL_QSORT = UnfortunatelyYes
> - NEEDS_LIBICONV=YesPlease
> + NEEDS_LIBICONV = YesPlease
>   BASIC_CFLAGS += -D_LARGE_FILES
>   ifeq ($(shell expr "$(uname_V)" : '[1234]'),1)
>   NO_PTHREADS = YesPlease
> @@ -1155,13 +1155,13 @@ ifeq ($(uname_S),AIX)
>   PTHREAD_LIBS = -lpthread
>   endif
>   ifeq ($(shell expr "$(uname_V).$(uname_R)" : '5\.1'),3)
> - INLINE=''
> + INLINE = ''
>   endif
>   GIT_TEST_CMP = cmp
>  endif
>  ifeq ($(uname_S),GNU)
>   # GNU/Hurd
> - NO_STRLCPY=YesPlease
> + NO_STRLCPY = YesPlease
>   NO_MKSTEMPS = YesPlease
>   HAVE_PATHS_H = YesPlease
>   LIBC_CONTAINS_LIBINTL = YesPlease
> @@ -1187,9 +1187,9 @@ ifeq ($(uname_S),IRIX)
>   NEEDS_LIBGEN = YesPlease
>  endif
>  ifeq ($(uname_S),IRIX64)
> - NO_SETENV=YesPlease
> + NO_SETENV = YesPlease
>   NO_UNSETENV = YesPlease
> - NO_STRCASESTR=YesPlease
> + NO_STRCASESTR = YesPlease
>   NO_MEMMEM = YesPlease
>   NO_MKSTEMPS = YesPlease
>   NO_MKDTEMP = YesPlease
> @@ -1203,14 +1203,14 @@ ifeq ($(uname_S),IRIX64)
>   NO_REGEX = YesPlease
>   NO_FNMATCH_CASEFOLD = YesPlease
>   SNPRINTF_RETURNS_BOGUS = YesPlease
> - SHELL_PATH=/usr/gnu/bin/bash
> + SHELL_PATH = /usr/gnu/bin/bash
>   NEEDS_LIBGEN = YesPlease
>  endif
>  ifeq ($(uname_S),HP-UX)
>   INLINE = __inline
> - NO_IPV6=YesPlease
> - NO_SETENV=YesPlease
> - NO_STRCASESTR=YesPlease
> + NO_IPV6 = YesPlease
> + NO_SETENV = YesPlease
> + NO_STRCASESTR = YesPlease
>   NO_MEMMEM = YesPlease
>   NO_MKSTEMPS = YesPlease
>   NO_STRLCPY = YesPlease
> @@ -1386,10 +1386,10 @@ ifeq ($(uname_S),NONSTOP_KERNEL)
>   MKDIR_WO_TRAILING_SLASH = YesPlease
>   # RFE 10-120912-4693 submitted to HP NonStop development.
>   NO_SETITIMER = UnfortunatelyYes
> - SANE_TOOL_PATH=/usr/coreutils/bin:/usr/local/bin
> - SHELL_PATH=/usr/local/bin/bash
> + SANE_TOOL_PATH = /usr/coreutils/bin:/usr/local/bin
> + SHELL_PATH = /usr/local/bin/bash
>   # as of H06.25/J06.14, we might better use this
> - #SHELL_PATH=/usr/coreutils/bin/bash
> + #SHELL_PATH = /usr/coreutils/bin/bash
>  endif
>  ifneq (,$(findstring MINGW,$(uname_S)))
>   pathsep = ;
> @@ -1437,7 +1437,7 @@ ifneq (,$(findstring MINGW,$(uname_S)))
>   X = .exe
>   SPARSE_FLAGS = -Wno-one-bit-signed-bitfield
>  ifneq (,$(wildcard ../THIS_IS_MSYSGIT))
> - htmldir=doc/git/html/
> + htmldir = doc/git/html/
>   prefix =
>   INSTALL = /bin/install
>   EXTLIBS += /mingw/lib/libz.a
> @@ -1559,7 +1559,7 @@ else
>   CURL_LIBCURL = -lcurl
>   endif
>   ifdef NEEDS_SSL_WITH_CURL
> - CURL_LIBCURL += -lssl
> + CURL_LIBCURL += -lssl
>   ifdef NEEDS_CRYPTO_WITH_SSL
>   CURL_LIBCURL += -lcrypto
>   endif
> @@ -1768,7 +1768,7 @@ ifdef OBJECT_CREATION_USES_RENAMES
>  endif
>  ifdef NO_STRUCT_ITIMERVAL
>   COMPAT_CFLAGS += -DNO_STRUCT_ITIMERVAL
> - NO_SETITIMER=YesPlease
> + NO_SETITIMER = YesPlease
>  endif
>  ifdef NO_SETITIMER
>   COMPAT_CFLAGS += -DNO_SETITIMER
> @@ -1920,15 +1920,15 @@ ifneq (,$(XDL_FAST_HASH))
>  endif
>  
>  ifeq ($(TCLTK_PATH),)
> -NO_TCLTK=NoThanks
> +NO_TCLTK = NoThanks
>  endif
>  
> 

Re: [PATCHv2] mingw_rmdir: do not prompt for retry when non-empty

[Erik Faye-Lund]

On Mon, Dec 10, 2012 at 5:25 PM, Junio C Hamano  wrote:
> Erik Faye-Lund  writes:
>
>> in ab1a11be ("mingw_rmdir: set errno=ENOTEMPTY when appropriate"),
>> a check was added to prevent us from retrying to delete a directory
>> that is both in use and non-empty.
>>
>> However, this logic was slightly flawed; since we didn't return
>> immediately, we end up falling out of the retry-loop, but right into
>> the prompting-loop.
>>
>> Fix this by setting errno, and guarding the prompting-loop with an
>> errno-check.
>>
>> Signed-off-by: Erik Faye-Lund 
>> ---
>>
>> Here's the second version of this patch, sorry for the slight delay.
>
> Is this meant for me, or is it to be applied to msysgit and later
> somehow fed to me in different form?
>
> I can s/_wrmdir/rmdir/;s/wpathname/pathname/ if that is what you
> want me to do, but otherwise this patch does not apply.
>

Ugh, you are right. I intended for you to apply it, but I didn't
realize that my patch was based on the msysGit-master, where Karsten's
UTF-8 patches has been applied.

I'm not entirely sure what the best approach would be. The issue is
present in both branches, but we only build installers from the
msysGit-branch. But I think there are other people who builds Git from
the upstream source code, so it would be slightly less annoying for
them if the patch was fixed up and applied. But on the other hand,
that causes some annoyance when (if?) Karsten's UTF-8 patches gets
upstreamed.

Thoughts?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] git-clean: Display more accurate delete messages

[Soren Brinkmann]

Hi Zoltan,

On Sun, Dec 09, 2012 at 10:18:19PM +1100, Zoltan Klinger wrote:
> >> Hrm, following your discussion (ellided above), I would have
> >> expected that you would show
> >>
> >> Removing directory foo/bar
> >> Removing untracked_file1
> >
> > Also it would be nice to have warnings about undeleted directories since 
> > this git
> > clean behavior (or the work around to pass -f twice) is not documented.
> > Without a warning you would probably miss that something was _not_ deleted.
> 
> Thanks for the feedback. I think you're right. Showing 'foo/bar/bar.txt' in
> the list when 'foo/bar/' directory has been successfully deleted is just 
> noise.
> 
> Would like to get some more feedback on the proposed output in case of
>  (1) an untracked subdirectory with multiple files where at least one of them
>  cannot be removed.
>  (2) reporting ignored untracked git subdirectories
> 
> Suppose we have a repo like the one below:
>   test.git/
> |-- tracked_file
> |-- untracked_file
> |-- untracked_foo/
> | |-- bar/
> | | |-- bar.txt
> | |-- emptydir/
> | |-- frotz.git/
> | | |-- frotx.txt
> | |-- quux/
> |   |-- failedquux.txt
> |   |-- quux.txt
> |-- untracked_unreadable_dir/
> | |-- afile
> |-- untracked_some.git/
>   |-- some.txt
> 
> $ git clean -fd
> Removing untracked_file
> Removing untracked_foo/bar
> Removing untracked_foo/emptydir
> Removing untracked_foo/quux/quux.txt
> warning: failed to remove untracked_foo/quux/failedquux.txt
> warning: failed to remove remove untracked_unreadable_dir/
> warning: ignoring untracked git repository untracked_foo/frotz.git/
> warning: ignoring untracked git repository untracked_some.git/
> Use git clean --force --force to delete all untracked git repositories
> 
> $ # use forced remove
> $ git clean --force --force -d
> Removing untracked_foo/frotz.git
> Removing untracked_foo/quux/quux.txt
> Removing untracked_some.git/
> warning: failed to remove untracked_foo/quux/failedquux.txt
> warning: failed to remove untracked_unreadable_dir/
> 
> Can you see any issues with the proposed output, wording above? If
> everyone is happy,
> I'm going to prepare patch V2 for it.
Looks good to me.

Thanks,
Soren


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

Re: [PATCHv2] mingw_rmdir: do not prompt for retry when non-empty

[Johannes Schindelin]

Hi kusma,

On Mon, 10 Dec 2012, Erik Faye-Lund wrote:

> On Mon, Dec 10, 2012 at 5:25 PM, Junio C Hamano  wrote:
> > Erik Faye-Lund  writes:
> >
> >> in ab1a11be ("mingw_rmdir: set errno=ENOTEMPTY when appropriate"), a
> >> check was added to prevent us from retrying to delete a directory
> >> that is both in use and non-empty.
> >>
> >> However, this logic was slightly flawed; since we didn't return
> >> immediately, we end up falling out of the retry-loop, but right into
> >> the prompting-loop.
> >>
> >> Fix this by setting errno, and guarding the prompting-loop with an
> >> errno-check.
> >>
> >> Signed-off-by: Erik Faye-Lund 
> >> ---
> >>
> >> Here's the second version of this patch, sorry for the slight delay.
> >
> > Is this meant for me, or is it to be applied to msysgit and later
> > somehow fed to me in different form?
> >
> > I can s/_wrmdir/rmdir/;s/wpathname/pathname/ if that is what you
> > want me to do, but otherwise this patch does not apply.
> >
> 
> Ugh, you are right. I intended for you to apply it, but I didn't realize
> that my patch was based on the msysGit-master, where Karsten's UTF-8
> patches has been applied.
> 
> I'm not entirely sure what the best approach would be. The issue is
> present in both branches, but we only build installers from the
> msysGit-branch. But I think there are other people who builds Git from
> the upstream source code, so it would be slightly less annoying for them
> if the patch was fixed up and applied. But on the other hand, that
> causes some annoyance when (if?) Karsten's UTF-8 patches gets
> upstreamed.
> 
> Thoughts?

My preference would be to fix it in both branches. I will fix the merge
conflicts when rebasing onto Junio's master branch next time.

Ciao,
Dscho
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] cache-tree: invalidate i-t-a paths after generating trees

[Junio C Hamano]

Nguyen Thai Ngoc Duy  writes:

> Yeah I use entry_count for two different things here. In the previous
> (unsent) version of the patch I had "entry_count = -1" right after "i
> -= entry_count"
>
>>> + if (sub->cache_tree->entry_count < 0) {
>>> + i -= sub->cache_tree->entry_count;
>>> + sub->cache_tree->entry_count = -1;
>>> + to_invalidate = 1;
>>> + }
>
>
> which makes it clearer that the use of negative entry count is only
> valid within update_one. Then I changed my mind because it says
> 'negative means "invalid"' in cache-tree.h.

But you make it to mean not just 'negative means invalid' but
'negate it and you can learn how many index entries to skip to reach
the entry outside the subtree'.  That is what I was wondering about.

I do not think that new invariant does not hold in general; it may
hold true while inside this function, but immediately after somebody
else calls cache_tree_invalidate_path() it won't be true anymore.
Leaking the information to outside callers that can easily be
mistaken as if it may mean something without any comment looks like
we are asking for trouble.

> So, put "entry_count = -1"
> back or just add another field  to struct cache_tree for this?

As long as it is made clear with in-code comment that says "negative
entry count, when negated, will give us how many index entries are
covered by this invalid cache tree, only inside this function", and
such a negative entry_count is reset to -1 to avoid leaking out the
value that will soon go stale to the outside world in the "write
this tree out" loop, I think the v2 patch is OK, if not ideal.

If we were to commit to keep the new invariant true throughout the
system, on the other hand, I suspect that a boolean flag "valid" may
help people who keep i-t-a entries around across write-tree calls.
The first if () statement in the update_one() function can check the
validity, and you can say the cache tree is valid even if the
section in the index that is covered by the cache-tree contains
i-t-a entries _after_ you wrote it out as a tree, no?  That may make
the semantics a lot cleaner, I suspect.

The new semantics might be:

 * update_one() returns negative only when the section of the index
   given to it cannot be written out as a tree (i.e. not merged, or
   corrupt index);

 * update_one() returns the number of entries in the index covered
   by the tree, including i-t-a entries (but not REMOVED, as these
   entries will not be in the index after the cache-tree has been
   written out);

 * cache_tree->valid tells if the cache_tree->sha1 is valid; the
   section of the index the tree covers may or may not have i-t-a
   entries in it;

 * cache_tree->entry_count holds the number of index entries the
   tree covers, couting i-t-a entries. This field is only meaningful
   when cache_tree->valid is true.

or something like that.

I noticed that the recent "ignore i-t-a only while writing trees
instead of erroring out" broke 331fcb5 (git add --intent-to-add: do
not let an empty blob be committed by accident, 2008-11-28) in
another way, by the way.  In verify_cache(), there is an unreachable
else clause to warn about "not added yet" entries that should have
been removed but is left behind.

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

Re: [PATCHv2] mingw_rmdir: do not prompt for retry when non-empty

[Junio C Hamano]

Johannes Schindelin  writes:

> My preference would be to fix it in both branches. I will fix the merge
> conflicts when rebasing onto Junio's master branch next time.

OK, then I'll queue the following to my tree.

Thanks for a quick turnaround.

-- >8 --
From: Erik Faye-Lund 
Date: Mon, 10 Dec 2012 15:42:27 +0100
Subject: [PATCH] mingw_rmdir: do not prompt for retry when non-empty

in ab1a11be ("mingw_rmdir: set errno=ENOTEMPTY when appropriate"),
a check was added to prevent us from retrying to delete a directory
that is both in use and non-empty.

However, this logic was slightly flawed; since we didn't return
immediately, we end up falling out of the retry-loop, but right into
the prompting-loop.

Fix this by setting errno, and guarding the prompting-loop with an
errno-check.

Signed-off-by: Erik Faye-Lund 
Signed-off-by: Junio C Hamano 
---
 compat/mingw.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/compat/mingw.c b/compat/mingw.c
index 4e63838..28527ab 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -256,6 +256,8 @@ int mingw_rmdir(const char *pathname)
 
while ((ret = rmdir(pathname)) == -1 && tries < ARRAY_SIZE(delay)) {
if (!is_file_in_use_error(GetLastError()))
+   errno = err_win_to_posix(GetLastError());
+   if (errno != EACCES)
break;
if (!is_dir_empty(pathname)) {
errno = ENOTEMPTY;
@@ -271,7 +273,7 @@ int mingw_rmdir(const char *pathname)
Sleep(delay[tries]);
tries++;
}
-   while (ret == -1 && is_file_in_use_error(GetLastError()) &&
+   while (ret == -1 && errno == EACCES && 
is_file_in_use_error(GetLastError()) &&
   ask_yes_no_if_possible("Deletion of directory '%s' failed. "
"Should I try again?", pathname))
   ret = rmdir(pathname);
-- 
1.8.1.rc1.123.gf61cb86

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

Re: [PATCH] git-clean: Display more accurate delete messages

[Soren Brinkmann]

Hi, 

On Sun, Dec 09, 2012 at 11:04:59PM -0800, Junio C Hamano wrote:
> Zoltan Klinger  writes:
> 
> > Would like to get some more feedback on the proposed output in case of
> >  (1) an untracked subdirectory with multiple files where at least one of 
> > them
> >  cannot be removed.
> >  (2) reporting ignored untracked git subdirectories
> >
> > Suppose we have a repo like the one below:
> >   test.git/
> > |-- tracked_file
> > |-- untracked_file
> > |-- untracked_foo/
> > | |-- bar/
> > | | |-- bar.txt
> > | |-- emptydir/
> > | |-- frotz.git/
> > | | |-- frotx.txt
> > | |-- quux/
> > |   |-- failedquux.txt
> > |   |-- quux.txt
> > |-- untracked_unreadable_dir/
> > | |-- afile
> > |-- untracked_some.git/
> >   |-- some.txt
> >
> > $ git clean -fd
> > Removing untracked_file
> > Removing untracked_foo/bar
> > Removing untracked_foo/emptydir
> > Removing untracked_foo/quux/quux.txt
> > warning: failed to remove untracked_foo/quux/failedquux.txt
> > warning: failed to remove remove untracked_unreadable_dir/
> 
> "remove remove" is a typo, I presume.
> 
> > warning: ignoring untracked git repository untracked_foo/frotz.git/
> > warning: ignoring untracked git repository untracked_some.git/
> 
> If you mean "we report the topmost directory and nothing about
> (recursive) contents in it if everything is removed successfully"
> (in other words, if we had subdirectories and files inside
> untracked_foo/bar/ and we successfully removed all of them, the
> above output does not change), it seems quite reasonable.
> 
> > Use git clean --force --force to delete all untracked git repositories
> 
> But I am not sure if this is ever sane.  Especially the one that
> removes an embedded repository is suspicious.  "git clean" should
> not ever touch it with or without --superforce or any other command.
As I mentioned in my email where I reported this incorrect git clean output, I
have a use case where I want git clean to remove embedded repositories.
Whether it is a sane one is probably a different discussion.

Soren


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

Re: [PATCH] git-clean: Display more accurate delete messages

[Junio C Hamano]

Soren Brinkmann  writes:

>> > Use git clean --force --force to delete all untracked git repositories
>> 
>> But I am not sure if this is ever sane.  Especially the one that
>> removes an embedded repository is suspicious.  "git clean" should
>> not ever touch it with or without --superforce or any other command.
> As I mentioned in my email where I reported this incorrect git clean output, I
> have a use case where I want git clean to remove embedded repositories.
> Whether it is a sane one is probably a different discussion.

Why is it a different discussion?  If something is not sane, the
tool shouldn't encourage users to do such an insane thing.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] git-clean: Display more accurate delete messages

[Soren Brinkmann]

On Mon, Dec 10, 2012 at 10:03:28AM -0800, Junio C Hamano wrote:
> Soren Brinkmann  writes:
> 
> >> > Use git clean --force --force to delete all untracked git repositories
> >> 
> >> But I am not sure if this is ever sane.  Especially the one that
> >> removes an embedded repository is suspicious.  "git clean" should
> >> not ever touch it with or without --superforce or any other command.
> > As I mentioned in my email where I reported this incorrect git clean 
> > output, I
> > have a use case where I want git clean to remove embedded repositories.
> > Whether it is a sane one is probably a different discussion.
> 
> Why is it a different discussion?  If something is not sane, the
> tool shouldn't encourage users to do such an insane thing.
> 
Well, ok. So I have a repository which essentially consists of a bunch of
scripts which then pull sources via git to build root filesystems, busybox,
kernel etc.
So I have the master repository I'm actually interested in. And then all the
other projects which are pulled in to build stuff from.
looking somehow like this:
top.git
 |-src
 |  |-proj1.git
 |  |-proj2.git
 |  |-projn.git
 |-build
 |-proj1
 |-proj2
 ...

Since the scripts are not perfect I usually used 'git clean -xdf' to wipe
everything and build from scratch. And I had to experience that the git clean
behavior somehow changed recently and the 'projn.git' directories were no longer
removed anymore, despite git indicating otherwise in its output.

So, I think having 'git clean -ff' removing embedded git repos is okay. But 
either
way, the output of git clean should match what it is doing. And at least tell me
if it didn't remove certain dirs or files.

Soren


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

Re: Use of a mailmap file with git-log

[Junio C Hamano]

Rich Midwinter  writes:

> I'm working on a project for a large organisation that wants to make
> widespread use of git and the mailmap feature.
>
> This seems to be supported by default in git-shortlog but not git-log
> (and other variants) without specifying custom formats, which isn't
> really something I want to try and 'fix' across the organisation. Is
> there a reason for this feature omission or has it just evolved that
> way and could it be fixed?

I think it was pretty much the latter, but people may already be
depending on the command to give them the "true as recorded back
then" names in the output.  A fix may have to involve inventing a
new option "log --use-mailmap" that is explicitly given from the
command line.

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

Re: [PATCH] git-clean: Display more accurate delete messages

[Junio C Hamano]

Soren Brinkmann  writes:

> But either
> way, the output of git clean should match what it is doing. And at least tell 
> me
> if it didn't remove certain dirs or files.

Oh, no question about that part.  I was reacting to --force --force
in general, and an unrelated git repository inside a working tree is
just a subset of the issue.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Use of a mailmap file with git-log

[Junio C Hamano]

Junio C Hamano  writes:

> Rich Midwinter  writes:
>
>> I'm working on a project for a large organisation that wants to make
>> widespread use of git and the mailmap feature.
>>
>> This seems to be supported by default in git-shortlog but not git-log
>> (and other variants) without specifying custom formats, which isn't
>> really something I want to try and 'fix' across the organisation. Is
>> there a reason for this feature omission or has it just evolved that
>> way and could it be fixed?
>
> I think it was pretty much the latter, but people may already be
> depending on the command to give them the "true as recorded back
> then" names in the output.  A fix may have to involve inventing a
> new option "log --use-mailmap" that is explicitly given from the
> command line.

If somebody wants to do this, I think the overall design should go
like this:

 * We may want to rewrite blame.c::get_ac_line() and the code in
   pretty.c::pp_user_info() that parse author/committer lines by
   using ident.c::split_ident_line() for better code reuse as a
   preparation step before all of the below.

 * We may want to lift the buffer length limit from the implementation
   of mailmap.c::map_user() by using the strbuf API as a preparation
   step before all of the below.

 * We may also want to rethink its signature (we may want to get a
   single strbuf and have the function parse out "Name "; I
   didn't check the existing callers to see if that would make it
   easier to use, and if it does not, this obviously shouldn't be done)
   as a preparation step before all of the below.

 * Introduce a new "struct string_list *mailmap" member to "struct
   pretty_print_context" and "struct rev_info" (default to NULL);

 * In log-tree.c::show_log(), copy opt->mailmap to ctx.mailmap;

 * Update pretty.c::pp_user_info() to convert the email address on
   "line" (between the beginning and "namelen") by calling
   map_user() immediately after it parses time/tz out, and adjust
   the remainder of the function to use it, when pp->mailmap is
   present;

 * Teach log.c::cmd_log_init_finosh() about "--use-mailmap" option.
   Allocate one "struct string_list" instance and use read_mailmap()
   on it when the option is used, and store it in rev->mailmap.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Use of a mailmap file with git-log

[Antoine Pelisse]

Hi,

I was thinking about that last week.
It could indeed be very interesting to have mailmap applied to git-log and
especially to git-log --author/--committer.

My first look at the code let me think that we would need to change the
parse_commit_buffer to replace, at reading time, the name of author and
committer if an option (--use-mailmap seems like a wise choice) and
probably a config option.
The choice of parse_commit_buffer to do the modification is due to
the grepping being done directly on buffer when grepping author/committerer.

Yet I'm afraid it could be:
1. expensive to rewrite all commit log (reallocating the buffer)
2. Inappropriate to change the value in function that is supposed to
read

My 2 cents.

Cheers,

On Mon, Dec 10, 2012 at 7:48 PM, Junio C Hamano  wrote:
> Rich Midwinter  writes:
>
>> I'm working on a project for a large organisation that wants to make
>> widespread use of git and the mailmap feature.
>>
>> This seems to be supported by default in git-shortlog but not git-log
>> (and other variants) without specifying custom formats, which isn't
>> really something I want to try and 'fix' across the organisation. Is
>> there a reason for this feature omission or has it just evolved that
>> way and could it be fixed?
>
> I think it was pretty much the latter, but people may already be
> depending on the command to give them the "true as recorded back
> then" names in the output.  A fix may have to involve inventing a
> new option "log --use-mailmap" that is explicitly given from the
> command line.
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Use of a mailmap file with git-log

[Junio C Hamano]

Antoine Pelisse  writes:

> Yet I'm afraid it could be:
> 1. expensive to rewrite all commit log (reallocating the buffer)
> 2. Inappropriate to change the value in function that is supposed to
> read

In my suggestion I avoided rewriting the log buffer, primarily
because of #2 (in addition to "read" cleanliness, such a change may
break the gpg signature checking for merges).

We do reencode the contents before we write it out when "encoding"
is present, so logically such a rewrite of authors and committers
belongs to where that happens, in pretty_print_commit().  Note that
this existing rewrite is not done to the commit log buffer but is to
a separate buffer meant to be used only for output.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Use of a mailmap file with git-log

[Junio C Hamano]

Antoine Pelisse  writes:

> It could indeed be very interesting to have mailmap applied to git-log and
> especially to git-log --author/--committer.
> ...
> The choice of parse_commit_buffer to do the modification is due to
> the grepping being done directly on buffer when grepping author/committerer.

For pattern matching, I think revision.c::commit_match() is probably
the right place to do this kind of thing.  I just noticed that we
grep for the string inside a raw buffer, even when "encoding" is
specified, which I think is a bug.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] format_commit_message(): simplify calls to logmsg_reencode()

[Junio C Hamano]

All the other callers of logmsg_reencode() pass return value of
get_commit_output_encoding() or get_log_output_encoding().  Teach
the function to optionally take NULL as a synonym to "" aka "no
conversion requested" so that we can simplify the only remaining
calling site.

Signed-off-by: Junio C Hamano 
---
 pretty.c | 16 
 1 file changed, 4 insertions(+), 12 deletions(-)

diff --git a/pretty.c b/pretty.c
index e87fe9f..732e2a2 100644
--- a/pretty.c
+++ b/pretty.c
@@ -500,7 +500,7 @@ char *logmsg_reencode(const struct commit *commit,
char *encoding;
char *out;
 
-   if (!*output_encoding)
+   if (!output_encoding || !*output_encoding)
return NULL;
encoding = get_header(commit, "encoding");
use_encoding = encoding ? encoding : utf8;
@@ -1184,23 +1184,15 @@ void format_commit_message(const struct commit *commit,
   const struct pretty_print_context *pretty_ctx)
 {
struct format_commit_context context;
-   static const char utf8[] = "UTF-8";
const char *output_enc = pretty_ctx->output_encoding;
 
memset(&context, 0, sizeof(context));
context.commit = commit;
context.pretty_ctx = pretty_ctx;
context.wrap_start = sb->len;
-   context.message = commit->buffer;
-   if (output_enc) {
-   char *enc = get_header(commit, "encoding");
-   if (strcmp(enc ? enc : utf8, output_enc)) {
-   context.message = logmsg_reencode(commit, output_enc);
-   if (!context.message)
-   context.message = commit->buffer;
-   }
-   free(enc);
-   }
+   context.message = logmsg_reencode(commit, output_enc);
+   if (!context.message)
+   context.message = commit->buffer;
 
strbuf_expand(sb, format, format_commit_item, &context);
rewrap_message_tail(sb, &context, 0, 0, 0);
-- 
1.8.1.rc1.123.gf61cb86

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

Re: Millisecond precision in timestamps?

[James Cloos]

> "ESR" == Eric S Raymond  writes:

ESR> I've never seen a software project under version control with bits
ESR> that old,

They do exist, but the vcs timestamps are (at least for those in git :)
not (always) correlated to when the files were first added to the project.

Maxima, as an example, has code which was written in the '60s.  (A
couple of years ago a bug was fixed in a contrib module which had
been added to MACSYMA back in '62 or so.)

I beleive axiom also has some similarly ancient code.

Those two are now managed in git.  (Except for the openaxiom fork.)

And there is a high-energy physics package still under development
with code going back to the '50s.  I'm pretty sure they moved to a
vcs sometime in the last decade or two. :)

-JimC
-- 
James Cloos  OpenPGP: 1024D/ED7DAEA6


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

[ANNOUNCE] Git v1.8.0.2

[Junio C Hamano]

The latest maintenance release Git v1.8.0.2 is now available at
the usual places.

The release tarballs are found at:

http://code.google.com/p/git-core/downloads/list

and their SHA-1 checksums are:

1e1640794596da40f35194c29a8cc4e41c6b4f6d  git-1.8.0.2.tar.gz
6b9e14c5b19b2e27605014252febd61a700012a3  git-htmldocs-1.8.0.2.tar.gz
ce0673256ce90451269a82a2464eab060adbfec6  git-manpages-1.8.0.2.tar.gz

Also the following public repositories all have a copy of the v1.8.0.2
tag and the maint branch that the tag points at:

  url = git://repo.or.cz/alt-git.git
  url = https://code.google.com/p/git-core/
  url = git://git.sourceforge.jp/gitroot/git-core/git.git
  url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
  url = https://github.com/gitster/git

Git v1.8.0.2 Release Notes
==

Fixes since v1.8.0.1


 * Various codepaths have workaround for a common misconfiguration to
   spell "UTF-8" as "utf8", but it was not used uniformly.  Most
   notably, mailinfo (which is used by "git am") lacked this support.

 * We failed to mention a file without any content change but whose
   permission bit was modified, or (worse yet) a new file without any
   content in the "git diff --stat" output.

 * When "--stat-count" hides a diffstat for binary contents, the total
   number of added and removed lines at the bottom was computed
   incorrectly.

 * When "--stat-count" hides a diffstat for unmerged paths, the total
   number of affected files at the bottom of the "diff --stat" output
   was computed incorrectly.

 * "diff --shortstat" miscounted the total number of affected files
   when there were unmerged paths.

 * "git p4" used to try expanding malformed "$keyword$" that spans
   across multiple lines.

 * "git update-ref -d --deref SYM" to delete a ref through a symbolic
   ref that points to it did not remove it correctly.

 * Syntax highlighting in "gitweb" was not quite working.

Also contains other minor fixes and documentation updates.



Changes since v1.8.0.1 are as follows:

Antoine Pelisse (1):
  Fix typo in remote set-head usage

Eric S. Raymond (1):
  doc/fast-import: clarify how content states are built

Johan Herland (2):
  t1400-update-ref: Add test verifying bug with symrefs in delete_ref()
  Fix failure to delete a packed ref through a symref

Junio C Hamano (13):
  reencode_string(): introduce and use same_encoding()
  test: add failing tests for "diff --stat" to t4049
  diff --stat: status of unmodified pair in diff-q is not zero
  diff --stat: use "file" temporary variable to refer to data->files[i]
  diff --stat: move the "total count" logic to the last loop
  diff --stat: do not count "unmerged" entries
  diff --shortstat: do not count "unmerged" entries
  Documentation/git-push.txt: clarify the "push from satellite" workflow
  Start preparing for 1.8.0.2
  t4049: refocus tests
  Update draft release notes to 1.8.0.2
  git(1): remove a defunct link to "list of authors"
  Git 1.8.0.2

Linus Torvalds (1):
  Fix "git diff --stat" for interesting - but empty - file changes

Mark Szepieniec (1):
  Documentation: improve phrasing in git-push.txt

Matthieu Moy (2):
  git-remote-mediawiki: escape ", \, and LF in file names
  git-fast-import.txt: improve documentation for quoted paths

Nguyễn Thái Ngọc Duy (1):
  compat/fnmatch: fix off-by-one character class's length check

Paul Gortmaker (1):
  Makefile: hide stderr of curl-config test

Pete Wyckoff (1):
  git p4: RCS expansion should not span newlines

Ralf Thielow (1):
  completion: add options --single-branch and --branch to "git clone"

Richard Hubbell (1):
  gitweb.perl: fix %highlight_ext mappings

Sébastien Loriot (1):
  Documentation/git-stash.txt: add a missing verb

W. Trevor King (1):
  git-submodule: wrap branch option with "<>" in usage strings.

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

What's cooking in git.git (Dec 2012, #02; Mon, 10)

[Junio C Hamano]

Here are the topics that have been cooking.  Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.

A new maintenance release 1.8.0.2 was tagged with accumulated fixes
we have already been using on the 'master' front for a while.  The
tip of the 'master' is a bit beyond 1.8.1-rc1 and many topics are
getting into good shape in 'next', hopefully ready to be merged soon
after the 1.8.1 final.

You can find the changes described here in the integration branches of the
repositories listed at

http://git-blame.blogspot.com/p/git-public-repositories.html

--
[New Topics]

* ef/mingw-rmdir (2012-12-10) 1 commit
 - mingw_rmdir: do not prompt for retry when non-empty

 MinGW has a workaround when rmdir unnecessarily fails to retry with
 a prompt, but the logic was kicking in when the rmdir failed with
 ENOTEMPTY, i.e. was expected to fail and there is no point retrying.

 Will fast-track to 'master'.


* jc/maint-fbsd-sh-ifs-workaround (2012-12-10) 1 commit
 - sh-setup: work around "unset IFS" bug in some shells

 Will merge to 'next'.


* jc/merge-blobs (2012-12-09) 4 commits
 - merge-tree: add comments to clarify what these functions are doing
 - merge-tree: lose unused "resolve_directories"
 - merge-tree: lose unused "flags" from merge_list
 - Which merge_file() function do you mean?

 A beginning of a new merge strategy based on the disused merge-tree
 proof-of-concept code.


* jc/same-encoding (2012-12-10) 1 commit
 - format_commit_message(): simplify calls to logmsg_reencode()

 Finishing touches to the series to unify "Do we need to reencode
 between these two encodings?" logic.


* nd/invalidate-i-t-a-cache-tree (2012-12-09) 1 commit
 - cache-tree: invalidate i-t-a paths after generating trees

 Writing out a tree object when you still have intent-to-add entries
 in the index left an incorrect cache-tree data there.

--
[Graduated to "master"]

* rr/t4041-cleanup (2012-12-02) 4 commits
  (merged to 'next' on 2012-12-04 at ecee35d)
 + t4041 (diff-submodule-option): modernize style
 + t4041 (diff-submodule-option): rewrite add_file() routine
 + t4041 (diff-submodule-option): parse digests sensibly
 + t4041 (diff-submodule-option): don't hardcode SHA-1 in expected outputs

 Test clean-up.

--
[Stalled]

* fc/remote-bzr (2012-11-28) 10 commits
 - (fixup) test-bzr.sh: fix multi-line string assignment
 - remote-bzr: detect local repositories
 - remote-bzr: add support for older versions of bzr
 - remote-bzr: add support to push special modes
 - remote-bzr: add support for fecthing special modes
 - remote-bzr: add simple tests
 - remote-bzr: update working tree
 - remote-bzr: add support for remote repositories
 - remote-bzr: add support for pushing
 - Add new remote-bzr transport helper

 New remote helper for bzr (v3).  With minor fixes, this may be ready
 for 'next'.


* mo/cvs-server-updates (2012-12-09) 18 commits
 - t9402: Use TABs for indentation
 - t9402: Rename check.cvsCount and check.list
 - t9402: Simplify git ls-tree
 - t9402: Add missing &&; Code style
 - t9402: No space after IO-redirection
 - t9402: Dont use test_must_fail cvs
 - t9402: improve check_end_tree() and check_end_full_tree()
 - t9402: sed -i is not portable
 - cvsserver Documentation: new cvs ... -r support
 - cvsserver: add t9402 to test branch and tag refs
 - cvsserver: support -r and sticky tags for most operations
 - cvsserver: Add version awareness to argsfromdir
 - cvsserver: generalize getmeta() to recognize commit refs
 - cvsserver: implement req_Sticky and related utilities
 - cvsserver: add misc commit lookup, file meta data, and file listing functions
 - cvsserver: define a tag name character escape mechanism
 - cvsserver: cleanup extra slashes in filename arguments
 - cvsserver: factor out git-log parsing logic

 Needs review by folks interested in cvsserver.


* as/check-ignore (2012-11-08) 14 commits
 - t0007: fix tests on Windows
 - Documentation/check-ignore: we show the deciding match, not the first
 - Add git-check-ignore sub-command
 - dir.c: provide free_directory() for reclaiming dir_struct memory
 - pathspec.c: move reusable code from builtin/add.c
 - dir.c: refactor treat_gitlinks()
 - dir.c: keep track of where patterns came from
 - dir.c: refactor is_path_excluded()
 - dir.c: refactor is_excluded()
 - dir.c: refactor is_excluded_from_list()
 - dir.c: rename excluded() to is_excluded()
 - dir.c: rename excluded_from_list() to is_excluded_from_list()
 - dir.c: rename path_excluded() to is_path_excluded()
 - dir.c: rename cryptic 'which' variable to more consistent name

 Duy helped to reroll this.

 Expecting a re-roll.


* aw/rebase-am-failure-detection (2012-10-11) 1 commit
 - rebase: Handle cases where format-patch fails

 I am unhappy a bit about the possible performance implications of
 having to store the out

A note from the maintainer

[Junio C Hamano]

Welcome to the Git development community.

This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.

* Mailing list and the community

The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address .  You don't have to be
subscribed to send messages.  The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
I am not subscribed".

Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.

If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise.  Please
do not hesitate to send a reminder message in such a case.  Messages
getting lost in the noise is a sign that people involved don't have
enough mental/time bandwidth to process them right at the moment, and
it often helps to wait until the list traffic becomes calmer before
sending such a reminder.

The list archive is available at a few public sites:

http://news.gmane.org/gmane.comp.version-control.git/
http://marc.theaimsgroup.com/?l=git
http://www.spinics.net/lists/git/

For those who prefer to read it over NNTP (including the maintainer):

nntp://news.gmane.org/gmane.comp.version-control.git

When you point at a message in a mailing list archive, using
gmane is often the easiest to follow by readers, like this:

http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217

as it also allows people who subscribe to the mailing list as gmane
newsgroup to "jump to" the article.

Some members of the development community can sometimes also be found
on the #git IRC channel on Freenode.  Its log is available at:

http://colabti.org/irclogger/irclogger_log/git

* Reporting bugs

When you think git does not behave as you expect, please do not stop
your bug report with just "git does not work".  "I used git in this
way, but it did not work" is not much better, neither is "I used git
in this way, and X happend, which is broken".  It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.

Please remember to always state

 - what you wanted to achieve;

 - what you did (the version of git and the command sequence to reproduce
   the behavior);

 - what you saw happen (X above);

 - what you expected to see (Y above); and

 - how the last two are different.

See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.

* Repositories, branches and documentation.

My public git.git repositories are at:

git://git.kernel.org/pub/scm/git/git.git/
git://repo.or.cz/alt-git.git/
https://github.com/git/git/
https://code.google.com/p/git-core/
git://git.sourceforge.jp/gitroot/git-core/git.git/
git://git-core.git.sourceforge.net/gitroot/git-core/git-core/

A few gitweb interfaces are found at:

http://git.kernel.org/?p=git/git.git
http://repo.or.cz/w/alt-git.git

Preformatted documentation from the tip of the "master" branch can be
found in:

git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
git://repo.or.cz/git-{htmldocs,manpages}.git/
https://code.google.com/p/git-{htmldocs,manpages}.git/
https://github.com/gitster/git-{htmldocs,manpages}.git/

You can browse the HTML manual pages at:

http://git-htmldocs.googlecode.com/git/git.html

There are four branches in git.git repository that track the source tree
of git: "master", "maint", "next", and "pu".

The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting.  Every now and then, a "feature
release" is cut from the tip of this branch and they typically are named
with three dotted decimal digits.  The last such release was 1.8.0 done on
Oct 21, 2012. You can expect that the tip of the "master" branch is always
more stable than any of the released versions.

Whenever a feature release is made, "maint" branch is forked off from
"master" at that point.  Obvious, safe and urgent fixes after a feature
release are applied to this branch and maintenance releases are cut from
it.  The maintenance releases are named with four dotted decimal, named
after the feature release they are updates to; the last such release was
1.8.0.2.  New features never go to this branch.  This branch is also
merged into "master" to propagate the fixes forward as needed.

A new development does not usually happen on "master". When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip 

Re: Python extension commands in git - request for policy change

[Patrick Donnelly]

Sorry I'm late to this party...

I'm an Nmap developer that is casually interested in git development.
I've been lurking for a while and thought I'd post my thoughts on this
thread.

On Sun, Nov 25, 2012 at 6:25 AM, Nguyen Thai Ngoc Duy  wrote:
>> The most important issues to consider when imagining a future with a
>> hybrid of code in C and some scripting language "X" are:
>>
>> * Portability: is "X" available on all platforms targeted by git, in
>>   usable and mutually-compatible versions?
>>
>> * Startup time: Is the time to start the "X" interpreter prohibitive?
>>   (On my computer, "python -c pass", which starts the Python
>>   interpreter and does nothing, takes about 24ms.)  This overhead would
>>   be incurred by every command that is not pure C.
>>
>> * Should the scripting language access the C functionality only by
>>   calling pure-C executables or by dynamically or statically linking to
>>   a binary module interface?  If the former, then the granularity of
>>   interactions between "X" and C is necessarily coarse, and "X" cannot
>>   be used to implement anything but the outermost layer of
>>   functionality.  If the latter, then the way would be clear to
>>   implement much more of git in "X" (and lua would also be worth
>>   considering).
>>
>> * Learning curve for developers: how difficult is it for a typical git
>>   developer to become conversant with "X", considering both (1) how
>>   likely is it that the typical git developer already knows "X" and
>>   (2) how straightforward and predictable is the language "X"?
>>   In this category I think that Python has a huge advantage over
>>   Perl, though certainly opinions will differ and Ruby would also be
>>   a contender.
>
> * We might also need an embedded language variant, like Jeff's lua
> experiment. I'd be nice if "X" can also take this role.

Lua has been an incredible success for Nmap [2](and other projects).
As an embedded scripting language, it's unrivaled in terms of ease of
embedding, ease of use for users, and performance. I would strongly
recommend the git developers to seriously consider it.

Addressing the points listed above:

>> * Portability: is "X" available on all platforms targeted by git, in
>>   usable and mutually-compatible versions?

Lua is written in ANSI C and so compiles basically anywhere (certainly
anywhere git does).

>> * Startup time: Is the time to start the "X" interpreter prohibitive?
>>   (On my computer, "python -c pass", which starts the Python
>>   interpreter and does nothing, takes about 24ms.)  This overhead would
>>   be incurred by every command that is not pure C.

As mentioned elsewhere in this thread by Joshua:

"Because Lua was mentioned in another message of this thread, I'll
provide the following:

* A cold run of 'lua5.1 -e ""' takes 0.4 seconds.  The second run
takes 0.03 seconds.
* A cold run of LuaJIT takes the same."

The runtime figures would probably be much lower if git modules (e.g.
pull) were capable of calling other modules without forking, all
within the same Lua environment.

>> * Should the scripting language access the C functionality only by
>>   calling pure-C executables or by dynamically or statically linking to
>>   a binary module interface?  If the former, then the granularity of
>>   interactions between "X" and C is necessarily coarse, and "X" cannot
>>   be used to implement anything but the outermost layer of
>>   functionality.  If the latter, then the way would be clear to
>>   implement much more of git in "X" (and lua would also be worth
>>   considering).

Using Lua as a glue between a proper git C API and modules would be
optimal in my opinion and experience.

>> * Learning curve for developers: how difficult is it for a typical git
>>   developer to become conversant with "X", considering both (1) how
>>   likely is it that the typical git developer already knows "X" and
>>   (2) how straightforward and predictable is the language "X"?
>>   In this category I think that Python has a huge advantage over
>>   Perl, though certainly opinions will differ and Ruby would also be
>>   a contender.

Lua is remarkably easy to learn and is engineered so it's approachable
by novice (or non-) programmers. Still, it offers all the features you
expect from a modern scripting language including GC, real lexical
scoping and closure, tables/arrays, and *coroutines*. While Nmap
occasionally gets questions about why we didn't use Python, no one
complains about Lua itself.


As for version considerations, Lua changes at a glacial pace compared
to other popular languages like Python or Ruby. Lua 5.2 was released
last year and 5.1 was released 5 years before that [1]. Still, while
users (people who bind Lua to applications) are certainly encouraged
to upgrade Lua, there is no real need to. Binding Lua to an
application statically is not a significant cost as it compiles to
less than 200 KB including base libraries; so, it's simple and cheap
to remain independent of the syste

[PATCH 2/2] strbuf_add_wrapped*(): Remove unused return value

[Steffen Prohaska]

Since shortlog isn't using the return value anymore (see previous
commit), the functions can be changed to void.

Signed-off-by: Steffen Prohaska 
---
 utf8.c | 13 ++---
 utf8.h |  4 ++--
 2 files changed, 8 insertions(+), 9 deletions(-)

diff --git a/utf8.c b/utf8.c
index 5c61bbe..a4ee665 100644
--- a/utf8.c
+++ b/utf8.c
@@ -323,7 +323,7 @@ static size_t display_mode_esc_sequence_len(const char *s)
  * If indent is negative, assume that already -indent columns have been
  * consumed (and no extra indent is necessary for the first line).
  */
-int strbuf_add_wrapped_text(struct strbuf *buf,
+void strbuf_add_wrapped_text(struct strbuf *buf,
const char *text, int indent1, int indent2, int width)
 {
int indent, w, assume_utf8 = 1;
@@ -332,7 +332,7 @@ int strbuf_add_wrapped_text(struct strbuf *buf,
 
if (width <= 0) {
strbuf_add_indented_text(buf, text, indent1, indent2);
-   return 1;
+   return;
}
 
 retry:
@@ -356,14 +356,14 @@ retry:
if (w <= width || !space) {
const char *start = bol;
if (!c && text == start)
-   return w;
+   return;
if (space)
start = space;
else
strbuf_addchars(buf, ' ', indent);
strbuf_add(buf, start, text - start);
if (!c)
-   return w;
+   return;
space = text;
if (c == '\t')
w |= 0x07;
@@ -405,13 +405,12 @@ new_line:
}
 }
 
-int strbuf_add_wrapped_bytes(struct strbuf *buf, const char *data, int len,
+void strbuf_add_wrapped_bytes(struct strbuf *buf, const char *data, int len,
 int indent, int indent2, int width)
 {
char *tmp = xstrndup(data, len);
-   int r = strbuf_add_wrapped_text(buf, tmp, indent, indent2, width);
+   strbuf_add_wrapped_text(buf, tmp, indent, indent2, width);
free(tmp);
-   return r;
 }
 
 int is_encoding_utf8(const char *name)
diff --git a/utf8.h b/utf8.h
index 93ef600..a214238 100644
--- a/utf8.h
+++ b/utf8.h
@@ -9,9 +9,9 @@ int is_utf8(const char *text);
 int is_encoding_utf8(const char *name);
 int same_encoding(const char *, const char *);
 
-int strbuf_add_wrapped_text(struct strbuf *buf,
+void strbuf_add_wrapped_text(struct strbuf *buf,
const char *text, int indent, int indent2, int width);
-int strbuf_add_wrapped_bytes(struct strbuf *buf, const char *data, int len,
+void strbuf_add_wrapped_bytes(struct strbuf *buf, const char *data, int len,
 int indent, int indent2, int width);
 
 #ifndef NO_ICONV
-- 
1.8.1.rc1.2.gfb98a3a

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

[PATCH 1/2] shortlog: Fix wrapping lines of wraplen (was broken since recent off-by-one fix)

[Steffen Prohaska]

A recent commit [1] fixed a off-by-one wrapping error.  As
a side-effect, the conditional in add_wrapped_shortlog_msg() whether to
append a newline needs to be removed.  add_wrapped_shortlog_msg() should
always append a newline, which was the case before the off-by-one fix,
because strbuf_add_wrapped_text() never returned a value of wraplen.

[1] 14e1a4e1ff70aff36db3f5d2a8b806efd0134d50 utf8: fix off-by-one
wrapping of text

Signed-off-by: Steffen Prohaska 
---
 builtin/shortlog.c  |  5 ++---
 t/t4201-shortlog.sh | 24 
 2 files changed, 26 insertions(+), 3 deletions(-)

diff --git a/builtin/shortlog.c b/builtin/shortlog.c
index b316cf3..8360514 100644
--- a/builtin/shortlog.c
+++ b/builtin/shortlog.c
@@ -306,9 +306,8 @@ parse_done:
 static void add_wrapped_shortlog_msg(struct strbuf *sb, const char *s,
 const struct shortlog *log)
 {
-   int col = strbuf_add_wrapped_text(sb, s, log->in1, log->in2, log->wrap);
-   if (col != log->wrap)
-   strbuf_addch(sb, '\n');
+   strbuf_add_wrapped_text(sb, s, log->in1, log->in2, log->wrap);
+   strbuf_addch(sb, '\n');
 }
 
 void shortlog_output(struct shortlog *log)
diff --git a/t/t4201-shortlog.sh b/t/t4201-shortlog.sh
index 6872ba1..02ac978 100755
--- a/t/t4201-shortlog.sh
+++ b/t/t4201-shortlog.sh
@@ -120,6 +120,30 @@ test_expect_success 'shortlog from non-git directory' '
test_cmp expect out
 '
 
+test_expect_success 'shortlog should add newline when input line matches 
wraplen' '
+   cat >expect <<\EOF &&
+A U Thor (2):
+  bb:  bbb  bbb bb  bbb b bb
+  aa: aa aa   aa  aa aaa
+
+EOF
+   git shortlog -w >out <<\EOF &&
+commit 0001
+Author: A U Thor 
+Date:   Thu Apr 7 15:14:13 2005 -0700
+
+aa: aa aa   aa  aa aaa
+
+commit 0002
+Author: A U Thor 
+Date:   Thu Apr 7 15:14:13 2005 -0700
+
+bb:  bbb  bbb bb  bbb b bb
+
+EOF
+   test_cmp expect out
+'
+
 iconvfromutf8toiso88591() {
printf "%s" "$*" | iconv -f UTF-8 -t ISO8859-1
 }
-- 
1.8.1.rc1.2.gfb98a3a

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

[PATCH 0/2] Re: [PATCH] shortlog: Fix wrapping lines of wraplen

[Steffen Prohaska]

On Dec 9, 2012, at 10:36 AM, Junio C Hamano  wrote:

> Steffen Prohaska  writes:
> 
> > A recent commit [1] fixed a off-by-one wrapping error.  As
> > a side-effect, add_wrapped_shortlog_msg() needs to be changed to always
> > append a newline.
> 
> Could you clarify "As a side effect" a bit more?  Do you mean
> something like this?

See updated patches below.

Steffen

Steffen Prohaska (2):
  shortlog: Fix wrapping lines of wraplen (was broken since recent
off-by-one fix)
  strbuf_add_wrapped*(): Remove unused return value

 builtin/shortlog.c  |  5 ++---
 t/t4201-shortlog.sh | 24 
 utf8.c  | 13 ++---
 utf8.h  |  4 ++--
 4 files changed, 34 insertions(+), 12 deletions(-)

-- 
1.8.1.rc1.2.gfb98a3a

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