Re: How to get notified of new releases?
- Original Message - Are there any dedicated mailing lists for git releases, or RSS feeds? Not sure if there's a Windows-dedicated list, but there's this: http://gitrss.q42.co.uk/ It filters the mailing-list posts starting with eg. [ANNOUNCE] and turns it into an RSS feed. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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: How to get notified of new releases?
Robert Dailey schrieb: Are there any dedicated mailing lists for git releases, or RSS feeds? I am on Windows so I'd specifically be interested in notifications when new releases or preview binaries are released on the Windows platform. I'm constantly checking the website currently. You may want to subscribe to msys...@googlegroups.com, which is low-traffic. -- 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
What's with git blame --reverse ?
The git blame manual page talks about using git blame --reverse to figure out when a particular change disappeared, but I cannot make it produce anything useful regardless of what range I give it. Using --root delivers a different state of uselessness. Can anyone give a recipe for using git blame --reverse on the Git code base for figuring out anything of relevance? Since I am in the process of rewriting git-blame, of course I want to verify that everything works, but while I achieve the same results, they seem fabulously useless before and after my rewrite. -- David Kastrup -- 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: What's with git blame --reverse ?
On Mon, Jan 27, 2014 at 7:45 PM, David Kastrup d...@gnu.org wrote: The git blame manual page talks about using git blame --reverse to figure out when a particular change disappeared, but I cannot make it produce anything useful regardless of what range I give it. Using --root delivers a different state of uselessness. Can anyone give a recipe for using git blame --reverse on the Git code base for figuring out anything of relevance? I rarely use blame, but the commit that introduces --reverse seems to have an example. See 85af792 (git-blame --reverse - 2008-04-02) -- 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: How to substructure rewrites?
David Kastrup d...@gnu.org writes: As it can easily be guessed, the add xxx function commits are basically adding not-yet-used code (and so will not disrupt compilation), but everything starting with Reorganize blame data structures up until the final commit will not work or compile since the code does not match the data structures. So there is little point in substructing all that, right? Even something seemingly isolated like commit f64b41c472442ae9971321fe8f62c3885ba4d8b7 Author: David Kastrup d...@gnu.org Date: Sun Jan 19 02:16:21 2014 +0100 blame.c: Let output determine MORE_THAN_ONE_PATH more efficiently is not really useful as a separate commit since while it does implement a particular task, this is done starting with non-working code relying on no-longer existent data structures. Small pieces that are incrementally added with their own documentation would certainly be a lot easier to read than one big ball of wax. I am wondering if it would make it easier for everybody to tentatively do git-blame vs git-blame2 dance here, just like we did git-blame vs git-annotate dance some years ago. That is, to add a completely new command and have them in parallel while cooking in 'next' (or we could even keep them in a few releases if we are not absolutely certain about the correctness of the result of the new code), aiming to eventually retire the current implementation and replace it with the new one. We have already have test infrastructure to allow us to run variants of blames, too, to help that kind of transition. In general, the rule is likely any commit should not create a non-working state right? Yes. -- 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] send-email: If the ca path is not specified, use the defaults
Ramkumar Ramachandra artag...@gmail.com writes: Junio C Hamano wrote: This change could introduce a regression for people on a platform whose certificate directory is /etc/ssl/certs but its IO::Socket:SSL somehow fails to use it as SSL_ca_path without being told. I can confirm that my git-send-email doesn't regress to the pre-35035bbf state; my certificate directory is /etc/ssl/certs. I'm somewhat surprised that IO::Socket::SSL picks the right file/ directory on every platform without being told explicitly. This change definitely looks like the right fix. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] doc: remote author/documentation sections from more pages
Michael Haggerty mhag...@alum.mit.edu writes: On 01/27/2014 01:15 AM, Eric Sunshine wrote: On Sun, Jan 26, 2014 at 6:43 PM, Michael Haggerty mhag...@alum.mit.edu wrote: Subject: [PATCH] doc: remote author/documentation sections from more pages s/remote/remove/ Gaah! Git is a virus that invades your muscle memory and prevents you from typing words that are similar to git subcommands. Thanks for noticing. Michael Thanks; s/remote/remove/ will be done on this end; no need to resend. -- 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 v3 1/4] t3030-merge-recursive: Test known breakage with empty work tree
Sometimes when working with a large repository it can be useful to try out a merge and only check out conflicting files to disk (for example as a speed optimization on a server). Until v1.7.7-rc1~28^2~20 (merge-recursive: When we detect we can skip an update, actually skip it, 2011-08-11), it was possible to do so with the following idiom: # Prepare a temporary index and empty work tree. GIT_INDEX_FILE=$PWD/tmp-$$-index export GIT_INDEX_FILE GIT_WORK_TREE=$PWD/tmp-$$-work export GIT_WORK_TREE mkdir $GIT_WORK_TREE # Convince the index that our side is on disk. git read-tree -i -m $ours git update-index --ignore-missing --refresh # Merge their side into our side. bases=$(git merge-base --all $ours $theirs) git merge-recursive $bases -- $ours $theirs tree=$(git write-tree) Nowadays, that still works and the exit status is the same, but merge-recursive produces a diagnostic if our side renamed a file: error: addinfo_cache failed for path 'dst' Add a test to document this regression. Signed-off-by: Brad King brad.k...@kitware.com --- t/t3030-merge-recursive.sh | 47 ++ 1 file changed, 47 insertions(+) diff --git a/t/t3030-merge-recursive.sh b/t/t3030-merge-recursive.sh index 2f96100..3db3bf6 100755 --- a/t/t3030-merge-recursive.sh +++ b/t/t3030-merge-recursive.sh @@ -257,6 +257,7 @@ test_expect_success 'setup 8' ' git add e test_tick git commit -m rename a-e + c7=$(git rev-parse --verify HEAD) git checkout rename-ln git mv a e test_ln_s_add e a @@ -517,6 +518,52 @@ test_expect_success 'reset and bind merge' ' ' +test_expect_failure 'merge-recursive w/ empty work tree - ours has rename' ' + ( + GIT_WORK_TREE=$PWD/ours-has-rename-work + export GIT_WORK_TREE + GIT_INDEX_FILE=$PWD/ours-has-rename-index + export GIT_INDEX_FILE + mkdir $GIT_WORK_TREE + git read-tree -i -m $c7 + git update-index --ignore-missing --refresh + git merge-recursive $c0 -- $c7 $c3 + git ls-files -s actual-files + ) 2actual-err + expected-err + cat expected-files -EOF + 100644 $o3 0b/c + 100644 $o0 0c + 100644 $o0 0d/e + 100644 $o0 0e + EOF + test_cmp expected-files actual-files + test_cmp expected-err actual-err +' + +test_expect_success 'merge-recursive w/ empty work tree - theirs has rename' ' + ( + GIT_WORK_TREE=$PWD/theirs-has-rename-work + export GIT_WORK_TREE + GIT_INDEX_FILE=$PWD/theirs-has-rename-index + export GIT_INDEX_FILE + mkdir $GIT_WORK_TREE + git read-tree -i -m $c3 + git update-index --ignore-missing --refresh + git merge-recursive $c0 -- $c3 $c7 + git ls-files -s actual-files + ) 2actual-err + expected-err + cat expected-files -EOF + 100644 $o3 0b/c + 100644 $o0 0c + 100644 $o0 0d/e + 100644 $o0 0e + EOF + test_cmp expected-files actual-files + test_cmp expected-err actual-err +' + test_expect_success 'merge removes empty directories' ' git reset --hard master -- 1.8.5.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
[PATCH v3 0/3] merge-recursive: Avoid diagnostic on empty work tree
Hi Folks, Here is the third revision of this series. The previous revisions can be found at $gmane/241009 and $gmane/241030. Updates since the previous revision of the series: * Handling of lstat ENOENT has been moved down into refresh_cache_ent and activated by a new CE_MATCH_IGNORE_MISSING option. * Rather than adding a new argument to make_cache_entry, the existing 'refresh' boolean argument has been generalized to a set of options. This required the addition of a new CE_MATCH_REFRESH option to enable refresh with no other options. Thanks, -Brad Brad King (4): t3030-merge-recursive: Test known breakage with empty work tree read-cache.c: Refactor --ignore-missing implementation read-cache.c: Extend make_cache_entry refresh flag with options merge-recursive.c: Tolerate missing files while refreshing index cache.h| 6 +- merge-recursive.c | 4 +++- read-cache.c | 27 ++ t/t3030-merge-recursive.sh | 47 ++ 4 files changed, 70 insertions(+), 14 deletions(-) -- 1.8.5.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
[PATCH v3 2/4] read-cache.c: Refactor --ignore-missing implementation
Move lstat ENOENT handling from refresh_index to refresh_cache_ent and
activate it with a new CE_MATCH_IGNORE_MISSING option. This will allow
other call paths into refresh_cache_ent to use the feature.
Signed-off-by: Brad King brad.k...@kitware.com
---
cache.h | 2 ++
read-cache.c | 8 +---
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/cache.h b/cache.h
index c9efe88..c96ada7 100644
--- a/cache.h
+++ b/cache.h
@@ -498,6 +498,8 @@ extern void *read_blob_data_from_index(struct index_state
*, const char *, unsig
#define CE_MATCH_RACY_IS_DIRTY 02
/* do stat comparison even if CE_SKIP_WORKTREE is true */
#define CE_MATCH_IGNORE_SKIP_WORKTREE 04
+/* ignore non-existent files during stat update */
+#define CE_MATCH_IGNORE_MISSING0x08
extern int ie_match_stat(const struct index_state *, const struct cache_entry
*, struct stat *, unsigned int);
extern int ie_modified(const struct index_state *, const struct cache_entry *,
struct stat *, unsigned int);
diff --git a/read-cache.c b/read-cache.c
index 33dd676..d61846c 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -1031,6 +1031,7 @@ static struct cache_entry *refresh_cache_ent(struct
index_state *istate,
int changed, size;
int ignore_valid = options CE_MATCH_IGNORE_VALID;
int ignore_skip_worktree = options CE_MATCH_IGNORE_SKIP_WORKTREE;
+ int ignore_missing = options CE_MATCH_IGNORE_MISSING;
if (ce_uptodate(ce))
return ce;
@@ -1050,6 +1051,8 @@ static struct cache_entry *refresh_cache_ent(struct
index_state *istate,
}
if (lstat(ce-name, st) 0) {
+ if (ignore_missing errno == ENOENT)
+ return ce;
if (err)
*err = errno;
return NULL;
@@ -1127,7 +1130,8 @@ int refresh_index(struct index_state *istate, unsigned
int flags,
int ignore_submodules = (flags REFRESH_IGNORE_SUBMODULES) != 0;
int first = 1;
int in_porcelain = (flags REFRESH_IN_PORCELAIN);
- unsigned int options = really ? CE_MATCH_IGNORE_VALID : 0;
+ unsigned int options = ((really ? CE_MATCH_IGNORE_VALID : 0) |
+ (not_new ? CE_MATCH_IGNORE_MISSING : 0));
const char *modified_fmt;
const char *deleted_fmt;
const char *typechange_fmt;
@@ -1176,8 +1180,6 @@ int refresh_index(struct index_state *istate, unsigned
int flags,
if (!new) {
const char *fmt;
- if (not_new cache_errno == ENOENT)
- continue;
if (really cache_errno == EINVAL) {
/* If we are doing --really-refresh that
* means the index is not valid anymore.
--
1.8.5.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: How to substructure rewrites?
Junio C Hamano gits...@pobox.com writes: David Kastrup d...@gnu.org writes: As it can easily be guessed, the add xxx function commits are basically adding not-yet-used code (and so will not disrupt compilation), but everything starting with Reorganize blame data structures up until the final commit will not work or compile since the code does not match the data structures. So there is little point in substructing all that, right? Even something seemingly isolated like commit f64b41c472442ae9971321fe8f62c3885ba4d8b7 Author: David Kastrup d...@gnu.org Date: Sun Jan 19 02:16:21 2014 +0100 blame.c: Let output determine MORE_THAN_ONE_PATH more efficiently is not really useful as a separate commit since while it does implement a particular task, this is done starting with non-working code relying on no-longer existent data structures. Small pieces that are incrementally added with their own documentation would certainly be a lot easier to read than one big ball of wax. Sure. The problem is that my rewrite is characterized by doing as little as possible in order to achieve identical results (with the conceivable exception of picking a different, equally scored variant in those parts of the algorithm choosing a maximum). That also means that the basic logic and layout of the program stays the same while the data flow and parts of the data structures are replaced. I am wondering if it would make it easier for everybody to tentatively do git-blame vs git-blame2 dance here, just like we did git-blame vs git-annotate dance some years ago. That is, to add a completely new command and have them in parallel while cooking in 'next' (or we could even keep them in a few releases if we are not absolutely certain about the correctness of the result of the new code), aiming to eventually retire the current implementation and replace it with the new one. We have already have test infrastructure to allow us to run variants of blames, too, to help that kind of transition. Well, the point is that the implementation is supposed to a) deliver identical results b) reuse as much code as possible so there is no real point in working with a separate source file. For the if we are not absolutely certain about the correctness of the result of the new code angle, this should be covered with the usual stable/unstable/proposed division most projects have in some way or another for quality assurance. I have absolutely no clue how Git organizes that, but it would usually mean that the new code is not placed in a different _file_ (or a differently named command) but rather in a different _branch_ as compared with the current implementation. In general, the rule is likely any commit should not create a non-working state right? Yes. My current aim is to complete the code to the point where it is a) fully operative and delivering equivalent results to the current implementation b) in every aspect at least as efficient as the current implementation and in a state that is not basically less comprehensible than what I started with Since the change of the data structures and data flow requires changing all affected program parts to get to a working state, and since I don't have ambitions to do more than that which is required to get there, I don't see how the bulk of the work can sensibly avoid coming as one omnibus patch. Most changes, however, will be understandable quite well locally. For example, currently the code has a number of loops traversing one global linked list, ignoring all entries not relevant to a particular target, and doing something with the rest. Those loops generally are replaced with a simpler loop just running through a single _completely_ relevant linked list. Even while those replacements are scattered throughout the patch, they make sense without having to look at the rest of the patch. -- David Kastrup -- 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 2/2] setup: Don't dereference in-tree symlinks for absolute paths
Martin Erik Werner martinerikwer...@gmail.com writes:
In order to manipulate symliks in the
work tree using absolute paths, symlinks should only be dereferenced
outside the work tree.
I agree 100% with this reasoning (modulo s/symliks/symlinks/).
As to the implementation, it looks a bit overly complicated,
though. I haven't tried writing the same myself, but
* I suspect that strbuf would help simplifying the allocation and
deallocation;
* Also I suspect that use of string-list to split and then join is
making the code unnecessarily complex. In Python/Perl, that would
be a normal approach, but in C, it would be a lot simpler if you
prepare a writable temporary in wtpart[], walk from left to right
finding '/' and replacing it temporarily with NUL to terminate in
order to check with real_path(), restore the NUL back to '/' to
check deeper, and rinse and repeat.
Having said that, I am not absolutely sure if the repeated
calls to real_path() are doing the right thing, though ;-)
diff --git a/setup.c b/setup.c
index 5432a31..0789a96 100644
--- a/setup.c
+++ b/setup.c
@@ -22,11 +22,51 @@ char *prefix_path_gently(const char *prefix, int len,
const char *orig = path;
char *sanitized;
if (is_absolute_path(orig)) {
- const char *temp = real_path(path);
- sanitized = xmalloc(len + strlen(temp) + 1);
- strcpy(sanitized, temp);
+ int i, match;
+ size_t wtpartlen;
+ char *npath, *wtpart;
+ struct string_list list = STRING_LIST_INIT_DUP;
+ const char *work_tree = get_git_work_tree();
+ if (!work_tree)
+ return NULL;
+ npath = xmalloc(strlen(path) + 1);
if (remaining_prefix)
*remaining_prefix = 0;
+ if (normalize_path_copy_len(npath, path, remaining_prefix)) {
+ free(npath);
+ return NULL;
+ }
+
+ string_list_split(list, npath, '/', -1);
+ wtpart = xmalloc(strlen(npath) + 1);
+ i = 0;
+ match = 0;
+ strcpy(wtpart, list.items[i++].string);
+ strcat(wtpart, /);
+ if (strcmp(real_path(wtpart), work_tree) == 0) {
+ match = 1;
+ } else {
+ while (i list.nr) {
+ strcat(wtpart, list.items[i++].string);
+ if (strcmp(real_path(wtpart), work_tree) == 0) {
+ match = 1;
+ break;
+ }
+ strcat(wtpart, /);
+ }
+ }
+ string_list_clear(list, 0);
+ if (!match) {
+ free(npath);
+ free(wtpart);
+ return NULL;
+ }
+
+ wtpartlen = strlen(wtpart);
+ sanitized = xmalloc(strlen(npath) - wtpartlen);
+ strcpy(sanitized, npath + wtpartlen + 1);
+ free(npath);
+ free(wtpart);
} else {
sanitized = xmalloc(len + strlen(path) + 1);
if (len)
@@ -34,26 +74,10 @@ char *prefix_path_gently(const char *prefix, int len,
strcpy(sanitized + len, path);
if (remaining_prefix)
*remaining_prefix = len;
- }
- if (normalize_path_copy_len(sanitized, sanitized, remaining_prefix))
- goto error_out;
- if (is_absolute_path(orig)) {
- size_t root_len, len, total;
- const char *work_tree = get_git_work_tree();
- if (!work_tree)
- goto error_out;
- len = strlen(work_tree);
- root_len = offset_1st_component(work_tree);
- total = strlen(sanitized) + 1;
- if (strncmp(sanitized, work_tree, len) ||
- (len root_len sanitized[len] != '\0' sanitized[len]
!= '/')) {
- error_out:
+ if (normalize_path_copy_len(sanitized, sanitized,
remaining_prefix)) {
free(sanitized);
return NULL;
}
- if (sanitized[len] == '/')
- len++;
- memmove(sanitized, sanitized + len, total - len);
}
return sanitized;
}
diff --git a/t/t0060-path-utils.sh b/t/t0060-path-utils.sh
index 3a0677a..03a12ac 100755
--- a/t/t0060-path-utils.sh
+++ b/t/t0060-path-utils.sh
@@ -190,7 +190,7 @@ test_expect_success SYMLINKS 'real path works on
symlinks' '
test $sym = $(test-path-utils real_path $dir2/syml)
'
-test_expect_failure SYMLINKS 'prefix_path works with work tree symlinks' '
+test_expect_success SYMLINKS 'prefix_path works with work tree symlinks' '
[PATCH v3 4/4] merge-recursive.c: Tolerate missing files while refreshing index
Teach add_cacheinfo to tell make_cache_entry to skip refreshing stat
information when a file is missing from the work tree. We do not want
the index to be stat-dirty after the merge but also do not want to fail
when a file happens to be missing.
This fixes the 'merge-recursive w/ empty work tree - ours has rename'
case in t3030-merge-recursive.
Suggested-by: Elijah Newren new...@gmail.com
Signed-off-by: Brad King brad.k...@kitware.com
---
merge-recursive.c | 3 ++-
t/t3030-merge-recursive.sh | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index c3753c8..b8ea172 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -202,7 +202,8 @@ static int add_cacheinfo(unsigned int mode, const unsigned
char *sha1,
{
struct cache_entry *ce;
ce = make_cache_entry(mode, sha1 ? sha1 : null_sha1, path, stage,
- (refresh ? CE_MATCH_REFRESH : 0 ));
+ (refresh ? (CE_MATCH_REFRESH |
+ CE_MATCH_IGNORE_MISSING) : 0 ));
if (!ce)
return error(_(addinfo_cache failed for path '%s'), path);
return add_cache_entry(ce, options);
diff --git a/t/t3030-merge-recursive.sh b/t/t3030-merge-recursive.sh
index 3db3bf6..82e1854 100755
--- a/t/t3030-merge-recursive.sh
+++ b/t/t3030-merge-recursive.sh
@@ -518,7 +518,7 @@ test_expect_success 'reset and bind merge' '
'
-test_expect_failure 'merge-recursive w/ empty work tree - ours has rename' '
+test_expect_success 'merge-recursive w/ empty work tree - ours has rename' '
(
GIT_WORK_TREE=$PWD/ours-has-rename-work
export GIT_WORK_TREE
--
1.8.5.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
[PATCH v3 3/4] read-cache.c: Extend make_cache_entry refresh flag with options
Convert the make_cache_entry boolean 'refresh' argument to a more
general 'refresh_options' argument. Pass the value through to the
underlying refresh_cache_ent call. Add option CE_MATCH_REFRESH to
enable stat refresh. Update call sites to use the new signature.
Signed-off-by: Brad King brad.k...@kitware.com
---
cache.h | 4 +++-
merge-recursive.c | 3 ++-
read-cache.c | 21 +++--
3 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/cache.h b/cache.h
index c96ada7..e8820e1 100644
--- a/cache.h
+++ b/cache.h
@@ -487,7 +487,7 @@ extern int remove_file_from_index(struct index_state *,
const char *path);
#define ADD_CACHE_IMPLICIT_DOT 32 /* internal to git add -u/-A */
extern int add_to_index(struct index_state *, const char *path, struct stat *,
int flags);
extern int add_file_to_index(struct index_state *, const char *path, int
flags);
-extern struct cache_entry *make_cache_entry(unsigned int mode, const unsigned
char *sha1, const char *path, int stage, int refresh);
+extern struct cache_entry *make_cache_entry(unsigned int mode, const unsigned
char *sha1, const char *path, int stage, unsigned int refresh_options);
extern int ce_same_name(const struct cache_entry *a, const struct cache_entry
*b);
extern int index_name_is_other(const struct index_state *, const char *, int);
extern void *read_blob_data_from_index(struct index_state *, const char *,
unsigned long *);
@@ -500,6 +500,8 @@ extern void *read_blob_data_from_index(struct index_state
*, const char *, unsig
#define CE_MATCH_IGNORE_SKIP_WORKTREE 04
/* ignore non-existent files during stat update */
#define CE_MATCH_IGNORE_MISSING0x08
+/* enable stat refresh */
+#define CE_MATCH_REFRESH 0x10
extern int ie_match_stat(const struct index_state *, const struct cache_entry
*, struct stat *, unsigned int);
extern int ie_modified(const struct index_state *, const struct cache_entry *,
struct stat *, unsigned int);
diff --git a/merge-recursive.c b/merge-recursive.c
index a18bd15..c3753c8 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -201,7 +201,8 @@ static int add_cacheinfo(unsigned int mode, const unsigned
char *sha1,
const char *path, int stage, int refresh, int options)
{
struct cache_entry *ce;
- ce = make_cache_entry(mode, sha1 ? sha1 : null_sha1, path, stage,
refresh);
+ ce = make_cache_entry(mode, sha1 ? sha1 : null_sha1, path, stage,
+ (refresh ? CE_MATCH_REFRESH : 0 ));
if (!ce)
return error(_(addinfo_cache failed for path '%s'), path);
return add_cache_entry(ce, options);
diff --git a/read-cache.c b/read-cache.c
index d61846c..db3902e 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -15,7 +15,8 @@
#include strbuf.h
#include varint.h
-static struct cache_entry *refresh_cache_entry(struct cache_entry *ce, int
really);
+static struct cache_entry *refresh_cache_entry(struct cache_entry *ce,
+ unsigned int options);
/* Mask for the name length in ce_flags in the on-disk index */
@@ -696,7 +697,7 @@ int add_file_to_index(struct index_state *istate, const
char *path, int flags)
struct cache_entry *make_cache_entry(unsigned int mode,
const unsigned char *sha1, const char *path, int stage,
- int refresh)
+ unsigned int refresh_options)
{
int size, len;
struct cache_entry *ce;
@@ -716,10 +717,7 @@ struct cache_entry *make_cache_entry(unsigned int mode,
ce-ce_namelen = len;
ce-ce_mode = create_ce_mode(mode);
- if (refresh)
- return refresh_cache_entry(ce, 0);
-
- return ce;
+ return refresh_cache_entry(ce, refresh_options);
}
int ce_same_name(const struct cache_entry *a, const struct cache_entry *b)
@@ -1029,11 +1027,12 @@ static struct cache_entry *refresh_cache_ent(struct
index_state *istate,
struct stat st;
struct cache_entry *updated;
int changed, size;
+ int refresh = options CE_MATCH_REFRESH;
int ignore_valid = options CE_MATCH_IGNORE_VALID;
int ignore_skip_worktree = options CE_MATCH_IGNORE_SKIP_WORKTREE;
int ignore_missing = options CE_MATCH_IGNORE_MISSING;
- if (ce_uptodate(ce))
+ if (!refresh || ce_uptodate(ce))
return ce;
/*
@@ -1130,7 +1129,8 @@ int refresh_index(struct index_state *istate, unsigned
int flags,
int ignore_submodules = (flags REFRESH_IGNORE_SUBMODULES) != 0;
int first = 1;
int in_porcelain = (flags REFRESH_IN_PORCELAIN);
- unsigned int options = ((really ? CE_MATCH_IGNORE_VALID : 0) |
+ unsigned int options = (CE_MATCH_REFRESH |
+ (really ? CE_MATCH_IGNORE_VALID : 0) |
(not_new ? CE_MATCH_IGNORE_MISSING : 0));
const char *modified_fmt;
Re: How to get notified of new releases?
Matthieu Moy wrote: Robert Dailey wrote: Are there any dedicated mailing lists for git releases, or RSS feeds? Not sure if there's a Windows-dedicated list, but there's this: http://gitrss.q42.co.uk/ It filters the mailing-list posts starting with eg. [ANNOUNCE] and turns it into an RSS feed. There's also https://github.com/msysgit/msysgit/commits/master.atom, though that might be more activity than you're looking for (it would be the feed to follow if you want to build your own snapshots of git on Windows and try every change). Perhaps https://github.com/msysgit/msysgit/tags.atom would do the trick. Jonathan -- 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] builtin/blame.c: large-scale rewrite
David Kastrup d...@gnu.org writes:
The previous implementation uses a sorted linear list of struct
blame_entry in a struct scoreboard for organizing all partial or
completed work. Every task that is done requires going through the
whole list where most entries are not relevant to the task at hand.
This commit reorganizes the data structures in order to have each
remaining subtask work with its own sorted linear list it can work off
front to back. Subtasks are organized into struct origin chains
hanging off particular commits. Commits are organized into a priority
queue, processing them in commit date order in order to keep most of
the work affecting a particular blob collated even in the presence of
an extensive merge history. In that manner, linear searches can be
basically avoided anywhere. They still are done for identifying one
of multiple analyzed files in a given commit, but the degenerate case
of a single large file being assembled from a multitude of smaller
files in the past is not likely to occur often enough to warrant
special treatment.
---
Sign-off?
Actually, I'd like to take my previous suggestion to add this as
blame2 (to replace blame in the future) back. That was based on my
fear/hope to see an implementation based on a completely different
approach, but the basic premise of having one blame_entry record per
the lines of the final image in the scoreboard, using diff between
parents to the child to find common lines for passing the blame up,
etc. have not changed at all and the change is all about organizing
the pieces of data in a *much* *better* way to avoid needlessly
finding what we already have computed. It does look big (and if you
removed those #if 0/#endif, the final patch would be a lot bigger
because we will see a lot of deleted lines), but I do not think the
code conceptually is a different implementation to warrant create a
totally new blame2 and let it sit next to the original.
Looks nice overall.
diff --git a/builtin/blame.c b/builtin/blame.c
index ead6148..994a9e8 100644
--- a/builtin/blame.c
+++ b/builtin/blame.c
@@ -18,7 +18,9 @@
#include cache-tree.h
#include string-list.h
#include mailmap.h
+#include mergesort.h
#include parse-options.h
+#include prio-queue.h
#include utf8.h
#include userdiff.h
#include line-range.h
@@ -83,11 +85,43 @@ static unsigned blame_copy_score;
*/
struct origin {
int refcnt;
+ /* Record preceding blame record for this blob */
struct origin *previous;
+ /* origins are put in a list linked via `next' hanging off the
+ * corresponding commit's util field in order to make finding
+ * them fast. The presence in this chain does not count
+ * towards the origin's reference count. It is tempting to
+ * let it count as long as the commit is pending examination,
+ * but even under circumstances where the commit will be
+ * present multiple times in the priority queue of unexamined
+ * commits, processing the first instance will not leave any
+ * work requiring the origin data for the second instance. An
+ * interspersed commit changing that would have to be
+ * preexisting with a different ancestry and with the same
+ * commit date in order to wedge itself between two instances
+ * of the same commit in the priority queue _and_ produce
+ * blame entries relevant for it. While we don't want to let
+ * us get tripped up by this case, it certainly does not seem
+ * worth optimizing for.
+ */
Style; please make /* and */ sit on their own line without anything
else in multi-line comments.
+ struct origin *next;
struct commit *commit;
+ /* `suspects' contains blame entries that may be attributed to
+ * this origin's commit or to parent commits. When a commit
+ * is being processed, all suspects will be moved, either by
+ * assigning them to an origin in a different commit, or by
+ * shipping them to the scoreboard's ent list because they
+ * cannot be attributed to a different commit.
+ */
+ struct blame_entry *suspects;
mmfile_t file;
unsigned char blob_sha1[20];
unsigned mode;
+ /* shipped gets set when shipping any suspects to the final
+ * blame list instead of other commits
+ */
+ char shipped;
Unused?
+ char guilty;
char path[FLEX_ARRAY];
};
@@ -176,10 +210,23 @@ static inline struct origin *origin_incref(struct
origin *o)
static void origin_decref(struct origin *o)
{
if (o --o-refcnt = 0) {
+ struct origin *p, *l = NULL;
if (o-previous)
origin_decref(o-previous);
free(o-file.ptr);
- free(o);
+ /* Should be present exactly once in commit chain */
+ for (p = o-commit-util; p; l = p, p = p-next) {
+ if (p == o)
+
Re: [PATCH] tree_entry_interesting: match against all pathspecs
Duy Nguyen pclo...@gmail.com writes: Ack. Perhaps this on top to verify it -- 8 -- diff --git a/t/t4010-diff-pathspec.sh b/t/t4010-diff-pathspec.sh index af5134b..d9f37c3 100755 --- a/t/t4010-diff-pathspec.sh +++ b/t/t4010-diff-pathspec.sh @@ -110,4 +110,17 @@ test_expect_success 'diff-tree -r with wildcard' ' test_cmp expected result ' +test_expect_success 'diff multiple wildcard pathspecs' ' + mkdir path2 + echo rezrov path2/file1 + git update-index --add path2/file1 + tree3=`git write-tree` + git diff --name-only $tree $tree3 -- path2*1 path1*1 actual + cat EOF expect +path1/file1 +path2/file1 +EOF + test_cmp expect actual +' + test_done -- 8 -- Thanks, both. Will queue. -- 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 v3 2/4] read-cache.c: Refactor --ignore-missing implementation
Brad King brad.k...@kitware.com writes:
Move lstat ENOENT handling from refresh_index to refresh_cache_ent and
activate it with a new CE_MATCH_IGNORE_MISSING option. This will allow
other call paths into refresh_cache_ent to use the feature.
Signed-off-by: Brad King brad.k...@kitware.com
---
Good!
I forgot that we had update-index --ignore-missing --refresh, and
that is conceptually the thing you want to use in your perform
merge-recursive in an empty tree while pretending that the working
tree is fully populated and up-to-date scenario.
cache.h | 2 ++
read-cache.c | 8 +---
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/cache.h b/cache.h
index c9efe88..c96ada7 100644
--- a/cache.h
+++ b/cache.h
@@ -498,6 +498,8 @@ extern void *read_blob_data_from_index(struct index_state
*, const char *, unsig
#define CE_MATCH_RACY_IS_DIRTY 02
/* do stat comparison even if CE_SKIP_WORKTREE is true */
#define CE_MATCH_IGNORE_SKIP_WORKTREE04
+/* ignore non-existent files during stat update */
+#define CE_MATCH_IGNORE_MISSING 0x08
extern int ie_match_stat(const struct index_state *, const struct
cache_entry *, struct stat *, unsigned int);
extern int ie_modified(const struct index_state *, const struct cache_entry
*, struct stat *, unsigned int);
diff --git a/read-cache.c b/read-cache.c
index 33dd676..d61846c 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -1031,6 +1031,7 @@ static struct cache_entry *refresh_cache_ent(struct
index_state *istate,
int changed, size;
int ignore_valid = options CE_MATCH_IGNORE_VALID;
int ignore_skip_worktree = options CE_MATCH_IGNORE_SKIP_WORKTREE;
+ int ignore_missing = options CE_MATCH_IGNORE_MISSING;
if (ce_uptodate(ce))
return ce;
@@ -1050,6 +1051,8 @@ static struct cache_entry *refresh_cache_ent(struct
index_state *istate,
}
if (lstat(ce-name, st) 0) {
+ if (ignore_missing errno == ENOENT)
+ return ce;
if (err)
*err = errno;
return NULL;
@@ -1127,7 +1130,8 @@ int refresh_index(struct index_state *istate, unsigned
int flags,
int ignore_submodules = (flags REFRESH_IGNORE_SUBMODULES) != 0;
int first = 1;
int in_porcelain = (flags REFRESH_IN_PORCELAIN);
- unsigned int options = really ? CE_MATCH_IGNORE_VALID : 0;
+ unsigned int options = ((really ? CE_MATCH_IGNORE_VALID : 0) |
+ (not_new ? CE_MATCH_IGNORE_MISSING : 0));
const char *modified_fmt;
const char *deleted_fmt;
const char *typechange_fmt;
@@ -1176,8 +1180,6 @@ int refresh_index(struct index_state *istate, unsigned
int flags,
if (!new) {
const char *fmt;
- if (not_new cache_errno == ENOENT)
- continue;
if (really cache_errno == EINVAL) {
/* If we are doing --really-refresh that
* means the index is not valid anymore.
--
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: [ANNOUNCE] Git v1.9-rc0
On Tue, Jan 21, 2014 at 02:14:22PM -0800, Junio C Hamano wrote: It has been reported that turning git.rc into git.res does not like the new 2-dewey-decimal release numbering scheme; packagers of various distro might find similar issues in their build procedures, in which case they have about 3 weeks to update them until the final release. The change in release numbering also breaks down gitolite v2 setups. One of the gitolite commands, gl-compile-conf, expects the output of git --version to match /git version (\d+)\.(\d+)\.(\d+)/. I have no idea how big problem it is, as I don't know how many people hasn't migrate to gitolite v3 yet. -- Kacper -- 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: [ANNOUNCE] Git v1.9-rc0
Hi, Kacper Kornet wrote: The change in release numbering also breaks down gitolite v2 setups. One of the gitolite commands, gl-compile-conf, expects the output of git --version to match /git version (\d+)\.(\d+)\.(\d+)/. I have no idea how big problem it is, as I don't know how many people hasn't migrate to gitolite v3 yet. http://qa.debian.org/popcon.php?package=gitolite says there are some. I guess soon we'll see if there are complaints. http://gitolite.com/gitolite/migr.html says gitolite v2 is still maintained. Hopefully the patch to gitolite v2 to fix this would not be too invasive --- e.g., how about this patch (untested)? Thanks, Jonathan diff --git i/src/gl-compile-conf w/src/gl-compile-conf index f497ae5..8508313 100755 --- i/src/gl-compile-conf +++ w/src/gl-compile-conf @@ -394,8 +394,9 @@ die the server. If it is not, please edit ~/.gitolite.rc on the server and set the \$GIT_PATH variable to the correct value\n unless $git_version; -my ($gv_maj, $gv_min, $gv_patchrel) = ($git_version =~ m/git version (\d+)\.(\d+)\.(\d+)/); +my ($gv_maj, $gv_min, $gv_patchrel) = ($git_version =~ m/git version (\d+)\.(\d+)\.([^.-]*)/); die $ABRT I can't understand $git_version\n unless ($gv_maj = 1); +$gv_patchrel = 0 unless ($gv_patchrel =~ m/^\d+$/); $git_version = $gv_maj*1 + $gv_min*100 + $gv_patchrel; # now it's normalised die \n\t\t* AAARGH! *\n . -- 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] builtin/blame.c: large-scale rewrite
Junio C Hamano gits...@pobox.com writes:
David Kastrup d...@gnu.org writes:
The previous implementation uses a sorted linear list of struct
blame_entry in a struct scoreboard for organizing all partial or
completed work. Every task that is done requires going through the
whole list where most entries are not relevant to the task at hand.
This commit reorganizes the data structures in order to have each
remaining subtask work with its own sorted linear list it can work off
front to back. Subtasks are organized into struct origin chains
hanging off particular commits. Commits are organized into a priority
queue, processing them in commit date order in order to keep most of
the work affecting a particular blob collated even in the presence of
an extensive merge history. In that manner, linear searches can be
basically avoided anywhere. They still are done for identifying one
of multiple analyzed files in a given commit, but the degenerate case
of a single large file being assembled from a multitude of smaller
files in the past is not likely to occur often enough to warrant
special treatment.
---
Sign-off?
Not while this is not fit for merging because of #if 0 etc and missing
functionality. This is just for review.
Actually, I'd like to take my previous suggestion to add this as
blame2 (to replace blame in the future) back. That was based on my
fear/hope to see an implementation based on a completely different
approach, but the basic premise of having one blame_entry record per
the lines of the final image in the scoreboard, using diff between
parents to the child to find common lines for passing the blame up,
etc. have not changed at all and the change is all about organizing
the pieces of data in a *much* *better* way to avoid needlessly
finding what we already have computed.
Yes. Basically, the call graph outside of blame.c itself should be
pretty much the same.
Style; please make /* and */ sit on their own line without anything
else in multi-line comments.
Will do.
+struct origin *next;
struct commit *commit;
+/* `suspects' contains blame entries that may be attributed to
+ * this origin's commit or to parent commits. When a commit
+ * is being processed, all suspects will be moved, either by
+ * assigning them to an origin in a different commit, or by
+ * shipping them to the scoreboard's ent list because they
+ * cannot be attributed to a different commit.
+ */
+struct blame_entry *suspects;
mmfile_t file;
unsigned char blob_sha1[20];
unsigned mode;
+/* shipped gets set when shipping any suspects to the final
+ * blame list instead of other commits
+ */
+char shipped;
Unused?
More like added, forgotten, added under yet another name:
+char guilty;
I'll have to decide which one to keep.
+/* Should be present exactly once in commit chain */
+for (p = o-commit-util; p; l = p, p = p-next) {
+if (p == o)
+{
Style; please have { sit with the control structure that opens the
block, unless it is the opening brace of the function body or
struct/union definition.
Ok.
+static struct blame_entry *
+blame_merge(struct blame_entry *list1,
+struct blame_entry *list2)
Style; we do not do GNU-ish function name begins a line. Even
though I personally find it easier to use for things like 'grep',
that is not the style we use around here.
Ok. I'm also certain to have a few space between function name and
arguments left and will grep for those before submitting the next
version.
Next version will at least include -M option, possibly leaving -C for
later.
--
David Kastrup
--
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] repack.c: Use move_temp_to_file() instead of rename()
In a1bbc6c0 a shell command mv -f was replaced with the rename() function.
Use move_temp_to_file() from sha1_file.c instead of rename().
This is in line with the handling of other Git internal tmp files,
and calls adjust_shared_perm()
Signed-off-by: Torsten Bögershausen tbo...@web.de
---
Thanks for all comments.
I haven't been able to reproduce the problem here.
Tips and information how to reproduce it are wellcome.
I think this patch makes sense to support core.sharedRepository(),
but I haven't made a test case for the pack/idx files.
Jochen, doess this patch fix your problem, or do we need
another patch on top of this?
builtin/repack.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/builtin/repack.c b/builtin/repack.c
index ba66c6e..4b6d663 100644
--- a/builtin/repack.c
+++ b/builtin/repack.c
@@ -271,7 +271,7 @@ int cmd_repack(int argc, const char **argv, const char
*prefix)
if (unlink(fname_old))
failed = 1;
- if (!failed rename(fname, fname_old)) {
+ if (!failed move_temp_to_file(fname, fname_old)) {
free(fname);
failed = 1;
break;
@@ -288,7 +288,7 @@ int cmd_repack(int argc, const char **argv, const char
*prefix)
char *fname, *fname_old;
fname = mkpathdup(%s/%s, packdir, item-string);
fname_old = mkpath(%s/old-%s, packdir, item-string);
- if (rename(fname_old, fname))
+ if (move_temp_to_file(fname_old, fname))
string_list_append(rollback_failure, fname);
free(fname);
}
@@ -324,7 +324,7 @@ int cmd_repack(int argc, const char **argv, const char
*prefix)
statbuffer.st_mode = ~(S_IWUSR | S_IWGRP |
S_IWOTH);
chmod(fname_old, statbuffer.st_mode);
}
- if (rename(fname_old, fname))
+ if (move_temp_to_file(fname_old, fname))
die_errno(_(renaming '%s' failed), fname_old);
free(fname);
free(fname_old);
--
1.8.5.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 v3 17/17] Documentation: add documentation for 'git interpret-trailers'
From: Eric Sunshine sunsh...@sunshineco.com On Sun, Jan 26, 2014 at 12:00 PM, Christian Couder chrisc...@tuxfamily.org wrote: Signed-off-by: Christian Couder chrisc...@tuxfamily.org --- diff --git a/Documentation/git-interpret-trailers.txt b/Documentation/git-interpret-trailers.txt new file mode 100644 index 000..f74843e --- /dev/null +++ b/Documentation/git-interpret-trailers.txt @@ -0,0 +1,137 @@ +git-interpret-trailers(1) += + +NAME + +git-interpret-trailers - help add stuctured information into commit messages + +SYNOPSIS + +[verse] +'git interpret-trailers' [--trim-empty] [--infile=file] [token[=value]...] Would it be more consistent with existing documentation to format this as so? [--infile=file] [token[=value]]... No, it would be very inconsistent: $ grep '\.\.\.\]' *.txt | wc -l 103 $ grep '\]\.\.\.' *.txt | wc -l 0 +DESCRIPTION +--- +Help add RFC 822 like headers, called 'trailers', at the end of the s/822 like/822-like/ Ok. Was the suggestion, early in the discussion, to use footer rather than trailer dismissed? During the early discussions people initially talked about footer while Junio and others talked about trailer. See: http://thread.gmane.org/gmane.comp.version-control.git/236429/ http://thread.gmane.org/gmane.comp.version-control.git/236770/ I have no preference for one or the other, but by default I use what Junio uses. +otherwise free-form part of a commit message. + +Unless `--infile=file` is used, this command is a filter. It reads the +standard input for a commit message and apply the `token` arguments, s/apply/applies/ Ok. +if any, to this message. The resulting message is emited on the +standard output. + +Some configuration variables control the way the `token` arguments are +applied to the message and the way any existing trailer in the message +is changed. They also make it possible to automatically add some +trailers. + +By default, a 'token=value' or 'token:value' argument will be added +only if no trailer with the same (token, value) pair is already in the +message. The 'token' and 'value' parts will be trimmed to remove +starting and trailing white spaces, and the resulting trimmed 'token' Other git documentation uniformly spells it as whitespace rather than white spaces. You are right I will change that. +and 'value' will appear in the message like this: + + +token: value + + +By default, if there are already trailers with the same 'token' the +trailer will appear just after the last trailer with the same It might be a bit clearer to say the _new_ trailer will appear Ok. +'token'. Otherwise it will appear at the end of the message. + +Note that 'trailers' do not follow and are not intended to follow many +rules that are in RFC 822. For example they do not follow the line +breaking rules, the encoding rules and probably many other rules. + +Trailers have become a de facto standard way to add helpful structured +information into commit messages. For example the well known +Signed-off-by: trailer is used by many projects like the Linux +kernel and Git. This justification paragraph might make more sense near or at the very the top of the Description section. Yeah, or maybe I can remove it entirely. +OPTIONS +--- +--trim-empty:: + If the 'value' part of any trailer contains onlywhite spaces, s/onlywhite spaces/only whitespace/ Ok. + the whole trailer will be removed from the resulting message. + +infile=file:: + Read the commit message from `file` instead of the standard + input. + +CONFIGURATION VARIABLES +--- + +trailer.token.key:: + This 'key' will be used instead of 'token' in the + trailer. After some alphanumeric characters, it can contain + some non alphanumeric characters like ':', '=' or '#' that will + be used instead of ':' to separate the token from the value in + the trailer, though the default ':' is more standard. + +trailer.token.where:: + This can be either `after`, which is the default, or + `before`. If it is `before`, then a trailer with the specified + token, will appear before, instead of after, other trailers + with the same token, or otherwise at the beginning, instead of + at the end, of all the trailers. + +trailer.token.ifexist:: + This option makes it possible to chose what action will be s/chose/choose/ Ok. + performed when there is already at least one trailer with the + same token in the message. ++ +The valid values for this option are: `addIfDifferent` (this is the +default), `addIfDifferentNeighbor`, `add`, `overwrite` or `doNothing`. ++ +With `addIfDifferent`, a new trailer will be added only if no trailer +with the
Re: [PATCH 3/3] builtin/blame.c: large-scale rewrite
David Kastrup d...@gnu.org writes: Junio C Hamano gits...@pobox.com writes: David Kastrup d...@gnu.org writes: The previous implementation uses a sorted linear list of struct blame_entry in a struct scoreboard for organizing all partial or completed work. Every task that is done requires going through the whole list where most entries are not relevant to the task at hand. This commit reorganizes the data structures in order to have each remaining subtask work with its own sorted linear list it can work off front to back. Subtasks are organized into struct origin chains hanging off particular commits. Commits are organized into a priority queue, processing them in commit date order in order to keep most of the work affecting a particular blob collated even in the presence of an extensive merge history. In that manner, linear searches can be basically avoided anywhere. They still are done for identifying one of multiple analyzed files in a given commit, but the degenerate case of a single large file being assembled from a multitude of smaller files in the past is not likely to occur often enough to warrant special treatment. --- Sign-off? Not while this is not fit for merging because of #if 0 etc and missing functionality. This is just for review. That is not what Signing off a patch means, though ;-) Actually, I'd like to take my previous suggestion to add this as blame2 (to replace blame in the future) back. That was based on my fear/hope to see an implementation based on a completely different approach, but the basic premise of having one blame_entry record per the lines of the final image in the scoreboard, using diff between parents to the child to find common lines for passing the blame up, etc. have not changed at all and the change is all about organizing the pieces of data in a *much* *better* way to avoid needlessly finding what we already have computed. Yes. Basically, the call graph outside of blame.c itself should be pretty much the same. ... Ok. I'm also certain to have a few space between function name and arguments left and will grep for those before submitting the next version. Next version will at least include -M option, possibly leaving -C for later. OK. As we do not want to break the build in the middle of the series, but we still want to keep the individual steps reviewable incrementally, I would think the best structure would be have the series that consists of multiple steps the basic infrastructure is there, but no rename following, and neither -M or -C works, now renames are followed, now -M works, etc., with tests that are not yet working (in the beginning, most of git blame test may no longer work until the series is finished) marked with s/test_expect_success/test_expect_failure/ and turn expect_failure into expect_success as the series advances. That way, we may get a better picture of what each step achieves. I dunno. -- 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 v3 00/17] Add interpret-trailers builtin
Is this from the same Christian?
The series seems to have unusually high rate of style violations
compared to the usual submission, like these:
ERROR: open brace '{' following function declarations go on the next line
#78: FILE: trailer.c:44:
+static size_t alnum_len(const char *buf, size_t len) {
ERROR: trailing statements should be on next line
#79: FILE: trailer.c:45:
+ while (--len = 0 !isalnum(buf[len]));
ERROR: space required before the open parenthesis '('
#70: FILE: trailer.c:90:
+ switch(arg_tok-conf-if_exist) {
WARNING: braces {} are not necessary for any arm of this statement
#66: FILE: trailer.c:270:
+ if (!strcasecmp(doNothing, value)) {
[...]
+ } else if (!strcasecmp(add, value)) {
[...]
+ } else
[...]
ERROR: that open brace { should be on the previous line
#96: FILE: trailer.c:300:
+ for (previous = NULL, item = first_conf_item;
+item;
+previous = item, item = item-next)
+ {
Just trying to see if there is an impersonation ;-)
--
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 v3 17/17] Documentation: add documentation for 'git interpret-trailers'
Christian Couder chrisc...@tuxfamily.org writes: +'git interpret-trailers' [--trim-empty] [--infile=file] [token[=value]...] Would it be more consistent with existing documentation to format this as so? [--infile=file] [token[=value]]... No, it would be very inconsistent: $ grep '\.\.\.\]' *.txt | wc -l 103 $ grep '\]\.\.\.' *.txt | wc -l 0 I have a feeling that you are missing the point Eric is making. The value given to the --infile option can be anything, i.e. 'file' there is a placeholder, hence --infile=file not --infile=file as you wrote. Also I think [token[=value]]... is the correct way to spell that there can be 0 or more token[=value]. token[=value] in the original does not make any sense, as is meant to say this thing is a placeholder, and we do not try to say, with the string inside , what shape that placeholder takes. In fact '=' part is _not_ a placeholder but is required syntactically when you want to supply a value to the token, so the original doubly is incorrect. I find it a bad taste to allow unbound set of token on the LHS of '=' on the command line, but that is a separate issue in the design, not in the documentation of the design. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] builtin/blame.c: large-scale rewrite
Junio C Hamano gits...@pobox.com writes:
David Kastrup d...@gnu.org writes:
Junio C Hamano gits...@pobox.com writes:
David Kastrup d...@gnu.org writes:
The previous implementation uses a sorted linear list of struct
blame_entry in a struct scoreboard for organizing all partial or
completed work. Every task that is done requires going through the
whole list where most entries are not relevant to the task at hand.
This commit reorganizes the data structures in order to have each
remaining subtask work with its own sorted linear list it can work off
front to back. Subtasks are organized into struct origin chains
hanging off particular commits. Commits are organized into a priority
queue, processing them in commit date order in order to keep most of
the work affecting a particular blob collated even in the presence of
an extensive merge history. In that manner, linear searches can be
basically avoided anywhere. They still are done for identifying one
of multiple analyzed files in a given commit, but the degenerate case
of a single large file being assembled from a multitude of smaller
files in the past is not likely to occur often enough to warrant
special treatment.
---
Sign-off?
Not while this is not fit for merging because of #if 0 etc and missing
functionality. This is just for review.
That is not what Signing off a patch means, though ;-)
From Documentation/SubmittingPatches:
The sign-off is a simple line at the end of the explanation for
the patch, which certifies that you wrote it or otherwise have
the right to pass it on as a open-source patch. The rules are
pretty simple: if you can certify the below:
Developer's Certificate of Origin 1.1
By making a contribution to this project, I certify that:
Well, and the patch is not in a state where I want to contribute it to
this project. Basically I first want to bring it into a state where
I am not embarrassed by having my name attached to it.
Yes, that's probably not quite the idea of signing off...
OK. As we do not want to break the build in the middle of the
series, but we still want to keep the individual steps reviewable
incrementally, I would think the best structure would be have the
series that consists of multiple steps the basic infrastructure is
there, but no rename following, and neither -M or -C works, now
renames are followed, now -M works, etc., with tests that are not
yet working (in the beginning, most of git blame test may no
longer work until the series is finished) marked with
s/test_expect_success/test_expect_failure/
and turn expect_failure into expect_success as the series advances.
That way, we may get a better picture of what each step achieves. I
dunno.
Seems a bit pointless as the various functionalities are implemented in
separate code passages. Basically the only common code is
static void pass_blame(struct scoreboard *sb, struct origin *origin, int opt)
{
struct rev_info *revs = sb-revs;
int i, pass, num_sg;
struct commit *commit = origin-commit;
[...]
#if 0
/*
* Optionally find moves in parents' files.
*/
if (opt PICKAXE_BLAME_MOVE)
for (i = 0, sg = first_scapegoat(revs, commit);
i num_sg sg;
sg = sg-next, i++) {
struct origin *porigin = sg_origin[i];
if (!porigin)
continue;
if (find_move_in_parent(sb, origin, porigin))
goto finish;
}
/*
* Optionally find copies from parents' files.
*/
if (opt PICKAXE_BLAME_COPY)
for (i = 0, sg = first_scapegoat(revs, commit);
i num_sg sg;
sg = sg-next, i++) {
struct origin *porigin = sg_origin[i];
if (find_copy_in_parent(sb, origin, sg-item,
porigin, opt))
goto finish;
}
#endif
finish:
for (i = 0; i num_sg; i++) {
if (sg_origin[i]) {
drop_origin_blob(sg_origin[i]);
origin_decref(sg_origin[i]);
}
}
drop_origin_blob(origin);
if (sg_buf != sg_origin)
free(sg_origin);
}
So what will happen here is that the #if 0 will get removed again, and
there will be somewhat different code for
/*
* Optionally find moves in parents' files.
*/
and then somewhat different code for
/*
* Optionally find copies from parents' files.
*/
and some section elsewhere with the functions being called here. It's
not like there will be significant intersection between the
same-file-and-rename code and the move-in-file or
[ANNOUNCE] Git v1.9-rc1
The first release candidate for this cycle, Git v1.9-rc1, is now available for testing at the usual places. The release tarballs are found at: http://code.google.com/p/git-core/downloads/list and their SHA-1 checksums are: acc2343b4a0a0ed1920036fde1b1bf2109feb969 git-1.9.rc1.tar.gz 37bc0f5ef8f777a980304d58df003515364a54d0 git-htmldocs-1.9.rc1.tar.gz c378ff4aca0737c9773181f4e97d36a8d8413e9a git-manpages-1.9.rc1.tar.gz The following public repositories all have a copy of the v1.9-rc1 tag and the master branch that the tag points at: url = https://kernel.googlesource.com/pub/scm/git/git url = git://repo.or.cz/alt-git.git url = https://code.google.com/p/git-core/ url = git://git.sourceforge.jp/gitroot/git-core/git.git url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core url = https://github.com/gitster/git Git v1.9 Release Notes (draft) == Backward compatibility notes git submodule foreach $cmd $args used to treat $cmd $args the same way ssh did, concatenating them into a single string and letting the shell unquote. Careless users who forget to sufficiently quote $args gets their argument split at $IFS whitespaces by the shell, and got unexpected results due to this. Starting from this release, the command line is passed directly to the shell, if it has an argument. Read-only support for experimental loose-object format, in which users could optionally choose to write in their loose objects for a short while between v1.4.3 to v1.5.3 era, has been dropped. The meanings of --tags option to git fetch has changed; the command fetches tags _in addition to_ what are fetched by the same command line without the option. The way git push $there $what interprets $what part given on the command line, when it does not have a colon that explicitly tells us what ref at the $there repository is to be updated, has been enhanced. A handful of ancient commands that have long been deprecated are finally gone (repo-config, tar-tree, lost-found, and peek-remote). Backward compatibility notes (for Git 2.0) -- When git push [$there] does not say what to push, we have used the traditional matching semantics so far (all your branches were sent to the remote as long as there already are branches of the same name over there). In Git 2.0, the default will change to the simple semantics, which pushes: - only the current branch to the branch with the same name, and only when the current branch is set to integrate with that remote branch, if you are pushing to the same remote as you fetch from; or - only the current branch to the branch with the same name, if you are pushing to a remote that is not where you usually fetch from. Use the user preference configuration variable push.default to change this. If you are an old-timer who is used to the matching semantics, you can set the variable to matching to keep the traditional behaviour. If you want to live in the future early, you can set it to simple today without waiting for Git 2.0. When git add -u (and git add -A) is run inside a subdirectory and does not specify which paths to add on the command line, it will operate on the entire tree in Git 2.0 for consistency with git commit -a and other commands. There will be no mechanism to make plain git add -u behave like git add -u .. Current users of git add -u (without a pathspec) should start training their fingers to explicitly say git add -u . before Git 2.0 comes. A warning is issued when these commands are run without a pathspec and when you have local changes outside the current directory, because the behaviour in Git 2.0 will be different from today's version in such a situation. In Git 2.0, git add path will behave as git add -A path, so that git add dir/ will notice paths you removed from the directory and record the removal. Versions before Git 2.0, including this release, will keep ignoring removals, but the users who rely on this behaviour are encouraged to start using git add --ignore-removal path now before 2.0 is released. The default prefix for git svn will change in Git 2.0. For a long time, git svn created its remote-tracking branches directly under refs/remotes, but it will place them under refs/remotes/origin/ unless it is told otherwise with its --prefix option. Updates since v1.8.5 Foreign interfaces, subsystems and ports. * The HTTP transport, when talking GSS-Negotiate, uses 100 Continue response to avoid having to rewind and resend a large payload, which may not be always doable. * Various bugfixes to remote-bzr and remote-hg (in contrib/). * The build procedure is aware of MirBSD now. * Various git p4, git svn and gitk updates. UI, Workflows Features * Fetching from a shallowly-cloned repository used to be forbidden, primarily because the codepaths involved were not carefully vetted and we did not bother
What's cooking in git.git (Jan 2014, #05; Mon, 27)
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
The tip of 'master' is at 1.9-rc1; as far as new features are
concerned, this is pretty much it until the final.
On the maintenance track, we may have another 1.8.5.x maintenance
release before 1.9 final is tagged in 2-3 weeks.
You can find the changes described here in the integration branches
of the repositories listed at
http://git-blame.blogspot.com/p/git-public-repositories.html
--
[Graduated to master]
* ab/subtree-doc (2014-01-13) 1 commit
(merged to 'next' on 2014-01-22 at e352c75)
+ subtree: fix argument validation in add/pull/push
* ef/mingw-write (2014-01-17) 2 commits
(merged to 'next' on 2014-01-22 at b9ddab2)
+ mingw: remove mingw_write
+ prefer xwrite instead of write
* jc/maint-pull-docfix (2014-01-14) 2 commits
(merged to 'next' on 2014-01-22 at 2e62ef4)
+ Documentation: git pull does not have the -m option
+ Merge branch 'jc/maint-pull-docfix-for-409b8d82' into jc/maint-pull-docfix
(this branch uses jc/maint-pull-docfix-for-409b8d82.)
* jc/revision-range-unpeel (2014-01-15) 2 commits
(merged to 'next' on 2014-01-22 at ab2a159)
+ revision: propagate flag bits from tags to pointees
+ revision: mark contents of an uninteresting tree uninteresting
git log --left-right A...B lost the leftness of commits
reachable from A when A is a tag as a side effect of a recent
bugfix. This is a regression in 1.8.4.x series.
* jk/allow-fetch-onelevel-refname (2014-01-15) 1 commit
(merged to 'next' on 2014-01-22 at 15089b1)
+ fetch-pack: do not filter out one-level refs
git clone would fail to clone from a repository that has a ref
directly under refs/, e.g. refs/stash, because different
validation paths do different things on such a refname. Loosen the
client side's validation to allow such a ref.
* jk/complete-merge-base (2014-01-13) 2 commits
(merged to 'next' on 2014-01-22 at 91c428d)
+ completion: handle --[no-]fork-point options to git-rebase
+ completion: complete merge-base options
* jk/diff-filespec-cleanup (2014-01-17) 5 commits
(merged to 'next' on 2014-01-22 at fb26e43)
+ diff_filespec: use only 2 bits for is_binary flag
+ diff_filespec: reorder is_binary field
+ diff_filespec: drop xfrm_flags field
+ diff_filespec: drop funcname_pattern_ident field
+ diff_filespec: reorder dirty_submodule macro definitions
* jk/interpret-branch-name-fix (2014-01-15) 5 commits
(merged to 'next' on 2014-01-22 at f113c68)
+ interpret_branch_name: find all possible @-marks
+ interpret_branch_name: avoid @{upstream} past colon
+ interpret_branch_name: always respect namelen parameter
+ interpret_branch_name: rename cp variable to at
+ interpret_branch_name: factor out upstream handling
(this branch is used by jk/branch-at-publish-rebased.)
Fix a handful of bugs around interpreting $branch@{upstream}
notation and its lookalike, when $branch part has interesting
characters, e.g. @, and :.
* jk/mark-edges-uninteresting (2014-01-21) 2 commits
(merged to 'next' on 2014-01-22 at d8807c4)
+ list-objects: only look at cmdline trees with edge_hint
+ t/perf: time rev-list with UNINTERESTING commits
Fix to regression in v1.8.4.x and later.
* jk/test-fixes (2014-01-23) 2 commits
(merged to 'next' on 2014-01-23 at 6515089)
+ t7700: do not use touch unnecessarily
+ t7501: fix empty commit test with NO_PERL
* jn/ignore-doc (2014-01-16) 1 commit
(merged to 'next' on 2014-01-22 at a07ac63)
+ gitignore doc: add global gitignore to synopsis
Explicitly list $HOME/.config/git/ignore as one of the places you
can use to keep ignore patterns that depend on your personal choice
of tools, e.g. *~ for Emacs users.
* mh/attr-macro-doc (2014-01-14) 1 commit
(merged to 'next' on 2014-01-22 at e3ed767)
+ gitattributes: document more clearly where macros are allowed
* mh/retire-ref-fetch-rules (2014-01-14) 1 commit
(merged to 'next' on 2014-01-22 at 753b1f6)
+ refname_match(): always use the rules in ref_rev_parse_rules
Code simplification.
* mh/safe-create-leading-directories (2014-01-21) 17 commits
(merged to 'next' on 2014-01-22 at ad38e73)
+ rename_tmp_log(): on SCLD_VANISHED, retry
+ rename_tmp_log(): limit the number of remote_empty_directories() attempts
+ rename_tmp_log(): handle a possible mkdir/rmdir race
+ rename_ref(): extract function rename_tmp_log()
+ remove_dir_recurse(): handle disappearing files and directories
+ remove_dir_recurse(): tighten condition for removing unreadable dir
+ lock_ref_sha1_basic(): if locking fails with ENOENT, retry
+ lock_ref_sha1_basic(): on SCLD_VANISHED, retry
+ safe_create_leading_directories(): add new error value SCLD_VANISHED
+ cmd_init_db(): when creating directories, handle errors conservatively
+ safe_create_leading_directories(): introduce enum for return values
+
Re: [PATCH v2 0/9] About the trailing slashes
Thanks; will try to rebase on top of more recent codebase and then review. -- 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] diff: turn skip_stat_unmatch on selectively
skip_stat_unmatch flag is added in fb13227 (git-diff: squelch empty
diffs - 2007-08-03) to ignore empty diffs caused by stat-only
dirtiness. In some diff case, stat is not involved at all. While
the code is written in a way that no expensive I/O is done, we still
need to move all file pairs from the old queue to the new queue in
diffcore_skip_stat_unmatch().
Only enable it when worktree is involved: diff and diff rev.
This should help track down how skip_stat_unmatch is actually used
when bugs occur.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
This replaces 'diff: turn off skip_stat_unmatch on diff --cached'
The previous patch obviously leaves skip_stat_unmatch on in diff
rev rev and maybe other cases.
builtin/diff.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/builtin/diff.c b/builtin/diff.c
index 0f247d2..88542d9 100644
--- a/builtin/diff.c
+++ b/builtin/diff.c
@@ -150,6 +150,7 @@ static int builtin_diff_index(struct rev_info *revs,
perror(read_cache_preload);
return -1;
}
+ revs-diffopt.skip_stat_unmatch = !!diff_auto_refresh_index;
} else if (read_cache() 0) {
perror(read_cache);
return -1;
@@ -252,6 +253,7 @@ static int builtin_diff_files(struct rev_info *revs, int
argc, const char **argv
perror(read_cache_preload);
return -1;
}
+ revs-diffopt.skip_stat_unmatch = !!diff_auto_refresh_index;
return run_diff_files(revs, options);
}
@@ -343,7 +345,6 @@ int cmd_diff(int argc, const char **argv, const char
*prefix)
diff_no_index(rev, argc, argv, prefix);
/* Otherwise, we are doing the usual git diff */
- rev.diffopt.skip_stat_unmatch = !!diff_auto_refresh_index;
/* Scale to real terminal size and respect statGraphWidth config */
rev.diffopt.stat_width = -1;
--
1.8.5.2.240.g8478abd
--
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: [ANNOUNCE] Git v1.9-rc0
Jeff King p...@peff.net writes:
On Thu, Jan 23, 2014 at 10:15:33AM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
Junio, since you prepare such tarballs[1] anyway for kernel.org, it
might be worth uploading them to the Releases page of git/git. I
imagine there is a programmatic way to do so via GitHub's API, but I
don't know offhand. I can look into it if you are interested.
I already have a script that takes the three tarballs and uploads
them to two places, so adding GitHub as the third destination should
be a natural and welcome way to automate it.
I came up with the script below, which you can use like:
./script v1.8.2.3 git-1.8.2.3.tar.gz
It expects the tag to already be pushed up to GitHub. I'll leave
sticking it on the todo branch and integrating it into RelUpload to
you. This can also be used to backfill the old releases (though I looked
on k.org and it seems to have only partial coverage).
It sets the prerelease flag for -rc releases, but I did not otherwise
fill in any fields, including the summary and description. GitHub seems
to display reasonably if they are not set.
Thanks.
-- 8 --
#!/bin/sh
#
# usage: $0 tag tarball
repo=git/git
# replace this with however you store your oauth token
# if you don't have one, make one here:
# https://github.com/settings/tokens/new
token() {
pass -n github.web.oauth
Hmph, what is this pass thing?
}
post() {
curl -H Authorization: token $(token) $@
}
# usage: create tag-name
create() {
case $1 in
*-rc*)
prerelease=true
;;
*)
prerelease=false
;;
esac
post -d '
{
tag_name: '$1',
prerelease: '$prerelease'
}' https://api.github.com/repos/$repo/releases;
}
# use: upload release-id filename
upload() {
url=https://uploads.github.com/repos/$repo/releases/$1/assets;
url=$url?name=$(basename $2)
post -H Content-Type: $(file -b --mime-type $2) \
--data-binary @$2 \
$url
}
# This is a hack. If you don't mind a dependency on
# perl's JSON (or another parser), we can do a lot better.
extract_id() {
perl -lne '/id:\s*(\d+)/ or next; print $1; exit 0'
}
create $1 release.json
id=$(extract_id release.json)
upload $id $2 /dev/null
rm -f release.json
--
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 2/9] git-sh-setup.sh: add variable to use the stuck-long mode
brian m. carlson sand...@crustytoothpaste.net writes: From: Nicolas Vigier bo...@mars-attacks.org If the variable $OPTIONS_STUCKLONG is not empty, then rev-parse option parsing is done in --stuck-long mode. Signed-off-by: Nicolas Vigier bo...@mars-attacks.org Signed-off-by: brian m. carlson sand...@crustytoothpaste.net --- contrib/examples/git-checkout.sh | 1 + contrib/examples/git-clean.sh| 1 + contrib/examples/git-clone.sh| 1 + contrib/examples/git-merge.sh| 1 + contrib/examples/git-repack.sh | 1 + Hmmm, especially given that nobody is exercising the ``updated'' code even in our testsuite, is it a good idea to touch these? The STUCKLONG never existed back when they were scripted. It just adds noise when trying to view them for hints, no? diff --git a/git-sh-setup.sh b/git-sh-setup.sh index fffa3c7..5f28b32 100644 --- a/git-sh-setup.sh +++ b/git-sh-setup.sh @@ -72,6 +72,8 @@ if test -n $OPTIONS_SPEC; then parseopt_extra= [ -n $OPTIONS_KEEPDASHDASH ] parseopt_extra=--keep-dashdash + [ -n $OPTIONS_STUCKLONG ] + parseopt_extra=$parseopt_extra --stuck-long eval $( echo $OPTIONS_SPEC | -- 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 9/9] pull: add the --gpg-sign option.
brian m. carlson sand...@crustytoothpaste.net writes:
git merge already allows us to sign commits, and git rebase has recently
learned how to do so as well. Teach git pull to parse the -S/--gpg-sign
option and pass this along to merge or rebase, as appropriate.
Signed-off-by: brian m. carlson sand...@crustytoothpaste.net
---
git-pull.sh | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/git-pull.sh b/git-pull.sh
index 0a5aa2c..4164dac 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -138,6 +138,15 @@ do
--no-verify-signatures)
verify_signatures=--no-verify-signatures
;;
+ --gpg-sign|-S)
+ gpg_sign_args=-S
+ ;;
+ --gpg-sign=*)
+ gpg_sign_args=-S${1#--gpg-sign=}
+ ;;
Here, $1 is taken from the end-user without any extra quoting...
+ -S*)
+ gpg_sign_args=-S${1#-S}
+ ;;
--d|--dr|--dry|--dry-|--dry-r|--dry-ru|--dry-run)
dry_run=--dry-run
;;
@@ -305,11 +314,13 @@ merge_name=$(git fmt-merge-msg $log_arg
$GIT_DIR/FETCH_HEAD) || exit
case $rebase in
true)
eval=git-rebase $diffstat $strategy_args $merge_args $rebase_args
$verbosity
+ eval=$eval $gpg_sign_args
... but here it is used as if it is properly quoted so that later
eval $eval will take it as a single argument.
git pull --gpg-sign='foo bar'
will probably ask the command to use 'foo' as the signer key id,
with 'bar' as an extra, unknown token on the command line of the
underlying 'git merge', I suspect. A git rev-parse --sq-quote
in the earlier hunk may be all it takes to fix it.
Thanks.
eval=$eval --onto $merge_head ${oldremoteref:-$merge_head}
;;
*)
eval=git-merge $diffstat $no_commit $verify_signatures $edit $squash
$no_ff $ff_only
- eval=$eval $log_arg $strategy_args $merge_args $verbosity $progress
+ eval=$eval $log_arg $strategy_args $merge_args $verbosity $progress
+ eval=$eval $gpg_sign_args
eval=$eval \\$merge_name\ HEAD $merge_head
;;
esac
--
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 8/9] rebase: add the --gpg-sign option
brian m. carlson sand...@crustytoothpaste.net writes:
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 43c19e0..73d32dd 100644
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -181,7 +181,7 @@ exit_with_patch () {
git rev-parse --verify HEAD $amend
warn You can amend the commit now, with
warn
- warn git commit --amend
+ warn git commit --amend $gpg_sign_opt
I think this is meant to be cut--pasted, so you may have to quote
the RHS of --gpg-sign=key (or the key part of -Skey).
The same comment as the one for 'git pull' patch applies around
'eval's in the remainder of the patch.
@@ -248,7 +248,8 @@ pick_one () {
test -d $rewritten
pick_one_preserving_merges $@ return
- output eval git cherry-pick $strategy_args $empty_args $ff $@
+ output eval git cherry-pick ${gpg_sign_opt:+$gpg_sign_opt} \
+ $strategy_args $empty_args $ff $@
}
[rest snipped]
Thanks.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/3] diff: turn skip_stat_unmatch on selectively
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes: skip_stat_unmatch flag is added in fb13227 (git-diff: squelch empty diffs - 2007-08-03) to ignore empty diffs caused by stat-only dirtiness. In some diff case, stat is not involved at all. While the code is written in a way that no expensive I/O is done, we still need to move all file pairs from the old queue to the new queue in diffcore_skip_stat_unmatch(). Only enable it when worktree is involved: diff and diff rev. This should help track down how skip_stat_unmatch is actually used when bugs occur. Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- This replaces 'diff: turn off skip_stat_unmatch on diff --cached' The previous patch obviously leaves skip_stat_unmatch on in diff rev rev and maybe other cases. Oops, I lost track. Sorry. -- 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] rev-parse: Check argc before using argv[i+1]
Without this patch, git-rev-parse --prefix, --default, or
--resolve-git-dir, without a value argument, would result in a segfault.
Instead, die() with a message.
Signed-off-by: David Sharp dhsh...@google.com
---
builtin/rev-parse.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/builtin/rev-parse.c b/builtin/rev-parse.c
index aaeb611..3bf65c5 100644
--- a/builtin/rev-parse.c
+++ b/builtin/rev-parse.c
@@ -547,15 +547,17 @@ int cmd_rev_parse(int argc, const char **argv, const char
*prefix)
continue;
}
if (!strcmp(arg, --default)) {
- def = argv[i+1];
- i++;
+ if (++i = argc)
+ die(--default requires an argument);
+ def = argv[i];
continue;
}
if (!strcmp(arg, --prefix)) {
- prefix = argv[i+1];
+ if (++i = argc)
+ die(--prefix requires an argument);
+ prefix = argv[i];
startup_info-prefix = prefix;
output_prefix = 1;
- i++;
continue;
}
if (!strcmp(arg, --revs-only)) {
@@ -738,9 +740,11 @@ int cmd_rev_parse(int argc, const char **argv, const char
*prefix)
continue;
}
if (!strcmp(arg, --resolve-git-dir)) {
- const char *gitdir = resolve_gitdir(argv[i+1]);
+ if (++i = argc)
+ die(--resolve-git-dir requires an
argument);
+ const char *gitdir = resolve_gitdir(argv[i]);
if (!gitdir)
- die(not a gitdir '%s', argv[i+1]);
+ die(not a gitdir '%s', argv[i]);
puts(gitdir);
continue;
}
--
1.8.5.3
--
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 8/9] rebase: add the --gpg-sign option
On Mon, Jan 27, 2014 at 03:36:44PM -0800, Junio C Hamano wrote:
brian m. carlson sand...@crustytoothpaste.net writes:
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 43c19e0..73d32dd 100644
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -181,7 +181,7 @@ exit_with_patch () {
git rev-parse --verify HEAD $amend
warn You can amend the commit now, with
warn
- warn git commit --amend
+ warn git commit --amend $gpg_sign_opt
I think this is meant to be cut--pasted, so you may have to quote
the RHS of --gpg-sign=key (or the key part of -Skey).
The same comment as the one for 'git pull' patch applies around
'eval's in the remainder of the patch.
@@ -248,7 +248,8 @@ pick_one () {
test -d $rewritten
pick_one_preserving_merges $@ return
- output eval git cherry-pick $strategy_args $empty_args $ff $@
+ output eval git cherry-pick ${gpg_sign_opt:+$gpg_sign_opt} \
+ $strategy_args $empty_args $ff $@
}
[rest snipped]
Thanks.
Thanks for the review. I'll get working on a reroll.
--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
signature.asc
Description: Digital signature
Re: [ANNOUNCE] Git v1.9-rc0
On Mon, Jan 27, 2014 at 02:56:28PM -0800, Junio C Hamano wrote:
# replace this with however you store your oauth token
# if you don't have one, make one here:
# https://github.com/settings/tokens/new
token() {
pass -n github.web.oauth
Hmph, what is this pass thing?
It's a poor man's Keychain:
https://github.com/peff/pass
Judging from your use of netrc in Meta/RelUpload, you probably just
want:
token() {
cat ~/.github-token
}
-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: What's cooking in git.git (Jan 2014, #05; Mon, 27)
On Mon, Jan 27, 2014 at 02:09:52PM -0800, Junio C Hamano wrote: [Stalled] * jk/color-for-more-pagers (2014-01-17) 4 commits - pager: disable colors for some known-bad configurations - DONOTMERGE: needs matching change to git-sh-setup - setup_pager: set MORE=R - setup_pager: refactor LESS/LV environment setting 'more' implementation of BSD wants to be told with MORE=R environment before it shows colored output, while 'more' on some other platforms will die when seeing MORE=R environment. It appears that we are coming to the consensus that trying to be too intimately knowledgeable about quirks of various pager implementations on different platforms is a losing proposition, so perhaps I should replace this with the alternative and simpler approach I posted, unless there are strong objections. It saddens me that we can't better help people who have a custom LESS/MORE/LV set out of the box, but I think I agree that the intimacy with the pagers was just getting too ugly. So I agree we want to drop what you have there. I was planning to try to clean up the like this... patch to the Makefile I posted earlier, but haven't gotten around to it. It seemed like you were positive on that approach. Let me see if I can do that. -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: [PATCH] Added get sendmail from .mailrc
On Sun, Jan 26, 2014 at 09:17:09AM +, Eric Wong wrote:
+use File::HomeDir;
We should probably avoid a new dependency and also remain consistent
with the rest of git handles home directories.
Unfortunately, expand_user_path()/git_config_pathname() isn't currently
exposed to scripters right now...
Ok, if new dependency is not allowed I see next ways:
Not saying it's not allowed. I meant we should probably expose
expand_user_path()/git_config_pathname() C functions to script helpers
(so git-config or git-rev-parse can provide them to sh or perl scripts).
I do not think we need anything so complex. Most of the logic in
expand_user_path is about handling ~ and ~user. But here we _just_
want to know the current user's home directory, and for that
expand_user_path always just looks in $HOME.
So I think $ENV{HOME} would be fine to match what git does. My
understanding is that File::HomeDir does some magic that may work better
on non-Unix platforms. I do not know if we even care for this feature,
since .mailrc is presumably a Unix thing. But if we do, I think our
usual strategy with such things is to optionally use the dependency if
available, and fall back to something sane. Like:
sub homedir {
if (eval { require File::HomeDir; 1 }) {
return File::HomeDir-my_home;
}
return $ENV{HOME};
}
Whichever code path is followed, you should probably also check the
result for undef, which the original patch did not do.
-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: [PATCH] Added get sendmail from .mailrc
On Sat, Jan 25, 2014 at 01:46:50PM +0400, Brilliantov Kirill Vladimirovich
wrote:
+ if (!defined $smtp_server) {
+ my $mailrc = File::HomeDir-my_home . /.mailrc;
The new module dependency has been discussed elsewhere in the thread.
+ if (-e $mailrc) {
+ open FILE, $mailrc or die Failed open $mailrc: $!;
Please use the three-argument of 'open', and use a regular scalar
instead of a glob. Both are safer, and we assume a modern enough perl to
support both. I.e.:
open(my $file, '', $mailrc)
or die failed to open $mailrc: $!;
+ while (FILE) {
+ chomp;
+ if (/set sendmail=.*/) {
+ my @data = split '';
+ $smtp_server = $data[1];
+ last;
+ }
Your split is a rather unusual way to do the parsing, and it took me a
minute to figure it out. It might be more obvious as:
if (/set sendmail=(.*)/) {
$smtp_server = $1;
last;
}
I do not know anything about the mailrc format, nor does it seem to be
well documented. Are the double-quotes required? If not, then the above
regex can easily make them optional. I also wonder if any whitespace is
allowed. E.g., this might be more forgiving:
/set sendmail\s*=\s*?(.*?)?/
but I am just guessing at what the format allows.
-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/2] expand_user_path: do not look at NULL path
We explicitly check for and handle the case that the
incoming path variable is NULL, but before doing so we
call strchrnul on it, leading to a potential segfault.
We can fix this simply by moving the strchrnul call down; as
a bonus, we can tighten the scope on the associated
variable.
Signed-off-by: Jeff King p...@peff.net
---
Most of the callers already check for NULL, so the only way to trigger
this is via an empty include.path. That is addressed separately in the
next patch, so technically this is not needed if we apply that one. But
in that case, the path == NULL check here is useless, so I think this
makes things safer overall.
path.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/path.c b/path.c
index 24594c4..f9c5062 100644
--- a/path.c
+++ b/path.c
@@ -265,12 +265,12 @@ static struct passwd *getpw_str(const char *username,
size_t len)
char *expand_user_path(const char *path)
{
struct strbuf user_path = STRBUF_INIT;
- const char *first_slash = strchrnul(path, '/');
const char *to_copy = path;
if (path == NULL)
goto return_null;
if (path[0] == '~') {
+ const char *first_slash = strchrnul(path, '/');
const char *username = path + 1;
size_t username_len = first_slash - username;
if (username_len == 0) {
--
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/2] handle_path_include: don't look at NULL value
When we see config like:
[include]
path
the expand_user_path helper notices that the config value is
empty, but we then dereference NULL while printing the error
message (glibc will helpfully print (null) for us here,
but we cannot rely on that).
$ git -c include.path rev-parse
error: Could not expand include path '(null)'
fatal: unable to parse command-line config
Instead of tweaking our message, let's actually use
config_error_nonbool to match other config variables that
expect a value:
$ git -c include.path rev-parse
error: Missing value for 'include.path'
fatal: unable to parse command-line config
Signed-off-by: Jeff King p...@peff.net
---
config.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/config.c b/config.c
index d969a5a..314d8ee 100644
--- a/config.c
+++ b/config.c
@@ -84,8 +84,12 @@ static int handle_path_include(const char *path, struct
config_include_data *inc
{
int ret = 0;
struct strbuf buf = STRBUF_INIT;
- char *expanded = expand_user_path(path);
+ char *expanded;
+ if (!path)
+ return config_error_nonbool(include.path);
+
+ expanded = expand_user_path(path);
if (!expanded)
return error(Could not expand include path '%s', path);
path = expanded;
--
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] repack: add `repack.honorpackkeep` config var
On Thu, Jan 23, 2014 at 06:44:43PM -0800, Siddharth Agarwal wrote:
On 01/23/2014 06:28 PM, Jeff King wrote:
I think your understanding is accurate here. So we want repack to
respect keep files for deletion, but we _not_ necessarily want
pack-objects to avoid packing an object just because it's in a pack
marked by .keep (see my other email).
Yes, that makes sense and sounds pretty safe.
So the right solution for us probably is to apply the patch Vicent
posted, set repack.honorpackkeep to false, and also have a cron job
that cleans up stale .keep files so that subsequent repacks clean it
up.
Yes, that matches what we do at GitHub.
Here's Vicent's patch, with documentation and an expanded commit
message. I think it should be suitable for upstream git.
-- 8 --
From: Vicent Marti tan...@gmail.com
Subject: repack: add `repack.honorpackkeep` config var
The git-repack command always passes `--honor-pack-keep`
to pack-objects. This has traditionally been a good thing,
as we do not want to duplicate those objects in a new pack,
and we are not going to delete the old pack.
However, when bitmaps are in use, it is important for a full
repack to include all reachable objects, even if they may be
duplicated in a .keep pack. Otherwise, we cannot generate
the bitmaps, as the on-disk format requires the set of
objects in the pack to be fully closed.
Even if the repository does not generally have .keep files,
a simultaneous push could cause a race condition in which a
.keep file exists at the moment of a repack. The repack may
try to include those objects in one of two situations:
1. The pushed .keep pack contains objects that were
already in the repository (e.g., blobs due to a revert of
an old commit).
2. Receive-pack updates the refs, making the objects
reachable, but before it removes the .keep file, the
repack runs.
In either case, we may prefer to duplicate some objects in
the new, full pack, and let the next repack (after the .keep
file is cleaned up) take care of removing them.
This patch introduces an option to disable the
`--honor-pack-keep` option. It is not triggered by default,
even when pack.writeBitmaps is turned on, because its use
depends on your overall packing strategy and use of .keep
files.
Note that this option just disables the pack-objects
behavior. We still leave packs with a .keep in place, as we
do not necessarily know that we have duplicated all of their
objects.
Signed-off-by: Jeff King p...@peff.net
---
Intended for the jk/pack-bitmap topic.
Documentation/config.txt | 8
builtin/repack.c | 8 +++-
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 947e6f8..5036a10 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -2128,6 +2128,14 @@ repack.usedeltabaseoffset::
false and repack. Access from old Git versions over the
native protocol are unaffected by this option.
+repack.honorPackKeep::
+ If set to false, include objects in `.keep` files when repacking
+ via `git repack`. Note that we still do not delete `.keep` packs
+ after `pack-objects` finishes. This means that we may duplicate
+ objects, but this makes the option safe to use when there are
+ concurrent pushes or fetches. This option is generally only
+ useful if you have set `pack.writeBitmaps`. Defaults to true.
+
rerere.autoupdate::
When set to true, `git-rerere` updates the index with the
resulting contents after it cleanly resolves conflicts using
diff --git a/builtin/repack.c b/builtin/repack.c
index a9c4593..585c41d 100644
--- a/builtin/repack.c
+++ b/builtin/repack.c
@@ -9,6 +9,7 @@
#include argv-array.h
static int delta_base_offset = 1;
+static int honor_pack_keep = 1;
static char *packdir, *packtmp;
static const char *const git_repack_usage[] = {
@@ -22,6 +23,10 @@ static int repack_config(const char *var, const char *value,
void *cb)
delta_base_offset = git_config_bool(var, value);
return 0;
}
+ if (!strcmp(var, repack.honorpackkeep)) {
+ honor_pack_keep = git_config_bool(var, value);
+ return 0;
+ }
return git_default_config(var, value, cb);
}
@@ -190,10 +195,11 @@ int cmd_repack(int argc, const char **argv, const char
*prefix)
argv_array_push(cmd_args, pack-objects);
argv_array_push(cmd_args, --keep-true-parents);
- argv_array_push(cmd_args, --honor-pack-keep);
argv_array_push(cmd_args, --non-empty);
argv_array_push(cmd_args, --all);
argv_array_push(cmd_args, --reflog);
+ if (honor_pack_keep)
+ argv_array_push(cmd_args, --honor-pack-keep);
if (window)
argv_array_pushf(cmd_args, --window=%u, window);
if (window_memory)
--
1.8.5.2.500.g8060133
--
To unsubscribe from this list: send the line
Re: [PATCH] Added get sendmail from .mailrc
On Jan 27, 2014, at 17:15, Jeff King wrote:
On Sat, Jan 25, 2014 at 01:46:50PM +0400, Brilliantov Kirill
Vladimirovich wrote:
+ if (!defined $smtp_server) {
+ my $mailrc = File::HomeDir-my_home . /.mailrc;
Actually, based on the output of man mail, this should probably be
something more like
my $mailrc = $ENV{'MAILRC'} || $ENV{'HOME'}/.mailrc;
which takes into account any MAILRC setting and also avoids the use of
File::HomeDir.
+ while (FILE) {
+ chomp;
+ if (/set sendmail=.*/) {
+ my @data = split '';
+ $smtp_server = $data[1];
+ last;
+ }
Your split is a rather unusual way to do the parsing, and it took me a
minute to figure it out. It might be more obvious as:
if (/set sendmail=(.*)/) {
$smtp_server = $1;
last;
}
I do not know anything about the mailrc format, nor does it seem to be
well documented. Are the double-quotes required? If not, then the
above
regex can easily make them optional. I also wonder if any whitespace
is
allowed.
From man mail:
set (se) With no arguments, prints all variable values.
Otherwise,
sets option. Arguments are of the form option=value (no space
before or after `=') or option. Quotation marks may be placed
around any part of the assignment statement to quote blanks or
tabs, i.e. ``set indentprefix=-''
My version of man mail does not list all the variables that can be
set but it refers to The Mail Reference Manual document which
presumably does. I did find this [1] that documents many of the
available variables including the sendmail one. I then tried this:
cat EOF /tmp/shim
#!/bin/sh
exec cat
EOF
chmod a+x /tmp/shim
cat EOF /tmp/testrc
se sendmail=/tmp/shim
EOF
echo 'testing' | MAILRC=/tmp/testrc mail -s test nobody
And to my surprise the contents of the new message were cat'd out to
the terminal rather than being sent. So clearly there's some room for
improvement with the set, white space and quote checking.
[1] http://www.cs.fsu.edu/sysinfo/mail/mailrc.html
--Kyle
--
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
