Re: [PATCH 04/19] reset: don't allow "git reset -- $pathspec" in bare repo

On Wed, Jan 9, 2013 at 11:32 AM, Junio C Hamano wrote: > Martin von Zweigbergk writes: > >> --- >> builtin/reset.c | 6 -- >> 1 file changed, 4 insertions(+), 2 deletions(-) > > With the patch that does not have any explicit check for bareness > nor new error message to scold user with, it i

Re: [PATCH 06/19] reset.c: remove unnecessary variable 'i'

On Wed, Jan 9, 2013 at 11:39 AM, Junio C Hamano wrote: > Martin von Zweigbergk writes: > >> Throughout most of parse_args(), the variable 'i' remains at 0. In the >> remaining few cases, we can do pointer arithmentic on argv itself >> instead. >> --- >> This is clearly mostly a matter of taste. T

Re: [PATCH 08/19] reset.c: share call to die_if_unmerged_cache()

On Wed, Jan 9, 2013 at 11:48 AM, Junio C Hamano wrote: > Martin von Zweigbergk writes: > >> Use a single condition to guard the call to die_if_unmerged_cache for >> both --soft and --keep. This avoids the small distraction of the >> precondition check from the logic following it. >> >> Also chang

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

> I think the code before this patch used to say "Would not remove" > and "Not removing" in certain cases to report the paths that the > command decided not to remove, but after this patch these two > messages no longer appear in the patch. > > Is it expected, are we losing information, or...? > I

Re: [RFC/PATCH] avoid SIGPIPE warnings for aliases

On Wed, Jan 09, 2013 at 01:49:41PM -0800, Junio C Hamano wrote: > Jeff King writes: > > > But we still say "error: ... died of signal 13", because that comes from > > inside wait_or_whine. So it is a separate issue whether or not > > wait_or_whine should be silent on SIGPIPE (we already are on S

Re: [PATCH 03/19] reset.c: pass pathspec around instead of (prefix, argv) pair

On Thu, Jan 10, 2013 at 2:26 AM, Junio C Hamano wrote: > Martin von Zweigbergk writes: > >> We use the path arguments in two places in reset.c: in >> interactive_reset() and read_from_tree(). Both of these call >> get_pathspec(), so we pass the (prefix, arv) pair to both >> functions. Move the ca

about vim contrib support

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi. In the contrib/vim/README file there are instructions about how to setup git support with Vim builtin git syntax files. However these instructions seems to be redundant, since the system filetype.vim file already have the autocmd rules. The only

Re: [RFC/PATCH] avoid SIGPIPE warnings for aliases

On Wed, Jan 09, 2013 at 04:18:44PM -0800, Jonathan Nieder wrote: > > Do we know if we are upstream of a pager that reads from us through > > a pipe (I think we should, especially in a case where we are the one > > who processed the "git -p $alias" option)? Is there any other case > > where we wou

Re: about vim contrib support

On Thu, Jan 10, 2013 at 12:17:31PM +0100, Manlio Perillo wrote: > In the contrib/vim/README file there are instructions about how to setup > git support with Vim builtin git syntax files. > > However these instructions seems to be redundant, since the system > filetype.vim file already have the a

Re: about vim contrib support

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 10/01/2013 12:39, Jeff King ha scritto: > On Thu, Jan 10, 2013 at 12:17:31PM +0100, Manlio Perillo wrote: > >> In the contrib/vim/README file there are instructions about how to setup >> git support with Vim builtin git syntax files. >> >> However

[PATCH v2 0/2] improve-wincred-compatibility

Changes since initial version (see attached diff for details): - split in two patches - removed unused variables - improved the dll error message - changed ?: to if else - added comments Also available here: https://github.com/kblees/git/tree/kb/improve-wincred-compatibility-v2 git pull git://gith

[PATCH v2 1/2] wincred: accept CRLF on stdin to simplify console usage

The windows credential helper currently only accepts LF on stdin, but bash and cmd.exe both send CRLF. This prevents interactive use in the console. Change the stdin parser to optionally accept CRLF. Signed-off-by: Karsten Blees --- contrib/credential/wincred/git-credential-wincred.c | 7 +-

[PATCH v2 2/2] wincred: improve compatibility with windows versions

On WinXP, the windows credential helper doesn't work at all (due to missing Cred[Un]PackAuthenticationBuffer APIs). On Win7, the credential format used by wincred is incompatible with native Windows tools (such as the control panel applet or 'cmdkey.exe /generic'). These Windows tools only set the

[PATCH] git-commit-tree(1): correct description of defaults

The old phrasing indicated that the EMAIL environment variable takes precedence over the user.email configuration setting, but it is the other way around. Signed-off-by: Peter Eisentraut --- Documentation/git-commit-tree.txt |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --gi

Re: about vim contrib support

On Thu, Jan 10, 2013 at 12:51:18PM +0100, Manlio Perillo wrote: > .patch files are handled by diff highlight. > What I would like to do is to use gitcommit syntax highlight, in order > to also enable commit subject message hightlight. Using the regular gitcommit highlighter would not make sense,

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

Zoltan Klinger writes: >> I think the code before this patch used to say "Would not remove" >> and "Not removing" in certain cases to report the paths that the >> command decided not to remove, but after this patch these two >> messages no longer appear in the patch. >> >> Is it expected, are we

[PATCHv3] commit: make default of "cleanup" option configurable

The default of the "cleanup" option in "git commit" is not configurable. Users who don't want to use the default have to pass this option on every commit since there's no way to configure it. This commit introduces a new config option "commit.cleanup" which can be used to change the default of the

Re: t7400 broken on pu (Mac OS X)

Duy Nguyen writes: > On Wed, Jan 09, 2013 at 07:43:03PM +0100, Torsten Bögershausen wrote: >> The current pu fails on Mac OS, case insensitive FS. >> >> >> Bisecting points out >> commit 3f28e4fafc046284657945798d71c57608bee479 >> [snip] >> Date: Sun Jan 6 13:21:07 2013 +0700 >> >> Conve

Re: [PATCH 04/19] reset: don't allow "git reset -- $pathspec" in bare repo

Martin von Zweigbergk writes: > ... Fix by moving > the branching point after the check. OK, that is what I missed. We have an existing check for mixed reset, which was originally meant to handle case without any pathspec but can use the same error condition (i.e. type is mixed and repo

Re: [PATCH] git-commit-tree(1): correct description of defaults

Peter Eisentraut writes: > The old phrasing indicated that the EMAIL environment variable takes > precedence over the user.email configuration setting, but it is the > other way around. > > Signed-off-by: Peter Eisentraut > --- It could be argued that the observed behaviour is a bug, by the way

Re: t7400 broken on pu (Mac OS X)

On 10.01.13 18:58, Junio C Hamano wrote: > Duy Nguyen writes: > >> On Wed, Jan 09, 2013 at 07:43:03PM +0100, Torsten Bögershausen wrote: >>> The current pu fails on Mac OS, case insensitive FS. >>> >>> >>> Bisecting points out >>> commit 3f28e4fafc046284657945798d71c57608bee479 >>> [snip] >>> Date

Re* [PATCH] commit: make default of "cleanup" option configurable

Junio C Hamano writes: > I also wonder, as a longer term alternative (which would require a > lot of code auditing and some refactoring), if it is useful to have > an option and/or configuration that lets you configure the "comment > in log message editor" character from the default "#" to someth

Re: [RFC/PATCH] avoid SIGPIPE warnings for aliases

Jeff King writes: > Maybe the right rule is "if we are using the shell to execute, do not > mention SIGPIPE"? It seems a little iffy at first, but: > > 1. It tends to coincide with direct use of internal tools versus > external tools. > > 2. We do not reliably get SIGPIPE there, anyway,

[PATCH] contrib/vim: simplify instructions for old vim support

Rely on the upstream filetype.vim instead of duplicating its rules in git's instructions for syntax highlighting support on pre-7.2 vim versions. The result is a shorter contrib/vim/README. More importantly, it lets us punt on maintenance of the autocmd rules. So now when we fix the upstream git

Re: [PATCH] t0008: avoid brace expansion

Am 10.01.2013 01:18, schrieb Junio C Hamano: > Adam Spiers writes: > >> On Wed, Jan 9, 2013 at 11:49 PM, René Scharfe >> wrote: >>> Brace expansion is not required by POSIX and not supported by dash nor >>> NetBSD's sh. Explicitly list all combinations instead. >> >> Good catch, thanks! > > Ye

Re: [PATCH] contrib/vim: simplify instructions for old vim support

On Thu, Jan 10, 2013 at 12:54:27PM -0800, Jonathan Nieder wrote: > Rely on the upstream filetype.vim instead of duplicating its rules in > git's instructions for syntax highlighting support on pre-7.2 vim > versions. > > The result is a shorter contrib/vim/README. More importantly, it lets > us

Re: [PATCH v2 01/10] string-list: allow case-insensitive string list

Am 08.01.2013 01:10, schrieb Junio C Hamano: > Some string list needs to be searched case insensitively, and for > that to work correctly, the string needs to be sorted case > insensitively from the beginning. > > Allow a custom comparison function to be defined on a string list > instance and use

Re: [RFC/PATCH] avoid SIGPIPE warnings for aliases

On Thu, Jan 10, 2013 at 12:22:49PM -0800, Junio C Hamano wrote: > Jeff King writes: > > > Maybe the right rule is "if we are using the shell to execute, do not > > mention SIGPIPE"? It seems a little iffy at first, but: > > > > 1. It tends to coincide with direct use of internal tools versus >

Re: [RFC/PATCH] avoid SIGPIPE warnings for aliases

Am 10.01.2013 21:22, schrieb Junio C Hamano: > Jeff King writes: > >> Maybe the right rule is "if we are using the shell to execute, do not >> mention SIGPIPE"? It seems a little iffy at first, but: >> >> 1. It tends to coincide with direct use of internal tools versus >> external tools. >

Re: [RFC/PATCH] avoid SIGPIPE warnings for aliases

Johannes Sixt writes: > The interesting cases are when git reads back the output of the command. > Here, a SIGPIPE death of the child would indicate a bug in git, I think, > and some diagnostic would be worth it. But we can just as well declare > that git doesn't have bugs ;) > > These are the in

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

(1) Only print out the names of the files and directories that got actually deleted. Also do not mention that we are not removing directories when the user did not ask us to do so with '-d'. (2) Show ignore message for skipped untracked git repositories. Consider the following repo layout:

Re: [PATCH] contrib/vim: simplify instructions for old vim support

Jeff King wrote: > On Thu, Jan 10, 2013 at 12:54:27PM -0800, Jonathan Nieder wrote: >> Rely on the upstream filetype.vim instead of duplicating its rules in >> git's instructions for syntax highlighting support on pre-7.2 vim >> versions. [...] > Yeah, I think this makes sense. I'd be fine with re

Re: [PATCH 03/19] reset.c: pass pathspec around instead of (prefix, argv) pair

Duy Nguyen writes: > On Thu, Jan 10, 2013 at 2:26 AM, Junio C Hamano wrote: >> Martin von Zweigbergk writes: >> >>> We use the path arguments in two places in reset.c: in >>> interactive_reset() and read_from_tree(). Both of these call >>> get_pathspec(), so we pass the (prefix, arv) pair to bo

Re: bugreport: stgit cannot export empty patch

Junio C Hamano writes: > Stepan Koltsov writes: >> stgit fails to export empty patches: >> >> % stg new empty-patch -m 'asasas' >> Now at patch "empty-patch" >> % stg export empty-patch >> Checking for changes in the working directory ... done >> fatal: unrecognized input >> stg

Re: [PATCH 02/21] Add parse_pathspec() that converts cmdline args to struct pathspec

On Sat, Jan 5, 2013 at 10:20 PM, Nguyễn Thái Ngọc Duy wrote: > + > + /* No arguments, no prefix -> no pathspec */ > + if (!entry && !prefix) > + return; > > + /* No arguments with prefix -> prefix pathspec */ When working with the old get_pathspec(), I remember won

[PATCH] minor diff between gitweb docs and actual template for $GIT/description

The documentation for gitweb gives one description of the default content for the $GIT/description, the description template has other text. One of these two patches should be applied to bring them into order (applying both would just reverse the problem). Or, both could be changed to the sam

Re: [PATCH] minor diff between gitweb docs and actual template for $GIT/description

(+cc: Jakub, who maintains gitweb) Hi Tim, Tim Chase wrote: > The documentation for gitweb gives one description of the default > content for the $GIT/description, the description template has other > text. One of these two patches should be applied to bring them into > order (applying both woul

Re: [PATCH 02/21] Add parse_pathspec() that converts cmdline args to struct pathspec

On Fri, Jan 11, 2013 at 6:26 AM, Martin von Zweigbergk wrote: > On Sat, Jan 5, 2013 at 10:20 PM, Nguyễn Thái Ngọc Duy > wrote: >> + >> + /* No arguments, no prefix -> no pathspec */ >> + if (!entry && !prefix) >> + return; >> >> + /* No arguments with prefix -> pr

[PATCH v2] clone: forbid --bare --separate-git-dir

The --separate-git-dir option was introduced to make it simple to put the git directory somewhere outside the worktree, for example when cloning a repository for use as a submodule. It was not intended for use when creating a bare repository. In that case there is no worktree and it is more natura

Re: [PATCH v2] clone: forbid --bare --separate-git-dir

Thanks. -- 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] fetch, upload-pack: add --no-shallow for infinite depth

The user can do --depth=2147483647 (*) for infinite depth now. But it's hard to remember. Any other numbers larger than the longest commit chain in the repository would also do, but some guessing may be involved. Make easy-to-remember --no-shallow an alias for --depth=2147483647. Make upload-pack

[PATCH 2/2] upload-pack: fix off-by-one depth calculation in shallow clone

get_shallow_commits() is used to determine the cut points at a given depth (i.e. the number of commits in a chain that the user likes to get). However we count current depth up to the commit "commit" but we do the cutting at its parents (i.e. current depth + 1). This makes upload-pack always return

[PATCH] cvsimport: rewrite to use cvsps 3.x to fix major bugs

From: "Eric S. Raymond" The combination of git-cvsimport and cvsps had serious problems. Among these were: (1) Analysis of branchy repos was buggy in multiple ways in both programs, leading to incorrect repo translations. (2) Even after a correct branch analysis, extra (redundant) fileo

Suggestion: add option in git-p4 to preserve user in Git repository

Hi, I'm in a situation where I don't have P4 admin rights to use the --preserve-user option of git-p4. However, I would like to keep user information in the associated Git branch. Would it be possible to add an option for this? Thanks, -=- Olivier -- To unsubscribe from this list: send the line

Re: [PATCH 1/2] fetch, upload-pack: add --no-shallow for infinite depth

Nguyễn Thái Ngọc Duy writes: > The user can do --depth=2147483647 (*) for infinite depth now. But > it's hard to remember. Any other numbers larger than the longest > commit chain in the repository would also do, but some guessing may > be involved. Make easy-to-remember --no-shallow an alias fo

Re: [PATCH] minor diff between gitweb docs and actual template for $GIT/description

On 01/10/13 20:22, Jonathan Nieder wrote: (+cc: Jakub, who maintains gitweb) Hi Tim, Tim Chase wrote: The documentation for gitweb gives one description of the default content for the $GIT/description, the description template has other text. One of these two patches should be applied to brin

Re: [PATCH 2/2] upload-pack: fix off-by-one depth calculation in shallow clone

Nguyễn Thái Ngọc Duy writes: > get_shallow_commits() is used to determine the cut points at a given > depth (i.e. the number of commits in a chain that the user likes to > get). However we count current depth up to the commit "commit" but we > do the cutting at its parents (i.e. current depth +

[PATCH 0/3] fixup remaining cvsimport tests

These patchs apply on top of of Eric Raymond's cvsimport patch. 7 of 15 tests in t9600 fail, one of which is fixed w/ a cvsps patch I've sent to Eric (fixes revision map.) It no longer uses "origin" as the default branch which I suspect is a problem for at least some of the remaining tests. Both

[PATCH 1/3] t/lib-cvs.sh: allow cvsps version 3.x.

--- t/lib-cvs.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/t/lib-cvs.sh b/t/lib-cvs.sh index 44263ad..b55e861 100644 --- a/t/lib-cvs.sh +++ b/t/lib-cvs.sh @@ -15,7 +15,7 @@ export CVS cvsps_version=`cvsps -h 2>&1 | sed -ne 's/cvsps version //p'` case "$cvsps_version"

[PATCH 2/3] t9600: fixup for new cvsimport

--- t/t9600-cvsimport.sh | 10 -- 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/t/t9600-cvsimport.sh b/t/t9600-cvsimport.sh index 4c384ff..14f54d5 100755 --- a/t/t9600-cvsimport.sh +++ b/t/t9600-cvsimport.sh @@ -44,7 +44,7 @@ EOF test_expect_success PERL 'import a trivia

[PATCH 3/3] t9604: fixup for new cvsimport

--- t/t9604-cvsimport-timestamps.sh | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/t/t9604-cvsimport-timestamps.sh b/t/t9604-cvsimport-timestamps.sh index 1fd5142..b1629b6 100755 --- a/t/t9604-cvsimport-timestamps.sh +++ b/t/t9604-cvsimport-timestamps.sh @@ -7,8 +7,7 @@ s

Re: Turning a complete repository to a shallow one

Duy Nguyen writes: > Apparently we could do it: > > git clone --single-branch git.git > cd git > git tag -l|xargs git tag -d > git fetch --depth=1 origin master > git repack -ad I may have been unclear in the earlier message, but this is one of the reasons why I think "fetch --depth" is misadver

Re: [PATCH 09/19] reset.c: replace switch by if-else

On Wed, Jan 9, 2013 at 11:53 AM, Junio C Hamano wrote: > Martin von Zweigbergk writes: > >> --- >> builtin/reset.c | 13 +++-- >> 1 file changed, 3 insertions(+), 10 deletions(-) >> >> diff --git a/builtin/reset.c b/builtin/reset.c >> index 42d1563..05ccfd4 100644 >> --- a/builtin/reset.

Fwd: git checkout doesn't work?

This is my session on Win7 x64: Microsoft Windows [Version 6.1.7601] (c) Корпорация Майкрософт (Microsoft Corp.), 2009. Все права защищены. C:\Dropbox\Dropbox\Wesnoth\Apocryphs>cd Apokryphs.Orks C:\Dropbox\Dropbox\Wesnoth\Apocryphs\Apokryphs.Orks>git status # On branch master # Your branch is beh

git checkout bug on Win7 x64

This is my session on Win7 x64: Microsoft Windows [Version 6.1.7601] (c) Корпорация Майкрософт (Microsoft Corp.), 2009. Все права защищены. C:\Dropbox\Dropbox\Wesnoth\Apocryphs>cd Apokryphs.Orks C:\Dropbox\Dropbox\Wesnoth\Apocryphs\Apokryphs.Orks>git status # On branch master # Your branch is beh