On Wed, 15 Apr 2015 21:25:44 +, Dennis Kaarsemaker wrote:
...
> It does not and cannot work. The way mosh works, is that it uses ssh to
> log in and launch a mosh-server daemon. This daemon and the mosh client
> then communicate via a custom UDP protocol. The SSH connection is closed
> after th
On Tue, 21 Apr 2015 18:37:29 +, David Rodríguez wrote:
...
> This causes issues with Ruby git hooks, because Ruby version managers
> rely on custom settings in PATH to select the Ruby executable,
Even if git wouldn't modify PATH this is still a broken way to do that.
What ruby to execute a ho
Hello All,
I read the document of gitignore (http://git-scm.com/docs/gitignore),
and learned that $GIT_DIR/info/exclude has higher precedence than
the file specified by core.excludesfile.
But I noticed that patterns in core.excludesfile override patterns in
$GIT_DIR/info/exclude.
I tested as bel
> 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
Jeff King 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 uns
Signed-off-by: Bruno Vieira
---
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
--- a/builtin/merge.c
+
>> 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
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 s
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
---
As we discussed at Git Merge in P
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 21
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 als
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
---
git-multimail/README | 5 +
git-multimail/git_multimail.py | 10 +-
2 files changed, 14 insertions(+), 1 d
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
---
git-multimail/README | 7 +++
git-multimail/git_multimail.py | 44 ++
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
---
git-multimail/README | 3 +++
git-multimail/git_multimail.py | 11 ++-
2 files c
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
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 use
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 a
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/... //client/br
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 s
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
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 di
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
Junio C Hamano writes:
> Stefan Saasen 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
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 li
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" > t
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 th
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 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 ag
Duy Nguyen writes:
> On Mon, Apr 20, 2015 at 12:37 PM, Junio C Hamano wrote:
>> Duy Nguyen 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 different world, a world
>> differe
Eric Sunshine 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 envisioned as a
counter
>
> * 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 ini
On Tue, Apr 21, 2015 at 6:16 AM, Charles Bailey 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 with unrecogn
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\
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 c
erik elfström 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 an implementation I
[+mailing list]
On Tue, Apr 21, 2015 at 11:20 AM, Adam 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 I can't find the
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 Sun, Apr 19, 2015 at 3:14 AM, Junio C Hamano wrote:
> Erik Elfström 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 be more like setup_git_directo
Stefan Beller 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 alternative
On Tue, Apr 21, 2015 at 10:16 AM, Adam 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 '/Users/asteel/path/to/repo/.git/inde
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
Alexandre Garnier 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 line-terminate
On Tue, Apr 21, 2015 at 10:19 AM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> On Mon, Apr 20, 2015 at 3:51 PM, Junio C Hamano wrote:
>>
>>> On the core management side, xmalloc() and friends retry upon
>>> failure, after attempting to free the resource. I wonder if your
>>> codepath can
On Tue, Apr 21, 2015 at 10:16 AM, Junio C Hamano wrote:
> Stefan Beller 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.
>> + */
>> +
Stefan Beller 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 http://vger.kernel.org/majordomo-info.
Stefan Beller writes:
> On Mon, Apr 20, 2015 at 3:51 PM, Junio C Hamano 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, perhaps?
>
> But then we'd need to
Stefan Beller 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 this go nega
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
Stefan Saasen 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 merged to 'master' and
Michael J Gruber 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 matching engines in a s
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 wrote:
> Hi Luke,
>
> Using -v was a good suggestion. Unfortunately I still don't see what
> the problem is. I'm st
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_
> >trigg
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 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 Perforce
Thanks Sam, I'll check it out.
On Mon, Apr 20, 2015 at 12:23 PM, Sam Vilain 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 Perforce
---
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
On 04/21/2015 12:51 AM, Junio C Hamano wrote:
> Stefan Beller 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 apparently have 9
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,
+
From: Sergey Organov
Get rid of outdated explicit list of options.
Reflect that the obsolete form:
'git merge' HEAD ...
could also have options.
Signed-off-by: Sergey Organov
---
Documentation/git-merge.txt | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/Documenta
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 abou
Junio C Hamano venit, vidit, dixit 20.04.2015 20:44:
> Linus Torvalds 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)) {
>> p->pattern +=
Hi Junio,
On 2015-04-20 21:28, Junio C Hamano wrote:
> Junio C Hamano 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 "--ed
On April 20, 2015 11:45:15 PM GMT+01:00, Junio C Hamano
wrote:
>Vitor Antunes writes:
>
>> On April 20, 2015 6:43:49 AM GMT+01:00, Junio C Hamano
> wrote:
>>>Vitor Antunes writes:
>>>
Add failing scenario where branch detection is enabled together
>with
use client view. In this specif
62 matches
Mail list logo
