Signed-off-by: SZEDER Gábor
---
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 bfc74e9d57..a1098765f6 100644
--- a/contrib/completion/git-completion.b
The diff and submodule shortlog appended to the commit message template
by 'git commit --verbose' are not stripped when the commit message
contains an indented scissors line.
When cleaning up a commit message with 'git commit --verbose' or
'--cleanup=scissors' the code is careful and triggers only
A config option 'rebase.instructionFormat' can override the
default 'oneline' format of the rebase instruction list.
Since the list is parsed using the left, right or boundary mark plus
the sha1, they are prepended to the instruction format.
Signed-off-by: Michael Rappazzo
---
git-rebase--inter
Unless I am reading something wrong, the "new_changes" variable could
be dropped now. It was needed for the -m version for detecting the
smallest change number that was returned. Otherwise it looks good to
me.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a messag
You are required to click on the link to verify your email account
because we are upgrading our
webmail.http://distilleries-provence.com/webalizer/eupdate/
Webmail Technical Support
Copyright 2012. All Rights Reserved
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body o
The --changes-block-size handling was intended to help when
a user has a limited "maxscanrows" (see "p4 group"). It used
"p4 changes -m $maxchanges" to limit the number of results.
Unfortunately, it turns out that the "maxscanrows" and "maxresults"
limits are actually applied *before* the "-m maxc
Change the --changes-block-size git-p4 test to use an account with
limited "maxresults" and "maxscanrows" values.
These conditions are applied in the server *before* the "-m maxchanges"
parameter to "p4 changes" is applied, and so the strategy that git-p4
uses for limiting the number of changes do
Add additional tests of some corner-cases of the
--changes-block-size git-p4 parameter.
Also reduce the number of p4 changes created during the
tests, so that they complete faster.
Signed-off-by: Luke Diamand
Acked-by: Lex Spoon
---
t/t9818-git-p4-block.sh | 56
Updated per Lex's suggestion, so that git-p4 always uses the block mode,
and takes advantage of this to simplify the loop. This exposed a bug
in the termination condition.
One thing to note: 'git p4 sync' claims to support arbitrary p4 revision
specifications. I need to check that this is tested a
Junio,
This is my 1st time doing this, sorry.
I hope this satisfies the git Sign Off procedure.
Problem Description:
tcsh users who happen to have 'set noclobber' elsewhere in their ~/.tcshrc or
~/.cshrc startup files get a 'File exist' error, and the tcsh completion file
doesn't get generate
Thank you for the feedback. We are trying to apply all of your suggestions, but
we would prefer to rebase the history before doing some of them (like renaming
variables).
About the BISECT_OLDNEWMODE file: The current implementation changes almost
nothing to revision.c. We thought it was better
With 2.4.2 I'm seeing *very* poor packing performance on my workstation.
The 2nd stage, where it does open/mmap/close/munmap on each of the
object files is processing only about 60 per socond.
Hundreds or even thousands per second seems like a reasonable
expectation, not mealy dozens.
Is my expe
On 07/06/15 17:33, Lex Spoon wrote:
The implementation looks fine, especially given the test cases that
back it up. I am only curious why the block size is set to a default
of None. To put it as contcretely as possible: is there any expected
configuration where None would work but 500 would not?
On 07/06/15 17:01, Lex Spoon wrote:
Great work.
Thanks! I actually found the problem in my day job, so it was very handy
having all the infrastructure already in place!
For curiosity's sake, the -m solution has been observed to work on at
least one Perforce installation. However clearly it d
The implementation looks fine, especially given the test cases that
back it up. I am only curious why the block size is set to a default
of None. To put it as contcretely as possible: is there any expected
configuration where None would work but 500 would not? We know there
are many cases of the ot
LGTM. That's great adding a user with the appropriate restrictions on
it to really exercise the functionality. -Lex
--
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.
I'll add in reviews since I touched similar code, but I don't know
whether it's sufficient given I don't know the code very well.
Anyway, these tests LGTM. Having a smaller test repository is fine,
and the new tests for files outside the client spec are a great idea.
-Lex
--
To unsubscribe from th
Great work.
For curiosity's sake, the -m solution has been observed to work on at
least one Perforce installation. However clearly it doesn't work on
others, so the batch ranges approach looks like it will be better.
Based on what has been seen so far, the Perforce maxscanrows setting
must be app
On Sat, Jun 6, 2015 at 10:03 PM, Karthik Nayak wrote:
> This is a follow up series to the one posted here
> http://thread.gmane.org/gmane.comp.version-control.git/270922
>
> This patch series adds '--ponints-at', '--merged', '--no-merged' and
s/--ponints-at/--points-at/
> '--contain' options to
On Sun, Jun 07, 2015 at 08:40:01AM -0400, Jeff King wrote:
> Are you running flake8 across the whole tree, or just on the files with
> proposed changes? Does it need to see the whole tree? If you can get
> away with feeding it single files, then it should be very efficient to
> loop over the outpu
On Thu, Jun 04, 2015 at 08:43:00PM -0400, Jonathan Kamens wrote:
> I'm writing about the patch that Jeff King submitted on April 22, in
> <20150422193101.gc27...@peff.net>, in particular,
> https://github.com/git/git/commit/ed178ef13a26136d86ff4e33bb7b1afb5033f908 .
> It appears that this patch wa
On 06/06/2015 07:13 PM, Karthik Nayak wrote:
Version four of this patch can be found here :
http://www.mail-archive.com/git@vger.kernel.org/msg70280.html
v5 : http://www.mail-archive.com/git@vger.kernel.org/msg70888.html
Changes in v5:
*Rename functions to better suit the code.
*impleme
Before this change, t7063.17 fails. The actual action though happens at
t7063.16 where the entry "two" is added back to index after being
removed in the .13. Here we expect a directory invalidate at .16 and
none at .17 where untracked cache is refreshed. But things do not go as
expected when GIT_TE
Introduce filter_refs() which will act as an API for users to
call and provide a function which will iterate over a set of refs
while filtering out the required refs.
Currently this will wrap around ref_filter_handler(). Hence,
ref_filter_handler is made file scope static.
Helped-by: Junio C Hama
Move most of the code from 'for-each-ref' to 'ref-filter' to make
it publicly available to other commands, this is to unify the code
of 'tag -l', 'branch -l' and 'for-each-ref' so that they can share
their implementations with each other.
Add 'ref-filter' to the Makefile, this completes the moveme
Change the --changes-block-size git-p4 test to use an account with
limited "maxresults" and "maxscanrows" values.
These conditions are applied in the server *before* the "-m maxchanges"
parameter to "p4 changes" is applied, and so the strategy that git-p4
uses for limiting the number of changes do
The --changes-block-size handling was intended to help when
a user has a limited "maxscanrows" (see "p4 group"). It used
"p4 changes -m $maxchanges" to limit the number of results.
Unfortunately, it turns out that the "maxscanrows" and "maxresults"
limits are actually applied *before* the "-m maxc
Add additional tests of some corner-cases of the
--changes-block-size git-p4 parameter.
Also reduce the number of p4 changes created during the
tests, so that they complete faster.
Signed-off-by: Luke Diamand
---
t/t9818-git-p4-block.sh | 56 +
1
We recently added support to git-p4 to limit the number of changes it
would try to import at a time. That was to help clients who were being
limited by the "maxscanrows" limit. This used the "-m maxchanges"
argument to "p4 changes" to limit the number of results returned to
git-p4.
Unfortunately i
I try to download from this url:
https://github.com/msysgit/msysgit/releases/download/Git-1.9.5-preview20150319/Git-1.9.5-preview20150319.exe
It is redirect to amazon aws with url but not responsed:
https://s3.amazonaws.com/github-cloud/releases/325827/8ddeba82-ce92-11e4-9812-db61045d243b.exe?resp
30 matches
Mail list logo
