On Wed, Jan 9, 2013 at 11:32 AM, Junio C Hamano gits...@pobox.com wrote:
Martin von Zweigbergk martinv...@gmail.com 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
On Wed, Jan 9, 2013 at 11:48 AM, Junio C Hamano gits...@pobox.com wrote:
Martin von Zweigbergk martinv...@gmail.com 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
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 do not
On Wed, Jan 09, 2013 at 01:49:41PM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net 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 Thu, Jan 10, 2013 at 2:26 AM, Junio C Hamano gits...@pobox.com wrote:
Martin von Zweigbergk martinv...@gmail.com 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
-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
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 would want
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
-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 these
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
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 bl...@dcon.de
---
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
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 pe...@eisentraut.org
---
Documentation/git-commit-tree.txt |4 ++--
1 file changed, 2 insertions(+), 2
Zoltan Klinger zoltan.klin...@gmail.com 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
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
Duy Nguyen pclo...@gmail.com 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
Martin von Zweigbergk martinv...@gmail.com 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.
Peter Eisentraut pe...@eisentraut.org 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 pe...@eisentraut.org
---
It could be argued that the
On 10.01.13 18:58, Junio C Hamano wrote:
Duy Nguyen pclo...@gmail.com 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
Junio C Hamano gits...@pobox.com 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 #
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
Am 10.01.2013 01:18, schrieb Junio C Hamano:
Adam Spiers g...@adamspiers.org writes:
On Wed, Jan 9, 2013 at 11:49 PM, René Scharfe
rene.scha...@lsrfire.ath.cx wrote:
Brace expansion is not required by POSIX and not supported by dash nor
NetBSD's sh. Explicitly list all combinations
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 punt
On Thu, Jan 10, 2013 at 12:22:49PM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net 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
Am 10.01.2013 21:22, schrieb Junio C Hamano:
Jeff King p...@peff.net 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.
Johannes Sixt j...@kdbg.org 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
(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
Duy Nguyen pclo...@gmail.com writes:
On Thu, Jan 10, 2013 at 2:26 AM, Junio C Hamano gits...@pobox.com wrote:
Martin von Zweigbergk martinv...@gmail.com writes:
We use the path arguments in two places in reset.c: in
interactive_reset() and read_from_tree(). Both of these call
Junio C Hamano writes:
Stepan Koltsov lt;stepan.koltsov@gt; 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 export: git
On Sat, Jan 5, 2013 at 10:20 PM, Nguyễn Thái Ngọc Duy pclo...@gmail.com 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
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
(+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 would
On Fri, Jan 11, 2013 at 6:26 AM, Martin von Zweigbergk
martinv...@gmail.com wrote:
On Sat, Jan 5, 2013 at 10:20 PM, Nguyễn Thái Ngọc Duy pclo...@gmail.com
wrote:
+
+ /* No arguments, no prefix - no pathspec */
+ if (!entry !prefix)
+ return;
+ /* No
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
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
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
From: Eric S. Raymond e...@thyrsus.com
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
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
Nguyễn Thái Ngọc Duy pclo...@gmail.com 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
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
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
---
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
---
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 @@
Duy Nguyen pclo...@gmail.com 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
On Wed, Jan 9, 2013 at 11:53 AM, Junio C Hamano gits...@pobox.com wrote:
Martin von Zweigbergk martinv...@gmail.com 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
This is my session on Win7 x64:
Microsoft Windows [Version 6.1.7601]
(c) Корпорация Майкрософт (Microsoft Corp.), 2009. Все права защищены.
C:\Dropbox\Dropbox\Wesnoth\Apocryphscd Apokryphs.Orks
C:\Dropbox\Dropbox\Wesnoth\Apocryphs\Apokryphs.Orksgit status
# On branch master
# Your branch is
This is my session on Win7 x64:
Microsoft Windows [Version 6.1.7601]
(c) Корпорация Майкрософт (Microsoft Corp.), 2009. Все права защищены.
C:\Dropbox\Dropbox\Wesnoth\Apocryphscd Apokryphs.Orks
C:\Dropbox\Dropbox\Wesnoth\Apocryphs\Apokryphs.Orksgit status
# On branch master
# Your branch is
47 matches
Mail list logo
