On April 20, 2015 11:45:15 PM GMT+01:00, Junio C Hamano gits...@pobox.com
wrote:
Vitor Antunes vitor@gmail.com writes:
On April 20, 2015 6:43:49 AM GMT+01:00, Junio C Hamano
gits...@pobox.com wrote:
Vitor Antunes vitor@gmail.com writes:
Add failing scenario where branch detection is
Hi Junio,
On 2015-04-20 21:28, Junio C Hamano wrote:
Junio C Hamano gits...@pobox.com writes:
This is primarily note-to-self; even though I haven't got around
bisecting yet, I think I know I did some bad change myself.
git pull $URL $tag seems to:
* fail to invoke the editor without
Stefan Beller sbel...@google.com writes:
This replaces the latest patch on origin/sb/remove-fd-from-ref-lock
Thanks, will replace.
--
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
Stefan Beller sbel...@google.com writes:
I thought about putting a cap on it to not let it go negative in the first
place, but I did not find an easily accessible max() function, as I'd like
to write it as
int remaining_fds = max(get_max_fd_limit() - 32, 0);
to have it in one line. The
This is another attempt on enabling large transactions
(large in terms of open file descriptors). We keep track of how many
lock files are opened by the ref_transaction_commit function.
When more than a reasonable amount of files is open, we close
the file descriptors to make sure the transaction
About two weeks ago I started getting a regular rebase failure. I get this
error several times a day and at least once a day I lose work to it.
---
fatal: Unable to create '/Users/asteel/path/to/repo/.git/index.lock': File
exists.
If no other git process is currently running, this probably means
On Tue, Apr 21, 2015 at 10:16 AM, Junio C Hamano gits...@pobox.com wrote:
Stefan Beller sbel...@google.com writes:
+ /*
+ * We may want to open many files in a large transaction, so come up
with
+ * a reasonable maximum, keep some spares for stdin/out and other open
+ *
On Tue, Apr 21, 2015 at 10:19 AM, Junio C Hamano gits...@pobox.com wrote:
Stefan Beller sbel...@google.com writes:
On Mon, Apr 20, 2015 at 3:51 PM, Junio C Hamano gits...@pobox.com wrote:
On the core management side, xmalloc() and friends retry upon
failure, after attempting to free the
erik elfström erik.elfst...@gmail.com writes:
Ok, thanks for looking into this.
I have no well founded opinions on the implementation but I do
think the performance tests would be more meaningful if the
setup/cleanup code could be removed from the timed section.
If the community agrees on
Stefan Beller sbel...@google.com writes:
On Mon, Apr 20, 2015 at 3:51 PM, Junio C Hamano gits...@pobox.com wrote:
On the core management side, xmalloc() and friends retry upon
failure, after attempting to free the resource. I wonder if your
codepath can do something similar to that,
[+mailing list]
On Tue, Apr 21, 2015 at 11:20 AM, Adam adamgst...@gmail.com wrote:
I'm using git version 2.3.2 (Apple Git-55).
We should loop in the maintainers of the Apple Git version, they'd know
what changed in git about two weeks ago.
I have no idea who that is though.
That explains why
Stefan Beller sbel...@google.com writes:
+ /*
+ * We may want to open many files in a large transaction, so come up
with
+ * a reasonable maximum, keep some spares for stdin/out and other open
+ * files.
+ */
+ int remaining_fds = get_max_fd_limit() - 32;
Can
Alexandre Garnier zig...@gmail.com writes:
echo '* text=auto' .gitattributes
git add .gitattributes
git commit -q -m Normalize EOL
echo -ne 'some content\r\nother \rcontent with CR\r\ncontent\r\nagain
With text=auto, the user instructs us to guess, and we expect either
LF or CRLF
On 2015-04-21 15.51, Alexandre Garnier wrote:
Here is a test:
git init -q crlf-test
cd crlf-test
echo '* text=auto' .gitattributes
git add .gitattributes
git commit -q -m Normalize EOL
echo -ne 'some content\r\nother \rcontent with CR\r\ncontent\r\nagain
content with\r\r\n'
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
On Tue, Apr 21, 2015 at 10:16 AM, Adam adamgst...@gmail.com wrote:
About two weeks ago I started getting a regular rebase failure. I get this
error several times a day and at least once a day I lose work to it.
Which git version are you using?
---
fatal: Unable to create
On Sun, Apr 19, 2015 at 3:14 AM, Junio C Hamano gits...@pobox.com wrote:
Erik Elfström erik.elfst...@gmail.com writes:
Known Problems:
* Unsure about the setup.c:read_gitfile refactor, feels a bit
messy?
The interface indeed feels somewhat messy. I suspect that a better
interface might
Ok, thanks for looking into this.
I have no well founded opinions on the implementation but I do
think the performance tests would be more meaningful if the
setup/cleanup code could be removed from the timed section.
If the community agrees on an implementation I would be happy
to convert the new
On Tue, Apr 21, 2015 at 6:16 AM, Charles Bailey char...@hashpling.org wrote:
On Mon, Apr 20, 2015 at 09:22:47PM +0530, karthik nayak wrote:
On 04/20/2015 02:49 PM, Charles Bailey wrote:
As far as I could tell - and please correct me if I've misunderstood,
cat-file's literally is about dealing
From: Sergey Organov sorga...@gmail.com
Get rid of outdated explicit list of options.
Reflect that the obsolete form:
'git merge' msg HEAD commit...
could also have options.
Signed-off-by: Sergey Organov sorga...@gmail.com
---
Documentation/git-merge.txt | 6 ++
1 file changed, 2
On 04/21/2015 12:21 AM, Jeff King wrote:
On Tue, Apr 21, 2015 at 12:13:30AM +0530, karthik nayak wrote:
+static int unpack_sha1_header_to_strbuf(git_zstream *stream, unsigned char
*map,
+ unsigned long mapsize, void *buffer,
+
---
The patch at the tip of kk/log-merges-config misindented one of the case
arms, this one amends it.
contrib/completion/git-completion.bash | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index
Thanks Sam, I'll check it out.
On Mon, Apr 20, 2015 at 12:23 PM, Sam Vilain s...@vilain.net wrote:
On 04/20/2015 09:41 AM, FusionX86 wrote:
Hopefully this is an appropriate place to ask questions about git-p4.
I started at a company that wants to migrate from Perforce to Git. I'm
new to
Junio C Hamano venit, vidit, dixit 20.04.2015 20:44:
Linus Torvalds torva...@linux-foundation.org writes:
And to clarify: I don't suggest always building with libpcre. I
literally suggest having something like
/* hacky mac-hack hack */
if (strncmp((?i), p-pattern, 4)) {
On Mon, Apr 20, 2015 at 09:22:47PM +0530, karthik nayak wrote:
On 04/20/2015 02:49 PM, Charles Bailey wrote:
As far as I could tell - and please correct me if I've misunderstood,
cat-file's literally is about dealing with unrecognized types whereas
hash-object's --literally is about both
On Tue, Apr 21, 2015 at 04:56:08PM +0530, karthik nayak wrote:
+ status = unpack_sha1_header(stream, map, mapsize, buffer, bufsiz);
I wonder if we would feel comfortable just running this NUL-check as
part of unpack_sha1_header (i.e., in all code paths). It _shouldn't_
trigger in
Hi Luke,
Using -v was a good suggestion. Unfortunately I still don't see what
the problem is. I'm starting to think that maybe I should just create
the client views I need and setup a cron job that p4 syncs and then
git commits/pushes.
The --preserve-user option is for submitting back to
Here is a test:
git init -q crlf-test
cd crlf-test
echo '* text=auto' .gitattributes
git add .gitattributes
git commit -q -m Normalize EOL
echo -ne 'some content\r\nother \rcontent with CR\r\ncontent\r\nagain
content with\r\r\n' inline-cr.txt
echo Working directory content:
cat -A
On 04/21/2015 12:51 AM, Junio C Hamano wrote:
Stefan Beller sbel...@google.com writes:
The problem comes from guessing the number of fds we're allowed to use.
At first I thought it was a fundamental issue with the code being broken, but
it turns out we just need a larger offset as we
Junio C Hamano gits...@pobox.com writes:
Stefan Saasen ssaa...@atlassian.com writes:
I've noticed Peff's patches on pu which suggest they will be available
in git 2.5?
Being on 'pu' (or 'next' for that matter) is not a suggestion for a
change to appear in any future version at all, even
Thanks Junio for the useful link, I'll comment there.
On 21/04/15 18:48, Junio C Hamano wrote:
http://thread.gmane.org/gmane.comp.version-control.git/267143/focus=267251
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More
Duy Nguyen pclo...@gmail.com writes:
On Mon, Apr 20, 2015 at 12:37 PM, Junio C Hamano gits...@pobox.com wrote:
Duy Nguyen pclo...@gmail.com writes:
But if you look at it another way, cd subrepo; git add . should be
the same as git add subrepo ...
Once you cd into subrepo, you are in a
Eric Sunshine sunsh...@sunshineco.com writes:
It's easy to be blinded into thinking that cat-file's new option
should be named --literally since it was inspired by the --literally
option of hash-object, but indeed it may not be the best choice.
Yeah, I wouldn't even say inspired. It was
On Tue, Apr 21, 2015 at 11:34:37AM -0700, Stefan Beller wrote:
[+mailing list]
On Tue, Apr 21, 2015 at 11:20 AM, Adam adamgst...@gmail.com wrote:
I'm using git version 2.3.2 (Apple Git-55).
We should loop in the maintainers of the Apple Git version, they'd know
what changed in git about
On Tue, Apr 21, 2015 at 08:21:37PM +0200, erik elfström wrote:
Ok, thanks for looking into this.
I have no well founded opinions on the implementation but I do
think the performance tests would be more meaningful if the
setup/cleanup code could be removed from the timed section.
If the
The latest maintenance release Git v2.3.6 is now available at the
usual places. It is comprised of 14 non-merge commits since v2.3.5,
contributed by 8 people, 4 of which are new faces.
There is not much to see there (the changes are mostly documentation
and test updates), except for updates to
* Removed unneeded braces in the condition to check if we want to close
the lock file.
* made the counter for the remaining fds an unsigned int. That is what
get_max_fd_limit() returns, so there are no concerns for an overflow.
Also it cannot go below 0 any more.
* moved the
http://thread.gmane.org/gmane.comp.version-control.git/267143/focus=267251
--
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
On 04/22/2015 12:29 AM, Jeff King wrote:
Hmm, interestingly, if you do _not_ stage the changes (i.e., drop the
final git add there), you get:
$ git stash pop
error: Your local changes to the following files would be overwritten by
merge:
test
Please, commit your changes or
For example, if I run git using:
$ /usr/bin/git
then /usr/bin is prepended to the path. Is this intentional? If it is, why?
This causes issues with Ruby git hooks, because Ruby version managers
rely on custom settings in PATH to select the Ruby executable, and
there's usually a system Ruby
Signed-off-by: Bruno Vieira m...@bmpvieira.com
---
This seemed to be missing. Sorry if otherwise or if I'm doing something wrong
(first time contributing).
builtin/merge.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/builtin/merge.c b/builtin/merge.c
index 3b0f8f9..5dbc10f 100644
---
Jeff King peff at peff.net writes:
If we can get away with just dropping this element from the PATH, I'd
much rather do that than try to implement a complicated path-precedence
scheme.
-Peff
I agree, GIT_EXEC_DIR should be enough and this surprising behavior would be
avoided.
--
To
Perhaps companies like Atlassian that rely on the stability of the
open source Git can spare some resources and join forces with like
minded folks on LTS of older maintenance tracks, if they are truly
interested in.
We certainly can and would like to. I'm not entirely sure what that
would
We have a very log list of recipients...displaying that list
on every push is annoying
Add an option to prevent printing the list of email addresses from
the hook
Signed-off-by: Dave Boutcher daveboutc...@gmail.com
---
git-multimail/README | 3 +++
git-multimail/git_multimail.py | 11
Add a stdout option to the config that is equivalent to the --stdout
command line option. This allows for easier debugging for a hook
Signed-off-by: Dave Boutcher daveboutc...@gmail.com
---
git-multimail/README | 5 +
git-multimail/git_multimail.py | 10 +-
2 files
Add a branches option to the config. Only changes
pushed to specified branches will generate emails. Changes to tags
will continue to generate emails.
Signed-off-by: Dave Boutcher daveboutc...@gmail.com
---
git-multimail/README | 7 +++
git-multimail/git_multimail.py | 44
I'm actually not sure how to reply to an old thread...
From the thread I gather that the intention is to prevent this behavior
and stop prepending git's directory to the path. Is that right?
On 21/04/15 18:59, David Rodríguez wrote:
Thanks Junio for the useful link, I'll comment there.
On
On Wed, Apr 22, 2015 at 01:35:05AM +0300, Dmitry Gutov wrote:
But we seem to skip that safety valve when the content has been staged,
which seems questionable to me (technically we are slightly better off
than the protected case because b was written to a git blob
object, so you can
Add failing scenario when branch detection (--detect-branches) is
enabled together with use client spec (--use-client-spec). In this
specific scenario git-p4 will break when the Perforce client view
removes part of the depot path, as in the following example:
//depot/branch1/base/...
On Fri, Apr 17, 2015 at 06:16:48AM -0400, Eric Sunshine wrote:
If somebody has a FreeBSD or OS X system to test on, I'd
love to see what is needed to compile with HAVE_GETDELIM
there.
Modern Mac OS X, 10.10.x Yosemite, has getdelim() and git builds fine
with HAVE_GETDELIM. I also tested
On Mon, Apr 20, 2015 at 05:31:11PM -0700, Stefan Beller wrote:
When running the test locally, i.e. not in the test suite, but typing
the commands
myself into the shell, Git is fine with having just 5 file descriptors left.
The additional 4 required fds come from beign run inside the test
The updates introduced in the third revision of these two patches consist only
on updates to the commit messages to better clarify what they implement.
Vitor Antunes (2):
t9801: check git-p4's branch detection with client spec enabled
git-p4: improve client path detection when branches are
Perforce allows client side file/directory remapping through
the use of the client view definition that is part of the
user's client spec.
To support this functionality while branch detection is
enabled it is important to determine the branch location in
the workspace such that the correct files
This adds the design document for protocol version 2.
It's better to rewrite the design document instead of trying to
squash it into the existing pack-protocol.txt and then differentiating
between version 1 and 2 all the time.
Signed-off-by: Stefan Beller sbel...@google.com
---
As we
I've noticed Peff's patches on pu which suggest they will be available
in git 2.5?
Being on 'pu' (or 'next' for that matter) is not a suggestion for a
change to appear in any future version at all, even though it often
means that it would soon be merged to 'master' and will be in the
Can you post up the output from 'git p4 clone', and also see what the
output from doing this is:
$ p4 print //depot/some/branch/missingfile.c
On 21 April 2015 at 14:33, FusionX86 fusion...@gmail.com wrote:
Hi Luke,
Using -v was a good suggestion. Unfortunately I still don't see what
the
Michael J Gruber g...@drmicha.warpmail.net writes:
We have engine-switching options and engine-modification options. The
latter are certainly good in the expression itself. Maybe even the
former, though I don't know how to switch away from fixed-strings in
that way...
I do not think mixing
Stefan Saasen ssaa...@atlassian.com writes:
I've noticed Peff's patches on pu which suggest they will be available
in git 2.5?
Being on 'pu' (or 'next' for that matter) is not a suggestion for a
change to appear in any future version at all, even though it often
means that it would soon be
On Tue, Apr 21, 2015 at 01:54:56AM +0300, Dmitry Gutov wrote:
I'm not really sure what higher stage entries are, but this scenario seems
to be a counter-example:
git init
echo a test
git add test
git commit -m first
echo aaa test
git stash save
echo b test
git add test
git
59 matches
Mail list logo
