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

2012-12-10 Thread 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 missin

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

2012-12-10 Thread 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 >>>

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

2012-12-10 Thread 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

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

2012-12-10 Thread 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 falli

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

2012-12-10 Thread 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

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

2012-12-10 Thread 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 slight

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

2012-12-10 Thread 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 a

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

2012-12-10 Thread 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

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

2012-12-10 Thread 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 -=

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

2012-12-10 Thread 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 20

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

2012-12-10 Thread 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) r

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

2012-12-10 Thread 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

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

2012-12-10 Thread 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.

Re: Use of a mailmap file with git-log

2012-12-10 Thread 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 s

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

2012-12-10 Thread 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

Re: Use of a mailmap file with git-log

2012-12-10 Thread 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 custo

Re: Use of a mailmap file with git-log

2012-12-10 Thread 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 auth

Re: Use of a mailmap file with git-log

2012-12-10 Thread 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 "rea

Re: Use of a mailmap file with git-log

2012-12-10 Thread 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/committer

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

2012-12-10 Thread 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 Ha

Re: Millisecond precision in timestamps?

2012-12-10 Thread 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,

[ANNOUNCE] Git v1.8.0.2

2012-12-10 Thread 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 6b9e14c5b19b2e27605014252febd61a7

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

2012-12-10 Thread 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 th

A note from the maintainer

2012-12-10 Thread 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

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

2012-12-10 Thread 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 imaginin

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

2012-12-10 Thread 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

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

2012-12-10 Thread 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_wrapp

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

2012-12-10 Thread 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?