Re: [PATCH] clone: allow initial sparse checkouts
On Sun, Feb 23, 2014 at 2:32 PM, Robin H. Johnson robb...@gentoo.org wrote: This patch implements easily accessible sparse checkouts during clone, in the --sparse-checkout option. $ git clone REPO --sparse-checkout PATH Or take a file as input if there are lots of paths/rules. How much demand for taking a file of rules, I don't know. I guess it depends on each repo's layout. If the layout is simple, usually you would need one or two rules so it's ok to type again and again. If it's more complicated and starts using '!' rules, it's probably best to save in a file. and opinions of syntax to do that vs specify on the commandline? --sparse-checkout-from FILE I think this one is better. But if you don't see a need for it, we can always delay implementing it until an actual use case comes up. vs. --sparse-checkout 'PATH' or something other prefix character. -- Duy -- 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 v2 3/8] merge-recursive: -Xindex-only to leave worktree unchanged
On Sat, Feb 22, 2014 at 4:17 AM, Thomas Rast t...@thomasrast.ch wrote: Using the new no_worktree flag from the previous commit, we can teach merge-recursive to leave the worktree untouched. Expose this with a new strategy option so that scripts can use it. Signed-off-by: Junio C Hamano gits...@pobox.com --- diff --git a/Documentation/merge-strategies.txt b/Documentation/merge-strategies.txt index fb6e593..2934e99 100644 --- a/Documentation/merge-strategies.txt +++ b/Documentation/merge-strategies.txt @@ -92,6 +92,10 @@ subtree[=path];; is prefixed (or stripped from the beginning) to make the shape of two trees to match. +index-only;; s/;;/::/ + Write the merge result only to the index; do not touch the + worktree. + octopus:: This resolves cases with more than two heads, but refuses to do a complex merge that needs manual resolution. It is -- 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 v2 7/8] name-hash: allow dir hashing even when !ignore_case
On Sat, Feb 22, 2014 at 4:17 AM, Thomas Rast t...@thomasrast.ch wrote:
The directory hash (for fast checks if the index already has a
directory) was only used in ignore_case mode and so depended on that
flag.
Make it generally available on request.
Signed-off-by: Thomas Rast t...@thomasrast.ch
---
diff --git a/name-hash.c b/name-hash.c
index e5b6e1a..c8953be 100644
--- a/name-hash.c
+++ b/name-hash.c
@@ -141,16 +141,19 @@ static void hash_index_entry(struct index_state
*istate, struct cache_entry *ce)
*pos = ce;
}
- if (ignore_case !(ce-ce_flags CE_UNHASHED))
+ if (istate-has_dir_hash !(ce-ce_flags CE_UNHASHED))
add_dir_entry(istate, ce);
}
-static void lazy_init_name_hash(struct index_state *istate)
+void init_name_hash(struct index_state *istate, int force_dir_hash)
{
int nr;
if (istate-name_hash_initialized)
return;
+
+ istate-has_dir_hash = force_dir_hash || ignore_case;
This is getting a bit convoluted. Refactoring lazy_init_name_hash()
into two functions would eliminate the complexity. For instance:
void init_name_hash(struct index_state *istate)
{
...pure initialization code...
}
static void init_name_hash_if_needed(struct index_state *istate)
{
if (ignore_case !istate-name_hash_initialized)
init_name_hash(istate);
}
The two existing callers of lazy_init_name_hash() in name-hash.c,
which rely upon the lazy/ignore-case logic, would invoke the static
init_name_hash_if_needed().
The new caller in patch 8/8, which knows explicitly if and when it
wants the hash initialized can invoke the public init_name_hash().
if (istate-cache_nr)
preallocate_hash(istate-name_hash, istate-cache_nr);
for (nr = 0; nr istate-cache_nr; nr++)
@@ -161,7 +164,7 @@ static void lazy_init_name_hash(struct index_state
*istate)
void add_name_hash(struct index_state *istate, struct cache_entry *ce)
{
/* if already hashed, add reference to directory entries */
- if (ignore_case (ce-ce_flags CE_STATE_MASK) == CE_STATE_MASK)
+ if (istate-has_dir_hash (ce-ce_flags CE_STATE_MASK) ==
CE_STATE_MASK)
add_dir_entry(istate, ce);
ce-ce_flags = ~CE_UNHASHED;
@@ -181,7 +184,7 @@ void add_name_hash(struct index_state *istate, struct
cache_entry *ce)
void remove_name_hash(struct index_state *istate, struct cache_entry *ce)
{
/* if already hashed, release reference to directory entries */
- if (ignore_case (ce-ce_flags CE_STATE_MASK) == CE_HASHED)
+ if (istate-has_dir_hash (ce-ce_flags CE_STATE_MASK) ==
CE_HASHED)
remove_dir_entry(istate, ce);
ce-ce_flags |= CE_UNHASHED;
@@ -228,7 +231,7 @@ struct cache_entry *index_dir_exists(struct index_state
*istate, const char *nam
struct cache_entry *ce;
struct dir_entry *dir;
- lazy_init_name_hash(istate);
+ init_name_hash(istate, 0);
dir = find_dir_entry(istate, name, namelen);
if (dir dir-nr)
return dir-ce;
@@ -250,7 +253,7 @@ struct cache_entry *index_file_exists(struct index_state
*istate, const char *na
unsigned int hash = hash_name(name, namelen);
struct cache_entry *ce;
- lazy_init_name_hash(istate);
+ init_name_hash(istate, 0);
ce = lookup_hash(hash, istate-name_hash);
while (ce) {
@@ -286,9 +289,11 @@ void free_name_hash(struct index_state *istate)
if (!istate-name_hash_initialized)
return;
istate-name_hash_initialized = 0;
- if (ignore_case)
+ if (istate-has_dir_hash) {
/* free directory entries */
for_each_hash(istate-dir_hash, free_dir_entry, NULL);
+ istate-has_dir_hash = 0;
+ }
free_hash(istate-name_hash);
free_hash(istate-dir_hash);
--
1.9.0.313.g3d0a325
--
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 v5 02/14] trailer: process trailers from file and arguments
From: Junio C Hamano gits...@pobox.com Junio C Hamano gits...@pobox.com writes: Having said all that, it appears that nobody seems to be able to come up with a saner arrangement that would not paint us into a tough corner that we would not be able to later escape from without being backward incompatible---I certainly didn't. So... let's take this from your earlier message: If we limit it to if_exists and if_missing, the user can remember that without things becoming too complex. and go with the semantics the posted patches (I believe I have the latest from you on 'pu') attempt to implement, at least for now. IOW, when re-rolling, let's not try changing the arrangement to use if-exists/if-missing (configuration variable names) for keys' existence and include chosen set of conditions on values as modifiers to the action (i.e. X in do_Y_in_X). Ok, will re-roll soon. Thanks, Christian. -- 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 v2 3/8] merge-recursive: -Xindex-only to leave worktree unchanged
Eric Sunshine sunsh...@sunshineco.com writes: On Sat, Feb 22, 2014 at 4:17 AM, Thomas Rast t...@thomasrast.ch wrote: Using the new no_worktree flag from the previous commit, we can teach merge-recursive to leave the worktree untouched. Expose this with a new strategy option so that scripts can use it. Signed-off-by: Junio C Hamano gits...@pobox.com --- diff --git a/Documentation/merge-strategies.txt b/Documentation/merge-strategies.txt index fb6e593..2934e99 100644 --- a/Documentation/merge-strategies.txt +++ b/Documentation/merge-strategies.txt @@ -92,6 +92,10 @@ subtree[=path];; is prefixed (or stripped from the beginning) to make the shape of two trees to match. +index-only;; s/;;/::/ I think ;; is actually correct: this continues the sub-list of options to the recursive strategy. The :: level lists the available strategies. + Write the merge result only to the index; do not touch the + worktree. + octopus:: This resolves cases with more than two heads, but refuses to do a complex merge that needs manual resolution. It is -- 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 -- Thomas Rast t...@thomasrast.ch -- 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] diff: do not reuse_worktree_file for submodules
Thomas Rast t...@thomasrast.ch writes:
Junio C Hamano gits...@pobox.com writes:
Thomas Rast t...@thomasrast.ch writes:
@@ -2845,8 +2845,9 @@ static struct diff_tempfile *prepare_temp_file(const
char *name,
remove_tempfile_installed = 1;
}
- if (!one-sha1_valid ||
- reuse_worktree_file(name, one-sha1, 1)) {
+ if (!S_ISGITLINK(one-mode)
+ (!one-sha1_valid ||
+reuse_worktree_file(name, one-sha1, 1))) {
I agree with the goal/end result, but I have to wonder if the
reuse_worktree_file() be the helper function that ought to
encapsulate such a logic?
Instead of feeding it an object name and a path, if we passed a
diff_filespec to the helper, it would have access to the mode as
well. It would result in a more intrusive change, so I'd prefer to
see your patch applied first and then build such a refactor on top,
perhaps like the attached.
I see that you already queued 721e727, which has the change you
described plus moving the S_ISGITLINK test into reuse_worktree_file.
The change looks good to me.
I spoke too soon; it breaks the test I wrote to cover this case, for a
reason that gives me a headache.
When we hit the conditional
- if (!one-sha1_valid ||
- reuse_worktree_file(name, one-sha1, 1)) {
+ if (!S_ISGITLINK(one-mode)
+ (!one-sha1_valid ||
+reuse_worktree_file(name, one-sha1, 1))) {
sha1_valid=0 for the submodule on the worktree side of the diff. The
reason is that we start out with sha1_valid=0 and sha1=000..000 for the
worktree side of all dirty entries, which makes sense at that point. We
later set the sha1 by looking inside the submodule in
diff_fill_sha1_info(), but we never set sha1_valid. So the above
conditional will now trigger on the !one-sha1_valid arm, completely
defeating the change to reuse_worktree_file().
We can fix it like below, but it feels a bit wrong to me. Are
submodules the only case where it makes sense to set sha1_valid when we
fill the sha1?
diff.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git i/diff.c w/diff.c
index dabf913..cf7281d 100644
--- i/diff.c
+++ w/diff.c
@@ -3081,6 +3082,8 @@ static void diff_fill_sha1_info(struct diff_filespec *one)
die_errno(stat '%s', one-path);
if (index_path(one-sha1, one-path, st, 0))
die(cannot hash %s, one-path);
+ if (S_ISGITLINK(one-mode))
+ one-sha1_valid = 1;
}
}
else
--
Thomas Rast
t...@thomasrast.ch
--
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: Fwd: git p4: feature request - branch check filtering
dpr...@gmail.com wrote on Tue, 18 Feb 2014 12:42 +: I work at a company that has recently moved all CVS, SVN, and git repositories to Perforce. Depots have not been setup correctly in every case, and there is one depot that contains literally hundreds of projects under commercial development (and hundreds of branches as a result) My condolences. My project may be in //stupid_depot/commercial/teamporter/rok. This is the path I clone with git-p4. The only branches in this depot that contain files at this path are titled as 'rok_porter_branch/release_1.x' or similar. When using '--detect-branches' git-p4 checks each key of branches to see if any of them have files in the path I've cloned. Whilst this is good in practice there is unfortunately 6,809 branches, git-p4 processes about 2 a second and just under an hour to perform any git-p4 rebase, submit, or similar operation. This is in getBranchMapping() presumably. Where it loops over each branch doing p4 branch -o. Yuk. You could always avoid the --detect-branches if you don't really need it, instead doing, say, multiple git p4 sync for the different areas of the repo that interest you, each with its own destination branch in git (p4/depot-part1, p4/depot-part3, ...). Or --use-client-spec to cobble together an exact mapping of where p4 files should land in git, all in a single git branch then. I propose the addition of a branch list filtering option (--filter-branches) that takes either a regular expression or list of branches it should check. This may be useful in sane situations where you don't want to scan every branch in a Perforce repository, or blacklist branches that have undesirable content (for example, one of the branches is called 'svn-backup'. It contains a single, multi-GB tarball.) There is the existing git-p4.branchList option that explicitly adds (or overrides) branch information, beyond the ones auto-discovered. You might be able to use that option, but change its behavior to avoid the scan. So that if that option is set in the config, p4 is not asked anything about its branches. Not sure if this would break anyone's setup though. Another approach would be to add a config option git-p4.branchScan that defaults to True. You could turn it off and use branchList. It would be ideal to have this information (after initial clone or sync) stored somewhere in the git config where is appropriate so that future submit/rebase operations adhere to this list. Has something like this been worked on, or has been considered in the past? If not I will consider implementing this after reading up on the Git code guidelines. Thanks for keeping the Git workflow accessible in painful areas. It would be great if you could get something like this to work. Start in getBranchMapping() and don't forget to write up your work in Documentation/git-p4.txt. Also, this is sort of a messy area of the code, unfortunately. t/t9801 tries to make sure some of it keeps working. -- Pete -- 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 v2 3/8] merge-recursive: -Xindex-only to leave worktree unchanged
On Sun, Feb 23, 2014 at 6:57 AM, Thomas Rast t...@thomasrast.ch wrote: Eric Sunshine sunsh...@sunshineco.com writes: On Sat, Feb 22, 2014 at 4:17 AM, Thomas Rast t...@thomasrast.ch wrote: Using the new no_worktree flag from the previous commit, we can teach merge-recursive to leave the worktree untouched. Expose this with a new strategy option so that scripts can use it. Signed-off-by: Junio C Hamano gits...@pobox.com --- diff --git a/Documentation/merge-strategies.txt b/Documentation/merge-strategies.txt index fb6e593..2934e99 100644 --- a/Documentation/merge-strategies.txt +++ b/Documentation/merge-strategies.txt @@ -92,6 +92,10 @@ subtree[=path];; is prefixed (or stripped from the beginning) to make the shape of two trees to match. +index-only;; s/;;/::/ I think ;; is actually correct: this continues the sub-list of options to the recursive strategy. The :: level lists the available strategies. Make sense. Thanks for the explanation. + Write the merge result only to the index; do not touch the + worktree. + octopus:: This resolves cases with more than two heads, but refuses to do a complex merge that needs manual resolution. It is -- 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 -- Thomas Rast t...@thomasrast.ch -- 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: Cygwin + git log = no pager!
On Sat, Feb 22, 2014 at 1:39 AM, Chris Packham judge.pack...@gmail.com wrote: On 22/02/14 18:18, Robert Dailey wrote: So it seems that the pager doesn't work by default when running `git log` from Cygwin like it does in msysgit for Windows. I know I can pipe to `less` but that requires the additional typing obviously. Does anyone know how I can get the pager to work in Cygwin for git log, reflog, and other commands like it does in msysgit? Thanks in advance. Add GIT_PAGER=less to your environment. I don't know if you were using the cygwin packaged git or building from source but I'm surprised the pager is not set by default as you actually have to define the use of something other than less. Thanks for the response. I did set this environment variable in my .bashrc like so: export GIT_PAGER=less However after I do a 'git log' it is just spitting it out all at once and not entering the pager. -- 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 v2 0/3] Easier access to index-v4
Hi, previous round was at $gmane/242198. Thanks to Junio, Eric and Duy for comments on the previous round. Since then I've squashed the fixes suggested by Junio, added a test showing what should happen if an index file is present and GIT_INDEX_VERSION is set and fixed the typo found by Eric. Thomas Gummerer (3): introduce GIT_INDEX_VERSION environment variable test-lib: allow setting the index format version read-cache: add index.version config variable Documentation/config.txt | 4 ++ Documentation/git.txt | 5 +++ Makefile | 7 read-cache.c | 38 +- t/t1600-index.sh | 76 +++ t/t2104-update-index-skip-worktree.sh | 2 + t/test-lib-functions.sh | 5 +++ t/test-lib.sh | 3 ++ 8 files changed, 139 insertions(+), 1 deletion(-) create mode 100755 t/t1600-index.sh -- 1.9.0.1.ge0caaa8.dirty -- 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 v2 3/3] read-cache: add index.version config variable
Add a config variable that allows setting the default index version when
initializing a new index file. Similar to the GIT_INDEX_VERSION
environment variable this only affects new index files.
Signed-off-by: Thomas Gummerer t.gumme...@gmail.com
---
Documentation/config.txt | 4
read-cache.c | 35 ++-
t/t1600-index.sh | 27 +++
3 files changed, 57 insertions(+), 9 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 5f4d793..98200aa 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1601,6 +1601,10 @@ imap::
The configuration variables in the 'imap' section are described
in linkgit:git-imap-send[1].
+index.version::
+ Specify the version with which new index files should be
+ initialized. This does not affect existing repositories.
+
init.templatedir::
Specify the directory from which templates will be copied.
(See the TEMPLATE DIRECTORY section of linkgit:git-init[1].)
diff --git a/read-cache.c b/read-cache.c
index efc4aae..6bc9724 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -1219,23 +1219,40 @@ static struct cache_entry *refresh_cache_entry(struct
cache_entry *ce, int reall
#define INDEX_FORMAT_DEFAULT 3
+static int index_format_config(const char *var, const char *value, void *cb)
+{
+ unsigned int *version = cb;
+ if (!strcmp(var, index.version)) {
+ *version = git_config_int(var, value);
+ return 0;
+ }
+ return 1;
+}
+
static unsigned int get_index_format_default(void)
{
char *envversion = getenv(GIT_INDEX_VERSION);
- if (!envversion) {
- return INDEX_FORMAT_DEFAULT;
- } else {
- char *endp;
- unsigned int version = strtoul(envversion, endp, 10);
+ char *endp;
+ unsigned int version = INDEX_FORMAT_DEFAULT;
- if (*endp ||
- version INDEX_FORMAT_LB || INDEX_FORMAT_UB version) {
- warning(_(GIT_INDEX_VERSION set, but the value is
invalid.\n
+ if (!envversion) {
+ git_config(index_format_config, version);
+ if (version INDEX_FORMAT_LB || INDEX_FORMAT_UB version) {
+ warning(_(index.version set, but the value is
invalid.\n
Using version %i), INDEX_FORMAT_DEFAULT);
- version = INDEX_FORMAT_DEFAULT;
+ return INDEX_FORMAT_DEFAULT;
}
return version;
}
+
+ version = strtoul(envversion, endp, 10);
+ if (*endp ||
+ version INDEX_FORMAT_LB || INDEX_FORMAT_UB version) {
+ warning(_(GIT_INDEX_VERSION set, but the value is invalid.\n
+ Using version %i), INDEX_FORMAT_DEFAULT);
+ version = INDEX_FORMAT_DEFAULT;
+ }
+ return version;
}
/*
diff --git a/t/t1600-index.sh b/t/t1600-index.sh
index 6195c55..079d241 100755
--- a/t/t1600-index.sh
+++ b/t/t1600-index.sh
@@ -46,4 +46,31 @@ test_expect_success 'no warning with bogus GIT_INDEX_VERSION
and existing index'
)
'
+test_expect_success 'out of bounds index.version issues warning' '
+ (
+ sane_unset GIT_INDEX_VERSION
+ rm -f .git/index
+ git config --add index.version 1
+ git add a 21 | sed s/[0-9]// actual.err
+ sed -e s/ Z$/ / -\EOF expect.err
+ warning: index.version set, but the value is invalid.
+ Using version Z
+ EOF
+ test_i18ncmp expect.err actual.err
+ )
+'
+
+test_expect_success 'GIT_INDEX_VERSION takes precedence over config' '
+ (
+ rm -f .git/index
+ GIT_INDEX_VERSION=4
+ export GIT_INDEX_VERSION
+ git config --add index.version 2
+ git add a 21
+ echo 4 expect
+ test-index-version .git/index actual
+ test_cmp expect actual
+ )
+'
+
test_done
--
1.9.0.1.ge0caaa8.dirty
--
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 v2 2/3] test-lib: allow setting the index format version
Allow adding a TEST_GIT_INDEX_VERSION variable to config.mak to set the
index version with which the test suite should be run.
If it isn't set, the default version given in the source code is
used (currently version 3).
To avoid breakages with index versions other than [23], also set the
index version under which t2104 is run to 3. This test only tests
functionality specific to version 2 and 3 of the index file and would
fail if the test suite is run with any other version.
Helped-by: Junio C Hamano gits...@pobox.com
Signed-off-by: Thomas Gummerer t.gumme...@gmail.com
---
Makefile | 7 +++
t/t2104-update-index-skip-worktree.sh | 2 ++
t/test-lib-functions.sh | 5 +
t/test-lib.sh | 3 +++
4 files changed, 17 insertions(+)
diff --git a/Makefile b/Makefile
index dddaf4f..5caa3b2 100644
--- a/Makefile
+++ b/Makefile
@@ -342,6 +342,10 @@ all::
# Define DEFAULT_HELP_FORMAT to man, info or html
# (defaults to man) if you want to have a different default when
# git help is called without a parameter specifying the format.
+#
+# Define TEST_GIT_INDEX_VERSION to 2, 3 or 4 to run the test suite
+# with a different indexfile format version. If it isn't set the index
+# file format used is index-v[23].
GIT-VERSION-FILE: FORCE
@$(SHELL_PATH) ./GIT-VERSION-GEN
@@ -,6 +2226,9 @@ endif
ifdef GIT_PERF_MAKE_OPTS
@echo GIT_PERF_MAKE_OPTS=\''$(subst ','\'',$(subst
','\'',$(GIT_PERF_MAKE_OPTS)))'\' $@
endif
+ifdef TEST_GIT_INDEX_VERSION
+ @echo TEST_GIT_INDEX_VERSION=\''$(subst ','\'',$(subst
','\'',$(TEST_GIT_INDEX_VERSION)))'\' $@
+endif
### Detect Python interpreter path changes
ifndef NO_PYTHON
diff --git a/t/t2104-update-index-skip-worktree.sh
b/t/t2104-update-index-skip-worktree.sh
index 1d0879b..29c1fb1 100755
--- a/t/t2104-update-index-skip-worktree.sh
+++ b/t/t2104-update-index-skip-worktree.sh
@@ -7,6 +7,8 @@ test_description='skip-worktree bit test'
. ./test-lib.sh
+test_set_index_version 3
+
cat expect.full EOF
H 1
H 2
diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh
index aeae3ca..0bf1e63 100644
--- a/t/test-lib-functions.sh
+++ b/t/test-lib-functions.sh
@@ -32,6 +32,11 @@ test_set_editor () {
export EDITOR
}
+test_set_index_version () {
+GIT_INDEX_VERSION=$1
+export GIT_INDEX_VERSION
+}
+
test_decode_color () {
awk '
function name(n) {
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 1531c24..492f81f 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -108,6 +108,9 @@ export GIT_AUTHOR_EMAIL GIT_AUTHOR_NAME
export GIT_COMMITTER_EMAIL GIT_COMMITTER_NAME
export EDITOR
+GIT_INDEX_VERSION=$TEST_GIT_INDEX_VERSION
+export GIT_INDEX_VERSION
+
# Add libc MALLOC and MALLOC_PERTURB test
# only if we are not executing the test with valgrind
if expr $GIT_TEST_OPTS : .* --valgrind /dev/null ||
--
1.9.0.1.ge0caaa8.dirty
--
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 v2 1/3] introduce GIT_INDEX_VERSION environment variable
Respect a GIT_INDEX_VERSION environment variable, when a new index is
initialized. Setting the environment variable will not cause existing
index files to be converted to another format, but will only affect
newly written index files. This can be used to initialize repositories
with index-v4.
Helped-by: Junio C Hamano gits...@pobox.com
Signed-off-by: Thomas Gummerer t.gumme...@gmail.com
---
Documentation/git.txt | 5 +
read-cache.c | 21 -
t/t1600-index.sh | 49 +
3 files changed, 74 insertions(+), 1 deletion(-)
create mode 100755 t/t1600-index.sh
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 02bbc08..27a199c 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -720,6 +720,11 @@ Git so take care if using Cogito etc.
index file. If not specified, the default of `$GIT_DIR/index`
is used.
+'GIT_INDEX_VERSION'::
+ This environment variable allows the specification of an index
+ version for new repositories. It won't affect existing index
+ files. By default index file version [23] is used.
+
'GIT_OBJECT_DIRECTORY'::
If the object storage directory is specified via this
environment variable then the sha1 directories are created
diff --git a/read-cache.c b/read-cache.c
index 33dd676..efc4aae 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -1219,6 +1219,25 @@ static struct cache_entry *refresh_cache_entry(struct
cache_entry *ce, int reall
#define INDEX_FORMAT_DEFAULT 3
+static unsigned int get_index_format_default(void)
+{
+ char *envversion = getenv(GIT_INDEX_VERSION);
+ if (!envversion) {
+ return INDEX_FORMAT_DEFAULT;
+ } else {
+ char *endp;
+ unsigned int version = strtoul(envversion, endp, 10);
+
+ if (*endp ||
+ version INDEX_FORMAT_LB || INDEX_FORMAT_UB version) {
+ warning(_(GIT_INDEX_VERSION set, but the value is
invalid.\n
+ Using version %i), INDEX_FORMAT_DEFAULT);
+ version = INDEX_FORMAT_DEFAULT;
+ }
+ return version;
+ }
+}
+
/*
* dev/ino/uid/gid/size are also just tracked to the low 32 bits
* Again - this is just a (very strong in practice) heuristic that
@@ -1795,7 +1814,7 @@ int write_index(struct index_state *istate, int newfd)
}
if (!istate-version)
- istate-version = INDEX_FORMAT_DEFAULT;
+ istate-version = get_index_format_default();
/* demote version 3 to version 2 when the latter suffices */
if (istate-version == 3 || istate-version == 2)
diff --git a/t/t1600-index.sh b/t/t1600-index.sh
new file mode 100755
index 000..6195c55
--- /dev/null
+++ b/t/t1600-index.sh
@@ -0,0 +1,49 @@
+#!/bin/sh
+
+test_description='index file specific tests'
+
+. ./test-lib.sh
+
+test_expect_success 'setup' '
+ echo 1 a
+'
+
+test_expect_success 'bogus GIT_INDEX_VERSION issues warning' '
+ (
+ rm -f .git/index
+ GIT_INDEX_VERSION=2bogus
+ export GIT_INDEX_VERSION
+ git add a 21 | sed s/[0-9]// actual.err
+ sed -e s/ Z$/ / -\EOF expect.err
+ warning: GIT_INDEX_VERSION set, but the value is
invalid.
+ Using version Z
+ EOF
+ test_i18ncmp expect.err actual.err
+ )
+'
+
+test_expect_success 'out of bounds GIT_INDEX_VERSION issues warning' '
+ (
+ rm -f .git/index
+ GIT_INDEX_VERSION=1
+ export GIT_INDEX_VERSION
+ git add a 21 | sed s/[0-9]// actual.err
+ sed -e s/ Z$/ / -\EOF expect.err
+ warning: GIT_INDEX_VERSION set, but the value is
invalid.
+ Using version Z
+ EOF
+ test_i18ncmp expect.err actual.err
+ )
+'
+
+test_expect_success 'no warning with bogus GIT_INDEX_VERSION and existing
index' '
+ (
+ GIT_INDEX_VERSION=1
+ export GIT_INDEX_VERSION
+ git add a 2actual.err
+ expect.err
+ test_i18ncmp expect.err actual.err
+ )
+'
+
+test_done
--
1.9.0.1.ge0caaa8.dirty
--
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] clone: allow initial sparse checkouts
On Sun, Feb 23, 2014 at 03:43:47PM +0700, Duy Nguyen wrote: On Sun, Feb 23, 2014 at 2:32 PM, Robin H. Johnson robb...@gentoo.org wrote: This patch implements easily accessible sparse checkouts during clone, in the --sparse-checkout option. $ git clone REPO --sparse-checkout PATH Or take a file as input if there are lots of paths/rules. How much demand for taking a file of rules, I don't know. I guess it depends on each repo's layout. If the layout is simple, usually you would need one or two rules so it's ok to type again and again. If it's more complicated and starts using '!' rules, it's probably best to save in a file. and opinions of syntax to do that vs specify on the commandline? --sparse-checkout-from FILE I think this one is better. But if you don't see a need for it, we can always delay implementing it until an actual use case comes up. I think I'd prefer to delay that part then. What I'm concerned about if we do have it, is what ordering semantics there should be, eg for something like: --sparse-checkout '!X' --sparse-checkout-from F --sparse-checkout Y Should that be [!X, *F, Y], or [*F, !X, Y], or something else? Would the option parser need to be modified to handle this? Or do we just make them mutually exclusive? The only other clean alternative would be implementing ONLY --sparse-checkout-from, and letting uses use fds creatively: --sparse-checkout-from (echo X; echo Y) But the msysgit crowd would probably mumble complaints under their breath at me. -- Robin Hugh Johnson Gentoo Linux: Developer, Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 -- 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] diffcore.h: be explicit about the signedness of is_binary
Bitfields need to specify their signedness explicitly or the compiler is
free to default as it sees fit. With compilers that default 'unsigned'
(SUNWspro 12 seems to do this) the tri-state nature of is_binary
vanishes and all files are treated as binary.
Signed-off-by: Richard Lowe richl...@richlowe.net
---
diffcore.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/diffcore.h b/diffcore.h
index 79de8cf..7c6f391 100644
--- a/diffcore.h
+++ b/diffcore.h
@@ -46,7 +46,7 @@ struct diff_filespec {
unsigned is_stdin : 1;
unsigned has_more_entries : 1; /* only appear in combined diff */
/* data should be considered binary; -1 means don't know yet */
- int is_binary : 2;
+ signed int is_binary : 2;
struct userdiff_driver *driver;
};
--
1.8.5.5
--
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] Supporting non-blob notes
On Wed, Feb 19, 2014 at 12:10 AM, Duy Nguyen pclo...@gmail.com wrote: On Tue, Feb 18, 2014 at 9:46 PM, Johan Herland jo...@herland.net wrote: On Mon, Feb 17, 2014 at 11:48 AM, yann.dir...@bertin.fr wrote: The recent git-note -C changes commit type? thread (http://thread.gmane.org/gmane.comp.version-control.git/241950) looks like a good occasion to discuss possible uses of non-blob notes. The use-case we're thinking about is the storage of testrun logs as notes (think: being able to justify that a given set of tests were successfully run on a given revision). I think this is a good use of notes, and organizing the testrun logs into a tree of files seems like a natural way to proceed. Notes from the previous attempt to store trees as notes (something to watch out maybe, when you do it again) http://article.gmane.org/gmane.comp.version-control.git/197712 Thanks for that link. It is good to see that these issues have been considered/discussed previously. I've been thinking about this for a while now, and I find myself agreeing more and more with Junio's argument in the linked thread. I think notes are fundamentally - like file contents from Git's POV - an unstructured stream of bytes. Any real structure in a git note is imposed by the surrounding application/context, and having Git impose its own object model onto the contents of notes would likely be an unnecessary distraction. In Yann's example, the testrun logs are probably best structured as a hierarchy of files, but that does not necessarily mean that they MUST be stored as a Git tree object (with accompanying sub-trees and blobs). For example, one could imagine many different solutions for storing the testrun logs: (a) Storing the logs statically on some server, and putting the corresponding URL in a notes blob. Reachability is manual/on-demand (be retrieving the URL). (b) Storing the logs in a .tar.gz archive, and adding that archive as a blob note. Reachability is implicit/automatic (by unpacking the archive). (c) Storing the logs on some ref in an external repo, and putting the repo URL + ref in a notes blob. Reachability is manual/on-demand (by cloning/fetching the repo). (d) Storing the logs on some ref/commit in the same repo, and putting the ref/commit name in a notes blob. Reachability depends on the application/user to sync the ref/commit along with the notes. (e) Storing the logs in a commit, putting the commit name in a blob note, and then creating/rewriting the notes history to include the commit in its ancestry. Reachability is automatic (i.e.follows the notes), but the application must control/manipulate the notes history. Whichever of these (or other) solutions is most appropriate depends on the particular application/context, and (from Git's perspective), none of them are inherently superior to any of the other. Even the question of whether testrun logs should or should not be reachable by default, depends on the surrounding application/context. Now, the intention of Yann's RFC is to store the testrun logs directly in a notes _tree_. This is not too different from alternative (e) above, in that reachability is automatic. However, instead of having the surrounding application manipulate the notes history to ensure reachability, the RFC would rather teach Git's notes code to accomodate the (likely rather special) case of having a note that is BOTH structured like (or at least easily mapped to) a Git tree object, AND that should be automatically reachable. Even though there is a certain elegance to storing such a tree object directly as a notes object, there is AFAICS no other inherent advantage (e.g. performance- or functionality-wise) to following that approach. I'm not at all sure that it justifies increasing the complexity of the notes code. Furthermore, considering the RFC's original intention of also making commit and tag objects directly usable as notes, and realizing the fundamental difficulties in teaching Git to handle this (outlined in my previous email in this thread), I must conclude that the simplicity and flexibility of something like alternative (e) above far outweighs the added code complexity to support allowing any object type to be used as a note. Maybe we should instead consider making it easier to do alternative (e), by providing a command-line option for supplying additional parents to a notes commit? ...Johan [1]: The only structure in notes contents expected by Git is the text format expected when showing notes with git log, or when editing/appending notes with your default text editor. However, these are typically bypassed and/or customized by an external application storing custom data in notes. -- Johan Herland, jo...@herland.net www.herland.net -- 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] diffcore.h: be explicit about the signedness of is_binary
On Sun, Feb 23, 2014 at 07:54:47PM -0500, Richard Lowe wrote: Bitfields need to specify their signedness explicitly or the compiler is free to default as it sees fit. With compilers that default 'unsigned' (SUNWspro 12 seems to do this) the tri-state nature of is_binary vanishes and all files are treated as binary. Signed-off-by: Richard Lowe richl...@richlowe.net Thanks, I wasn't aware of this corner of the standard when I wrote it. Your fix is obviously correct. -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: [Bug report] too many open files while cvsimport
Hi git reports Unknown: error Too many open files when importing cvs repository using cvsimport. The repository is kind of middle size one, around 5000 files, thousands commits. Command line is: # git cvsimport -k -L 2 current ulimit: # ulimit -a -t: cpu time (seconds) unlimited -f: file size (blocks) unlimited -d: data seg size (kbytes) unlimited -s: stack size (kbytes) 10240 -c: core file size (blocks) 0 -m: resident set size (kbytes) unlimited -u: processes 32767 -n: file descriptors1 -l: locked-in-memory size (kbytes) 32 -v: address space (kbytes) unlimited -x: file locks unlimited -i: pending signals 32767 -q: bytes in POSIX msg queues 819200 -e: max nice0 -r: max rt priority 0 System: RHEL i386 # git --version git version 1.9.0 I build git from source. Best Regards, Xiangxin Zheng Best Regards, Xiangxin Zheng 2014-02-21 13:48 GMT+08:00 郑向昕 panda...@gmail.com: Hi git reports Unknown: error Too many open files when importing cvs repository using cvsimport. The repository is kind of middle size one, around 5000 files, thousands commits. Command line is: # git cvsimport -k -L 2 current ulimit: # ulimit -a -t: cpu time (seconds) unlimited -f: file size (blocks) unlimited -d: data seg size (kbytes) unlimited -s: stack size (kbytes) 10240 -c: core file size (blocks) 0 -m: resident set size (kbytes) unlimited -u: processes 32767 -n: file descriptors1 -l: locked-in-memory size (kbytes) 32 -v: address space (kbytes) unlimited -x: file locks unlimited -i: pending signals 32767 -q: bytes in POSIX msg queues 819200 -e: max nice0 -r: max rt priority 0 System: RHEL i386 # git --version git version 1.9.0 I build git from source. Best Regards, Xiangxin Zheng -- 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] difftool: support repositories with .git-files
Modern versions of git submodule use .git-files to setup the
submodule directory. When run in a git submodule-created
repository git difftool --dir-diff dies with the following
error:
$ git difftool -d HEAD~
fatal: This operation must be run in a work tree
diff --raw --no-abbrev -z HEAD~: command returned error: 128
core.worktree is relative to the .git directory but the logic
in find_worktree() does not account for it.
Use `git rev-parse --show-toplevel` to find the worktree so that
the dir-diff feature works inside a submodule.
Reported-by: Gábor Lipták gabor.lip...@gmail.com
Helped-by: Jens Lehmann jens.lehm...@web.de
Helped-by: John Keeping j...@keeping.me.uk
Signed-off-by: David Aguilar dav...@gmail.com
---
git-difftool.perl | 18 ++
1 file changed, 2 insertions(+), 16 deletions(-)
diff --git a/git-difftool.perl b/git-difftool.perl
index e57d3d1..18ca61e 100755
--- a/git-difftool.perl
+++ b/git-difftool.perl
@@ -39,24 +39,10 @@ USAGE
sub find_worktree
{
- my ($repo) = @_;
-
# Git-repository-wc_path() does not honor changes to the working
# tree location made by $ENV{GIT_WORK_TREE} or the 'core.worktree'
# config variable.
- my $worktree;
- my $env_worktree = $ENV{GIT_WORK_TREE};
- my $core_worktree = Git::config('core.worktree');
-
- if (defined($env_worktree) and (length($env_worktree) 0)) {
- $worktree = $env_worktree;
- } elsif (defined($core_worktree) and (length($core_worktree) 0)) {
- $worktree = $core_worktree;
- } else {
- $worktree = $repo-wc_path();
- }
-
- return $worktree;
+ return Git::command_oneline('rev-parse', '--show-toplevel');
}
sub print_tool_help
@@ -418,7 +404,7 @@ sub dir_diff
my $rc;
my $error = 0;
my $repo = Git-repository();
- my $workdir = find_worktree($repo);
+ my $workdir = find_worktree();
my ($a, $b, $tmpdir, @worktree) =
setup_dir_diff($repo, $workdir, $symlinks);
--
1.9.0.1.gd20a678
--
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] make commit --verbose work with --no-status
On Sat, Feb 22, 2014 at 4:31 PM, Jeff King p...@peff.net wrote:
On Sat, Feb 22, 2014 at 03:09:22AM +0800, Tay Ray Chuan wrote:
@@ -1141,7 +1146,12 @@ static int parse_and_validate_options(int argc, const
char *argv[],
if (all argc 0)
die(_(Paths with -a does not make sense.));
- if (status_format != STATUS_FORMAT_DEFAULT)
+ if (verbose !include_status) {
+ include_status = 1;
+ status_format = STATUS_FORMAT_NONE;
+ }
+
+ if (status_format != STATUS_FORMAT_DEFAULT !verbose)
dry_run = 1;
What happens here when there is an alternate status format _and_
--verbose is used? If I say git commit --porcelain it should imply
--dry-run. But git commit --porcelain --verbose no longer does so
after your patch.
I should have just left the --dry-run inference alone, like this.
--8--
@@ -1141,7 +1146,12 @@ static int parse_and_validate_options
if (all argc 0)
die(_(Paths with -a does not make sense.));
- if (status_format != STATUS_FORMAT_DEFAULT)
+ if (verbose !include_status) {
+ include_status = 1;
+ status_format = STATUS_FORMAT_NONE;
+ } else if (status_format != STATUS_FORMAT_DEFAULT)
dry_run = 1;
return argc;
--
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
[BUG] remote.pushdefault and branch.name.pushremote definition order
There seems to be a difference in the behavior of git push depending on whether remote.pushdefault is defined before or after branch.name.pushremote in .git/config. If remote.pushdefault is defined to be origin, and later in the file, branch.master.pushremote is defined to be upstream, then a plain git push from master errors out because I haven't provided a refspec or configured push.default. This makes sense. However, if the order of the two in the file is reversed, then a plain git push pushes to the origin repository, even though I have set the pushremote for master to upstream. This appears to be a bug. I would expect the order that things are defined in the config file to have no effect on the behavior of git push. I have reproduced this using git 1.9.0 and 1.8.3.4. Thanks, Jack -- 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
Nike Air Max 90 Dame Tilbud
Hver bit af nike jordan 12 sko eller støvler diskonteret får pæne og måske de er generelt bare en egnet prisniveau. Selvfølgelig, Nike Free 3.0 V5 Dame http://www.skobilligt2014.com/nike-free hvis du går til nike gratis køre folk sko eller støvler online shop, at de du kan reservere en masse kontanter. Disse er generelt i hele ekstraordinære funktioner og mode mens du bruger billig pris tag er som regel oprette en masse mennesker overraskelse. Sandsynligvis slået ihjel. personer, midt i luften Nike jordan sko eller støvler er blot grundlæggende to mennesker i dag, ikke desto mindre for folk tilhængere, hver sidste nike jordan sko eller støvler deres helt personlige alvorlige hvad dette betyder. Derfor er ikke gonna forsinkelse, billige jordan sko til salg Sørg for at de kan være ude i stedet og også akkumulere ræsonnementet.Nike Air Max 90 er virkelig en virkelig stærk sko på grund af sandheden kunne det gøre en yderst effektiv søgning som ingen andre sko. -- View this message in context: http://git.661346.n2.nabble.com/Nike-Air-Max-90-Dame-Tilbud-tp7604096.html Sent from the git mailing list archive at Nabble.com. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Nike Air Max 90 Dame Tilbud
Dies ist wirklich nicht auf den Läufer zusammen mit den Abschluss übertragen schließen Ergebnis ist tatsächlich ein Schuh, der ein gemütliches Erlebnis bietet. Nbsp der Schuh entspricht auch effektiv viele aufgrund der großen Schnürung-Strategie als ordnungsgemäß eine obere, die für Läufer produziert wird.Was ist auch erstaunlich, Nike Air Max 90 Herren http://www.airmaxherrench.com über die Nike Air Max neunzig wäre die Wirklichkeit, die es in das wesentliche Array von Versionen, die nicht nur Ihre bestimmte Mode aber auch die Dimension entsprechen wird und die Breite des Ihre Zehen ankommt. -- View this message in context: http://git.661346.n2.nabble.com/Nike-Air-Max-90-Dame-Tilbud-tp7604096p7604097.html Sent from the git mailing list archive at Nabble.com. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Nike Air Max 90 Femme
Probablement tué. personnes, mi air Nike jordan chaussures ou des bottes est simplement base deux personnes aujourd'hui, néanmoins pour les supporters de gens, Nike Air Max 90 Femme http://www.nikefemmepascher.fr/nike-air-max chaque dernier nike jordan chaussures ou des bottes eux-mêmes très grave ce qui veut dire. Par conséquent ne va pas tarder, cheap jordan chaussures à vendre Assurez-vous qu'ils peuvent être dans le site et aussi accumuler le raisonnement. -- View this message in context: http://git.661346.n2.nabble.com/Nike-Air-Max-90-Femme-tp7604098.html Sent from the git mailing list archive at Nabble.com. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Nike Air Max 90 Femme
Nike Air Max 90 Femme http://www.nikefemmepascher.fr/nike-air-max chaque dernier nike jordan chaussures ou des bottes eux-mêmes très grave ce qui veut dire. Par conséquent ne va pas tarder, cheap jordan chaussures à vendre Assurez-vous qu'ils peuvent être dans le site et aussi accumuler le raisonnement. -- View this message in context: http://git.661346.n2.nabble.com/Nike-Air-Max-90-Femme-tp7604099.html Sent from the git mailing list archive at Nabble.com. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Nike Air Max 90 Femme
hat is far more, a foam arch along with a toe bumper have been created to dexterously support the soles as well as the whole entire body, Nike Free 5.0 UK http://www.trainersuk.uk.com/nike-free maximizing the joy of barefoot working.Try using aspirin water for fighting plant diseases. 1 and half tablets of aspirin in a couple gallons of water will be a wonderful help on the plants you have. Spray this mixture onto your plants. Use this solution once in every three-week period. -- View this message in context: http://git.661346.n2.nabble.com/Nike-Air-Max-90-Femme-tp7604099p7604101.html Sent from the git mailing list archive at Nabble.com. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Nike Air Max 90 Femme
hat is far more, a foam arch along with a toe bumper have been created to dexterously support the soles as well as the whole entire body, Nike Free 5.0 UK http://www.trainersuk.uk.com/nike-free maximizing the joy of barefoot working.Try using aspirin water for fighting plant diseases. 1 and half tablets of aspirin in a couple gallons of water will be a wonderful help on the plants you have. Spray this mixture onto your plants. Use this solution once in every three-week period. -- View this message in context: http://git.661346.n2.nabble.com/Nike-Air-Max-90-Femme-tp7604098p7604100.html Sent from the git mailing list archive at Nabble.com. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/5] handle bogus commit dates
This series improves our handling of commit dates that are numbers, but are ridiculously large. The most critical one is the final commit, which fixes a segfault, but the others clean up various corner cases. [1/5]: t4212: test bogus timestamps with git-log [2/5]: fsck: report integer overflow in author timestamps [3/5]: date: check date overflow against time_t [4/5]: pretty: handle integer overflow in timestamps [5/5]: log: do not segfault on gmtime errors -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 1/5] t4212: test bogus timestamps with git-log
When t4212 was originally added by 9dbe7c3d (pretty: handle
broken commit headers gracefully, 2013-04-17), it tested our
handling of commits with broken ident lines in which the
timestamps could not be parsed. It does so using a bogus line
like Name email- 1234 -, because that simulates an
error that was seen in the wild.
Later, 03818a4 (split_ident: parse timestamp from end of
line, 2013-10-14) made our parser smart enough to actually
find the timestamp on such a line, and t4212 was adjusted to
match. While it's nice that we handle this real-world case,
this meant that we were not actually testing the
bogus-timestamp case anymore.
This patch adds a test with a totally incomprehensible
timestamp to make sure we are testing the code path.
Note that the behavior is slightly different between regular log
output and --format=%ad. In the former case, we produce a
sentinel value and in the latter, we produce an empty
string. While at first this seems unnecessarily
inconsistent, it matches the original behavior given by
9dbe7c3d.
Signed-off-by: Jeff King p...@peff.net
---
t/t4212-log-corrupt.sh | 21 +
1 file changed, 21 insertions(+)
diff --git a/t/t4212-log-corrupt.sh b/t/t4212-log-corrupt.sh
index 93c7c36..83de981 100755
--- a/t/t4212-log-corrupt.sh
+++ b/t/t4212-log-corrupt.sh
@@ -44,4 +44,25 @@ test_expect_success 'git log --format with broken author
email' '
test_cmp expect.err actual.err
'
+munge_author_date () {
+ git cat-file commit $1 commit.orig
+ sed s/^\(author .*\) [0-9]*/\1 $2/ commit.orig commit.munge
+ git hash-object -w -t commit commit.munge
+}
+
+test_expect_success 'unparsable dates produce sentinel value' '
+ commit=$(munge_author_date HEAD totally_bogus)
+ echo Date: Thu Jan 1 00:00:00 1970 + expect
+ git log -1 $commit actual.full
+ grep Date actual.full actual
+ test_cmp expect actual
+'
+
+test_expect_success 'unparsable dates produce sentinel value (%ad)' '
+ commit=$(munge_author_date HEAD totally_bogus)
+ echo expect
+ git log -1 --format=%ad $commit actual
+ test_cmp expect actual
+'
+
test_done
--
1.8.5.2.500.g8060133
--
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 2/5] fsck: report integer overflow in author timestamps
When we check commit objects, we complain if commit-date is
ULONG_MAX, which is an indication that we saw integer
overflow when parsing it. However, we do not do any check at
all for author lines, which also contain a timestamp.
Let's actually check the timestamps on each ident line
with strtoul. This catches both author and committer lines,
and we can get rid of the now-redundant commit-date check.
Note that like the existing check, we compare only against
ULONG_MAX. Now that we are calling strtoul at the site of
the check, we could be slightly more careful and also check
that errno is set to ERANGE. However, this will make further
refactoring in future patches a little harder, and it
doesn't really matter in practice.
For 32-bit systems, one would have to create a commit at the
exact wrong second in 2038. But by the time we get close to
that, all systems will hopefully have moved to 64-bit (and
if they haven't, they have a real problem one second later).
For 64-bit systems, by the time we get close to ULONG_MAX,
all systems will hopefully have been consumed in the fiery
wrath of our expanding Sun.
Signed-off-by: Jeff King p...@peff.net
---
Note that tags don't get checked here, because we do not feed their
ident lines to fsck_ident at all. This is still a step forward, though,
as if we ever teach them to check ident lines, they'll get this new
check automatically.
fsck.c | 12 ++--
t/t1450-fsck.sh | 14 ++
2 files changed, 20 insertions(+), 6 deletions(-)
diff --git a/fsck.c b/fsck.c
index 99c0497..760e072 100644
--- a/fsck.c
+++ b/fsck.c
@@ -245,6 +245,8 @@ static int fsck_tree(struct tree *item, int strict,
fsck_error error_func)
static int fsck_ident(char **ident, struct object *obj, fsck_error error_func)
{
+ char *end;
+
if (**ident == '')
return error_func(obj, FSCK_ERROR, invalid author/committer
line - missing space before email);
*ident += strcspn(*ident, \n);
@@ -264,10 +266,11 @@ static int fsck_ident(char **ident, struct object *obj,
fsck_error error_func)
(*ident)++;
if (**ident == '0' (*ident)[1] != ' ')
return error_func(obj, FSCK_ERROR, invalid author/committer
line - zero-padded date);
- *ident += strspn(*ident, 0123456789);
- if (**ident != ' ')
+ if (strtoul(*ident, end, 10) == ULONG_MAX)
+ return error_func(obj, FSCK_ERROR, invalid author/committer
line - date causes integer overflow);
+ if (end == *ident || *end != ' ')
return error_func(obj, FSCK_ERROR, invalid author/committer
line - bad date);
- (*ident)++;
+ *ident = end + 1;
if ((**ident != '+' **ident != '-') ||
!isdigit((*ident)[1]) ||
!isdigit((*ident)[2]) ||
@@ -287,9 +290,6 @@ static int fsck_commit(struct commit *commit, fsck_error
error_func)
int parents = 0;
int err;
- if (commit-date == ULONG_MAX)
- return error_func(commit-object, FSCK_ERROR, invalid
author/committer line);
-
if (memcmp(buffer, tree , 5))
return error_func(commit-object, FSCK_ERROR, invalid format
- expected 'tree' line);
if (get_sha1_hex(buffer+5, tree_sha1) || buffer[45] != '\n')
diff --git a/t/t1450-fsck.sh b/t/t1450-fsck.sh
index d730734..8c739c9 100755
--- a/t/t1450-fsck.sh
+++ b/t/t1450-fsck.sh
@@ -142,6 +142,20 @@ test_expect_success ' in name is reported' '
grep error in commit $new out
'
+# date is 2^64 + 1
+test_expect_success 'integer overflow in timestamps is reported' '
+ git cat-file commit HEAD basis
+ sed s/^\\(author .*\\) [0-9]*/\\1 18446744073709551617/ \
+ basis bad-timestamp
+ new=$(git hash-object -t commit -w --stdin bad-timestamp)
+ test_when_finished remove_object $new
+ git update-ref refs/heads/bogus $new
+ test_when_finished git update-ref -d refs/heads/bogus
+ git fsck 2out
+ cat out
+ grep error in commit $new.*integer overflow out
+'
+
test_expect_success 'tag pointing to nonexistent' '
cat invalid-tag -\EOF
object
--
1.8.5.2.500.g8060133
--
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 3/5] date: check date overflow against time_t
When we check whether a timestamp has overflowed, we check
only against ULONG_MAX, meaning that strtoul has overflowed.
However, we also feed these timestamps to system functions
like gmtime, which expect a time_t. On many systems, time_t
is actually smaller than unsigned long (e.g., because it
is signed), and we would overflow when using these
functions. We don't know the actual size or signedness of
time_t, but we can easily check for truncation with a simple
assignment.
Signed-off-by: Jeff King p...@peff.net
---
cache.h | 1 +
date.c | 17 +
fsck.c | 2 +-
3 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/cache.h b/cache.h
index dc040fb..e405598 100644
--- a/cache.h
+++ b/cache.h
@@ -959,6 +959,7 @@ void datestamp(char *buf, int bufsize);
unsigned long approxidate_careful(const char *, int *);
unsigned long approxidate_relative(const char *date, const struct timeval
*now);
enum date_mode parse_date_format(const char *format);
+int date_overflows(unsigned long date);
#define IDENT_STRICT 1
#define IDENT_NO_DATE 2
diff --git a/date.c b/date.c
index 83b4166..90b28f7 100644
--- a/date.c
+++ b/date.c
@@ -1113,3 +1113,20 @@ unsigned long approxidate_careful(const char *date, int
*error_ret)
gettimeofday(tv, NULL);
return approxidate_str(date, tv, error_ret);
}
+
+int date_overflows(unsigned long t)
+{
+ time_t sys;
+
+ /* If we overflowed our unsigned long, that's bad... */
+ if (t == ULONG_MAX)
+ return 1;
+
+ /*
+* ...but we also are going to feed the result to system
+* functions that expect time_t, which is often signed long.
+* Make sure that we fit into time_t, as well.
+*/
+ sys = t;
+ return t != sys || (t 1) != (sys 1);
+}
diff --git a/fsck.c b/fsck.c
index 760e072..64bf279 100644
--- a/fsck.c
+++ b/fsck.c
@@ -266,7 +266,7 @@ static int fsck_ident(char **ident, struct object *obj,
fsck_error error_func)
(*ident)++;
if (**ident == '0' (*ident)[1] != ' ')
return error_func(obj, FSCK_ERROR, invalid author/committer
line - zero-padded date);
- if (strtoul(*ident, end, 10) == ULONG_MAX)
+ if (date_overflows(strtoul(*ident, end, 10)))
return error_func(obj, FSCK_ERROR, invalid author/committer
line - date causes integer overflow);
if (end == *ident || *end != ' ')
return error_func(obj, FSCK_ERROR, invalid author/committer
line - bad date);
--
1.8.5.2.500.g8060133
--
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 4/5] log: handle integer overflow in timestamps
If an ident line has a ridiculous date value like (2^64)+1,
we currently just pass ULONG_MAX along to the date code,
which can produce nonsensical dates.
On systems with a signed long time_t (e.g., 64-bit glibc
systems), this actually doesn't end up too bad. The
ULONG_MAX is converted to -1, we apply the timezone field to
that, and the result ends up somewhere between Dec 31, 1969
and Jan 1, 1970.
However, there is still a few good reasons to detect the
overflow explicitly:
1. On systems where unsigned long is smaller than
time_t, we get a nonsensical date in the future.
2. Even where it would produce Dec 31, 1969, it's easier
to recognize midnight Jan 1 as a consistent sentinel
value for we could not parse this.
3. Values which do not overflow strtoul but do overflow a
signed time_t produce nonsensical values in the past.
For example, on a 64-bit system with a signed long
time_t, a timestamp of 184467440730 produces a
date in 1947.
We also recognize overflow in the timezone field, which
could produce nonsensical results. In this case we show the
parsed date, but in UTC.
Signed-off-by: Jeff King p...@peff.net
---
A note on these tests. They are designed for 64-bit systems, but should
run fine on 32-bit systems (they are both just overflow, and the second
test is not doing anything novel that the first is not).
However, the second test relies on finding a value that fits into an
unsigned long but does not fit into a time_t. For systems with a
64-bit signed time_t, that's fine. But if a system has an unsigned
64-bit time_t, the test will fail (it will actually produce some value
300 billion years from now).
I'm inclined to include it as-is, as I do not know of any such system
(and it would be kind of lame, since it could not represent dates before
1970). If somebody comes up with such a system, we can allow either
output (we could do it preemptively, but somebody would have to
calculate the exact date/time billions of years in the future; we would
be just as likely to disagree with the system's gmtime about something
silly like leapseconds).
pretty.c | 10 --
t/t4212-log-corrupt.sh | 16
2 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/pretty.c b/pretty.c
index 87db08b..3b811ed 100644
--- a/pretty.c
+++ b/pretty.c
@@ -401,8 +401,14 @@ static const char *show_ident_date(const struct
ident_split *ident,
if (ident-date_begin ident-date_end)
date = strtoul(ident-date_begin, NULL, 10);
- if (ident-tz_begin ident-tz_end)
- tz = strtol(ident-tz_begin, NULL, 10);
+ if (date_overflows(date))
+ date = 0;
+ else {
+ if (ident-tz_begin ident-tz_end)
+ tz = strtol(ident-tz_begin, NULL, 10);
+ if (tz == LONG_MAX || tz == LONG_MIN)
+ tz = 0;
+ }
return show_date(date, tz, mode);
}
diff --git a/t/t4212-log-corrupt.sh b/t/t4212-log-corrupt.sh
index 83de981..ba25a2e 100755
--- a/t/t4212-log-corrupt.sh
+++ b/t/t4212-log-corrupt.sh
@@ -65,4 +65,20 @@ test_expect_success 'unparsable dates produce sentinel value
(%ad)' '
test_cmp expect actual
'
+# date is 2^64 + 1
+test_expect_success 'date parser recognizes integer overflow' '
+ commit=$(munge_author_date HEAD 18446744073709551617)
+ echo Thu Jan 1 00:00:00 1970 + expect
+ git log -1 --format=%ad $commit actual
+ test_cmp expect actual
+'
+
+# date is 2^64 - 2
+test_expect_success 'date parser recognizes time_t overflow' '
+ commit=$(munge_author_date HEAD 18446744073709551614)
+ echo Thu Jan 1 00:00:00 1970 + expect
+ git log -1 --format=%ad $commit actual
+ test_cmp expect actual
+'
+
test_done
--
1.8.5.2.500.g8060133
--
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 5/5] log: do not segfault on gmtime errors
Many code paths assume that show_date and show_ident_date
cannot return NULL. For the most part, we handle missing or
corrupt timestamps by showing the epoch time t=0.
However, we might still return NULL if gmtime rejects the
time_t we feed it, resulting in a segfault. Let's catch this
case and just format t=0.
Signed-off-by: Jeff King p...@peff.net
---
This test is of questionable portability, since we are depending on
gmtime's arbitrary point to decide that our input is crazy and return
NULL. The value is sufficiently large that I'd expect most to do so,
though, so it may be safe.
On 32-bit systems, of course, the test does nothing (it is just hitting
the integer overflow code path). But that's OK, since the output is the
same for both cases.
date.c | 6 --
t/t4212-log-corrupt.sh | 8
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/date.c b/date.c
index 90b28f7..e1a2cee 100644
--- a/date.c
+++ b/date.c
@@ -184,8 +184,10 @@ const char *show_date(unsigned long time, int tz, enum
date_mode mode)
tz = local_tzoffset(time);
tm = time_to_tm(time, tz);
- if (!tm)
- return NULL;
+ if (!tm) {
+ tm = time_to_tm(0, 0);
+ tz = 0;
+ }
strbuf_reset(timebuf);
if (mode == DATE_SHORT)
diff --git a/t/t4212-log-corrupt.sh b/t/t4212-log-corrupt.sh
index ba25a2e..3fa1715 100755
--- a/t/t4212-log-corrupt.sh
+++ b/t/t4212-log-corrupt.sh
@@ -81,4 +81,12 @@ test_expect_success 'date parser recognizes time_t overflow'
'
test_cmp expect actual
'
+# date is within 2^63-1, but enough to choke glibc's gmtime
+test_expect_success 'absurdly far-in-future dates produce sentinel' '
+ commit=$(munge_author_date HEAD 99)
+ echo Thu Jan 1 00:00:00 1970 + expect
+ git log -1 --format=%ad $commit actual
+ test_cmp expect actual
+'
+
test_done
--
1.8.5.2.500.g8060133
--
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: Cygwin + git log = no pager!
On 24/02/14 09:33, Robert Dailey wrote: On Sat, Feb 22, 2014 at 1:39 AM, Chris Packham judge.pack...@gmail.com wrote: On 22/02/14 18:18, Robert Dailey wrote: So it seems that the pager doesn't work by default when running `git log` from Cygwin like it does in msysgit for Windows. I know I can pipe to `less` but that requires the additional typing obviously. Does anyone know how I can get the pager to work in Cygwin for git log, reflog, and other commands like it does in msysgit? Thanks in advance. Add GIT_PAGER=less to your environment. I don't know if you were using the cygwin packaged git or building from source but I'm surprised the pager is not set by default as you actually have to define the use of something other than less. Thanks for the response. I did set this environment variable in my .bashrc like so: export GIT_PAGER=less However after I do a 'git log' it is just spitting it out all at once and not entering the pager. Um OK that was the obvious thing to try. There is also the config variable core.pager but GIT_PAGER should take precedence. Could something be setting the environment variable LESS? Reading the git-config man page for core.pager git wants to set LESS to FRSX but if it is already set git takes that as an indication that you don't want to set LESS automatically. If neither of those help you probably want to let us know your cygwin version as well as your git version and how you installed git (i.e. built from source or installed via cygwin). -- 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
Nike Air Max TN
nbsp la chaussure correspond également à correctement beaucoup à cause de la stratégie de grand laçage comme correctement un dessus qui est conçu pour les coureurs.Aussi, Nike Air Max TN http://www.femmefootlocker.fr/nike-air-max ce qui est fantastique à propos de la Nike Air Max 90 est la réalité qu'il arrive dans une gamme importante de versions qui ne correspondront pas seulement votre certain mode mais aussi la dimension et la largeur de vos orteils. -- View this message in context: http://git.661346.n2.nabble.com/Nike-Air-Max-TN-tp7604110.html Sent from the git mailing list archive at Nabble.com. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
