Packing speed
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 expectation wrong? -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 0x997A9F17ED7DAEA6 -- 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
Re: [PATCHv1 3/3] git-p4: fixing --changes-block-size handling
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? We know there are many cases of the other way around, and those cases are going to send users to StackOverflow to find the right workaround. I think it was just caution: it's pretty easy to make it fall back to the old non-batched scheme, so if it turns out that there *is* a problem, fewer people will hit the problem and we're less likely to have a paper-bag release. Dropping the option would also simplify the code in several places. The complex logic around get_another_block could be removed, and instead there could be a loop from start to mostRecentCommit by block_size. Several places that check if not block_size could just choose the other branch. Fair point. I'll give it a go and see what happens. (Plus 500 is a very unnatural number, chosen just because we still place some kind of significance on a chance evolutionary accident that gave our ape ancestors 5 digits on each hand :-) Luke -- 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
PATCH [git/contrib] Avoid failing to create ${__git_tcsh_completion_script} when 'set noclobber' is in effect (af7333c)
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 generated/updated. Adding a `!` in the redirect works correctly
for both clobber and noclobber users.
Developer's Certificate of Origin 1.1
By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or
(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or
(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.
(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.
Signed-off-by: Ariel Faigon github.2...@yendor.com
git patch follows.
---
contrib/completion/git-completion.tcsh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.tcsh
b/contrib/completion/git-completion.tcsh
index 6104a42..4a790d8 100644
--- a/contrib/completion/git-completion.tcsh
+++ b/contrib/completion/git-completion.tcsh
@@ -41,7 +41,7 @@ if ( ! -e ${__git_tcsh_completion_original_script} ) then
exit
endif
-cat EOF ${__git_tcsh_completion_script}
+cat EOF ! ${__git_tcsh_completion_script}
#!bash
#
# This script is GENERATED and will be overwritten automatically.
--
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
Re: [PATCHv1 0/3] git-p4: fixing --changes-block-size support
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 doesn't work on others, so the batch ranges approach looks like it will be better. Yes, I can easily imagine that it's changed from one version to the next. I tried going back to a 2014.2 server which still had the same problem (with maxresults), but my investigations were not very exhaustive! Based on what has been seen so far, the Perforce maxscanrows setting must be applying the low-level database queries that Perforce uses internally in its implementation. That makes the precise effect on external queries rather hard to predict. It likely also depends on the version of Perforce. Indeed. All sorts of things can cause it to fail; I've seen it reject p4 files and p4 print, albeit with artificially low maxscanrows and maxresults values. I think this means there's no way to ever make it reliably work for all possible sizes of depot and values of maxscanrows/maxresults. Luke -- 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
Re: [PATCH 1/2] git-bisect.sh : create a file if the bisection is in old/new mode, named BISECT_OLDNEWMODE, so it can easily be seen outside the program without having to read BISECT_TERMS. This wil
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, even if it needs a new file. The code for bisect uses BISECT_TERMS because 3 states are possible: 'bad/good mode', 'old/new mode', or 'no bisection started' (if BISECT_TERMS doesn't exist). But the other files (like revision.c) don't need all these informations, so we thought it would be good to check if a file exists instead of reusing BISECT_TERMS, which would require reading its content. -- 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
Re: [RFC/PATCH 0/9] add options to ref-filter
On Sat, Jun 6, 2015 at 10:03 PM, Karthik Nayak karthik@gmail.com 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 'ref-filter' and uses these options in 'for-each-ref'. -- 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
Re: [PATCHv1 0/3] git-p4: fixing --changes-block-size support
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 applying the low-level database queries that Perforce uses internally in its implementation. That makes the precise effect on external queries rather hard to predict. It likely also depends on the version of Perforce. Lex Spoon -- 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
Re: [PATCHv1 3/3] git-p4: fixing --changes-block-size handling
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 other way around, and those cases are going to send users to StackOverflow to find the right workaround. Dropping the option would also simplify the code in several places. The complex logic around get_another_block could be removed, and instead there could be a loop from start to mostRecentCommit by block_size. Several places that check if not block_size could just choose the other branch. Lex Spoon -- 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
Fwd: release address not working
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?response-content-disposition=attachment%3B%20filename%3DGit-1.9.5-preview20150319.exeresponse-content-type=application/octet-streamAWSAccessKeyId=AKIAISTNZFOVBIJMK3TQExpires=1433671774Signature=Qn3RvEVrb01Gm9wPJ7s6DObwAdM%3D -- Mustafa Kerim YILMAZ -- 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
[PATCH v6 10/11] for-each-ref: introduce filter_refs()
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 Hamano gits...@pobox.com
Mentored-by: Christian Couder christian.cou...@gmail.com
Mentored-by: Matthieu Moy matthieu@grenoble-inp.fr
Signed-off-by: Karthik Nayak karthik@gmail.com
---
ref-filter.c | 12 +++-
ref-filter.h | 8 ++--
2 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/ref-filter.c b/ref-filter.c
index ece16a1..886c3d7 100644
--- a/ref-filter.c
+++ b/ref-filter.c
@@ -858,7 +858,7 @@ static struct ref_array_item *new_ref_array_item(const char
*refname,
* A call-back given to for_each_ref(). Filter refs and keep them for
* later object processing.
*/
-int ref_filter_handler(const char *refname, const struct object_id *oid, int
flag, void *cb_data)
+static int ref_filter_handler(const char *refname, const struct object_id
*oid, int flag, void *cb_data)
{
struct ref_filter_cbdata *ref_cbdata = cb_data;
struct ref_filter *filter = ref_cbdata-filter;
@@ -904,6 +904,16 @@ void ref_array_clear(struct ref_array *array)
array-nr = array-alloc = 0;
}
+/*
+ * API for filtering a set of refs. The refs are provided and iterated
+ * over using the for_each_ref_fn(). The refs are stored into and filtered
+ * based on the ref_filter_cbdata structure.
+ */
+int filter_refs(int (for_each_ref_fn)(each_ref_fn, void *), struct
ref_filter_cbdata *data)
+{
+ return for_each_ref_fn(ref_filter_handler, data);
+}
+
static int cmp_ref_sorting(struct ref_sorting *s, struct ref_array_item *a,
struct ref_array_item *b)
{
struct atom_value *va, *vb;
diff --git a/ref-filter.h b/ref-filter.h
index c2c5d37..15e6766 100644
--- a/ref-filter.h
+++ b/ref-filter.h
@@ -46,8 +46,12 @@ struct ref_filter_cbdata {
struct ref_filter filter;
};
-/* Callback function for for_each_*ref(). This filters the refs based on the
filters set */
-int ref_filter_handler(const char *refname, const struct object_id *oid, int
flag, void *cb_data);
+/*
+ * API for filtering a set of refs. The refs are provided and iterated
+ * over using the for_each_ref_fn(). The refs are stored into and filtered
+ * based on the ref_filter_cbdata structure.
+ */
+int filter_refs(int (for_each_ref_fn)(each_ref_fn, void *), struct
ref_filter_cbdata *data);
/* Clear all memory allocated to ref_array */
void ref_array_clear(struct ref_array *array);
/* Parse format string and sort specifiers */
--
2.4.2
--
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
Re: [PATCH v6 0/11] create ref-filter from for-each-ref
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. *implement filter_refs() *use FLEX_ARRAY for refname *other small changes Changes in v6: *based on latest master branch (github.com/git/git) *rename variables named sort to sorting. Patch 09/11 and 10/11 had a some code swapped, weird. Have mailed new patches. -- Regards, Karthik -- 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
[PATCHv1 2/3] git-p4: test with limited p4 server results
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 does not work. As a result,
the tests all fail.
Note that maxscanrows is set quite high, as it appears to not only
limit results from p4 changes, but *also* limits results from
p4 print. Files that have more than maxscanrows changes seem
(experimentally) to be impossible to print. There's no good way to
work around this.
Signed-off-by: Luke Diamand l...@diamand.org
---
t/t9818-git-p4-block.sh | 29 +++--
1 file changed, 23 insertions(+), 6 deletions(-)
diff --git a/t/t9818-git-p4-block.sh b/t/t9818-git-p4-block.sh
index 79765a4..aae1121 100755
--- a/t/t9818-git-p4-block.sh
+++ b/t/t9818-git-p4-block.sh
@@ -8,6 +8,19 @@ test_expect_success 'start p4d' '
start_p4d
'
+create_restricted_group() {
+ p4 group -i -EOF
+ Group: restricted
+ MaxResults: 7
+ MaxScanRows: 40
+ Users: author
+ EOF
+}
+
+test_expect_success 'Create group with limited maxrows' '
+ create_restricted_group
+'
+
test_expect_success 'Create a repo with many changes' '
(
client_view //depot/included/... //client/included/... \
@@ -32,11 +45,15 @@ test_expect_success 'Create a repo with many changes' '
)
'
-test_expect_success 'Clone the repo' '
+test_expect_success 'Default user cannot fetch changes' '
+ ! p4 changes -m 1 //depot/...
+'
+
+test_expect_failure 'Clone the repo' '
git p4 clone --dest=$git --changes-block-size=7 --verbose
//depot/included@all
'
-test_expect_success 'All files are present' '
+test_expect_failure 'All files are present' '
echo file.txt expected
test_write_lines outer0.txt outer1.txt outer2.txt outer3.txt outer4.txt
expected
test_write_lines outer5.txt expected
@@ -44,18 +61,18 @@ test_expect_success 'All files are present' '
test_cmp expected current
'
-test_expect_success 'file.txt is correct' '
+test_expect_failure 'file.txt is correct' '
echo 55 expected
test_cmp expected $git/file.txt
'
-test_expect_success 'Correct number of commits' '
+test_expect_failure 'Correct number of commits' '
(cd $git git log --oneline) log
wc -l log
test_line_count = 43 log
'
-test_expect_success 'Previous version of file.txt is correct' '
+test_expect_failure 'Previous version of file.txt is correct' '
(cd $git git checkout HEAD^^)
echo 53 expected
test_cmp expected $git/file.txt
@@ -85,7 +102,7 @@ test_expect_success 'Add some more files' '
# This should pick up the 10 new files in included, but not be confused
# by the additional files in excluded
-test_expect_success 'Syncing files' '
+test_expect_failure 'Syncing files' '
(
cd $git
git p4 sync --changes-block-size=7
--
2.3.4.48.g223ab37
--
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
[PATCHv1 3/3] git-p4: fixing --changes-block-size handling
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 maxchanges parameter
is considered (experimentally).
Fix the block-size handling so that it gets blocks of changes
limited by revision number ($Start..$Start+$N, etc). This limits
the number of results early enough that both sets of tests pass.
If the --changes-block-size option is not in use, then the code
naturally falls back to the original scheme and gets as many changes
as possible.
Unfortunately, it also turns out that p4 print can fail on
files with more changes than maxscanrows. This fix is unable to
workaround this problem, although in the real world this shouldn't
normally happen.
Signed-off-by: Luke Diamand l...@diamand.org
---
git-p4.py | 48 +++-
t/t9818-git-p4-block.sh | 12 ++--
2 files changed, 41 insertions(+), 19 deletions(-)
diff --git a/git-p4.py b/git-p4.py
index 26ad4bc..0e29b75 100755
--- a/git-p4.py
+++ b/git-p4.py
@@ -744,41 +744,63 @@ def originP4BranchesExist():
def p4ChangesForPaths(depotPaths, changeRange, block_size):
assert depotPaths
-assert block_size
# Parse the change range into start and end
if changeRange is None or changeRange == '':
-changeStart = '@1'
-changeEnd = '#head'
+changeStart = 1
+changeEnd = None
else:
parts = changeRange.split(',')
assert len(parts) == 2
-changeStart = parts[0]
-changeEnd = parts[1]
+changeStart = int(parts[0][1:])
+if parts[1] == '#head':
+changeEnd = None
+else:
+changeEnd = int(parts[1])
# Accumulate change numbers in a dictionary to avoid duplicates
changes = {}
+# We need the most recent change list number if we're operating in
+# batch mode. For whatever reason, clients with limited MaxResults
+# can get this for the entire depot, but not for individual bits of
+# the depot.
+if block_size:
+results = p4CmdList([changes, -m, 1])
+mostRecentCommit = int(results[0]['change'])
+
for p in depotPaths:
# Retrieve changes a block at a time, to prevent running
# into a MaxScanRows error from the server.
start = changeStart
-end = changeEnd
get_another_block = True
while get_another_block:
new_changes = []
cmd = ['changes']
-cmd += ['-m', str(block_size)]
-cmd += [%s...%s,%s % (p, start, end)]
+
+if block_size:
+end = changeStart + block_size# only fetch a few at a time
+else:
+end = changeEnd # fetch as many as possible
+
+if end:
+endStr = str(end)
+else:
+endStr = '#head'
+
+cmd += [%s...@%d,%s % (p, changeStart, endStr)]
for line in p4_read_pipe_lines(cmd):
changeNum = int(line.split( )[1])
new_changes.append(changeNum)
changes[changeNum] = True
-if len(new_changes) == block_size:
-get_another_block = True
-end = '@' + str(min(new_changes))
-else:
+
+if not block_size:
+# Not batched, so nothing more to do
get_another_block = False
+elif end = mostRecentCommit:
+get_another_block = False
+else:
+changeStart = end + 1
changelist = changes.keys()
changelist.sort()
@@ -1974,7 +1996,7 @@ class P4Sync(Command, P4UserMap):
self.syncWithOrigin = True
self.importIntoRemotes = True
self.maxChanges =
-self.changes_block_size = 500
+self.changes_block_size = None
self.keepRepoPath = False
self.depotPaths = None
self.p4BranchesInGit = []
diff --git a/t/t9818-git-p4-block.sh b/t/t9818-git-p4-block.sh
index aae1121..3b3ae1f 100755
--- a/t/t9818-git-p4-block.sh
+++ b/t/t9818-git-p4-block.sh
@@ -49,11 +49,11 @@ test_expect_success 'Default user cannot fetch changes' '
! p4 changes -m 1 //depot/...
'
-test_expect_failure 'Clone the repo' '
+test_expect_success 'Clone the repo' '
git p4 clone --dest=$git --changes-block-size=7 --verbose
//depot/included@all
'
-test_expect_failure 'All files are present' '
+test_expect_success 'All files are present' '
echo file.txt expected
test_write_lines outer0.txt outer1.txt outer2.txt outer3.txt outer4.txt
expected
test_write_lines outer5.txt expected
@@ -61,18 +61,18 @@ test_expect_failure 'All files are present' '
test_cmp expected current
'
-test_expect_failure 'file.txt is
[PATCHv1 1/3] git-p4: additional testing of --changes-block-size
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 l...@diamand.org
---
t/t9818-git-p4-block.sh | 56 +
1 file changed, 47 insertions(+), 9 deletions(-)
diff --git a/t/t9818-git-p4-block.sh b/t/t9818-git-p4-block.sh
index 153b20a..79765a4 100755
--- a/t/t9818-git-p4-block.sh
+++ b/t/t9818-git-p4-block.sh
@@ -8,18 +8,21 @@ test_expect_success 'start p4d' '
start_p4d
'
-test_expect_success 'Create a repo with ~100 changes' '
+test_expect_success 'Create a repo with many changes' '
(
- cd $cli
+ client_view //depot/included/... //client/included/... \
+ //depot/excluded/... //client/excluded/...
+ mkdir -p $cli/included $cli/excluded
+ cd $cli/included
file.txt
p4 add file.txt
p4 submit -d Add file.txt
- for i in $(test_seq 0 9)
+ for i in $(test_seq 0 5)
do
outer$i.txt
p4 add outer$i.txt
p4 submit -d Adding outer$i.txt
- for j in $(test_seq 0 9)
+ for j in $(test_seq 0 5)
do
p4 edit file.txt
echo $i$j file.txt
@@ -30,33 +33,68 @@ test_expect_success 'Create a repo with ~100 changes' '
'
test_expect_success 'Clone the repo' '
- git p4 clone --dest=$git --changes-block-size=10 --verbose //depot@all
+ git p4 clone --dest=$git --changes-block-size=7 --verbose
//depot/included@all
'
test_expect_success 'All files are present' '
echo file.txt expected
test_write_lines outer0.txt outer1.txt outer2.txt outer3.txt outer4.txt
expected
- test_write_lines outer5.txt outer6.txt outer7.txt outer8.txt outer9.txt
expected
+ test_write_lines outer5.txt expected
ls $git current
test_cmp expected current
'
test_expect_success 'file.txt is correct' '
- echo 99 expected
+ echo 55 expected
test_cmp expected $git/file.txt
'
test_expect_success 'Correct number of commits' '
(cd $git git log --oneline) log
- test_line_count = 111 log
+ wc -l log
+ test_line_count = 43 log
'
test_expect_success 'Previous version of file.txt is correct' '
(cd $git git checkout HEAD^^)
- echo 97 expected
+ echo 53 expected
test_cmp expected $git/file.txt
'
+# Test git-p4 sync, with some files outside the client specification.
+
+p4_add_file() {
+ (cd $cli
+ $1
+ p4 add $1
+ p4 submit -d Added a file $1
+ )
+}
+
+test_expect_success 'Add some more files' '
+ for i in $(test_seq 0 10)
+ do
+ p4_add_file included/x$i
+ p4_add_file excluded/x$i
+ done
+ for i in $(test_seq 0 10)
+ do
+ p4_add_file excluded/y$i
+ done
+'
+
+# This should pick up the 10 new files in included, but not be confused
+# by the additional files in excluded
+test_expect_success 'Syncing files' '
+ (
+ cd $git
+ git p4 sync --changes-block-size=7
+ git checkout p4/master
+ ls -l x* log
+ test_line_count = 11 log
+ )
+'
+
test_expect_success 'kill p4d' '
kill_p4d
'
--
2.3.4.48.g223ab37
--
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
[PATCHv1 0/3] git-p4: fixing --changes-block-size support
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 it turns out that in practice, the server limits the number of results returned *before* the -m maxchanges argument is considered. Even supplying a -m 1 argument doesn't help. This affects both the maxscanrows and maxresults group options. This set of patches updates the t9818 git-p4 tests to show the problem, and then adds a fix which works by iterating over the changes in batches (as at present) but using a revision range to limit the number of changes, rather than -m $BATCHSIZE. That means it will in most cases require more transactions with the server, but usually the effect will be small. Along the way I also found that p4 print can fail if you have a file with too many changes in it, but there's unfortunately no way to workaround this. It's fairly unlikely to ever happen in practice. I think I've covered everything in this fix, but it's possible that there are still bugs to be uncovered; I find the way that these limits interact somewhat tricky to understand. Thanks, Luke Luke Diamand (3): git-p4: additional testing of --changes-block-size git-p4: test with limited p4 server results git-p4: fixing --changes-block-size handling git-p4.py | 48 +++- t/t9818-git-p4-block.sh | 73 +++-- 2 files changed, 99 insertions(+), 22 deletions(-) -- 2.3.4.48.g223ab37 -- 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
Re: [PATCH 3/3] stash: require a clean index to apply
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 was included in git 2.4.2, and it breaks my workflow. In particular, I have a pre-commit hook whith does the following: 1. Stash unstaged changes (git stash -k). 2. Run flake8 over all staged changes. 3. If flake8 complains, then error out of the commit. 4. Otherwise, apply the stash and exit. Hrm. The new protection in v2.4.2 is meant to prevent you from losing your index state during step 4 when we run into a conflict. But here you know something that git doesn't: that we just created the stash based on this same state, so it should apply cleanly. So besides the obvious fix of reverting the patch, we could perhaps do something along the lines of: 1. Add a --force option to tell git to do it anyway. 2. Only have the protection kick in when we would in fact have a conflict. This is probably hard to implement, though, as we don't know until we do the merge (so it would probably involve teaching merge a mode where it bails immediately on conflicts rather than writing out the conflicted entries to the index). However, I am puzzled by something in your workflow: does it work when you have staged and working tree changes to the same hunk? For example: [differing content for HEAD, index, and working tree] $ git init $ echo base file git add file git commit -m base $ echo index file git add file $ echo working file [make our stash] $ git stash -k Saved working directory and index state WIP on master: dc7f0dd base HEAD is now at dc7f0dd base [new version] $ git.v2.4.2 stash apply Cannot apply stash: Your index contains uncommitted changes. [old version] $ git.v2.4.1 stash apply Auto-merging file CONFLICT (content): Merge conflict in file $ git diff diff --cc file index 9015a7a,d26b33d..000 --- a/file +++ b/file @@@ -1,1 -1,1 +1,5 @@@ ++ Updated upstream +index ++=== + working ++ Stashed changes So v2.4.1 shows a conflict, and loses the index state you had. Is there something more to your hook that I'm missing (stash options, or something else) that covers this case? The reason I have to do things this way is as follows. Suppose I did the following: 1. Stage changes that have a flake8 violation. 2. Fix the flake8 violation in the unstaged version of the staged file. 3. Commit the previously staged changes. If my commit hook runs over the unstaged version of the file, then it won't detect the flake8 violation, and as a result the violation will be committed. Yeah, the fundamental pattern makes sense. You want to test what is going into the commit, not what happens to be in the working tree. One way to do that would be to checkout the proposed index to a temporary directory and operate on that. But of course that's inefficient if most of the files are unchanged. 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 output of git diff-index HEAD and feed the proposed updated blobs to it. If you can get away with feeding single lines, then feeding the actual diffs to it would be even better, but I assume that is not enough (I do not use flake8 myself). -Peff -- 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
Re: [PATCHv1 1/3] git-p4: additional testing of --changes-block-size
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 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
[PATCH] read-cache: fix untracked cache invalidation when split-index is used
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_TEST_SPLIT_INDEX is set. The different behavior that happens at .16 when split index is used: the entry two, when deleted at .13, is simply marked deleted. When .16 executes, the entry resurfaces from the version in base index. This happens in merge_base_index() where add_index_entry() is called to add two back from the base index. This is where the bug comes from. The add_index_entry() is called with ADD_CACHE_KEEP_CACHE_TREE flag because this version of two is not new, it does not break either cache-tree or untracked cache. The code should check this flag and not invalidate untracked cache. This causes a second invalidation violates test expectation. The fix is obvious. Noticed-by: Thomas Gummerer t.gumme...@gmail.com Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- PS. perhaps I should rename ADD_CACHE_KEEP_CACHE_TREE to ADD_CACHE_KEEP_CACHE, or add a new flag .._KEEP_UNTRACKED_CACHE to avoid confusion. On Sun, Jun 7, 2015 at 1:20 PM, Junio C Hamano gits...@pobox.com wrote: Thomas Gummerer t.gumme...@gmail.com writes: When running the test suite with GIT_TEST_SPLIT_INDEX set, tests 17-18 in t7063 fail. Unset GIT_TEST_SPLIT_INDEX at the beginning of the test, in order to fix it. That is not fixing but sweeping the problem under the rug, is it? Indeed. Duy, untracked-cache is a fairly new toy and I wouldn't be surprised if it has un-thought-out interaction with split-index which is also a fairly new exotic toy. As both are from you, can you take a look at it? Still a bit slow to address, but I marked Thomas' mail for investigation when it came. We may want to make it easier to run tests with TEST-SPLIT-INDEX, if we envision that the feature will bring us sufficient benefit and we would eventually want to encourage its use to more people. As it stands now, only people who are curious enough opt into trying it out by exporting the environment, which would be done by a tiny minority of developers and users. Untracked cache, split index and the last part (*) all aim at a smaller user audience with large work trees. They are not really what a common user needs, but I hope they do have users. We could make the test suite run twice, a normal run and a test-split-index run. But I'm not sure if it really justifies doubling test time. We will have to deal with this situation when/if pack-v4 is merged because we would want to exercise both v3 and v4 as much as possible. (*) the last part should keep index read time small enough even if the index is very large and avoid lstat() at refresh time with the help from watchman. read-cache.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/read-cache.c b/read-cache.c index 723d48d..309ccc7 100644 --- a/read-cache.c +++ b/read-cache.c @@ -999,7 +999,8 @@ static int add_index_entry_with_check(struct index_state *istate, struct cache_e } pos = -pos-1; - untracked_cache_add_to_index(istate, ce-name); + if (!(option ADD_CACHE_KEEP_CACHE_TREE)) + untracked_cache_add_to_index(istate, ce-name); /* * Inserting a merged entry (stage 0) into the index -- 2.3.0.rc1.137.g477eb31 -- 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
Re: [PATCH 3/3] stash: require a clean index to apply
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 output of git diff-index HEAD and feed the proposed updated blobs to it. If you can get away with feeding single lines, then feeding the actual diffs to it would be even better, but I assume that is not enough (I do not use flake8 myself). Like I said, I do not use it, but peeking at the flake8 source code, it has an --install-hook option to set up a pre-commit hook. It looks like the hook runs git diff-index --cached --name-only HEAD to get the list of modified files, filters that only for *.py, and then copies the results into a temporary directory to operate on. -Peff -- 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
[PATCH v6 09/11] ref-filter: move code from 'for-each-ref'
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 movement of code
from 'for-each-ref' to 'ref-filter'.
Mentored-by: Christian Couder christian.cou...@gmail.com
Mentored-by: Matthieu Moy matthieu@grenoble-inp.fr
Signed-off-by: Karthik Nayak karthik@gmail.com
---
Makefile |1 +
builtin/for-each-ref.c | 1075 +--
ref-filter.c | 1077
3 files changed, 1079 insertions(+), 1074 deletions(-)
create mode 100644 ref-filter.c
diff --git a/Makefile b/Makefile
index 54ec511..d715b66 100644
--- a/Makefile
+++ b/Makefile
@@ -762,6 +762,7 @@ LIB_OBJS += reachable.o
LIB_OBJS += read-cache.o
LIB_OBJS += reflog-walk.o
LIB_OBJS += refs.o
+LIB_OBJS += ref-filter.o
LIB_OBJS += remote.o
LIB_OBJS += replace_object.o
LIB_OBJS += rerere.o
diff --git a/builtin/for-each-ref.c b/builtin/for-each-ref.c
index 063de00..4d2d024 100644
--- a/builtin/for-each-ref.c
+++ b/builtin/for-each-ref.c
@@ -2,1082 +2,9 @@
#include cache.h
#include refs.h
#include object.h
-#include tag.h
-#include commit.h
-#include tree.h
-#include blob.h
-#include quote.h
#include parse-options.h
-#include remote.h
-#include color.h
#include ref-filter.h
-typedef enum { FIELD_STR, FIELD_ULONG, FIELD_TIME } cmp_type;
-
-static struct {
- const char *name;
- cmp_type cmp_type;
-} valid_atom[] = {
- { refname },
- { objecttype },
- { objectsize, FIELD_ULONG },
- { objectname },
- { tree },
- { parent },
- { numparent, FIELD_ULONG },
- { object },
- { type },
- { tag },
- { author },
- { authorname },
- { authoremail },
- { authordate, FIELD_TIME },
- { committer },
- { committername },
- { committeremail },
- { committerdate, FIELD_TIME },
- { tagger },
- { taggername },
- { taggeremail },
- { taggerdate, FIELD_TIME },
- { creator },
- { creatordate, FIELD_TIME },
- { subject },
- { body },
- { contents },
- { contents:subject },
- { contents:body },
- { contents:signature },
- { upstream },
- { push },
- { symref },
- { flag },
- { HEAD },
- { color },
-};
-
-/*
- * An atom is a valid field atom listed above, possibly prefixed with
- * a * to denote deref_tag().
- *
- * We parse given format string and sort specifiers, and make a list
- * of properties that we need to extract out of objects. ref_array_item
- * structure will hold an array of values extracted that can be
- * indexed with the atom number, which is an index into this
- * array.
- */
-static const char **used_atom;
-static cmp_type *used_atom_type;
-static int used_atom_cnt, need_tagged, need_symref;
-static int need_color_reset_at_eol;
-
-/*
- * Used to parse format string and sort specifiers
- */
-int parse_ref_filter_atom(const char *atom, const char *ep)
-{
- const char *sp;
- int i, at;
-
- sp = atom;
- if (*sp == '*' sp ep)
- sp++; /* deref */
- if (ep = sp)
- die(malformed field name: %.*s, (int)(ep-atom), atom);
-
- /* Do we have the atom already used elsewhere? */
- for (i = 0; i used_atom_cnt; i++) {
- int len = strlen(used_atom[i]);
- if (len == ep - atom !memcmp(used_atom[i], atom, len))
- return i;
- }
-
- /* Is the atom a valid one? */
- for (i = 0; i ARRAY_SIZE(valid_atom); i++) {
- int len = strlen(valid_atom[i].name);
- /*
-* If the atom name has a colon, strip it and everything after
-* it off - it specifies the format for this entry, and
-* shouldn't be used for checking against the valid_atom
-* table.
-*/
- const char *formatp = strchr(sp, ':');
- if (!formatp || ep formatp)
- formatp = ep;
- if (len == formatp - sp !memcmp(valid_atom[i].name, sp, len))
- break;
- }
-
- if (ARRAY_SIZE(valid_atom) = i)
- die(unknown field name: %.*s, (int)(ep-atom), atom);
-
- /* Add it in, including the deref prefix */
- at = used_atom_cnt;
- used_atom_cnt++;
- REALLOC_ARRAY(used_atom, used_atom_cnt);
- REALLOC_ARRAY(used_atom_type, used_atom_cnt);
- used_atom[at] = xmemdupz(atom, ep - atom);
- used_atom_type[at] = valid_atom[i].cmp_type;
- if (*atom == '*')
- need_tagged = 1;
- if (!strcmp(used_atom[at], symref))
- need_symref = 1;
- return at;
Re: [PATCHv1 2/3] git-p4: test with limited p4 server results
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.html
Re: Suggestion: add author info to TODO list in git-rebase--interactive
Mike Rappazzo rappa...@gmail.com writes:
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index dc3133f..e2d5ffc 100644
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -977,7 +977,18 @@ else
revisions=$onto...$orig_head
shortrevisions=$shorthead
fi
-git rev-list $merges_option --pretty=oneline --reverse --left-right
--topo-order \
+custom_format=$(git config --get rebase.interactive.todo-format)
We use three-level names only when we need an unbounded end-user
supplied things (e.g. nickname for remotes in remote.*.url,
description for a branch in branch.*.description). interactive
is not such a token, so a two-level name, e.g. rebase.insnformat
or something like that. Also core Git avoids variable names with
- in them.
+if test -z $custom_format
+then
+ custom_format=oneline
+else
+ # the custom format MUST start with %m%h or %m%H
+ if test ${custom_format:0:5} != '%m%h '
+ then
+ custom_format=%m%h ${custom_format}
+ fi
+fi
Why not allow them to *ONLY* set what follows '%m%h '? That is, if
they say '%m%h %s', give them '%m%h %m%h %s', by unconditionally
prepend '%m%h '. That way you do not need these conditional.
Something along the lines of...
format=$(git config rebase.insnFormat)
if test -z $format
then
format=%m%h%s
else
format=%m%h$format
fi
git rev-list $merge_option --format=$format --reverse \
--topo-order --left-right \
...
... I also tried changing the
'--left-right' to '--left-only', but that seemed to not produce any
results.
Wouldn't we want right side of the symmetric difference, though?
--
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
[PATCHv2 2/3] git-p4: test with limited p4 server results
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 does not work. As a result,
the tests all fail.
Note that maxscanrows is set quite high, as it appears to not only
limit results from p4 changes, but *also* limits results from
p4 print. Files that have more than maxscanrows changes seem
(experimentally) to be impossible to print. There's no good way to
work around this.
Signed-off-by: Luke Diamand l...@diamand.org
Acked-by: Lex Spoon l...@lexspoon.org
---
t/t9818-git-p4-block.sh | 29 +++--
1 file changed, 23 insertions(+), 6 deletions(-)
diff --git a/t/t9818-git-p4-block.sh b/t/t9818-git-p4-block.sh
index 79765a4..aae1121 100755
--- a/t/t9818-git-p4-block.sh
+++ b/t/t9818-git-p4-block.sh
@@ -8,6 +8,19 @@ test_expect_success 'start p4d' '
start_p4d
'
+create_restricted_group() {
+ p4 group -i -EOF
+ Group: restricted
+ MaxResults: 7
+ MaxScanRows: 40
+ Users: author
+ EOF
+}
+
+test_expect_success 'Create group with limited maxrows' '
+ create_restricted_group
+'
+
test_expect_success 'Create a repo with many changes' '
(
client_view //depot/included/... //client/included/... \
@@ -32,11 +45,15 @@ test_expect_success 'Create a repo with many changes' '
)
'
-test_expect_success 'Clone the repo' '
+test_expect_success 'Default user cannot fetch changes' '
+ ! p4 changes -m 1 //depot/...
+'
+
+test_expect_failure 'Clone the repo' '
git p4 clone --dest=$git --changes-block-size=7 --verbose
//depot/included@all
'
-test_expect_success 'All files are present' '
+test_expect_failure 'All files are present' '
echo file.txt expected
test_write_lines outer0.txt outer1.txt outer2.txt outer3.txt outer4.txt
expected
test_write_lines outer5.txt expected
@@ -44,18 +61,18 @@ test_expect_success 'All files are present' '
test_cmp expected current
'
-test_expect_success 'file.txt is correct' '
+test_expect_failure 'file.txt is correct' '
echo 55 expected
test_cmp expected $git/file.txt
'
-test_expect_success 'Correct number of commits' '
+test_expect_failure 'Correct number of commits' '
(cd $git git log --oneline) log
wc -l log
test_line_count = 43 log
'
-test_expect_success 'Previous version of file.txt is correct' '
+test_expect_failure 'Previous version of file.txt is correct' '
(cd $git git checkout HEAD^^)
echo 53 expected
test_cmp expected $git/file.txt
@@ -85,7 +102,7 @@ test_expect_success 'Add some more files' '
# This should pick up the 10 new files in included, but not be confused
# by the additional files in excluded
-test_expect_success 'Syncing files' '
+test_expect_failure 'Syncing files' '
(
cd $git
git p4 sync --changes-block-size=7
--
2.4.1.502.gb11c5ab
--
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
[PATCHv2 1/3] git-p4: additional testing of --changes-block-size
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 l...@diamand.org
Acked-by: Lex Spoon l...@lexspoon.org
---
t/t9818-git-p4-block.sh | 56 +
1 file changed, 47 insertions(+), 9 deletions(-)
diff --git a/t/t9818-git-p4-block.sh b/t/t9818-git-p4-block.sh
index 153b20a..79765a4 100755
--- a/t/t9818-git-p4-block.sh
+++ b/t/t9818-git-p4-block.sh
@@ -8,18 +8,21 @@ test_expect_success 'start p4d' '
start_p4d
'
-test_expect_success 'Create a repo with ~100 changes' '
+test_expect_success 'Create a repo with many changes' '
(
- cd $cli
+ client_view //depot/included/... //client/included/... \
+ //depot/excluded/... //client/excluded/...
+ mkdir -p $cli/included $cli/excluded
+ cd $cli/included
file.txt
p4 add file.txt
p4 submit -d Add file.txt
- for i in $(test_seq 0 9)
+ for i in $(test_seq 0 5)
do
outer$i.txt
p4 add outer$i.txt
p4 submit -d Adding outer$i.txt
- for j in $(test_seq 0 9)
+ for j in $(test_seq 0 5)
do
p4 edit file.txt
echo $i$j file.txt
@@ -30,33 +33,68 @@ test_expect_success 'Create a repo with ~100 changes' '
'
test_expect_success 'Clone the repo' '
- git p4 clone --dest=$git --changes-block-size=10 --verbose //depot@all
+ git p4 clone --dest=$git --changes-block-size=7 --verbose
//depot/included@all
'
test_expect_success 'All files are present' '
echo file.txt expected
test_write_lines outer0.txt outer1.txt outer2.txt outer3.txt outer4.txt
expected
- test_write_lines outer5.txt outer6.txt outer7.txt outer8.txt outer9.txt
expected
+ test_write_lines outer5.txt expected
ls $git current
test_cmp expected current
'
test_expect_success 'file.txt is correct' '
- echo 99 expected
+ echo 55 expected
test_cmp expected $git/file.txt
'
test_expect_success 'Correct number of commits' '
(cd $git git log --oneline) log
- test_line_count = 111 log
+ wc -l log
+ test_line_count = 43 log
'
test_expect_success 'Previous version of file.txt is correct' '
(cd $git git checkout HEAD^^)
- echo 97 expected
+ echo 53 expected
test_cmp expected $git/file.txt
'
+# Test git-p4 sync, with some files outside the client specification.
+
+p4_add_file() {
+ (cd $cli
+ $1
+ p4 add $1
+ p4 submit -d Added a file $1
+ )
+}
+
+test_expect_success 'Add some more files' '
+ for i in $(test_seq 0 10)
+ do
+ p4_add_file included/x$i
+ p4_add_file excluded/x$i
+ done
+ for i in $(test_seq 0 10)
+ do
+ p4_add_file excluded/y$i
+ done
+'
+
+# This should pick up the 10 new files in included, but not be confused
+# by the additional files in excluded
+test_expect_success 'Syncing files' '
+ (
+ cd $git
+ git p4 sync --changes-block-size=7
+ git checkout p4/master
+ ls -l x* log
+ test_line_count = 11 log
+ )
+'
+
test_expect_success 'kill p4d' '
kill_p4d
'
--
2.4.1.502.gb11c5ab
--
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
[PATCHv2 0/3] git-p4: fixing --changes-block-size handling
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 and hasn't been broken by these changes. Luke Luke Diamand (3): git-p4: additional testing of --changes-block-size git-p4: test with limited p4 server results git-p4: fixing --changes-block-size handling git-p4.py | 45 ++ t/t9818-git-p4-block.sh | 73 +++-- 2 files changed, 92 insertions(+), 26 deletions(-) -- 2.4.1.502.gb11c5ab -- 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
[PATCHv2 3/3] git-p4: fixing --changes-block-size handling
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 maxchanges parameter
is considered (experimentally).
Fix the block-size handling so that it gets blocks of changes
limited by revision number ($Start..$Start+$N, etc). This limits
the number of results early enough that both sets of tests pass.
Note that many other Perforce operations can fail for the same
reason (p4 print, p4 files, etc) and it's probably not possible
to workaround this. In the real world, this is probably not
usually a problem.
Signed-off-by: Luke Diamand l...@diamand.org
---
git-p4.py | 45 -
t/t9818-git-p4-block.sh | 12 ++--
2 files changed, 34 insertions(+), 23 deletions(-)
diff --git a/git-p4.py b/git-p4.py
index 26ad4bc..4be0037 100755
--- a/git-p4.py
+++ b/git-p4.py
@@ -249,6 +249,10 @@ def p4_reopen(type, f):
def p4_move(src, dest):
p4_system([move, -k, wildcard_encode(src), wildcard_encode(dest)])
+def p4_last_change():
+results = p4CmdList([changes, -m, 1])
+return int(results[0]['change'])
+
def p4_describe(change):
Make sure it returns a valid result by checking for
the presence of field time. Return a dict of the
@@ -746,39 +750,46 @@ def p4ChangesForPaths(depotPaths, changeRange,
block_size):
assert depotPaths
assert block_size
+# We need the most recent change list number since we can't just
+# use #head in block mode.
+lastChange = p4_last_change()
+
# Parse the change range into start and end
if changeRange is None or changeRange == '':
-changeStart = '@1'
-changeEnd = '#head'
+changeStart = 1
+changeEnd = lastChange
else:
parts = changeRange.split(',')
assert len(parts) == 2
-changeStart = parts[0]
-changeEnd = parts[1]
+changeStart = int(parts[0][1:])
+if parts[1] == '#head':
+changeEnd = lastChange
+else:
+changeEnd = int(parts[1])
# Accumulate change numbers in a dictionary to avoid duplicates
changes = {}
for p in depotPaths:
# Retrieve changes a block at a time, to prevent running
-# into a MaxScanRows error from the server.
-start = changeStart
-end = changeEnd
-get_another_block = True
-while get_another_block:
-new_changes = []
+# into a MaxResults/MaxScanRows error from the server.
+
+while True:
+end = min(changeEnd, changeStart + block_size)
+
cmd = ['changes']
-cmd += ['-m', str(block_size)]
-cmd += [%s...%s,%s % (p, start, end)]
+cmd += [%s...@%d,%d % (p, changeStart, end)]
+
+new_changes = []
for line in p4_read_pipe_lines(cmd):
changeNum = int(line.split( )[1])
new_changes.append(changeNum)
changes[changeNum] = True
-if len(new_changes) == block_size:
-get_another_block = True
-end = '@' + str(min(new_changes))
-else:
-get_another_block = False
+
+if end = changeEnd:
+break
+
+changeStart = end + 1
changelist = changes.keys()
changelist.sort()
diff --git a/t/t9818-git-p4-block.sh b/t/t9818-git-p4-block.sh
index aae1121..3b3ae1f 100755
--- a/t/t9818-git-p4-block.sh
+++ b/t/t9818-git-p4-block.sh
@@ -49,11 +49,11 @@ test_expect_success 'Default user cannot fetch changes' '
! p4 changes -m 1 //depot/...
'
-test_expect_failure 'Clone the repo' '
+test_expect_success 'Clone the repo' '
git p4 clone --dest=$git --changes-block-size=7 --verbose
//depot/included@all
'
-test_expect_failure 'All files are present' '
+test_expect_success 'All files are present' '
echo file.txt expected
test_write_lines outer0.txt outer1.txt outer2.txt outer3.txt outer4.txt
expected
test_write_lines outer5.txt expected
@@ -61,18 +61,18 @@ test_expect_failure 'All files are present' '
test_cmp expected current
'
-test_expect_failure 'file.txt is correct' '
+test_expect_success 'file.txt is correct' '
echo 55 expected
test_cmp expected $git/file.txt
'
-test_expect_failure 'Correct number of commits' '
+test_expect_success 'Correct number of commits' '
(cd $git git log --oneline) log
wc -l log
test_line_count = 43 log
'
-test_expect_failure 'Previous version of file.txt is correct' '
+test_expect_success 'Previous version of file.txt is correct' '
(cd $git git checkout HEAD^^)
echo 53 expected
test_cmp expected $git/file.txt
@@ -102,7 +102,7 @@ test_expect_success 'Add
Re: [PATCHv2 3/3] git-p4: fixing --changes-block-size handling
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 message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] completion: teach 'scissors' mode to 'git commit --cleanup='
Signed-off-by: SZEDER Gábor sze...@ira.uka.de
---
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.bash
+++ b/contrib/completion/git-completion.bash
@@ -1108,7 +1108,7 @@ _git_commit ()
case $cur in
--cleanup=*)
- __gitcomp default strip verbatim whitespace
+ __gitcomp default scissors strip verbatim whitespace
${cur##--cleanup=}
return
;;
--
2.4.3.384.g605df7b
--
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
Email Disabled Notification
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 of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] git-rebase--interactive.sh: add config option for custom
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 rappa...@gmail.com
---
git-rebase--interactive.sh | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index dc3133f..cc79b81 100644
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -977,7 +977,14 @@ else
revisions=$onto...$orig_head
shortrevisions=$shorthead
fi
-git rev-list $merges_option --pretty=oneline --reverse --left-right
--topo-order \
+format=$(git config --get rebase.instructionFormat)
+if test -z $format
+then
+ format=%s
+fi
+# the 'rev-list .. | sed' requires %m to parse; the instruction requires %h to
parse
+format=%m%h ${format}
+git rev-list $merges_option --pretty=${format} --reverse --left-right
--topo-order \
$revisions ${restrict_revision+^$restrict_revision} | \
sed -n s/^//p |
while read -r sha1 rest
---
https://github.com/git/git/pull/146
[PATCH] commit: cope with scissors lines in commit message
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 on a pure
scissors line, i.e. a line containing nothing but a comment character, a
space, and the scissors cut. This is good, because people can embed
scissor lines in the commit message while using 'git commit --verbose',
and the text they write after their indented scissors line doesn't get
deleted.
While doing so, however, the cleanup function only looks at the first
line matching the scissors pattern and if it doesn't start at the
beginning of the line, then the function just returns without performing
any cleanup. This is bad, because a real scissors line added by 'git
commit --verbose' might follow, and in that case the diff and submodule
shortlog get included in the commit message.
Don't bail out if a scissors line doesn't start at the beginning of the
line, but keep looking for a non-indented scissors line to fix this.
Signed-off-by: SZEDER Gábor sze...@ira.uka.de
---
t/t7502-commit.sh | 25 +
wt-status.c | 12
2 files changed, 33 insertions(+), 4 deletions(-)
diff --git a/t/t7502-commit.sh b/t/t7502-commit.sh
index 2e0d557243..77db3a31c3 100755
--- a/t/t7502-commit.sh
+++ b/t/t7502-commit.sh
@@ -239,6 +239,31 @@ EOF
'
+test_expect_success 'cleanup commit messages (scissors option,-F,-e, scissors
line in commit message)' '
+ echo negative
+ cat text EOF
+
+ # to be kept
+
+ # 8
+ # to be kept, too
+# 8
+to be removed
+# 8
+to be removed, too
+EOF
+
+ cat expect EOF
+ # to be kept
+
+ # 8
+ # to be kept, too
+EOF
+ git commit --cleanup=scissors -e -F text -a
+ git cat-file -p HEAD |sed -e 1,/^\$/dactual
+ test_cmp expect actual
+'
+
test_expect_success 'cleanup commit messages (strip option,-F)' '
echo negative
diff --git a/wt-status.c b/wt-status.c
index c56c78fb6f..e6d171a0cb 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -822,13 +822,17 @@ conclude:
void wt_status_truncate_message_at_cut_line(struct strbuf *buf)
{
- const char *p;
+ const char *p = buf-buf;
struct strbuf pattern = STRBUF_INIT;
strbuf_addf(pattern, %c %s, comment_line_char, cut_line);
- p = strstr(buf-buf, pattern.buf);
- if (p (p == buf-buf || p[-1] == '\n'))
- strbuf_setlen(buf, p - buf-buf);
+ while ((p = strstr(p, pattern.buf))) {
+ if (p == buf-buf || p[-1] == '\n') {
+ strbuf_setlen(buf, p - buf-buf);
+ break;
+ }
+ p++;
+ }
strbuf_release(pattern);
}
--
2.4.2.423.gad3a03f
--
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
Re: [PATCH] t7063: fix breakage with split index
Thomas Gummerer t.gumme...@gmail.com writes:
When running the test suite with GIT_TEST_SPLIT_INDEX set, tests 17-18
in t7063 fail. Unset GIT_TEST_SPLIT_INDEX at the beginning of the test,
in order to fix it.
That is not fixing but sweeping the problem under the rug, is it?
Duy, untracked-cache is a fairly new toy and I wouldn't be surprised
if it has un-thought-out interaction with split-index which is also
a fairly new exotic toy. As both are from you, can you take a look
at it?
We may want to make it easier to run tests with TEST-SPLIT-INDEX, if
we envision that the feature will bring us sufficient benefit and we
would eventually want to encourage its use to more people. As it
stands now, only people who are curious enough opt into trying it
out by exporting the environment, which would be done by a tiny
minority of developers and users.
Thanks.
Signed-off-by: Thomas Gummerer t.gumme...@gmail.com
---
Hi,
This breakage is both in the current master and next. I'm not entirely
sure this is the best way to solve the issue, but unfortunately I don't
have any more time to look into this.
t/t7063-status-untracked-cache.sh | 2 ++
1 file changed, 2 insertions(+)
diff --git a/t/t7063-status-untracked-cache.sh
b/t/t7063-status-untracked-cache.sh
index bd4806c..2f958c7 100755
--- a/t/t7063-status-untracked-cache.sh
+++ b/t/t7063-status-untracked-cache.sh
@@ -8,6 +8,8 @@ avoid_racy() {
sleep 1
}
+unset GIT_TEST_SPLIT_INDEX
+
# It's fine if git update-index returns an error code other than one,
# it'll be caught in the first test.
test_lazy_prereq UNTRACKED_CACHE '
--
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
Re: Submodules as first class citizens (was Re: Moving to subtrees for plugins?)
On 06.06.2015 12:53, Luca Milanesio wrote: Thank you Phil, you anticipated me :-) Luca. On 6 Jun 2015, at 18:49, Phil Hord phil.h...@gmail.com wrote: On Fri, Jun 5, 2015, 2:58 AM lucamilanesio luca.milane...@gmail.com wrote: Some devs of my Team complained that with submodules it is difficult to see the “full picture” of the difference between two SHA1 on the root project, as the submodules would just show as different SHA1s. When you Google “subtree submodules” you find other opinions as well: Just to mention a few: - https://codingkilledthecat.wordpress.com/2012/04/28/why-y our-company-shouldnt-use-git-submodules/ - http://blogs.atlassian.com/2013/05/alternatives-to-git-su bmodule-git-subtree/ To be honest with you, I am absolutely fine with submodules as I can easily leave with the “extra pain” of diffing by hand recursively on submodules. But it is true that it may happen to either forget to do a git submodule update or otherwise forget you are in a detached branch and start committing “on the air” without a branch. ... Ideally, as a git clone --recursive already exists, I would like to see a git diff --recursive that goes through the submodules as well :-) Something possibly to propose to the Git mailing list? I've worked on git diff --recursive a bit myself, along with some simpler use cases (git ls-tree --recursive) as POCs. I think some of the needs there begin to have ui implications which could be high-friction. I really want to finish it someday, but I've been too busy lately at $job, and now my experiments are all rather stale. It would be a good discussion to have over at the git list (copied). Heiko and Jens have laid some new groundwork in this area and it may be a good time to revisit it. Or maybe they've even moved deeper than that; I have been distracted for well over a year now. Glad you're working (or planning to) working on submodulues. This is also on my todo list for the next months as well. I'd review stuff in that area if you're looking for reviewers. Stefan Phil -- 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 -- 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
