Hi,
I can no longer clone my git repository from v1.7 client, i get error: Trying
to write ref refs/heads/master with nonexistant object.
It is a remote repo that im using ssh to connect to, and i have done everything
i can find on google from creating a new master branch, cleaning up the
On Thu, Apr 11, 2013 at 3:56 AM, Jeff King p...@peff.net wrote:
On Thu, Apr 11, 2013 at 01:19:19AM +0200, Magnus Therning wrote:
Nope. I'm pretty sure this had *nothing* to do with my config. This
is the original config, which doesn't work:
$HTTP[url] =~ ^/git {
cgi.assign = ( = )
On Thu, Apr 11, 2013 at 5:32 AM, Jeff King p...@peff.net wrote:
When the http-backend is set up to allow anonymous read but
authenticated write, the http-backend manual suggests
catching only the /git-receive-pack POST of the packfile,
not the initial info/refs?service=git-receive-pack GET in
Hello,
I am not sure this is the right place to ask this. If it isn't I would
be grateful if you could help me find the best place to do it.
I am trying to push some files to a server with git push. I have
configured the server to push the files:
git remote set-url test
Jeff King wrote:
$ git clone https://github.com/upstream/project.git
$ cd project
$ hack hack hack; commit commit commit
$ git tag -m 'something of note' my-tag
$ git remote add me https://github.com/me/project.git
$ git config branch.master.remote me
$ git tag -m 'something
On Wed, Apr 10, 2013 at 4:40 PM, Jeremy Rosen jeremy.ro...@openwide.fr wrote:
is there some way to know how far you are within a rebase when the rebase is
interupted by a conflict other than the message given by git rebase when it
was interrupted ?
How about
$ cat .git/rebase-merge/done
Ramkumar Ramachandra wrote:
- branch.implicit-push-next.pushremote set to null**, because I will
never want to push this branch.
Currently, I have a hacky workaround: I set
branch.implicit-push-next.pushremote to a remote that I don't have
write access to (ie. origin), effectively failing all
On Thu, 2013-04-11 at 01:42 -0400, Jeff King wrote:
On Thu, Apr 11, 2013 at 05:39:43AM +0200, Mike Galbraith wrote:
ALLOWED_ENV=PATH HOME
HOME=/
I can work around it by changing the init script to use su - git -c bla
bla to launch the thing, instead of using --user=git
Jens Lehmann wrote:
When moving a submodule which uses a gitfile to point to the git directory
stored in .git/modules/name of the superproject two changes must be made
to make the submodule work: the .git file and the core.worktree setting
must be adjusted to point from work tree to git
Jens Lehmann wrote:
Currently the attempt to use git mv on a submodule errors out with:
fatal: source directory is empty, source=src, destination=dest
The reason is that mv searches for the submodule with a trailing slash in
the index, which it doesn't find (because it is stored without a
On Thu, 11 Apr 2013 07:49:44 +0100
João Joyce joao.jo...@netcabo.pt wrote:
[...]
but I am getting the following error:
git send-pack: protocol error: bad band #50
fatal: The remote end hung up unexpectedly
It seems that something is failing on the remote side but I can't
find
When a single argument was a non-commit, the error message used to be:
fatal: BUG: expected exactly one commit from walk
For multiple arguments, when none of the arguments was a commit, the error was:
fatal: empty commit set passed
Finally, when some of the arguments were
Jens Lehmann wrote:
Currently using git mv on a submodule moves the submodule's work tree in
that of the superproject.
It's not Currently: it's the result of your last two patches. The
wording is very unclear. Perhaps: As a result of the last two patches
in this series, a 'git mv' moves the
Benoit Bourbie wrote:
I apologize for being picky
There's nothing to apologize for. These are good catches worth fixing.
but that patch fixes 3 typos.
Please read Documentation/SubmittingPatches, particularly the parts about:
1. Sending patches inline using git send-email, as opposed to an
Hi,
Thanks for the reply.
Can you tell us what command you ran, and also try to get a readable
backtrace from your installation?
The crash is happening only when the users are trying to do a clone. I
was monitoring from the htop when triggering a clone operation, all
the cores of the
Miklos Vajna wrote:
When a single argument was a non-commit, the error message used to be:
fatal: BUG: expected exactly one commit from walk
For multiple arguments, when none of the arguments was a commit, the error
was:
fatal: empty commit set passed
Finally, when some
Hi,
I noticed that code that you put in merge will not be visible by
default. This seems like a pretty horrible security problem, no?
I made the following test tree, with just 3 commits:
https://github.com/johnflux/ExampleEvilness.git
Doing git log -p shows all very innocent commits.
On Thu, Apr 11, 2013 at 01:31:45AM -0400, Jeff King wrote:
On Thu, Apr 11, 2013 at 02:59:32AM +0100, Adam Spiers wrote:
@@ -111,14 +110,11 @@ static int check_ignore_stdin_paths(struct
path_exclude_check check, const char
die(line is badly quoted);
On Thu, Apr 11, 2013 at 03:52:44PM +0530, Ramkumar Ramachandra
artag...@gmail.com wrote:
+ for (i = 0; i opts-revs-pending.nr; i++) {
+ unsigned char sha1[20];
+ const char *name = opts-revs-pending.objects[i].name;
+
+ if
On Thu, Apr 11, 2013 at 01:25:53AM -0400, Jeff King wrote:
On Thu, Apr 11, 2013 at 02:59:31AM +0100, Adam Spiers wrote:
-static int check_ignore(const char *prefix, const char **pathspec)
+static int check_ignore(struct path_exclude_check check,
+ const char *prefix, const
On Thu, Apr 11, 2013 at 02:59:32AM +0100, Adam Spiers wrote:
+test_expect_success STDBUF 'streaming support for --stdin' '
+ (
+ echo one
+ sleep 2
+ echo two
+ ) | stdbuf -oL git check-ignore -v -n --stdin out
I just noticed that this patch
Miklos Vajna wrote:
I guess that is a should-not-happen category. parse_args() calls
setup_revisions(), and that will already die() if the argument is not a
valid object at all.
Then why do you have an if() guarding the code? In my opinion, you
should have an else-clause that die()s with an
The expected contents of STDOUT for the final --stdin tests can be
derived from the expected contents of STDOUT for the same tests when
--verbose is given, in the same way that test_expect_success_multi
derives this for earlier tests.
Signed-off-by: Adam Spiers g...@adamspiers.org
---
Initialisation of the dir_struct and path_exclude_check structs was
previously done within check_ignore(). This was acceptable since
check_ignore() was only called once per check-ignore invocation;
however the next commit will convert it into an inner loop which is
called once per line of STDIN
If `-n` or `--non-matching` are specified, non-matching pathnames will
also be output, in which case all fields in each output record except
for pathname will be empty. This can be useful when running
check-ignore as a background process, so that files can be
incrementally streamed to STDIN, and
Some callers, such as the git-annex web assistant, find it useful to
invoke git check-ignore as a persistent background process, which can
then have queries fed to its STDIN at any point, and the corresponding
response consumed from its STDOUT. For this we need to invoke
check_ignore() once per
check-attr and check-ignore have the potential to deadlock callers
which do not read back the output in real-time. For example, if a
caller writes N paths out and then reads N lines back in, it risks
becoming blocked on write() to check-*, and check-* is blocked on
write back to the caller.
Hi,
This is a reroll of the previous series due to a few minor issues. As the
previous version, forced pushes remain a configuration option. Also, I picked
up a fix for test regarding hg_log() that was sent to the mailing list.
Antoine Pelisse (1):
remote-hg: activate graphlog extension for
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-hg | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/contrib/remote-helpers/git-remote-hg
b/contrib/remote-helpers/git-remote-hg
index 328c2dc..d0dfb1e 100755
---
From: Dusty Phillips du...@linux.ca
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-hg | 4
1 file changed, 4 insertions(+)
diff --git a/contrib/remote-helpers/git-remote-hg
b/contrib/remote-helpers/git-remote-hg
index d0dfb1e..844ec50
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-hg | 1 +
1 file changed, 1 insertion(+)
diff --git a/contrib/remote-helpers/git-remote-hg
b/contrib/remote-helpers/git-remote-hg
index 844ec50..19eb4db 100755
---
From: Peter van Zetten peter.van.zet...@cgi.com
Set the maximum number of splits to make when dividing the diff stat
lines based on space characters.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-hg | 4 ++--
1 file changed, 2 insertions(+), 2
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-hg | 7 +++
contrib/remote-helpers/test-hg-bidi.sh | 1 +
contrib/remote-helpers/test-hg-hg-git.sh | 1 +
3 files changed, 9 insertions(+)
diff --git a/contrib/remote-helpers/git-remote-hg
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/test-hg-bidi.sh | 5 ++---
contrib/remote-helpers/test-hg-hg-git.sh | 3 +--
2 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/contrib/remote-helpers/test-hg-bidi.sh
Will be useful for remote bookmarks.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-hg | 39 +++-
1 file changed, 25 insertions(+), 14 deletions(-)
diff --git a/contrib/remote-helpers/git-remote-hg
No functional changes.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-hg | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/contrib/remote-helpers/git-remote-hg
b/contrib/remote-helpers/git-remote-hg
index
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-hg | 5 +
1 file changed, 5 insertions(+)
diff --git a/contrib/remote-helpers/git-remote-hg
b/contrib/remote-helpers/git-remote-hg
index 3ceec85..46cddc9 100755
---
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-hg | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/contrib/remote-helpers/git-remote-hg
b/contrib/remote-helpers/git-remote-hg
index 46cddc9..fc04f81 100755
---
From: Dusty Phillips du...@linux.ca
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-hg | 4
1 file changed, 4 insertions(+)
diff --git a/contrib/remote-helpers/git-remote-hg
b/contrib/remote-helpers/git-remote-hg
index fc04f81..ec599c6
Ideally we shouldn't do this, as it's not recommended in mercurial
documentation, but there's no other way to push multiple bookmarks (on
the same branch), which would be the behavior most similar to git.
At the same time, add a configuration option for the people that don't
want to risk creating
When cloning or pushing fails, we don't want to show a stack-trace.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-hg | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/contrib/remote-helpers/git-remote-hg
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/test-hg.sh | 35 +++
1 file changed, 35 insertions(+)
diff --git a/contrib/remote-helpers/test-hg.sh
b/contrib/remote-helpers/test-hg.sh
index 5f81dfa..62e3a47 100755
---
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/test-hg.sh | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/contrib/remote-helpers/test-hg.sh
b/contrib/remote-helpers/test-hg.sh
index 62e3a47..6a1e4b1 100755
---
The problem reportedly happened after doing a push that fails, the abort
causes the state of remote-hg to go bad, this happens because
remote-hg's marks are not stored, but 'git fast-export' marks are.
Ensure that the marks are _always_ stored.
Signed-off-by: Felipe Contreras
From: Simon Ruderich si...@ruderich.org
If set to true acts as hg's clone/pull --insecure option.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-hg | 9 +
1 file changed, 9 insertions(+)
diff --git a/contrib/remote-helpers/git-remote-hg
Mercurial allows absolute file paths, and Git doesn't like that.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-hg | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/contrib/remote-helpers/git-remote-hg
From: Simon Ruderich si...@ruderich.org
Signed-off-by: Simon Ruderich si...@ruderich.org
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-hg | 3 +++
1 file changed, 3 insertions(+)
diff --git a/contrib/remote-helpers/git-remote-hg
From: Antoine Pelisse apeli...@gmail.com
The hg_log() test helper uses the --graph parameter that is
implemented by the GraphLog extension. If the extension is not activated
by the user, the parameter is not available. Activate the extension in
setup().
Also changes the way we grep the output in
Mercurial emits messages like searching for changes, no changes
found, etc. meant for the use of its own UI layer, which break the pipe
between transport helper and remote helper.
Since there's no way to silence Mercurial, let's redirect to standard
error.
Signed-off-by: Felipe Contreras
When a single argument was a non-commit, the error message used to be:
fatal: BUG: expected exactly one commit from walk
For multiple arguments, when none of the arguments was a commit, the error was:
fatal: empty commit set passed
Finally, when some of the arguments were
On Thu, 11 Apr 2013 15:50:31 +0530
Sivaram Kannan siva.de...@gmail.com wrote:
[...]
Output of coredump gdb:
gitadmin@gitserver:/var/crash/dump$ gdb git CoreDump
GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU
On Wed, Apr 10, 2013 at 4:15 PM, Jeff King p...@peff.net wrote:
From: Felipe Contreras felipe.contre...@gmail.com
If a push fails because the remote-helper died (with
fast-export), the user does not see any error message. We do
correctly die with a failed exit code, as we notice that the
A 'git pull' without specifying a remote is asked to take the current
branch's upstream as the branch to merge from. This cannot work
without an upstream configuration nor with HEAD detached, but we only
check for this after fetching.
Perform the check beforehand, as we already know whether we
Miklos Vajna wrote:
Signed-off-by: Miklos Vajna vmik...@suse.cz
This one looks good. FWIW,
Reviewed-by: Ramkumar Ramachandra artag...@gmail.com
--
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
On 04/10/2013 09:44 PM, Junio C Hamano wrote:
Thanks.
My pleasure.
While removing that item from the configuration is a good thing to
do in the post 1.8.2.1 era, the reason why it is does not have much
to do with GMail is SSL capable.
Should I change the commit message in order to avoid
On Thu, Apr 11, 2013 at 6:36 PM, John Tapsell johnf...@gmail.com wrote:
I noticed that code that you put in merge will not be visible by
default. This seems like a pretty horrible security problem, no?
I made the following test tree, with just 3 commits:
On Wed, Apr 10, 2013 at 11:44:03AM -0700, Junio C Hamano wrote:
The reason why we can run with sslverify=true against gmail is
because we know imap.gmail.com gives a validly signed certificate
that leads all the way to a root CA the user's OpenSSL installation
is likely to trust (if your
Jeff King p...@peff.net writes:
On Thu, Apr 11, 2013 at 05:39:43AM +0200, Mike Galbraith wrote:
ALLOWED_ENV=PATH HOME
HOME=/
I can work around it by changing the init script to use su - git -c bla
bla to launch the thing, instead of using --user=git --group=daemon,
but that's just
On 04/11/2013 06:26 PM, Simon Ruderich wrote:
I think we should remove sslverify = false from the other example
as well. Recommending sslverify = false is IMHO a bad idea as
SSL provides no protection without verification.
Yep, that was why I thought there should be at least an example
On Thu, Apr 11, 2013 at 08:22:26AM -0500, Felipe Contreras wrote:
We
currently do so robustly when the helper uses the done
feature (and that is what we test). We cannot do so
reliably when the helper does not use the done feature,
but it is not even worth testing; the right solution
Ramkumar Ramachandra artag...@gmail.com writes:
Then rename() will move the submodule work tree just
like it moves a file.
What is this rename() function you're talking about? I don't see it anywhere.
man 2 rename; it is called from a generic part of builtin/mv.c to
rename one path to
W dniu 11.04.2013 03:56, Jeff King napisał:
So _if_ you fixed it by setting http.receivepack (which I think is the
simplest thing under Apache, since matching the query string there is
hard), then you would need a version of git with that fix on the
client side to actually have git prompt for
Ramkumar Ramachandra artag...@gmail.com writes:
Why does it search for a submodule with a trailing slash in the index?
You make it sound like it's doing something unnatural; in reality, it
does this because it executes lstat() on the filesystem path
specified, and the stat mode matches
W dniu 11.04.2013 05:36, Jeff King napisał:
+Note that unlike the similar setup with Apache, we can easily match the
+query string for receive-pack, catching the initial request from the
+client. This means that the server administrator does not have to worry
+about configuring
On Thu, Apr 11, 2013 at 11:18 AM, Jeff King p...@peff.net wrote:
On Thu, Apr 11, 2013 at 08:22:26AM -0500, Felipe Contreras wrote:
We
currently do so robustly when the helper uses the done
feature (and that is what we test). We cannot do so
reliably when the helper does not use the done
On Thu, Apr 11, 2013 at 11:49:11AM -0500, Felipe Contreras wrote:
I am OK with adding the test for import as a separate patch. What I am
not OK with (and this goes for the rest of the commit message, too) is
failing to explain any back-story at all for why the change is done in
the way it
Jens Lehmann jens.lehm...@web.de writes:
Currently using git mv on a submodule moves the submodule's work tree in
that of the superproject. But the submodule's path setting in .gitmodules
is left untouched, which is now inconsistent with the work tree and makes
git commands that rely on the
On Thu, Apr 11, 2013 at 06:47:49PM +0200, Jakub Narębski wrote:
W dniu 11.04.2013 05:36, Jeff King napisał:
+Note that unlike the similar setup with Apache, we can easily match the
+query string for receive-pack, catching the initial request from the
+client. This means that the server
Hi,
I'm currently struggeling with a strage behaviour of git-svn: After
git-svn-cloning a given repository (see attachment) in some cases the
git blame differs from the svn blame. The history looks like after a
merge all affected files have been added from scratch at this revision.
The behaviour
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
---
Documentation/RelNotes/1.8.2.1.txt | 2 +-
Documentation/RelNotes/1.8.3.txt | 8
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/Documentation/RelNotes/1.8.2.1.txt
b/Documentation/RelNotes/1.8.2.1.txt
On Thu, Apr 11, 2013 at 08:35:46AM -0700, Junio C Hamano wrote:
Yeah, I think the bug here is that git-daemon should be setting $HOME
when it switches privileges with --user. Does this patch fix it for you?
[...]
Yeah, that sounds like the obvious fix to me.
Here it is with a commit
On 09/04/2013 21:00, Kevin Bracey wrote:
So, how to automatically find a merge that ignored a known change?
I think I've found the problem. It only doesn't work _if you specify the
file_.
Specifically, if I was missing an addition, my first attempt to find it
would be
git log -p -m
Carlos Martín Nieto c...@elego.de writes:
I can't quite decide whether the behaviour of 'git pull' with no
upstream configured but a default remote with no fetch refspecs
merging the remote's HEAD is a feature, a bug or something in between,
but it's used by t7409 so maybe someone else is
If a push fails because the remote-helper died (with fast-export), the
user might not see any error message. So let's add one.
Suggested-by: Jeff King p...@peff.net
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
git-remote-testgit| 11 +++
Felipe Contreras felipe.contre...@gmail.com writes:
This is a reroll of the previous series due to a few minor issues. As the
previous version, forced pushes remain a configuration option. Also, I picked
up a fix for test regarding hg_log() that was sent to the mailing list.
Will replace the
On Thu, Apr 11, 2013 at 11:59 AM, Jeff King p...@peff.net wrote:
On Thu, Apr 11, 2013 at 11:49:11AM -0500, Felipe Contreras wrote:
I am OK with adding the test for import as a separate patch. What I am
not OK with (and this goes for the rest of the commit message, too) is
failing to
Adam Spiers g...@adamspiers.org writes:
diff --git a/Documentation/git-check-ignore.txt
b/Documentation/git-check-ignore.txt
index 7e3cabc..8e1f7ab 100644
--- a/Documentation/git-check-ignore.txt
+++ b/Documentation/git-check-ignore.txt
@@ -81,6 +81,11 @@ not. (Without this option, it
Jeff King wrote:
Here it is with a commit message.
-- 8 --
Subject: [PATCH] daemon: set HOME when we switch to --user
Thanks for taking care of it. For what it's worth,
Acked-by: Jonathan Nieder jrnie...@gmail.com
I'm not sure whether to keep 96b9e0e (config: treat user and xdg
config
On Thu, Apr 11, 2013 at 11:11:03AM -0700, Jonathan Nieder wrote:
-- 8 --
Subject: [PATCH] daemon: set HOME when we switch to --user
Thanks for taking care of it. For what it's worth,
Acked-by: Jonathan Nieder jrnie...@gmail.com
I'm not sure whether to keep 96b9e0e (config: treat
Jeff King wrote:
I could go either way. I think 96b9e0e is the right thing to do
conceptually, but I kind of doubt it was affecting all that many people.
And though it's _possible_ for it to be a security problem, I find it
much more likely that the site admin tries to set some config, gets
W dniu 11.04.2013 19:02, Jeff King napisał:
On Thu, Apr 11, 2013 at 06:47:49PM +0200, Jakub Narębski wrote:
W dniu 11.04.2013 05:36, Jeff King napisał:
+Note that unlike the similar setup with Apache, we can easily match the
+query string for receive-pack, catching the initial request from
On Thu, Apr 11, 2013 at 12:20:00PM +0100, Adam Spiers wrote:
On Thu, Apr 11, 2013 at 02:59:32AM +0100, Adam Spiers wrote:
+test_expect_success STDBUF 'streaming support for --stdin' '
+ (
+ echo one
+ sleep 2
+ echo two
+ ) | stdbuf -oL git
On Thu, Apr 11, 2013 at 12:05:11PM +0100, Adam Spiers wrote:
On Thu, Apr 11, 2013 at 01:25:53AM -0400, Jeff King wrote:
On Thu, Apr 11, 2013 at 02:59:31AM +0100, Adam Spiers wrote:
-static int check_ignore(const char *prefix, const char **pathspec)
+static int check_ignore(struct
Hello,
João Joyce wrote:
I am not sure this is the right place to ask this.
You're in the right place.
[...]
I am trying to push some files to a server with git push. I have
configured the server to push the files:
git remote set-url test ssh://u...@location.com:2200/fullpath/
but I
Ramkumar Ramachandra artag...@gmail.com writes:
Jens Lehmann wrote:
When moving a submodule which uses a gitfile to point to the git directory
stored in .git/modules/name of the superproject two changes must be made
to make the submodule work: the .git file and the core.worktree setting
must
Felipe Contreras felipe.contre...@gmail.com writes:
On Wed, Apr 10, 2013 at 4:15 PM, Jeff King p...@peff.net wrote:
From: Felipe Contreras felipe.contre...@gmail.com
If a push fails because the remote-helper died (with
fast-export), the user does not see any error message. We do
I agree
Felipe Contreras felipe.contre...@gmail.com writes:
On Thu, Apr 11, 2013 at 11:59 AM, Jeff King p...@peff.net wrote:
But I give up on you. I find most of your commit messages lacking in
details and motivation, making assumptions that the reader is as
familiar with the code when reading the
I tried running git p4 submit on a repo that I've been running as an
interim bridge between git and perforce. Multiple people are using the
repo as a remote and its being periodically submitted back to
perforce.
It's been working mostly fine. Then one day out of the blue I get this
error. I can
On Thu, Apr 11, 2013 at 01:05:12PM +0100, Adam Spiers wrote:
+test_expect_success 'setup: have stdbuf?' '
+ if which stdbuf /dev/null 21
+ then
+ test_set_prereq STDBUF
+ fi
+'
+
+test_expect_success STDBUF 'streaming support for --stdin' '
+ (
+
When the git directory is accessed through a symlink like
ln -s /tmp/git /tmp/git-symlink
cd /tmp/git-symlink/t
make -C .. ./t9903-bash-prompt.sh
$TRASH_DIRECTORY is /tmp/git-symlink/t/trash directory.t9903-bash-prompt
and $(pwd -P) is /tmp/git/t/trash directory.t9903-bash-prompt.
When
On Thu, Apr 11, 2013 at 08:53:22PM +0200, Torstein Hegge wrote:
When the git directory is accessed through a symlink like
ln -s /tmp/git /tmp/git-symlink
cd /tmp/git-symlink/t
make -C .. ./t9903-bash-prompt.sh
$TRASH_DIRECTORY is /tmp/git-symlink/t/trash
Kevin Bracey ke...@bracey.fi writes:
I think I've found the problem. It only doesn't work _if you specify
the file_.
Specifically, if I was missing an addition, my first attempt to find
it would be
git log -p -m -Saddition file
If the addition was lost in a merge, that doesn't even
On Thu, Apr 11, 2013 at 08:52:56AM +0200, Magnus Therning wrote:
The documentation should probably make the use of http.receivepack more
clear in this situation.
I think that'd be good. The fact that it wasn't until several mails
into the thread that anyone thought of the
Jeff King p...@peff.net writes:
On Thu, Apr 11, 2013 at 11:11:03AM -0700, Jonathan Nieder wrote:
-- 8 --
Subject: [PATCH] daemon: set HOME when we switch to --user
Thanks for taking care of it. For what it's worth,
Acked-by: Jonathan Nieder jrnie...@gmail.com
I'm not sure whether
On Thu, Apr 11, 2013 at 12:54:34PM -0700, Junio C Hamano wrote:
I could go either way. I think 96b9e0e is the right thing to do
conceptually, but I kind of doubt it was affecting all that many people.
And though it's _possible_ for it to be a security problem, I find it
much more likely
On Thu, Apr 11, 2013 at 11:09:28AM -0700, Junio C Hamano wrote:
Reflowing of the text is very much unappreciated X-.
I very much appreciate the excellent job you do as maintainer; your
attention to detail results in an incredibly high quality project.
However I do occasionally find your
Just a thought, but check the files that are failing to see if they've
got RCS keywords in them ($Id$, $File$, $Date$, etc). These cause all
sorts of nasty problems.
That's assuming it's definitely not a CRLF line ending problem on Windows.
On Thu, Apr 11, 2013 at 8:01 PM, Christopher Yee Mon
On Thu, Apr 11, 2013 at 03:11:32PM -0400, Jeff King wrote:
I always get a little nervous with sleeps in the test suite, as they are
indicative that we are trying to avoid some race condition, which means
that the test can fail when the system is under load, or when a tool
like valgrind is used
On Thu, Apr 11, 2013 at 09:31:41PM +0100, Adam Spiers wrote:
The shell source is strong with this one ;-)
Congrats - I first tried with FIFOs (hence my other patch which moves
the PIPE test prerequisite definition into the core framework - the
original intention was to reuse it here) but
Mostly suggested by codespell https://github.com/lucasdemarchi/codespell
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
---
Documentation/git-credential.txt | 2 +-
Documentation/git-remote-ext.txt | 2 +-
Documentation/git-svn.txt
1 - 100 of 126 matches
Mail list logo
