Re: [PATCH] pack-objects: name pack files after trailer hash

2013-12-15 Thread Michael Haggerty
On 12/05/2013 09:28 PM, Jeff King wrote: > [...] > This patch simply uses the pack trailer sha1 as the pack > name. It should be similarly unique, but covers the exact > representation of the objects. Other parts of git should not > care, as the pack name is returned by pack-objects and is > essent

Re: [PATCH v2 02/21] path.c: rename vsnpath() to git_vsnpath()

2013-12-15 Thread Duy Nguyen
On Mon, Dec 16, 2013 at 4:13 AM, Ramsay Jones wrote: -static char *vsnpath(char *buf, size_t n, const char *fmt, va_list args) +static char *git_vsnpath(char *buf, size_t n, const char *fmt, va_list args) >>> >>> :-D I renamed this _from_ git_vsnpath() in commit 5b3b8fa2 ("path.c:

Re: What's cooking in git.git (Dec 2013, #03; Thu, 12)

2013-12-15 Thread Junio C Hamano
Junio C Hamano writes: > [Stalled] > > * nv/commit-gpgsign-config (2013-11-06) 1 commit > - Add the commit.gpgsign option to sign all commits > > Introduce commit.gpgsign configuration variable to force every > commit to be GPG signed. > > Needs tests, perhaps? Besides, we would need at leas

Re: [PATCH v2 02/21] path.c: rename vsnpath() to git_vsnpath()

2013-12-15 Thread Ramsay Jones
On 15/12/13 02:25, Duy Nguyen wrote: > On Sun, Dec 15, 2013 at 3:23 AM, Ramsay Jones > wrote: >> On 14/12/13 10:54, Nguyễn Thái Ngọc Duy wrote: >>> This is the underlying implementation of git_path(), git_pathdup() and >>> git_snpath() which will prefix $GIT_DIR in the result string. Put git_ >>>

Re: Unexpected cherry-pick behaviour

2013-12-15 Thread Philip Oakley
From: "Junio C Hamano" , Saturday, December 14, 2013 7:39 PM "Philip Oakley" writes: Would this be a good use of the * Magic pathspecs like ":(icase) that was recently released (v1.8.5 2Dec13) so that the merge stages can be named. Because the pathspec mechahism is for you to tell an op

Re: [PATCH v2 01/21] path.c: avoid PATH_MAX as buffer size from get_pathname()

2013-12-15 Thread Antoine Pelisse
On Sun, Dec 15, 2013 at 10:02 AM, Duy Nguyen wrote: > On Sun, Dec 15, 2013 at 3:35 PM, Torsten Bögershausen wrote: >> If we really want to go away from PATH_MAX, is a hard-coded value of 4096 so >> attractive ? >> Because we can either >> >> a) Re-define PATH_MAX in git-compat-util.h >> b) Use a

Re: [PATCH v2 01/21] path.c: avoid PATH_MAX as buffer size from get_pathname()

2013-12-15 Thread Duy Nguyen
On Sun, Dec 15, 2013 at 3:35 PM, Torsten Bögershausen wrote: > If we really want to go away from PATH_MAX, is a hard-coded value of 4096 so > attractive ? > Because we can either > > a) Re-define PATH_MAX in git-compat-util.h > b) Use an own #define in git-compat-util.h, like e.g. GIT_PATH_MAX >

Re: [PATCH v2 01/21] path.c: avoid PATH_MAX as buffer size from get_pathname()

2013-12-15 Thread Torsten Bögershausen
On 2013-12-14 11.54, Nguyễn Thái Ngọc Duy wrote: > We've been avoiding PATH_MAX whenever possible. This patch avoids > PATH_MAX in get_pathname() and gives it enough room not to worry about > really long paths. > > Signed-off-by: Nguyễn Thái Ngọc Duy > --- > path.c | 28 -