[PATCH v2 2/4] employ new explicit exists in index? API
Each caller of index_name_exists() knows whether it is looking for a
directory or a file, and can avoid the unnecessary indirection of
index_name_exists() by instead calling index_dir_exists() or
index_file_exists() directly.
Invoking the appropriate search function explicitly will allow a
subsequent patch to relieve callers of the artificial burden of having
to add a trailing '/' to the pathname given to index_dir_exists().
Signed-off-by: Eric Sunshine sunsh...@sunshineco.com
---
dir.c | 10 +-
read-cache.c | 4 ++--
unpack-trees.c | 4 ++--
3 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/dir.c b/dir.c
index b439ff0..a8401b9 100644
--- a/dir.c
+++ b/dir.c
@@ -860,7 +860,7 @@ static struct dir_entry *dir_entry_new(const char
*pathname, int len)
static struct dir_entry *dir_add_name(struct dir_struct *dir, const char
*pathname, int len)
{
- if (cache_name_exists(pathname, len, ignore_case))
+ if (cache_file_exists(pathname, len, ignore_case))
return NULL;
ALLOC_GROW(dir-entries, dir-nr+1, dir-alloc);
@@ -885,11 +885,11 @@ enum exist_status {
/*
* Do not use the alphabetically sorted index to look up
* the directory name; instead, use the case insensitive
- * name hash.
+ * directory hash.
*/
static enum exist_status directory_exists_in_index_icase(const char *dirname,
int len)
{
- const struct cache_entry *ce = cache_name_exists(dirname, len + 1,
ignore_case);
+ const struct cache_entry *ce = cache_dir_exists(dirname, len + 1);
unsigned char endchar;
if (!ce)
@@ -1071,7 +1071,7 @@ static int get_index_dtype(const char *path, int len)
int pos;
const struct cache_entry *ce;
- ce = cache_name_exists(path, len, 0);
+ ce = cache_file_exists(path, len, 0);
if (ce) {
if (!ce_uptodate(ce))
return DT_UNKNOWN;
@@ -1131,7 +1131,7 @@ static enum path_treatment treat_one_path(struct
dir_struct *dir,
int dtype, struct dirent *de)
{
int exclude;
- int has_path_in_index = !!cache_name_exists(path-buf, path-len,
ignore_case);
+ int has_path_in_index = !!cache_file_exists(path-buf, path-len,
ignore_case);
if (dtype == DT_UNKNOWN)
dtype = get_dtype(de, path-buf, path-len);
diff --git a/read-cache.c b/read-cache.c
index 885943a..b8d3759 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -643,7 +643,7 @@ int add_to_index(struct index_state *istate, const char
*path, struct stat *st,
if (*ptr == '/') {
struct cache_entry *foundce;
++ptr;
- foundce = index_name_exists(istate, ce-name,
ptr - ce-name, ignore_case);
+ foundce = index_dir_exists(istate, ce-name,
ptr - ce-name);
if (foundce) {
memcpy((void *)startPtr, foundce-name
+ (startPtr - ce-name), ptr - startPtr);
startPtr = ptr;
@@ -652,7 +652,7 @@ int add_to_index(struct index_state *istate, const char
*path, struct stat *st,
}
}
- alias = index_name_exists(istate, ce-name, ce_namelen(ce),
ignore_case);
+ alias = index_file_exists(istate, ce-name, ce_namelen(ce),
ignore_case);
if (alias !ce_stage(alias) !ie_match_stat(istate, alias, st,
ce_option)) {
/* Nothing changed, really */
free(ce);
diff --git a/unpack-trees.c b/unpack-trees.c
index 1a61e6f..35cb05e 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -1357,7 +1357,7 @@ static int icase_exists(struct unpack_trees_options *o,
const char *name, int le
{
const struct cache_entry *src;
- src = index_name_exists(o-src_index, name, len, 1);
+ src = index_file_exists(o-src_index, name, len, 1);
return src !ie_match_stat(o-src_index, src, st,
CE_MATCH_IGNORE_VALID|CE_MATCH_IGNORE_SKIP_WORKTREE);
}
@@ -1403,7 +1403,7 @@ static int check_ok_to_remove(const char *name, int len,
int dtype,
* delete this path, which is in a subdirectory that
* is being replaced with a blob.
*/
- result = index_name_exists(o-result, name, len, 0);
+ result = index_file_exists(o-result, name, len, 0);
if (result) {
if (result-ce_flags CE_REMOVE)
return 0;
--
1.8.4.535.g7b94f8e
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/4] name-hash: refactor polymorphic index_name_exists()
Depending upon the absence or presence of a trailing '/' on the incoming
pathname, index_name_exists() checks either if a file is present in the
index or if a directory is represented within the index. Each caller
explicitly chooses the mode of operation by adding or removing a
trailing '/' before invoking index_name_exists().
Since these two modes of operations are disjoint and have no code in
common (one searches index_state.name_hash; the other dir_hash), they
can be represented more naturally as distinct functions: one to search
for a file, and one for a directory.
Splitting index searching into two functions relieves callers of the
artificial burden of having to add or remove a slash to select the mode
of operation; instead they just call the desired function. A subsequent
patch will take advantage of this benefit in order to eliminate the
requirement that the incoming pathname for a directory search must have
a trailing slash.
(In order to avoid disturbing in-flight topics, index_name_exists() is
retained as a thin wrapper dispatching either to index_dir_exists() or
index_file_exists().)
Signed-off-by: Eric Sunshine sunsh...@sunshineco.com
---
cache.h | 4
name-hash.c | 54 ++
2 files changed, 34 insertions(+), 24 deletions(-)
diff --git a/cache.h b/cache.h
index a47b9c0..038afe1 100644
--- a/cache.h
+++ b/cache.h
@@ -314,6 +314,8 @@ extern void free_name_hash(struct index_state *istate);
#define refresh_cache(flags) refresh_index(the_index, (flags), NULL, NULL,
NULL)
#define ce_match_stat(ce, st, options) ie_match_stat(the_index, (ce), (st),
(options))
#define ce_modified(ce, st, options) ie_modified(the_index, (ce), (st),
(options))
+#define cache_dir_exists(name, namelen) index_dir_exists(the_index, (name),
(namelen))
+#define cache_file_exists(name, namelen, igncase)
index_file_exists(the_index, (name), (namelen), (igncase))
#define cache_name_exists(name, namelen, igncase)
index_name_exists(the_index, (name), (namelen), (igncase))
#define cache_name_is_other(name, namelen) index_name_is_other(the_index,
(name), (namelen))
#define resolve_undo_clear() resolve_undo_clear_index(the_index)
@@ -463,6 +465,8 @@ extern int write_index(struct index_state *, int newfd);
extern int discard_index(struct index_state *);
extern int unmerged_index(const struct index_state *);
extern int verify_path(const char *path);
+extern struct cache_entry *index_dir_exists(struct index_state *istate, const
char *name, int namelen);
+extern struct cache_entry *index_file_exists(struct index_state *istate, const
char *name, int namelen, int igncase);
extern struct cache_entry *index_name_exists(struct index_state *istate, const
char *name, int namelen, int igncase);
extern int index_name_pos(const struct index_state *, const char *name, int
namelen);
#define ADD_CACHE_OK_TO_ADD 1 /* Ok to add */
diff --git a/name-hash.c b/name-hash.c
index 617c86c..f06b049 100644
--- a/name-hash.c
+++ b/name-hash.c
@@ -222,7 +222,29 @@ static int same_name(const struct cache_entry *ce, const
char *name, int namelen
return slow_same_name(name, namelen, ce-name, len);
}
-struct cache_entry *index_name_exists(struct index_state *istate, const char
*name, int namelen, int icase)
+struct cache_entry *index_dir_exists(struct index_state *istate, const char
*name, int namelen)
+{
+ struct cache_entry *ce;
+ struct dir_entry *dir;
+
+ lazy_init_name_hash(istate);
+ dir = find_dir_entry(istate, name, namelen);
+ if (dir dir-nr)
+ return dir-ce;
+
+ /*
+* It might be a submodule. Unlike plain directories, which are stored
+* in the dir-hash, submodules are stored in the name-hash, so check
+* there, as well.
+*/
+ ce = index_file_exists(istate, name, namelen - 1, 1);
+ if (ce S_ISGITLINK(ce-ce_mode))
+ return ce;
+
+ return NULL;
+}
+
+struct cache_entry *index_file_exists(struct index_state *istate, const char
*name, int namelen, int icase)
{
unsigned int hash = hash_name(name, namelen);
struct cache_entry *ce;
@@ -237,32 +259,16 @@ struct cache_entry *index_name_exists(struct index_state
*istate, const char *na
}
ce = ce-next;
}
-
- /*
-* When looking for a directory (trailing '/'), it might be a
-* submodule or a directory. Despite submodules being directories,
-* they are stored in the name hash without a closing slash.
-* When ignore_case is 1, directories are stored in a separate hash
-* table *with* their closing slash.
-*
-* The side effect of this storage technique is we have need to
-* lookup the directory in a separate hash table, and if not found
-* remove the slash from name and perform the lookup again without
-* the slash. If a match is made, S_ISGITLINK(ce-mode)
[PATCH v2 0/4] stop storing trailing slash in dir-hash
This series changes name-hash to stop storing the (redundant) trailing slash with index_state.dir_hash entries. As an intentional side-effect, the series fixes [1] in a cleaner way (suggested by Junio [2]) than either [3] (680be044 in master) or [4]. Changes since v1 [5]: * Add index_file_exists() as complement of index_dir_exists() introduced in v1 rather than changing the behavior of index_name_exists() to check only for files. To avoid disturbing current or future in-flight topics, index_name_exists() is retained (suggested by Junio [6]) as a thin wrapper dispatching either to index_file_exists() or index_dir_exists(). * Split v1 patch 1 into v2 patches 1 2 to ease review. (This is possible now that index_name_exists() retains its original behavior.) [1]: http://thread.gmane.org/gmane.comp.version-control.git/232727 [2]: http://thread.gmane.org/gmane.comp.version-control.git/232727/focus=232813 [3]: http://thread.gmane.org/gmane.comp.version-control.git/232796 [4]: http://thread.gmane.org/gmane.comp.version-control.git/232833 [5]: http://thread.gmane.org/gmane.comp.version-control.git/234743 [6]: http://article.gmane.org/gmane.comp.version-control.git/234761 Eric Sunshine (4): name-hash: refactor polymorphic index_name_exists() employ new explicit exists in index? API name-hash: stop storing trailing '/' on paths in index_state.dir_hash dir: revert work-around for retired dangerous behavior cache.h| 4 dir.c | 28 --- name-hash.c| 61 -- read-cache.c | 4 ++-- unpack-trees.c | 4 ++-- 5 files changed, 50 insertions(+), 51 deletions(-) -- 1.8.4.535.g7b94f8e -- 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 4/4] dir: revert work-around for retired dangerous behavior
directory_exists_in_index_icase() dangerously assumed that it could
access one character beyond the end of its directory argument, and that
that character would unconditionally be '/'. 2eac2a4c (ls-files -k: a
directory only can be killed if the index has a non-directory,
2013-08-15) added a caller which did not respect this undocumented
assumption, and 680be044 (dir.c::test_one_path(): work around
directory_exists_in_index_icase() breakage, 2013-08-23) added a
work-around which temporarily appends a '/' before invoking
directory_exists_in_index_icase().
Since the dangerous behavior of directory_exists_in_index_icase() has
been eliminated, the work-around is now redundant, so retire it (but not
the tests added by the same commit).
Signed-off-by: Eric Sunshine sunsh...@sunshineco.com
---
dir.c | 18 +++---
1 file changed, 3 insertions(+), 15 deletions(-)
diff --git a/dir.c b/dir.c
index fccd479..23b6de4 100644
--- a/dir.c
+++ b/dir.c
@@ -1160,21 +1160,9 @@ static enum path_treatment treat_one_path(struct
dir_struct *dir,
*/
if ((dir-flags DIR_COLLECT_KILLED_ONLY)
(dtype == DT_DIR)
- !has_path_in_index) {
- /*
-* NEEDSWORK: directory_exists_in_index_icase()
-* assumes that one byte past the given path is
-* readable and has '/', which needs to be fixed, but
-* until then, work it around in the caller.
-*/
- strbuf_addch(path, '/');
- if (directory_exists_in_index(path-buf, path-len - 1) ==
- index_nonexistent) {
- strbuf_setlen(path, path-len - 1);
- return path_none;
- }
- strbuf_setlen(path, path-len - 1);
- }
+ !has_path_in_index
+ (directory_exists_in_index(path-buf, path-len) ==
index_nonexistent))
+ return path_none;
exclude = is_excluded(dir, path-buf, dtype);
--
1.8.4.535.g7b94f8e
--
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: 1.8.4 rebase regression?
Matthieu Moy matthieu@grenoble-inp.fr writes: Patrick Welche pr...@cam.ac.uk writes: $ git diff ESC[1mdiff --cc glib/gmain.cESC[m ESC[1mindex 738e69c,5aaebd0..000ESC[m ESC[1m--- a/glib/gmain.cESC[m ESC[1m+++ b/glib/gmain.cESC[m ESC[36m@@@ -4953,32 -4921,32 +4953,48 @@@ESC[m ESC[mg_unix_signal_watch_dispatch (GSourcESC[m (same xterm, no change of TERM in both invocations above) git status in 1.8.4 does show red, so colour does work... Thoughts on how to help debug? Can you try: git -c color.ui=never diff git -c color.ui=auto diff git -c color.ui=always diff ? ... and Junio suggested offline to look for a broken pager, so, you can try this too: git --no-pager diff -- 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: RFC: git bisect should accept paths-to-be-excluded
Hi, On Mon, Sep 16, 2013 at 2:39 PM, Toralf Förster toralf.foers...@gmx.de wrote: I'm bisecting a linux kernel issue and want to ignore all commits just touching something in ./drives/staging. Currently the only way would be to specify all dir/subdir combination under ./linux except that particular directory, right ? Yeah, you are right, currently the only way would be to specify all dir/subdir combination under ./linux except the particular directory you want to exclude. It might indeed be useful to have a way to exclude some directories or files. In practice though, as git bisect is a kind of binary search, if what you want to exclude is exclusively touched by half the commits, it will only add one more bisection step if you don't exclude it. Best regards, Christian. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: git bisect should accept paths-to-be-excluded
Christian Couder christian.cou...@gmail.com writes: In practice though, as git bisect is a kind of binary search, if what you want to exclude is exclusively touched by half the commits, it will only add one more bisection step if you don't exclude it. Actually, I think the same remark would apply to any other Git command that deal with a set of revisions. If you want to review code with git log -p, but you don't care about a subdirectory, you may want a git log -p --ignore-dir foo/ or so, too. And then, the it's logarithmic argument doesn't work anymore ;-). -- 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: [PATCH 1/2] relative_path should honor dos_drive_prefix
2013/9/13 Junio C Hamano gits...@pobox.com:
Jiang Xin worldhello@gmail.com writes:
2013/9/13 Junio C Hamano gits...@pobox.com:
For systems that need POSIX escape hatch for Apollo Domain ;-), we
would need a bit more work. When both path1 and path2 begin with a
double-dash, we would need to check if they match up to the next
slash, so that
- //host1/usr/src and //host1/usr/lib share the same root and the
former can be made to ../src relative to the latter;
- //host1/usr/src and //host2/usr/lib are of separate roots.
or something.
But how could we know which platform supports network pathnames and
needs such implementation.
Near the end of
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_12
is this:
If a pathname begins with two successive slash characters, the
first component following the leading slash characters may be
interpreted in an implementation-defined manner, although more than
two leading slash characters shall be treated as a single slash
character.
Two points to note are
(1) Only paths that begin with exactly two slashes are special.
(2) As it is implementation-defined, we are not even allowed to
treat that //host1/usr/src and //host1/usr/lib as sharing the
same root, and make the former to ../src relative to the
latter.
So in the strictest sense, we do not have to bother. As long as we
make sure we do not molest anything that begins with exactly two
slashes.
I have checked the behavior of UNC path on Windows (msysGit):
* I can cd to a UNC path:
cd //server1/share1/path
* can cd to other share:
cd ../../share2/path
* and can cd to other server's share:
cd ../../../server2/share/path
That means relative_path(path1, path2) support UNC paths out of the box.
We only need to check both path1 and path2 are UNC paths, or both not.
So, funciton “have_same_root will write like this:
+static int have_same_root(const char *path1, const char *path2)
+{
+ int is_abs1, is_abs2;
+
+ is_abs1 = is_absolute_path(path1);
+ is_abs2 = is_absolute_path(path2);
+ if (is_abs1 is_abs2) {
+ if (is_unc_path(path1) ^ is_unc_path(path2))
+ return 0;
+ return tolower(path1[0]) == tolower(path2[0]);
+ } else {
+ return !is_abs1 !is_abs2;
+ }
+}
--
Jiang Xin
--
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/3] relative_path should honor DOS and UNC paths
Tvangeste found that the relative_path function could not work
properly on Windows if in and prefix have DOS driver prefix
(such as C:/windows). And the relative_path function won't
work properly if either in or prefix is a UNC path (like
//host/share). ($gmane/234434)
E.g., When execute: test-path-utils relative_path C:/a/b D:/x/y,
should return C:/a/b, but returns ../../C:/a/b, which is wrong.
So make relative_path honor DOS and UNC paths, and add test cases
for it in t0060.
Reported-by: Tvangeste i.4m.l...@yandex.ru
Helped-by: Johannes Sixt j...@kdbg.org
Signed-off-by: Jiang Xin worldhello@gmail.com
---
compat/mingw.h| 9 +
git-compat-util.h | 4
path.c| 25 +
t/t0060-path-utils.sh | 8
4 files changed, 46 insertions(+)
diff --git a/compat/mingw.h b/compat/mingw.h
index bd0a88b..06e9f49 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -311,6 +311,15 @@ int winansi_fprintf(FILE *stream, const char *format, ...)
__attribute__((format
#define has_dos_drive_prefix(path) (isalpha(*(path)) (path)[1] == ':')
#define is_dir_sep(c) ((c) == '/' || (c) == '\\')
+static inline int is_unc_path(const char *path)
+{
+ if (!is_dir_sep(*path) || !is_dir_sep(*(path+1)) ||
is_dir_sep(*(path+2)))
+ return 0;
+ for (path += 2; *path; path++)
+ if (is_dir_sep(*path))
+ return 1;
+ return 0;
+}
static inline char *mingw_find_last_dir_sep(const char *path)
{
char *ret = NULL;
diff --git a/git-compat-util.h b/git-compat-util.h
index 9549de6..93c2206 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -274,6 +274,10 @@ extern char *gitbasename(char *);
#define is_dir_sep(c) ((c) == '/')
#endif
+#ifndef is_unc_path
+#define is_unc_path(path) 0
+#endif
+
#ifndef find_last_dir_sep
#define find_last_dir_sep(path) strrchr(path, '/')
#endif
diff --git a/path.c b/path.c
index 9fd28bcd..544d10d 100644
--- a/path.c
+++ b/path.c
@@ -434,6 +434,21 @@ int adjust_shared_perm(const char *path)
return 0;
}
+static int have_same_root(const char *path1, const char *path2)
+{
+ int is_abs1, is_abs2;
+
+ is_abs1 = is_absolute_path(path1);
+ is_abs2 = is_absolute_path(path2);
+ if (is_abs1 is_abs2) {
+ if (is_unc_path(path1) ^ is_unc_path(path2))
+ return 0;
+ return tolower(path1[0]) == tolower(path2[0]);
+ } else {
+ return !is_abs1 !is_abs2;
+ }
+}
+
/*
* Give path as relative to prefix.
*
@@ -454,6 +469,16 @@ const char *relative_path(const char *in, const char
*prefix,
else if (!prefix_len)
return in;
+ if (have_same_root(in, prefix)) {
+ /* bypass dos_drive, for c: is identical to C: */
+ if (has_dos_drive_prefix(in)) {
+ i = 2;
+ j = 2;
+ }
+ } else {
+ return in;
+ }
+
while (i prefix_len j in_len prefix[i] == in[j]) {
if (is_dir_sep(prefix[i])) {
while (is_dir_sep(prefix[i]))
diff --git a/t/t0060-path-utils.sh b/t/t0060-path-utils.sh
index 92976e0..830b6d5 100755
--- a/t/t0060-path-utils.sh
+++ b/t/t0060-path-utils.sh
@@ -210,6 +210,14 @@ relative_path foo/a/b/ foo/a/b ./
relative_path foo/afoo/a/b ../
relative_path foo/x/y foo/a/b ../../x/y
relative_path foo/a/c foo/a/b ../c
+relative_path foo/a/b /foo/x/yfoo/a/b
+relative_path /foo/a/b foo/x/y /foo/a/b
+relative_path d:/a/b D:/a/c ../bMINGW
+relative_path C:/a/b D:/a/c C:/a/b MINGW
+relative_path //host1/a/b //host1/a/c ../b
+relative_path //host1/a/b //host2/a/c ../../../host1/a/b
+relative_path //host1/a/b /foo/a/c//host1/a/b MINGW
+relative_path /foo/a/b //host2/a/c /foo/a/bMINGW
relative_path foo/a/b empty foo/a/b
relative_path foo/a/b nullfoo/a/b
relative_path empty/foo/a/b./
--
1.8.4.460.g2f083d1
--
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/3] test: use unambigous leading path (/foo) for mingw
In test cases for relative_path, path with one leading character (such as /a, /x) may be recogonized as a:/ or x:/ if there is such DOS drive on MINGW platform. Use an umambigous leading path /foo instead. Also change two leading slashes (//) to three leading slashes (///), otherwize it will be recognized as UNC path on MINGW platform. Signed-off-by: Jiang Xin worldhello@gmail.com --- t/t0060-path-utils.sh | 56 +-- 1 file changed, 28 insertions(+), 28 deletions(-) diff --git a/t/t0060-path-utils.sh b/t/t0060-path-utils.sh index 3a48de2..92976e0 100755 --- a/t/t0060-path-utils.sh +++ b/t/t0060-path-utils.sh @@ -190,33 +190,33 @@ test_expect_success SYMLINKS 'real path works on symlinks' ' test $sym = $(test-path-utils real_path $dir2/syml) ' -relative_path /a/b/c/ /a/b/ c/ -relative_path /a/b/c/ /a/bc/ -relative_path /a//b//c///a/b// c/ POSIX -relative_path /a/b /a/b./ -relative_path /a/b//a/b./ -relative_path /a /a/b../ -relative_path //a/b/ ../../ -relative_path /a/c /a/b/ ../c -relative_path /a/c /a/b../c -relative_path /x/y /a/b/ ../../x/y -relative_path /a/b empty /a/b -relative_path /a/b null/a/b -relative_path a/b/c/ a/b/c/ -relative_path a/b/c/ a/b c/ -relative_path a/b//c a//bc -relative_path a/b/ a/b/./ -relative_path a/b/ a/b ./ -relative_path aa/b ../ -relative_path x/y a/b ../../x/y -relative_path a/c a/b ../c -relative_path a/b empty a/b -relative_path a/b nulla/b -relative_path empty/a/b./ -relative_path emptyempty ./ -relative_path emptynull./ -relative_path null empty ./ -relative_path null null./ -relative_path null /a/b./ +relative_path /foo/a/b/c/ /foo/a/b/ c/ +relative_path /foo/a/b/c/ /foo/a/bc/ +relative_path /foo/a//b//c////foo/a/b//c/ POSIX +relative_path /foo/a/b /foo/a/b./ +relative_path /foo/a/b//foo/a/b./ +relative_path /foo/a /foo/a/b../ +relative_path //foo/a/b/ ../../../ +relative_path /foo/a/c /foo/a/b/ ../c +relative_path /foo/a/c /foo/a/b../c +relative_path /foo/x/y /foo/a/b/ ../../x/y +relative_path /foo/a/b empty /foo/a/b +relative_path /foo/a/b null/foo/a/b +relative_path foo/a/b/c/ foo/a/b/c/ +relative_path foo/a/b/c/ foo/a/b c/ +relative_path foo/a/b//c foo/a//bc +relative_path foo/a/b/ foo/a/b/./ +relative_path foo/a/b/ foo/a/b ./ +relative_path foo/afoo/a/b ../ +relative_path foo/x/y foo/a/b ../../x/y +relative_path foo/a/c foo/a/b ../c +relative_path foo/a/b empty foo/a/b +relative_path foo/a/b nullfoo/a/b +relative_path empty/foo/a/b./ +relative_path emptyempty ./ +relative_path emptynull./ +relative_path null empty ./ +relative_path null null./ +relative_path null /foo/a/b./ test_done -- 1.8.4.460.g2f083d1 -- 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
little suggestion for revert/checkout
hi I like your crash curse http://git.or.cz/course/svn.html (sorry for my bad English) a little suggestion for revert/checkout svn revert -R .--- git checkout id '*' best regards Michele Paoli -- --- Dott. Michele Paoli Innsbruck Medical University IT-Services Medicent Innrain 143, 4th fl. phone: ++43(0)512 9003 71025 fax: ++43(0)512 9003 73021 e-mail: michele.pa...@i-med.ac.at url: http://www.i-med.ac.at/itservices -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: git bisect should accept paths-to-be-excluded
On Tue, Sep 17, 2013 at 10:21 AM, Matthieu Moy matthieu@grenoble-inp.fr wrote: Christian Couder christian.cou...@gmail.com writes: In practice though, as git bisect is a kind of binary search, if what you want to exclude is exclusively touched by half the commits, it will only add one more bisection step if you don't exclude it. Actually, I think the same remark would apply to any other Git command that deal with a set of revisions. If you want to review code with git log -p, but you don't care about a subdirectory, you may want a git log -p --ignore-dir foo/ or so, too. Yeah, and there was a patch series about that 2 years ago: http://thread.gmane.org/gmane.comp.version-control.git/182830/ And then, the it's logarithmic argument doesn't work anymore ;-). Sure. Best regards, Christian. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 1.8.4 rebase regression?
On Mon, Sep 16, 2013 at 01:18:48PM +0200, Matthieu Moy wrote: Patrick Welche pr...@cam.ac.uk writes: $ git diff ESC[1mdiff --cc glib/gmain.cESC[m ESC[1mindex 738e69c,5aaebd0..000ESC[m ESC[1m--- a/glib/gmain.cESC[m ESC[1m+++ b/glib/gmain.cESC[m ESC[36m@@@ -4953,32 -4921,32 +4953,48 @@@ESC[m ESC[mg_unix_signal_watch_dispatch (GSourcESC[m (same xterm, no change of TERM in both invocations above) git status in 1.8.4 does show red, so colour does work... Thoughts on how to help debug? Can you try: git -c color.ui=never diff git -c color.ui=auto diff git -c color.ui=always diff ? Got it: the change between 1.8.3.4 and 1.8.4 is that colour is on by default. If I take 1.8.3.4 and git -c color.ui=always log, I see the same ESC codes = not a regression! I'll just have to sort my box out if I want colour. (The only oddity is that git status is correctly colourful.) ( If you have a bit of time, you can use git bisect on a clone of git.git to find out the guilty commit. commit e5be297279e8ee8c503eb59da21ab17edc40e748 Merge: a3bc3d0 6897a64 but that is presumably just when the default changed ) Sorry for the confusion - it just looked like a regression to me, but isn't! Cheers, Patrick -- 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: 1.8.4 rebase regression?
On Tue, Sep 17, 2013 at 09:15:43AM +0200, Matthieu Moy wrote: Matthieu Moy matthieu@grenoble-inp.fr writes: Patrick Welche pr...@cam.ac.uk writes: $ git diff ESC[1mdiff --cc glib/gmain.cESC[m ESC[1mindex 738e69c,5aaebd0..000ESC[m ESC[1m--- a/glib/gmain.cESC[m ESC[1m+++ b/glib/gmain.cESC[m ESC[36m@@@ -4953,32 -4921,32 +4953,48 @@@ESC[m ESC[mg_unix_signal_watch_dispatch (GSourcESC[m (same xterm, no change of TERM in both invocations above) git status in 1.8.4 does show red, so colour does work... Thoughts on how to help debug? Can you try: git -c color.ui=never diff git -c color.ui=auto diff git -c color.ui=always diff ? ... and Junio suggested offline to look for a broken pager, so, you can try this too: git --no-pager diff Even better - colour works here too = I must look at my pager. Thank you! Patrick -- 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: 1.8.4 rebase regression?
Patrick Welche pr...@cam.ac.uk writes: Got it: the change between 1.8.3.4 and 1.8.4 is that colour is on by default. If I take 1.8.3.4 and git -c color.ui=always log, I see the same ESC codes = not a regression! I'll just have to sort my box out if I want colour. (The only oddity is that git status is correctly colourful.) Maybe you disabled the pager for git status? ( If you have a bit of time, you can use git bisect on a clone of git.git to find out the guilty commit. commit e5be297279e8ee8c503eb59da21ab17edc40e748 Merge: a3bc3d0 6897a64 but that is presumably just when the default changed ) It doesn't seem so. On my box, color work just fine when piped to less, but I guess not all pagers accept this, and perhaps a wrong value of $LESS can cause less to reject it. -- 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: 1.8.4 rebase regression?
On Tue, Sep 17, 2013 at 11:23:51AM +0200, Matthieu Moy wrote: Patrick Welche pr...@cam.ac.uk writes: Got it: the change between 1.8.3.4 and 1.8.4 is that colour is on by default. If I take 1.8.3.4 and git -c color.ui=always log, I see the same ESC codes = not a regression! I'll just have to sort my box out if I want colour. (The only oddity is that git status is correctly colourful.) Maybe you disabled the pager for git status? Interesting: I didn't disable it on purpose, but indeed, it is not used for status. Can't believe this: $ echo $PAGER more unset PAGER, and git diff is fine... Thanks for all the help! Cheers, Patrick -- 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: 1.8.4 rebase regression?
Patrick Welche pr...@cam.ac.uk writes: On Tue, Sep 17, 2013 at 11:23:51AM +0200, Matthieu Moy wrote: Patrick Welche pr...@cam.ac.uk writes: Got it: the change between 1.8.3.4 and 1.8.4 is that colour is on by default. If I take 1.8.3.4 and git -c color.ui=always log, I see the same ESC codes = not a regression! I'll just have to sort my box out if I want colour. (The only oddity is that git status is correctly colourful.) Maybe you disabled the pager for git status? Interesting: I didn't disable it on purpose, but indeed, it is not used for status. Ah, my bad. Whether the pager should be enabled by default for status led to a lot of debates here, and I thought the conclusion was yes. But I'm the one having it enabled by default: [pager] status = true Can't believe this: $ echo $PAGER more unset PAGER, and git diff is fine... less will be a much better pager than more, indeed. The default behavior of less is sometimes anoying (open full-page, and 'q' restores the terminal, which is very inconvenient for short output), but if you didn't set $LESS, then Git will set it for you to something appropriate for git pager. -- 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: Issue with sparse checkout
On Tue, Sep 17, 2013 at 5:46 AM, Martin Gregory martin.greg...@adelaideinterim.com.au wrote: An additional note. I did git ls-files -v | grep ^S and I can see that the files that remain in the working version have the ^S bit set. So it does feel like a bug to me: why are files with ^S set remaining in the working version after git read-tree -mu HEAD ? I don't know. Maybe the bits are set, but then the remove operation fails (silently). I tried to reproduce on Linux without success. It seemed to work ok. Can you copy the (stripped down if necessary) repository somewhere? Pack the whole thing including worktree and config file, just in case. -- 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: sparse checkout file with windows line endings doesn't work
On Mon, Sep 16, 2013 at 8:20 PM, Martin Gregory mart...@adelaideinterim.com.au wrote: Hi, Please see http://pastebin.com/zMXvvXuy It shows that if the .git/info/sparsecheckout file is in windows format (windows line ending) then it doesn't work. And it does work for me with CRLF endings (again tested on Linux). Can you send me your sparse-checkout file? Zip it if needed. I just wanted to make sure there's no weird visible characters there. If none is found, then I don't know what causes your problem. Perhaps msys guys can help. -- 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: RFC: git bisect should accept paths-to-be-excluded
On Tue, Sep 17, 2013 at 4:03 PM, Christian Couder christian.cou...@gmail.com wrote: On Tue, Sep 17, 2013 at 10:21 AM, Matthieu Moy matthieu@grenoble-inp.fr wrote: Christian Couder christian.cou...@gmail.com writes: In practice though, as git bisect is a kind of binary search, if what you want to exclude is exclusively touched by half the commits, it will only add one more bisection step if you don't exclude it. Actually, I think the same remark would apply to any other Git command that deal with a set of revisions. If you want to review code with git log -p, but you don't care about a subdirectory, you may want a git log -p --ignore-dir foo/ or so, too. Yeah, and there was a patch series about that 2 years ago: http://thread.gmane.org/gmane.comp.version-control.git/182830/ And that's just one of the few attempts if I remember correctly. I guess it's time revisit it. A few things to sort out before we get to the implementation: Support flat or nested negation (i.e.include A, ignore A/B, but include A/B/C..). Nested thing complicates things so I'm towards the flat exclusion (exclude B means all inside B, no buts nor excepts) and probably cover most use cases Interaction with git grep --depth Syntax. I guess --ignore (or --exclude) is more intuitive than :(exclude)something but then it might collide with existing options (I did not check if --ignore or --exclude is used anywhere though). The latter also enables combining with other filters, such as case-insensitive matching.. -- 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
[PATCH 1/2] perf-lib: split starting the test from the execution
Separate the execution part to make future changes to the tests simpler.
Signed-off-by: Thomas Gummerer t.gumme...@gmail.com
---
t/perf/perf-lib.sh | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/t/perf/perf-lib.sh b/t/perf/perf-lib.sh
index c61d535..95e483c 100644
--- a/t/perf/perf-lib.sh
+++ b/t/perf/perf-lib.sh
@@ -148,13 +148,8 @@ exit $ret' 3 24
return $eval_ret
}
-
-test_perf () {
+perf_test_ () {
test_start_
- test $# = 3 { test_prereq=$1; shift; } || test_prereq=
- test $# = 2 ||
- error bug in the test script: not 2 or 3 parameters to
test-expect-success
- export test_prereq
if ! test_skip $@
then
base=$(basename $0 .sh)
@@ -191,6 +186,14 @@ test_perf () {
test_finish_
}
+test_perf () {
+ test $# = 3 { test_prereq=$1; shift; } || test_prereq=
+ test $# = 2 ||
+ error bug in the test script: not 2 or 3 parameters to
test-expect-success
+ export test_prereq
+ perf_test_ $1 $2
+}
+
# We extend test_done to print timings at the end (./run disables this
# and does it after running everything)
test_at_end_hook_ () {
--
1.8.3.4.1238.ga800761
--
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] perf-lib: add test_perf_cleanup target
Currently there is no way to clean up the changes that have been made
with test_perf for the next run. Add a way to reset the repository to
the state before the test for testing commands that modify the git
repository, e.g. for perf testing git add.
Signed-off-by: Thomas Gummerer t.gumme...@gmail.com
---
This enables me to do something like (hint, hint, hint ;-)):
TestHEAD~1HEAD
0003.16: v5 update-index file 0.19(0.12+0.06) 0.08(0.06+0.01)
-57.9%
There are no performance tests currently using this, but since I have
it anyway for a POC of partial writing of index-v5 (which is ugly and
will have to wait a bit until I'm ready to send it to the list) I think
this may be a worthwhile addition others can use in the meantime.
t/perf/README | 11 +++
t/perf/perf-lib.sh | 25 +
2 files changed, 36 insertions(+)
diff --git a/t/perf/README b/t/perf/README
index 8848c14..72f8a7b 100644
--- a/t/perf/README
+++ b/t/perf/README
@@ -123,6 +123,17 @@ tests, use
command2
'
+For performance tests that need cleaning up after them that should not
+be timed, use
+
+ test_perf_cleanup 'descriptive string' '
+ command1
+ command2
+ ' '
+ cleanupcommand1
+ cleanupcommand2
+ '
+
test_perf spawns a subshell, for lack of better options. This means
that
diff --git a/t/perf/perf-lib.sh b/t/perf/perf-lib.sh
index 95e483c..11a93f1 100644
--- a/t/perf/perf-lib.sh
+++ b/t/perf/perf-lib.sh
@@ -174,6 +174,22 @@ perf_test_ () {
test_failure_ $@
break
fi
+ say 3 cleaning up: $3
+ if test $# = 3
+ then
+ if test_run_ $3
+ then
+ if test -z $verbose; then
+ echo -n c$i
+ else
+ echo * cleaning up run
$i/$GIT_PERF_REPEAT_COUNT:
+ fi
+ else
+ test -z $verbose echo
+ test_failure_ $@
+ break
+ fi
+ fi
done
if test -z $verbose; then
echo ok
@@ -194,6 +210,15 @@ test_perf () {
perf_test_ $1 $2
}
+test_perf_cleanup () {
+ test_start_
+ test $# = 4 { test_prereq=$1; shift; } || test_prereq=
+ test $# = 3 ||
+ error bug in the test script: not 3 or 4 parameters to
test-expect-success
+ export test_prereq
+ perf_test_ $1 $2 $3
+}
+
# We extend test_done to print timings at the end (./run disables this
# and does it after running everything)
test_at_end_hook_ () {
--
1.8.3.4.1238.ga800761
--
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
Mail Back iF You Are Interested!
It is Private I am George Daniels, a Banker and credit system programmer (HSBC bank). I saw your email address while browsing through the bank D.T.C Screen in my office yesterday so I decided to use this very chance to know you. I believe we should use every opportunity to know each other better. However, I am contacting you for obvious reason which you will understand. I am sending this mail just to know if this email address is OK, reply me back so that I will send more details to you. I have a very important thing to discuss with you, I look forward to receiving your response at: georgedaniel...@matrock.net. Have a pleasant day. George Daniels -- 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] contacts: allow execution from other directories
Currently git-contacts only works if it is executed from the top level
of the git repository. Enable the execution in sub directories of that
repository.
Signed-off-by: Thomas Gummerer t.gumme...@gmail.com
---
I have no experience in perl, so there may be nicer implementations. It works
when tested manually.
contrib/contacts/git-contacts | 3 +++
1 file changed, 3 insertions(+)
diff --git a/contrib/contacts/git-contacts b/contrib/contacts/git-contacts
index fb6429b..32f03fc 100755
--- a/contrib/contacts/git-contacts
+++ b/contrib/contacts/git-contacts
@@ -61,6 +61,9 @@ sub import_commits {
sub get_blame {
my ($commits, $source, $from, $ranges) = @_;
return unless @$ranges;
+ my $git_dir = `git rev-parse --show-toplevel`;
+ chomp($git_dir);
+ $source = $git_dir . '/' . $source;
open my $f, '-|',
qw(git blame --porcelain -C),
map({-L$_-[0],+$_-[1]} @$ranges),
--
1.8.4.535.g7b94f8e.dirty
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] build: add default configuration
For now simply add a few common aliases. co = checkout ci = commit rb = rebase st = status Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- Makefile | 5 - gitconfig | 5 + 2 files changed, 9 insertions(+), 1 deletion(-) create mode 100644 gitconfig diff --git a/Makefile b/Makefile index 3588ca1..18081bf 100644 --- a/Makefile +++ b/Makefile @@ -1010,7 +1010,7 @@ ifndef sysconfdir ifeq ($(prefix),/usr) sysconfdir = /etc else -sysconfdir = etc +sysconfdir = $(prefix)/etc endif endif @@ -1586,6 +1586,7 @@ template_dir_SQ = $(subst ','\'',$(template_dir)) htmldir_relative_SQ = $(subst ','\'',$(htmldir_relative)) prefix_SQ = $(subst ','\'',$(prefix)) gitwebdir_SQ = $(subst ','\'',$(gitwebdir)) +sysconfdir_SQ = $(subst ','\'',$(sysconfdir)) SHELL_PATH_SQ = $(subst ','\'',$(SHELL_PATH)) PERL_PATH_SQ = $(subst ','\'',$(PERL_PATH)) @@ -2340,6 +2341,8 @@ install: all $(MAKE) -C templates DESTDIR='$(DESTDIR_SQ)' install $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(mergetools_instdir_SQ)' $(INSTALL) -m 644 mergetools/* '$(DESTDIR_SQ)$(mergetools_instdir_SQ)' + $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(sysconfdir_SQ)' + $(INSTALL) -m 644 gitconfig '$(DESTDIR_SQ)$(ETC_GITCONFIG_SQ)' ifndef NO_GETTEXT $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(localedir_SQ)' (cd po/build/locale $(TAR) cf - .) | \ diff --git a/gitconfig b/gitconfig new file mode 100644 index 000..c45d300 --- /dev/null +++ b/gitconfig @@ -0,0 +1,5 @@ +[alias] + co = checkout + ci = commit + rb = rebase + st = status -- 1.8.4-fc -- 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] Add core.mode configuration
So that we can specify general modes of operation, specifically, add the
'next' mode, which makes Git pre v2.0 behave as Git v2.0.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
builtin/add.c | 3 +++
cache.h | 6 ++
config.c | 13 +
environment.c | 1 +
4 files changed, 23 insertions(+)
diff --git a/builtin/add.c b/builtin/add.c
index 8266a9c..85b4c54 100644
--- a/builtin/add.c
+++ b/builtin/add.c
@@ -41,6 +41,9 @@ static void warn_pathless_add(void)
static int shown;
assert(option_with_implicit_dot short_option_with_implicit_dot);
+ if (git_mode == MODE_NEXT)
+ return;
+
if (shown)
return;
shown = 1;
diff --git a/cache.h b/cache.h
index 85b544f..f28240f 100644
--- a/cache.h
+++ b/cache.h
@@ -627,9 +627,15 @@ enum push_default_type {
PUSH_DEFAULT_UNSPECIFIED
};
+enum git_mode {
+ MODE_CURRENT = 0,
+ MODE_NEXT
+};
+
extern enum branch_track git_branch_track;
extern enum rebase_setup_type autorebase;
extern enum push_default_type push_default;
+extern enum git_mode git_mode;
enum object_creation_mode {
OBJECT_CREATION_USES_HARDLINKS = 0,
diff --git a/config.c b/config.c
index e13a7b6..f0e0370 100644
--- a/config.c
+++ b/config.c
@@ -831,6 +831,19 @@ static int git_default_core_config(const char *var, const
char *value)
return 0;
}
+ if (!strcmp(var, core.mode)) {
+ if (!value)
+ return config_error_nonbool(var);
+ else if (!strcmp(value, current))
+ git_mode = MODE_CURRENT;
+ else if (!strcmp(value, next)) {
+ git_mode = MODE_NEXT;
+ push_default = PUSH_DEFAULT_SIMPLE;
+ } else
+ die(wrong mode '%s', value);
+ return 0;
+ }
+
/* Add other config variables here and to Documentation/config.txt. */
return 0;
}
diff --git a/environment.c b/environment.c
index 5398c36..751e14d 100644
--- a/environment.c
+++ b/environment.c
@@ -62,6 +62,7 @@ int merge_log_config = -1;
int precomposed_unicode = -1; /* see probe_utf8_pathname_composition() */
struct startup_info *startup_info;
unsigned long pack_size_limit_cfg;
+enum git_mode git_mode = MODE_CURRENT;
/*
* The character that begins a commented line in user-editable file
--
1.8.4-fc
--
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] git-compat-util: Avoid strcasecmp() being inlined
Sebastian Schuberth sschube...@gmail.com writes: I think this is less favorable compared to my last proposed solution. That is only needed if you insist to use C preprocessor that does not understand include_next. That choice is a platform specific decision (even if you want to use such a compiler on a platform it may not have been ported to yours, etc.). Keeping the ugliness to deal with the platform issue (i.e. broken string.h) in one place (e.g. compat/mingw) is far more preferrable than having a similar ugliness in git-compat-util.h for people on all other platforms to see, no? -- 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 1/3] test: use unambigous leading path (/foo) for mingw
Torsten Bögershausen tbo...@web.de writes: Yes, there is a directoctory structure in / like this: /usr /bin /lib Then we have the drive letters mapped to single letters: /c/Documents and Settings /c/temp 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 v3 2/3] relative_path should honor DOS and UNC paths
Jiang Xin worldhello@gmail.com writes:
diff --git a/compat/mingw.h b/compat/mingw.h
index bd0a88b..06e9f49 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -311,6 +311,15 @@ int winansi_fprintf(FILE *stream, const char *format,
...) __attribute__((format
#define has_dos_drive_prefix(path) (isalpha(*(path)) (path)[1] == ':')
#define is_dir_sep(c) ((c) == '/' || (c) == '\\')
+static inline int is_unc_path(const char *path)
+{
+ if (!is_dir_sep(*path) || !is_dir_sep(*(path+1)) ||
is_dir_sep(*(path+2)))
+ return 0;
If path[1] == '\0', it would be !is_dir_sep() and we end up
inspecting past the end of the string?
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] diff: add a config option to control orderfile
Michael S. Tsirkin m...@redhat.com writes: Actually, after I've looked at the code, diffcore_order is already already called for patch-id. That was a band-aid for an ill-thought-out orderfile misfeature to hide the breakage. You somehow make sure that you pass the same orderfile to diff generating machinery used internal to patch-id generation. The standalone git patch-id would be reading the patch in the order you give it when you are feeding a patch somebody sent you via the mailing list using an order unknown to you, no? Before making it _easier_ to use the orderfile to generate diffs, we would need to prepare the parts that will be broken by wider use of the feature. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: git bisect should accept paths-to-be-excluded
On 09/17/2013 09:26 AM, Christian Couder wrote: Hi, On Mon, Sep 16, 2013 at 2:39 PM, Toralf Förster toralf.foers...@gmx.de wrote: I'm bisecting a linux kernel issue and want to ignore all commits just touching something in ./drives/staging. Currently the only way would be to specify all dir/subdir combination under ./linux except that particular directory, right ? Yeah, you are right, currently the only way would be to specify all dir/subdir combination under ./linux except the particular directory you want to exclude. It might indeed be useful to have a way to exclude some directories or files. Great to hear In practice though, as git bisect is a kind of binary search, if what you want to exclude is exclusively touched by half the commits, it will only add one more bisection step if you don't exclude it. Unfortunately not. Linus pulls from Greg's staging tree usually once in a merge window. It is not uncommon to have hundreds of commits in that merge. If now (by accident) the merge point is marked as BAD and the base is GOOD, then git bisect falls into that trap and wastes about ld(few hundreds) steps - and this happened here for me and each bisect step took hours ... Best regards, Christian. -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] repack: rewrite the shell script in C
Ramkumar Ramachandra artag...@gmail.com writes: Is $GIT_OBJECT_DIRECTORY a standard variable, or should it be $GIT_DIR/objects? man git ;-) It has been there since early May 2005 -- 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 0/4] stop storing trailing slash in dir-hash
Eric Sunshine sunsh...@sunshineco.com writes: * Split v1 patch 1 into v2 patches 1 2 to ease review. (This is possible now that index_name_exists() retains its original behavior.) It really shows in [PATCH 2/4] that illustrates which callers were depending on the old calling convention; I like it. 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] contacts: allow execution from other directories
On Tue, Sep 17, 2013 at 8:50 AM, Thomas Gummerer t.gumme...@gmail.com wrote:
Currently git-contacts only works if it is executed from the top level
of the git repository. Enable the execution in sub directories of that
repository.
Thanks. This was on my to-do list but fell off my radar when I
accidentally deleted the to-do list (which, oddly, was not under
version control).
I have a patch in my local tree accomplishing the same thing, but in a
less expensive manner. I'll post it a bit later today for review.
Signed-off-by: Thomas Gummerer t.gumme...@gmail.com
---
I have no experience in perl, so there may be nicer implementations. It
works when tested manually.
contrib/contacts/git-contacts | 3 +++
1 file changed, 3 insertions(+)
diff --git a/contrib/contacts/git-contacts b/contrib/contacts/git-contacts
index fb6429b..32f03fc 100755
--- a/contrib/contacts/git-contacts
+++ b/contrib/contacts/git-contacts
@@ -61,6 +61,9 @@ sub import_commits {
sub get_blame {
my ($commits, $source, $from, $ranges) = @_;
return unless @$ranges;
+ my $git_dir = `git rev-parse --show-toplevel`;
+ chomp($git_dir);
+ $source = $git_dir . '/' . $source;
open my $f, '-|',
qw(git blame --porcelain -C),
map({-L$_-[0],+$_-[1]} @$ranges),
--
1.8.4.535.g7b94f8e.dirty
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] diff: add a config option to control orderfile
Michael S. Tsirkin m...@redhat.com writes: So might it not be useful to tweak patch id to sort the diff, making it a bit more stable? That is one thing that needs to be done, I think. But it would be unfortunate if we have to do that unconditionally, though, as we may be buffering many hundred kilobytes of patch text in core. If we can do so without regressing the streaming performance for the most common case of not using the orderfile on the generating side (hence not having to sort on the receiving end), it would be ideal. I am not sure offhand how much code damage we are talking about, though. I'll be glad to help do this if you tell me what these parts are. anything else besides fixing besides the stand-alone patch id? Off the top of my head I do not think of one (but that is not a guarantee that there isn't any). -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] diff: add a config option to control orderfile
On Tue, Sep 17, 2013 at 09:26:13AM -0700, Junio C Hamano wrote: Michael S. Tsirkin m...@redhat.com writes: Actually, after I've looked at the code, diffcore_order is already already called for patch-id. That was a band-aid for an ill-thought-out orderfile misfeature to hide the breakage. You somehow make sure that you pass the same orderfile to diff generating machinery used internal to patch-id generation. The standalone git patch-id would be reading the patch in the order you give it when you are feeding a patch somebody sent you via the mailing list using an order unknown to you, no? Yes but that's already the case, right? People don't have to use git to generate patches. So might it not be useful to tweak patch id to sort the diff, making it a bit more stable? This means it needs to pass twice over the file, but is this a huge issue? pass 1 - get offsets of chunks and sort them pass 2 - seek each chunk and hash what do you think? Before making it _easier_ to use the orderfile to generate diffs, we would need to prepare the parts that will be broken by wider use of the feature. I'll be glad to help do this if you tell me what these parts are. anything else besides fixing besides the stand-alone patch id? -- MST -- 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
YOUR WIN INFORMATION
Your e-mail has won you ￡1,000,000.00 from BBC XMAS PROMO 1, Name 2, Country 3, Mobile No 4, Occupation Send Response to ( eruraf...@56788.com ) Prof. Peter --==Mailed via NDMCTSGH Webmail==-- -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: git bisect should accept paths-to-be-excluded
Duy Nguyen pclo...@gmail.com writes: On Tue, Sep 17, 2013 at 4:03 PM, Christian Couder christian.cou...@gmail.com wrote: On Tue, Sep 17, 2013 at 10:21 AM, Matthieu Moy matthieu@grenoble-inp.fr wrote: Christian Couder christian.cou...@gmail.com writes: In practice though, as git bisect is a kind of binary search, if what you want to exclude is exclusively touched by half the commits, it will only add one more bisection step if you don't exclude it. Actually, I think the same remark would apply to any other Git command that deal with a set of revisions. If you want to review code with git log -p, but you don't care about a subdirectory, you may want a git log -p --ignore-dir foo/ or so, too. Yeah, and there was a patch series about that 2 years ago: http://thread.gmane.org/gmane.comp.version-control.git/182830/ And that's just one of the few attempts if I remember correctly. I guess it's time revisit it. A few things to sort out before we get to the implementation: Support flat or nested negation (i.e.include A, ignore A/B, but include A/B/C..). Nested thing complicates things so I'm towards the flat exclusion (exclude B means all inside B, no buts nor excepts) and probably cover most use cases Yeah, it is easy to say that git log -- A ':(exclude)A/B' A/B/C has two positive (A, A/B/C) and one negative (A/B), and then the most specific one A/B/C matches a path A/B/C/D and hence A/B/C/D is included. But to actually _design_ it, there are ambiguities that makes understanding and explaining the semantics, especially given pathspecs can have wildcards, icase matches, etc. For example, is :(exclude,icase)A/B/? more specific than A/?/C or less? So I tend to agree that we should aim for an easier to explain, if less capable, approach. Interaction with git grep --depth I am not sure how that affects anything. Conceptually, isn't --depth an independent axis to filter out paths that have too many components after given positive pathspec elements? E.g. given git grep --depth=2 pattern -- A B/C we will grab paths from two levels starting at A and B/C (so A/1/2 and B/C/1/2 may hit but not A/1/2/3 nor B/C/1/2/3). Shouldn't negative pathspecs just filter that depth filtering, i.e. if you have :(exclude)*/1/*, even though both A/1/2 and A/a/b may pass the --depth=2 filter, the former is excluded while the latter is not. Syntax. I guess --ignore (or --exclude) is more intuitive than :(exclude)something but then it might collide with existing options (I did not check if --ignore or --exclude is used anywhere though). The latter also enables combining with other filters, such as case-insensitive matching.. I do not think it is an option to do this with any mechanism other than negative pathspecs. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] diff: add a config option to control orderfile
On Tue, Sep 17, 2013 at 10:24:19AM -0700, Junio C Hamano wrote: Michael S. Tsirkin m...@redhat.com writes: So might it not be useful to tweak patch id to sort the diff, making it a bit more stable? That is one thing that needs to be done, I think. But it would be unfortunate if we have to do that unconditionally, though, as we may be buffering many hundred kilobytes of patch text in core. If we can do so without regressing the streaming performance for the most common case of not using the orderfile on the generating side (hence not having to sort on the receiving end), it would be ideal. I am not sure offhand how much code damage we are talking about, though. So make it conditional on the presence of the orderefile option? I'll be glad to help do this if you tell me what these parts are. anything else besides fixing besides the stand-alone patch id? Off the top of my head I do not think of one (but that is not a guarantee that there isn't any). -- 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: Bisect needing to be at repo top-level?
Burton, Ross ross.bur...@intel.com writes: Why does git-bisect need to be ran from the top level of the working tree? It sources git-sh-setup.sh which sets GIT_DIR, which git-bisect.sh then appears to consistently use. Is there a reason for needing to be at the top-level, or is this an old and redundant message? A wild guess. Imagine if you start from a subdirectory foo/ but the directory did not exist in the older part of the history of the project. When bisect needs to check out a revision that was older than the first revision that introduced that subdirectory, what should happen? Worse yet, if foo was a file in the older part of the history, what should happen? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: git bisect should accept paths-to-be-excluded
Junio C Hamano gits...@pobox.com napisał: Yeah, it is easy to say that git log -- A ':(exclude)A/B' A/B/C has two positive (A, A/B/C) and one negative (A/B), and then the most specific one A/B/C matches a path A/B/C/D and hence A/B/C/D is included. But to actually _design_ it, there are ambiguities that makes understanding and explaining the semantics, especially given pathspecs can have wildcards, icase matches, etc. For example, is :(exclude,icase)A/B/? more specific than A/?/C or less? What about simply iterating over options in order in which they are specified and the last option that matches specifies the result? -- Piotr Krukowiecki -- 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 2/2] perf-lib: add test_perf_cleanup target
Thomas Gummerer t.gumme...@gmail.com writes: +For performance tests that need cleaning up after them that should not +be timed, use + + test_perf_cleanup 'descriptive string' ' + command1 + command2 + ' ' + cleanupcommand1 + cleanupcommand2 + ' + Hmm, if not timing the clean-up actions is the primary goal, is it an option to reuse test_when_finished for this (you may have to make sure that the commands run inside it are not timed; I didn't check). One thing I felt uneasy about the above construct is that it makes cleanupcommand2 responsible for handling cases where not just command2 but also command1 might have failed. Compared to that, test-when-finished allows you to control what clean-up to do depending on what have already been done, i.e. test_when_finished 'undo what command1 would have done' command1 test_when_finished 'undo what command2 would have done' command2 ... The second undo command2 must be prepared for the case where command2 may have failed in the middle, but it can at least rely on command1 having succeeded when it is run. -- 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
Delete branch during fast-import
I'm trying out a rather large subversion import, and am trying to figure out if there is a way to delete branches during a fast-import. Right now I can think of only 2 ways to handle this: 1) End the import, do a git branch -D and then resume the import. 2) Scan the entire repository history, identify deleted branches and handle them upfront so that they never have conflicting names. Is there a better way? -Jason -- 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: Bisect needing to be at repo top-level?
On Tue, Sep 17, 2013 at 10:27:49AM -0700, Junio C Hamano wrote: Burton, Ross ross.bur...@intel.com writes: Why does git-bisect need to be ran from the top level of the working tree? It sources git-sh-setup.sh which sets GIT_DIR, which git-bisect.sh then appears to consistently use. Is there a reason for needing to be at the top-level, or is this an old and redundant message? A wild guess. Imagine if you start from a subdirectory foo/ but the directory did not exist in the older part of the history of the project. When bisect needs to check out a revision that was older than the first revision that introduced that subdirectory, what should happen? Worse yet, if foo was a file in the older part of the history, what should happen? If that is the real explanation, why do we allow running git-checkout(1) from a subdirectory? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] diff: add a config option to control orderfile
Michael S. Tsirkin m...@redhat.com writes: On Tue, Sep 17, 2013 at 10:24:19AM -0700, Junio C Hamano wrote: Michael S. Tsirkin m...@redhat.com writes: So might it not be useful to tweak patch id to sort the diff, making it a bit more stable? That is one thing that needs to be done, I think. But it would be unfortunate if we have to do that unconditionally, though, as we may be buffering many hundred kilobytes of patch text in core. If we can do so without regressing the streaming performance for the most common case of not using the orderfile on the generating side (hence not having to sort on the receiving end), it would be ideal. I am not sure offhand how much code damage we are talking about, though. So make it conditional on the presence of the orderefile option? That would mean that those who set orderfile from configuration in the future will have to always suffer, I would think. Is that acceptable? I dunno. Also, if the sender used a non-standard order, the recipient does not know what order the patch was generated, and the recipient does not use a custom orderfile, what should happen? I thought your idea was to normalize by using some canonical order that is not affected by the orderfile to make sure patch-id stays stable, so I would imagine that such a recipient who does not have orderfile specified still needs to sort before hashing, no? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] repack: rewrite the shell script in C
Stefan Beller stefanbel...@googlemail.com writes:
+ struct option builtin_repack_options[] = {
+ OPT_BIT('a', NULL, pack_everything,
+ N_(pack everything in a single pack),
ALL_INTO_ONE),
+ OPT_BIT('A', NULL, pack_everything,
+ N_(same as -a, and turn unreachable objects
loose),
+LOOSEN_UNREACHABLE),
Micronit.
With the current version of the code in cmd_repack() that uses the
pack_everything variable this may not make a difference, but I think
this should logically be LOOSEN_UNREACHABLE | ALL_INTO_ONE instead,
and the code should check (pack_evertying ALL_INTO_ONE) instead of
checking !pack_everything. You may want to add to this flag variable
a new bit that does _not_ cause it to pack everything into one.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: git bisect should accept paths-to-be-excluded
Piotr Krukowiecki piotr.krukowie...@gmail.com writes: What about simply iterating over options in order in which they are specified and the last option that matches specifies the result? But isn't it very inconsistent from the way normal pathspec works? git log -- A B and git log -- B A would give the same result. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[BUG?] git checkout $commit -- somedir doesn't drop files
Hello, after these commands: $ git init $ mkdir subdir $ echo a subdir/a $ git add subdir/a $ git commit -m a $ echo more a subdir/a $ echo b subdir/b $ git add subdir/* $ git commit -m b $ git checkout HEAD^ -- subdir I'd expect that subdir/b is removed from the index as this file didn't exist in HEAD^ but git-status only reports: # On branch master # Changes to be committed: # (use git reset HEAD file... to unstage) # # modified: subdir/a # Is this intended? (I'm using git 1.8.4.rc3 as shipped by Debian (package version 1:1.8.4~rc3-1).) Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- 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: Bisect needing to be at repo top-level?
On 17 September 2013 18:27, Junio C Hamano gits...@pobox.com wrote: Burton, Ross ross.bur...@intel.com writes: Why does git-bisect need to be ran from the top level of the working tree? It sources git-sh-setup.sh which sets GIT_DIR, which git-bisect.sh then appears to consistently use. Is there a reason for needing to be at the top-level, or is this an old and redundant message? A wild guess. Imagine if you start from a subdirectory foo/ but the directory did not exist in the older part of the history of the project. When bisect needs to check out a revision that was older than the first revision that introduced that subdirectory, what should happen? Worse yet, if foo was a file in the older part of the history, what should happen? git checkout doesn't mandate that you're at the top-level, so that's not a very strong argument. Ross -- 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] git-compat-util: Avoid strcasecmp() being inlined
On Tue, Sep 17, 2013 at 6:17 PM, Junio C Hamano gits...@pobox.com wrote: Keeping the ugliness to deal with the platform issue (i.e. broken string.h) in one place (e.g. compat/mingw) is far more preferrable than having a similar ugliness in git-compat-util.h for people on all other platforms to see, no? I don't think people on other platforms seeing the ugliness is really an issue. After all, the file is called git-*compat*-util.h; I sort of expect to see such things there, and I would expect only more complex compatibility stuff that requires multiple files in the compat/ directory. Also, your solution does not really keep the ugliness in one place, you need the change in config.mak.uname, too (because yes, I do insist to avoid GCC-ism in C files, just like you probably would insist to avoid Bash-ism in shell scripts). -- Sebastian Schuberth -- 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: Bisect needing to be at repo top-level?
Lukas Fleischer g...@cryptocrack.de writes: Imagine if you start from a subdirectory foo/ but the directory did not exist in the older part of the history of the project. When bisect needs to check out a revision that was older than the first revision that introduced that subdirectory, what should happen? Worse yet, if foo was a file in the older part of the history, what should happen? If that is the real explanation, No. As the line you snipped from your quote says, it is just a guess without running git log -- git-bisect.sh git-bisect-script. Also it points at things one needs to watch out for and think about when attempting to update git bisect to make it possible to run it anywhere in the working tree. why do we allow running git-checkout(1) from a subdirectory? Oversight? At least on Linux, if you checkout a revision with foo/ directory, chdir to it and then checkout a revision with foo file to nuke your current place, I know git checkout will happily do so and you will still be in a directory that is connected nowhere. Your .. is probably pointing at the top-level, but there is no reverse, so cd ../foo may or may not work from that state, and it would lead to an interesting confusion. We may want to check the condition and forbid such a checkout. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] diff: add a config option to control orderfile
On Tue, Sep 17, 2013 at 11:06:07AM -0700, Junio C Hamano wrote: Michael S. Tsirkin m...@redhat.com writes: On Tue, Sep 17, 2013 at 10:24:19AM -0700, Junio C Hamano wrote: Michael S. Tsirkin m...@redhat.com writes: So might it not be useful to tweak patch id to sort the diff, making it a bit more stable? That is one thing that needs to be done, I think. But it would be unfortunate if we have to do that unconditionally, though, as we may be buffering many hundred kilobytes of patch text in core. If we can do so without regressing the streaming performance for the most common case of not using the orderfile on the generating side (hence not having to sort on the receiving end), it would be ideal. I am not sure offhand how much code damage we are talking about, though. So make it conditional on the presence of the orderefile option? That would mean that those who set orderfile from configuration in the future will have to always suffer, I would think. Is that acceptable? I dunno. Well it's just two passes over a diff. Are we optimizing this for tape based systems or something? Also, if the sender used a non-standard order, the recipient does not know what order the patch was generated, and the recipient does not use a custom orderfile, what should happen? I thought your idea was to normalize by using some canonical order that is not affected by the orderfile to make sure patch-id stays stable, so I would imagine that such a recipient who does not have orderfile specified still needs to sort before hashing, no? If you like, but I don't really care. It's fine with me to make this conditional on specifying an order file on recepient side. Or we can make it a separate option. Or we can stick some hint about the order in the patch. Tell me what you prefer :) -- MST -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: git bisect should accept paths-to-be-excluded
On Tue, Sep 17, 2013 at 9:04 PM, Junio C Hamano gits...@pobox.com wrote: Piotr Krukowiecki piotr.krukowie...@gmail.com writes: What about simply iterating over options in order in which they are specified and the last option that matches specifies the result? But isn't it very inconsistent from the way normal pathspec works? git log -- A B and git log -- B A would give the same result. Both are include-type filters. --include A --include B will give the same result as --include B --include A too. Are there existing include/exclude filters where order does not matter? For example gitattributes(5) says When more than one pattern matches the path, a later line overrides an earlier line. Ignoring (possible) inconsistency thing, I think they are easy to understand and use. -- Piotr Krukowiecki -- 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
Locking files / git
Ooops. It seems that each time somebody says these two words together, people hate him, and he is scorned by friends and family. However, - gitolite implement it (but gitolite is not git). - In the documentation, each time the need is evocated, it is replace by do communication, don't use git for that. I'm still looking for the good way to communicate this information. In my humble opinion, git is a communication tool. I won't explain here why it could be a if not good, at least helpfull new feature (and everybody is not mandatory to use new feature), I've still heard no argument about why it could not be accepted in git better than locking is bad. I want to explain how I could implement it. Firstly, it would (in the general form ; some options could be added) alter no existing command of git. It would add 3 new commands : - git lock [path] - git unlock [path] - git lslock It would add 2 new files in .git : - lockserver containing a ssh url of the git repository, not necessary the source of the clone (in fact, the same content of the lockserver file in the source of the clone so that people gets the same lock server) - lockedfiles containing the list of pathes of locked files (plus name of the people locking, date) on the lock server. git push would not be altered, however, you can imagine an option to unlock all locked files by yourself. the 3 new commands would require a communication to the lock server. note that the idea is that everybody get the same lock server in any workflow. In case there was no server defined on the original git repository, you have to communicate so that people configure the lockserver file. git lock would put the path provided into the lock server git unlock would remove the path provided from the lock server git lslock would ask pathes to the lock server You must have rules on your project, for example, lock a .doc file each time you modify it. If you follow that guideline, you’ll be fine. If you don’t, people will hate you, and you’ll be scorned by friends and family. If you push a file which is not locked by you, any problem, it will push (eventually, telling you that the file was locked and that your project has some rules). What about automatic unlocking to prevent from forgetting to unlock : Something like pushing when the push server is the same as the lock server could automatically unlock the file. The question is when to unlock when you have a complex workflow with a dictator. I agree i've not the best answer for the moment. Something like when the developper have the files back, identically from the source of the dictator. This point could be think more. Scenario : @alice : git lock src/main.c @bob : git lock src/main.c fatal: file src/main.c locked by alice @alice : git unlock src/main.c @bob : git lock src/main.c For the moment, i want a first feedback, an intermediate between locking is bad and ok, but i would prefer in the negativ answer something with arguments (Take CVS as an example of what not to do; if in doubt, make the exact opposite decision. is one), and in the positiv answer, good remarks about problems with my implementation that could make it better. Perhaps this subject has already been discussed and is closed, in this case, sorry, just give me the link i've not found please. Nicolas Adenis-Lamarre -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] relative_path should honor dos_drive_prefix
Am 17.09.2013 10:24, schrieb Jiang Xin: I have checked the behavior of UNC path on Windows (msysGit): * I can cd to a UNC path: cd //server1/share1/path * can cd to other share: cd ../../share2/path * and can cd to other server's share: cd ../../../server2/share/path That means relative_path(path1, path2) support UNC paths out of the box. We only need to check both path1 and path2 are UNC paths, or both not. Your tests are flawed. You issued the commands in bash, which (or rather MSYS) does everything for you that you need to make it work. But in reality it does not, because the system cannot apply .. to //server/share: $ git ls-remote //srv/public/../repos/his/setups.git fatal: '//srv/public/../repos/his/setups.git' does not appear to be a git repository fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. even though the repository (and //srv/public, let me assure) exists: $ git ls-remote //srv/repos/his/setups.git bea489b0611a72c41f133343fdccbd3e2b9f80b5HEAD ... The situation does not change with your latest round (v3). Please let me suggest not to scratch where there is no itch. ;) Your round v2 was good enough. If you really want to check UNC paths, then you must compare two path components after the the double-slash, not just one. Furthermore, you should audit all code that references is_absolute_path(), relative_path(), normalize_path_copy(), and possibly a few others whether the functions or call sites need improvement. That's worth a separate patch. -- Hannes -- 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: Delete branch during fast-import
Jason Miller wrote: I'm trying out a rather large subversion import, and am trying to figure out if there is a way to delete branches during a fast-import. Right now I can think of only 2 ways to handle this: 1) End the import, do a git branch -D and then resume the import. 2) Scan the entire repository history, identify deleted branches and handle them upfront so that they never have conflicting names. Is there a better way? Yes, support branch deletion natively: http://mid.gmane.org/1377789808-2213-7-git-send-email-felipe.contre...@gmail.com -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG?] git checkout $commit -- somedir doesn't drop files
Uwe Kleine-König u.kleine-koe...@pengutronix.de writes: after these commands: $ git init $ mkdir subdir $ echo a subdir/a $ git add subdir/a $ git commit -m a $ echo more a subdir/a $ echo b subdir/b $ git add subdir/* $ git commit -m b $ git checkout HEAD^ -- subdir I'd expect that subdir/b is removed from the index as this file didn't exist in HEAD^ but git-status only reports: # On branch master # Changes to be committed: # (use git reset HEAD file... to unstage) # # modified: subdir/a # Is this intended? (I'm using git 1.8.4.rc3 as shipped by Debian (package version 1:1.8.4~rc3-1).) The intended behaviour of git checkout tree-ish -- pathspec has always been grab paths that match pathspec from tree-ish, add them to the index and check them out to the working tree. If you have subdir/b in the index and the working tree, it will be kept when the paths that match subdir pathspec is grabbed out of the tree-ish HEAD^ (namely, subdir/a) is added to the index and to the working tree. I could argue that the above intended behaviour is suboptimal and it should have been the resulting paths in the index and the work tree that match the given pathspec must be identical to that of the tree-ish. In the resulting index or working tree, paths that match subdir pathspec in the above result is subdir/a and subdir/b, and that is different from what exists in the given tree-ish (which has only subdir/a and not subdir/b), and under that modified definition, what the current one does is not correct. I vaguely recall arguing for the updated behaviour described in the above paragraph, and I even might have started working on it, but I do not think we changed this behaviour recently, unfortunately. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG?] git checkout $commit -- somedir doesn't drop files
On Tue, Sep 17, 2013 at 12:58:07PM -0700, Junio C Hamano wrote: I could argue that the above intended behaviour is suboptimal and it should have been the resulting paths in the index and the work tree that match the given pathspec must be identical to that of the tree-ish. In the resulting index or working tree, paths that match subdir pathspec in the above result is subdir/a and subdir/b, and that is different from what exists in the given tree-ish (which has only subdir/a and not subdir/b), and under that modified definition, what the current one does is not correct. Our emails just crossed, but I basically ended up saying a similar thing. Could we simply replace the update_some in builtin/checkout.c with a two-way merge via unpack-trees? I vaguely recall arguing for the updated behaviour described in the above paragraph, and I even might have started working on it, but I do not think we changed this behaviour recently, unfortunately. Yes, I did some digging and I think it has always been this way, even before git-checkout was a builtin. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG?] git checkout $commit -- somedir doesn't drop files
On Tue, Sep 17, 2013 at 09:06:59PM +0200, Uwe Kleine-König wrote: $ git checkout HEAD^ -- subdir I'd expect that subdir/b is removed from the index as this file didn't exist in HEAD^ but git-status only reports: I'm not sure if this is intentional or not. The definition of git checkout $tree $path given in commit 0a1283b says: Checking paths out of a tree is (currently) defined to do: - Grab the paths from the named tree that match the given pathspec, and add them to the index; - Check out the contents from the index for paths that match the pathspec to the working tree; and while at it - If the given pathspec did not match anything, suspect a typo from the command line and error out without updating the index nor the working tree. So we are applying the pathspec to the named tree, and pulling anything that matches into the index. Which by definition cannot involve a deletion, because there is no comparison happening (so we either have it, or we do not). Whereas what you are expecting is to compare the tree and the index, limited by the pathspec, and pull any changes from the tree into the index. I tend to agree that the latter is more like how other git commands behave (e.g., if you tried to use read-tree to emulate what git-checkout was doing, I think you would end up with a two-way merge). But there may be implications I haven't thought of. Note also that git checkout -p does present subdir/b as a deletion. It works by doing a pathspec-limited diff between the two endpoints, which will notice deletions. So there is some inconsistency there with the baseline form. -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 1/2] repack: rewrite the shell script in C
On 09/15/2013 05:31 PM, Stefan Beller wrote:
Rene, thank you very much for the review!
the parameter hex contains the pack- already.
The remove_redundant_pack function is called in a loop iterating over
elements of existing_packs, which is filled in get_non_kept_pack_filenames,
which doesn't fill in the hex, but filenames without extension.
I'll rename the variables to base_name and dir_name as you suggested.
I did write a lengthy paragraph, but forgot to actually to it.
---8---
From 92af79a5a89929d8834ff6d585c0455c867a774f Mon Sep 17 00:00:00 2001
From: Stefan Beller stefanbel...@googlemail.com
Date: Tue, 17 Sep 2013 22:04:14 +0200
Subject: [PATCH 1/2] Fixup missing by Rene.
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
builtin/repack.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin/repack.c b/builtin/repack.c
index f7e91bf..e5f90c6 100644
--- a/builtin/repack.c
+++ b/builtin/repack.c
@@ -92,14 +92,14 @@ static void get_non_kept_pack_filenames(struct string_list
*fname_list)
closedir(dir);
}
-static void remove_redundant_pack(const char *path_prefix, const char *hex)
+static void remove_redundant_pack(const char *dir_name, const char *base_name)
{
const char *exts[] = {.pack, .idx, .keep};
int i;
struct strbuf buf = STRBUF_INIT;
size_t plen;
- strbuf_addf(buf, %s/%s, path_prefix, hex);
+ strbuf_addf(buf, %s/%s, dir_name, base_name);
plen = buf.len;
for (i = 0; i ARRAY_SIZE(exts); i++) {
--
1.8.4.273.ga194ead
signature.asc
Description: OpenPGP digital signature
Re: [PATCH] diff: add a config option to control orderfile
On Tue, Sep 17, 2013 at 11:16:04PM +0300, Michael S. Tsirkin wrote: Thinking about it some more, it's a best effort thing anyway, correct? So how about, instead of doing a hash over the whole input, we hash each chunk and XOR them together? This way it will be stable against chunk reordering, and no need to keep patch in memory. Hmm? ENOCOFFEE That was a silly suggestion, two identical chunks aren't that unlikely :) In a single patch, they should not be, as we should be taking into account the filenames, no? You could also do it hierarchically. Hash each chunk, store only the hashes, then sort them and hash the result. That still has O(chunks) storage, but it is only one hash per chunk, not the whole data. A problem with both schemes, though, is that they are not backwards-compatible with existing git-patch-id implementations. Whereas sorting the data itself is (kind of, at least with respect to people who are not using orderfile). -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] diff: add a config option to control orderfile
On Tue, Sep 17, 2013 at 11:06:07AM -0700, Junio C Hamano wrote: Michael S. Tsirkin m...@redhat.com writes: On Tue, Sep 17, 2013 at 10:24:19AM -0700, Junio C Hamano wrote: Michael S. Tsirkin m...@redhat.com writes: So might it not be useful to tweak patch id to sort the diff, making it a bit more stable? That is one thing that needs to be done, I think. But it would be unfortunate if we have to do that unconditionally, though, as we may be buffering many hundred kilobytes of patch text in core. If we can do so without regressing the streaming performance for the most common case of not using the orderfile on the generating side (hence not having to sort on the receiving end), it would be ideal. I am not sure offhand how much code damage we are talking about, though. So make it conditional on the presence of the orderefile option? That would mean that those who set orderfile from configuration in the future will have to always suffer, I would think. Is that acceptable? I dunno. Also, if the sender used a non-standard order, the recipient does not know what order the patch was generated, and the recipient does not use a custom orderfile, what should happen? I thought your idea was to normalize by using some canonical order that is not affected by the orderfile to make sure patch-id stays stable, so I would imagine that such a recipient who does not have orderfile specified still needs to sort before hashing, no? Thinking about it some more, it's a best effort thing anyway, correct? So how about, instead of doing a hash over the whole input, we hash each chunk and XOR them together? This way it will be stable against chunk reordering, and no need to keep patch in memory. Hmm? -- MST -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG?] git checkout $commit -- somedir doesn't drop files
Jeff King p...@peff.net writes: On Tue, Sep 17, 2013 at 12:58:07PM -0700, Junio C Hamano wrote: I could argue that the above intended behaviour is suboptimal and it should have been the resulting paths in the index and the work tree that match the given pathspec must be identical to that of the tree-ish. In the resulting index or working tree, paths that match subdir pathspec in the above result is subdir/a and subdir/b, and that is different from what exists in the given tree-ish (which has only subdir/a and not subdir/b), and under that modified definition, what the current one does is not correct. Our emails just crossed, but I basically ended up saying a similar thing. Could we simply replace the update_some in builtin/checkout.c with a two-way merge via unpack-trees? Would it work to resolve a conflicted index by checking out from a known tree? I vaguely recall arguing for the updated behaviour described in the above paragraph, and I even might have started working on it, but I do not think we changed this behaviour recently, unfortunately. Yes, I did some digging and I think it has always been this way, even before git-checkout was a builtin. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG?] git checkout $commit -- somedir doesn't drop files
On Tue, Sep 17, 2013 at 01:27:08PM -0700, Junio C Hamano wrote: Jeff King p...@peff.net writes: On Tue, Sep 17, 2013 at 12:58:07PM -0700, Junio C Hamano wrote: I could argue that the above intended behaviour is suboptimal and it should have been the resulting paths in the index and the work tree that match the given pathspec must be identical to that of the tree-ish. In the resulting index or working tree, paths that match subdir pathspec in the above result is subdir/a and subdir/b, and that is different from what exists in the given tree-ish (which has only subdir/a and not subdir/b), and under that modified definition, what the current one does is not correct. Our emails just crossed, but I basically ended up saying a similar thing. Could we simply replace the update_some in builtin/checkout.c with a two-way merge via unpack-trees? Would it work to resolve a conflicted index by checking out from a known tree? Hrm. Probably not. It is almost a one-way merge going to the named tree (but limited by the pathspec), except that I think the current git-checkout code may provide some safety checks related to where we are coming from (e.g., do we unconditionally overwrite entries that are not uptodate?). -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 1/3] repack: rewrite the shell script in C
Stefan Beller stefanbel...@googlemail.com writes:
On 09/17/2013 08:17 PM, Junio C Hamano wrote:
Stefan Beller stefanbel...@googlemail.com writes:
+ struct option builtin_repack_options[] = {
+ OPT_BIT('a', NULL, pack_everything,
+ N_(pack everything in a single pack),
ALL_INTO_ONE),
+ OPT_BIT('A', NULL, pack_everything,
+ N_(same as -a, and turn unreachable objects
loose),
+ LOOSEN_UNREACHABLE),
Micronit.
With the current version of the code in cmd_repack() that uses the
pack_everything variable this may not make a difference, but I think
this should logically be LOOSEN_UNREACHABLE | ALL_INTO_ONE instead,
and the code should check (pack_evertying ALL_INTO_ONE) instead of
checking !pack_everything. You may want to add to this flag variable
a new bit that does _not_ cause it to pack everything into one.
I do understand the LOOSEN_UNREACHABLE | ALL_INTO_ONE here, as that
is the logical thing we are doing. Combined with your second idea this
would result in
---8---
From 4bbbfb312bf23efa7e702e200fbc2d4479e3477e Mon Sep 17 00:00:00 2001
From: Stefan Beller stefanbel...@googlemail.com
Date: Tue, 17 Sep 2013 22:04:35 +0200
Subject: [PATCH 2/2] Suggestions by Junio
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
builtin/repack.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/builtin/repack.c b/builtin/repack.c
index e5f90c6..a0ff5c7 100644
--- a/builtin/repack.c
+++ b/builtin/repack.c
@@ -143,7 +143,7 @@ int cmd_repack(int argc, const char **argv, const char
*prefix)
N_(pack everything in a single pack),
ALL_INTO_ONE),
OPT_BIT('A', NULL, pack_everything,
N_(same as -a, and turn unreachable objects
loose),
-LOOSEN_UNREACHABLE),
+LOOSEN_UNREACHABLE | ALL_INTO_ONE),
OPT_BOOL('d', NULL, delete_redundant,
N_(remove redundant packs, and run
git-prune-packed)),
OPT_BOOL('f', NULL, no_reuse_delta,
@@ -197,10 +197,7 @@ int cmd_repack(int argc, const char **argv, const char
*prefix)
if (no_reuse_object)
argv_array_pushf(cmd_args, --no-reuse-object);
- if (!pack_everything) {
- argv_array_push(cmd_args, --unpacked);
- argv_array_push(cmd_args, --incremental);
- } else {
+ if (pack_everything ALL_INTO_ONE) {
get_non_kept_pack_filenames(existing_packs);
if (existing_packs.nr delete_redundant) {
@@ -212,6 +209,9 @@ int cmd_repack(int argc, const char **argv, const char
*prefix)
argv_array_push(cmd_args,
--unpack-unreachable);
}
+ } else {
+ argv_array_push(cmd_args, --unpacked);
+ argv_array_push(cmd_args, --incremental);
}
if (local)
--
1.8.4.273.ga194ead
Yes.
Above was what I would have expected from a straight *.sh to *.c
conversion.
But I didn't think about the change in the patch below.
However I assume you mean to even ease up the conditions now, because now
both -a as well as -A set ALL_INTO_ONE we could apply the following
on top of the previous.
---8---
From 80199368ab6c7ab72f81a5c531f79073a99d2498 Mon Sep 17 00:00:00 2001
From: Stefan Beller stefanbel...@googlemail.com
Date: Tue, 17 Sep 2013 22:11:08 +0200
Subject: [PATCH] Further improvements by reducing nested ifs
This may pass --unpacked and --unpack-unreachable to pack-objects in one
command, which is redundant. On the other hand we may gain simplicity in
repack.
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
builtin/repack.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/builtin/repack.c b/builtin/repack.c
index a0ff5c7..3e56614 100644
--- a/builtin/repack.c
+++ b/builtin/repack.c
@@ -197,23 +197,23 @@ int cmd_repack(int argc, const char **argv, const char
*prefix)
if (no_reuse_object)
argv_array_pushf(cmd_args, --no-reuse-object);
- if (pack_everything ALL_INTO_ONE) {
+ if (pack_everything ALL_INTO_ONE)
get_non_kept_pack_filenames(existing_packs);
-
- if (existing_packs.nr delete_redundant) {
- if (unpack_unreachable)
- argv_array_pushf(cmd_args,
- --unpack-unreachable=%s,
- unpack_unreachable);
- else if (pack_everything LOOSEN_UNREACHABLE)
- argv_array_push(cmd_args,
- --unpack-unreachable);
- }
- } else
Re: [PATCH] diff: add a config option to control orderfile
On Tue, Sep 17, 2013 at 11:14:01PM +0300, Michael S. Tsirkin wrote: On Tue, Sep 17, 2013 at 11:06:07AM -0700, Junio C Hamano wrote: Michael S. Tsirkin m...@redhat.com writes: On Tue, Sep 17, 2013 at 10:24:19AM -0700, Junio C Hamano wrote: Michael S. Tsirkin m...@redhat.com writes: So might it not be useful to tweak patch id to sort the diff, making it a bit more stable? That is one thing that needs to be done, I think. But it would be unfortunate if we have to do that unconditionally, though, as we may be buffering many hundred kilobytes of patch text in core. If we can do so without regressing the streaming performance for the most common case of not using the orderfile on the generating side (hence not having to sort on the receiving end), it would be ideal. I am not sure offhand how much code damage we are talking about, though. So make it conditional on the presence of the orderefile option? That would mean that those who set orderfile from configuration in the future will have to always suffer, I would think. Is that acceptable? I dunno. Also, if the sender used a non-standard order, the recipient does not know what order the patch was generated, and the recipient does not use a custom orderfile, what should happen? I thought your idea was to normalize by using some canonical order that is not affected by the orderfile to make sure patch-id stays stable, so I would imagine that such a recipient who does not have orderfile specified still needs to sort before hashing, no? Thinking about it some more, it's a best effort thing anyway, correct? So how about, instead of doing a hash over the whole input, we hash each chunk and XOR them together? This way it will be stable against chunk reordering, and no need to keep patch in memory. Hmm? ENOCOFFEE That was a silly suggestion, two identical chunks aren't that unlikely :) -- MST -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] diff: add a config option to control orderfile
On Tue, Sep 17, 2013 at 04:18:28PM -0400, Jeff King wrote: On Tue, Sep 17, 2013 at 11:16:04PM +0300, Michael S. Tsirkin wrote: Thinking about it some more, it's a best effort thing anyway, correct? So how about, instead of doing a hash over the whole input, we hash each chunk and XOR them together? This way it will be stable against chunk reordering, and no need to keep patch in memory. Hmm? ENOCOFFEE That was a silly suggestion, two identical chunks aren't that unlikely :) In a single patch, they should not be, as we should be taking into account the filenames, no? Right. You could also do it hierarchically. Hash each chunk, store only the hashes, then sort them and hash the result. That still has O(chunks) storage, but it is only one hash per chunk, not the whole data. Could be optional too :) Or maybe just sum byte by byte instead. A problem with both schemes, though, is that they are not backwards-compatible with existing git-patch-id implementations. Could you clarify? We never send patch IDs on the wire - how isn't this compatible? Whereas sorting the data itself is (kind of, at least with respect to people who are not using orderfile). -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] diff: add a config option to control orderfile
On Wed, Sep 18, 2013 at 12:03:25AM +0300, Michael S. Tsirkin wrote: It may be esoteric enough not to worry about, though. By far the most common use of patch-ids is going to be in a single rev-list --cherry-pick situation where you are trying to omit commits during a rebase. I am mostly thinking of the problems we had with the kup tool, which expected stability across diffs that would be signed by both kernel.org. But as far as I know, they do not use patch-id. We can always do a compatibility option. --order-sensitive ? --ignore-order ? That may make sense as an escape hatch in case somebody has a use we didn't foresee. If it is just about consistent order versus whatever is in the diff, I do not know that we need to worry as much; only the minority using orderfile is affected, and they have _always_ been affected. IOW, we are fixing a bug, and they should be happier. But if it is changing the output entirely in all cases (e.g., the 1s-complement sum), I think you would want to have a classic mode that tries to be compatible with the old style (with the caveat that of course it depends on patch ordering). -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] diff: add a config option to control orderfile
On Tue, Sep 17, 2013 at 11:38:07PM +0300, Michael S. Tsirkin wrote:
A problem with both schemes, though, is that they are not
backwards-compatible with existing git-patch-id implementations.
Could you clarify?
We never send patch IDs on the wire - how isn't this compatible?
I meant that you might be comparing patch-ids generated by different
implementations, or across time. There are no dedicated tools to do so,
but it is very easy to do so with standard tools like join.
For example, you can do:
patch_ids() {
git rev-list $1 |
git diff-tree --stdin -p |
git patch-id |
sort
}
patch_ids origin..topic1 us
patch_ids origin..topic2 them
join us them | cut -d' ' -f2-3
to get a list of correlated commits between two branches. If the them
was on another machine with a different implementation (or is saved from
an earlier time), your patch-ids would not match.
It may be esoteric enough not to worry about, though. By far the most
common use of patch-ids is going to be in a single rev-list
--cherry-pick situation where you are trying to omit commits during
a rebase.
I am mostly thinking of the problems we had with the kup tool, which
expected stability across diffs that would be signed by both kernel.org.
But as far as I know, they do not use patch-id. More details in case you
are curious (including me arguing that we should not care, and it is
kup's problem!) are here:
http://thread.gmane.org/gmane.comp.version-control.git/192331/focus=192424
rerere is mentioned in that thread, but I believe that it does its own
hash, and does not rely on patch-id.
-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG?] git checkout $commit -- somedir doesn't drop files
Jeff King p...@peff.net writes: On Tue, Sep 17, 2013 at 01:27:08PM -0700, Junio C Hamano wrote: Jeff King p...@peff.net writes: On Tue, Sep 17, 2013 at 12:58:07PM -0700, Junio C Hamano wrote: I could argue that the above intended behaviour is suboptimal and it should have been the resulting paths in the index and the work tree that match the given pathspec must be identical to that of the tree-ish. In the resulting index or working tree, paths that match subdir pathspec in the above result is subdir/a and subdir/b, and that is different from what exists in the given tree-ish (which has only subdir/a and not subdir/b), and under that modified definition, what the current one does is not correct. Our emails just crossed, but I basically ended up saying a similar thing. Could we simply replace the update_some in builtin/checkout.c with a two-way merge via unpack-trees? Would it work to resolve a conflicted index by checking out from a known tree? Hrm. Probably not. It is almost a one-way merge going to the named tree (but limited by the pathspec), except that I think the current git-checkout code may provide some safety checks related to where we are coming from (e.g., do we unconditionally overwrite entries that are not uptodate?). I think we do unconditionally overwrite and that has been very much on purpose. git checkout tree-ish -- file.txt has always been about replacing whatever cruft is in paths in the worktree that match pathspec, just like cat content-created-elsewhere file.txt is. Oops, you have a local change that do not match index is the last thing we want to say, because getting rid of that local change is the primary reason why checkout tree-ish -- file.txt exists. Taking the state of a subdirectory as a whole as content, the change we are discussing will make it more like rm -fr dir tar xf some-content dir to replace the directory wholesale, which I personally think is a good thing in the longer term. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] diff: add a config option to control orderfile
On Tue, Sep 17, 2013 at 11:38:07PM +0300, Michael S. Tsirkin wrote: On Tue, Sep 17, 2013 at 04:18:28PM -0400, Jeff King wrote: On Tue, Sep 17, 2013 at 11:16:04PM +0300, Michael S. Tsirkin wrote: Thinking about it some more, it's a best effort thing anyway, correct? So how about, instead of doing a hash over the whole input, we hash each chunk and XOR them together? This way it will be stable against chunk reordering, and no need to keep patch in memory. Hmm? ENOCOFFEE That was a silly suggestion, two identical chunks aren't that unlikely :) In a single patch, they should not be, as we should be taking into account the filenames, no? Right. You could also do it hierarchically. Hash each chunk, store only the hashes, then sort them and hash the result. That still has O(chunks) storage, but it is only one hash per chunk, not the whole data. Could be optional too :) Or maybe just sum byte by byte instead. One's complement probably ... A problem with both schemes, though, is that they are not backwards-compatible with existing git-patch-id implementations. Could you clarify? We never send patch IDs on the wire - how isn't this compatible? Whereas sorting the data itself is (kind of, at least with respect to people who are not using orderfile). -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: RFC: git bisect should accept paths-to-be-excluded
Piotr Krukowiecki piotr.krukowie...@gmail.com writes: Ignoring (possible) inconsistency thing, I think they are easy to understand and use. Probably you are right (in the sense that I do not offhand think of a confusing and ambiguous set of positive and negative pathspecs; others may find holes in my/our thinking). I am not sure if it will fit well to the current struct pathspec design, though. We could start from when there is any negative pathspec, disable the 'optimize away the common leading prefix' thing, I guess. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] diff: add a config option to control orderfile
On Tue, Sep 17, 2013 at 04:56:16PM -0400, Jeff King wrote:
On Tue, Sep 17, 2013 at 11:38:07PM +0300, Michael S. Tsirkin wrote:
A problem with both schemes, though, is that they are not
backwards-compatible with existing git-patch-id implementations.
Could you clarify?
We never send patch IDs on the wire - how isn't this compatible?
I meant that you might be comparing patch-ids generated by different
implementations, or across time. There are no dedicated tools to do so,
but it is very easy to do so with standard tools like join.
For example, you can do:
patch_ids() {
git rev-list $1 |
git diff-tree --stdin -p |
git patch-id |
sort
}
patch_ids origin..topic1 us
patch_ids origin..topic2 them
join us them | cut -d' ' -f2-3
to get a list of correlated commits between two branches. If the them
was on another machine with a different implementation (or is saved from
an earlier time), your patch-ids would not match.
It may be esoteric enough not to worry about, though. By far the most
common use of patch-ids is going to be in a single rev-list
--cherry-pick situation where you are trying to omit commits during
a rebase.
I am mostly thinking of the problems we had with the kup tool, which
expected stability across diffs that would be signed by both kernel.org.
But as far as I know, they do not use patch-id.
We can always do a compatibility option. --order-sensitive ?
--ignore-order ?
More details in case you
are curious (including me arguing that we should not care, and it is
kup's problem!) are here:
http://thread.gmane.org/gmane.comp.version-control.git/192331/focus=192424
rerere is mentioned in that thread, but I believe that it does its own
hash, and does not rely on patch-id.
-Peff
I think so too.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG?] git checkout $commit -- somedir doesn't drop files
On Tue, Sep 17, 2013 at 01:40:17PM -0700, Junio C Hamano wrote: Hrm. Probably not. It is almost a one-way merge going to the named tree (but limited by the pathspec), except that I think the current git-checkout code may provide some safety checks related to where we are coming from (e.g., do we unconditionally overwrite entries that are not uptodate?). I think we do unconditionally overwrite and that has been very much on purpose. I thought so, too, but I was thrown off by the code in checkout_paths() that warns/aborts if there are unmerged entries. But it looks like we will have thrown out those entries already during the read_tree_some call, which adds the new entries using OK_TO_REPLACE. git checkout tree-ish -- file.txt has always been about replacing whatever cruft is in paths in the worktree that match pathspec, just like cat content-created-elsewhere file.txt is. Oops, you have a local change that do not match index is the last thing we want to say, because getting rid of that local change is the primary reason why checkout tree-ish -- file.txt exists. Taking the state of a subdirectory as a whole as content, the change we are discussing will make it more like rm -fr dir tar xf some-content dir to replace the directory wholesale, which I personally think is a good thing in the longer term. Yeah, that makes sense. What about untracked files? Right now we overwrite them if the tree-ish has an entry at the same path; that is a bit more dangerous than the rest of git, but does match the ignore local modifications rule. I assume if we handled deletions, though, that we would simply leave them be. So given that, is it fair to say that a one-way go here merge, limited by pathspec, is the closest equivalent? -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: Locking files / git
On Tue, Sep 17, 2013 at 09:45:26PM +0200, Nicolas Adenis-Lamarre wrote: Ooops. It seems that each time somebody says these two words together, people hate him, and he is scorned by friends and family. And strangers on mailing lists. :) However, - gitolite implement it (but gitolite is not git). Yes, and I think that distinction is important. Locking is fundamentally about having a centralized server. Even if you have some decentralization (e.g., let's imagine two divisions of a company that work as peers), the whole point of the lock is that multiple people are communicating with the same lock server (so in that same example, from the perspective of people in those divisions, there is a central server for each division, and that would be the lock server). Git itself does not know know or care about your workflow, and whether the remote you are pushing to is central or not. Having a lock server would be unlike the rest of git. Whereas gitolite, since it is about managing access to a centralized repository, is a good place to handle locking. In other words, I do not think locking is inherently bad. It is only that it is useful for a subset of workflows that git provides. So I don't think that git is the right place to implement it; rather it should be built on top, either standalone or as part of other tools that already assume some centralization. I want to explain how I could implement it. [...] That all sounds like a reasonable workflow, but I think you could just as easily implement it on top of git. In particular, the protocol does not have any room to communicate this data. So you are already going out-of-band over ssh, or something similar. The only support you need from git is to auto-unlock the files after a push. And I think you could do that using a post-receive hook. And indeed, you would not want git itself to do it anyway, because the rules for when to unlock are going to depend on your workflow (e.g., which branches a commit must hit to trigger an unlock). -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: Locking files / git
On Tue, Sep 17, 2013 at 09:45:26PM +0200, Nicolas Adenis-Lamarre wrote: Ooops. It seems that each time somebody says these two words together, people hate him, and he is scorned by friends and family. For the moment, i want a first feedback, an intermediate between locking is bad and ok, but i would prefer in the negativ answer something with arguments (Take CVS as an example of what not to do; if in doubt, make the exact opposite decision. is one), and in the positiv answer, good remarks about problems with my implementation that could make it better. So working with locks and text-files is generally stupid to do with git since you don't use git merging capabilities. Working with binary files in git is stupid because git doesn't handle them very well because they the deltas can't be calculated very good. It seems to me that if you need to do locking one of the above scenarios is true for you and you should not use git at all. However, there's always the case when you've a mixed project with both binary and text-files. In that case I believe Jeff gave an excellent answer. But think twice, are you using git in a sane way? Even a small binary file will result in a huge git repo if it's updated often and the project has a long history. -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-compat-util: Avoid strcasecmp() being inlined
Sebastian Schuberth sschube...@gmail.com writes: On Tue, Sep 17, 2013 at 6:17 PM, Junio C Hamano gits...@pobox.com wrote: Keeping the ugliness to deal with the platform issue (i.e. broken string.h) in one place (e.g. compat/mingw) is far more preferrable than having a similar ugliness in git-compat-util.h for people on all other platforms to see, no? I don't think people on other platforms seeing the ugliness is really an issue. After all, the file is called git-*compat*-util.h; Well, judging from the way Linus reacted to the patch, I'd have to disagree. After all, that argument leads to the position that nothing is needed in compat/, no? Also, your solution does not really keep the ugliness in one place,... One ugliness (lack of sane strcasecmp definition whose address can be taken) specific to mingw is worked around in compat/mingw.h, and another ugliness that some people may use compilers without include_next may need help from another configuration in the Makefile to tell it where the platform string.h resides. I am not sure why you see it as a problem. I do insist to avoid GCC-ism in C files,... To that I tend to agree. Unconditionally killing inlining for any mingw compilation in compat/mingw.h may be the simplest (albeit it may be less than optimal) solution. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG?] git checkout $commit -- somedir doesn't drop files
Jeff King p...@peff.net writes: On Tue, Sep 17, 2013 at 03:00:41PM -0700, Junio C Hamano wrote: So given that, is it fair to say that a one-way go here merge, limited by pathspec, is the closest equivalent? Sorry, but it is unclear to me what you mean by one-way go here merge. Do you mean oneway_merge() in unpack-trees.c? Yes, that is what I meant. Yeah, then I agree that git checkout HEAD^ -- subdir should be a one-way go HEAD^ merge limited only to the paths that match subdir/. If implemented in a straight-forward way, I suspect that we may end up not removing subdir/b in Uwe's sample transcript. I am not sure if that is a good thing or not, though. If the index originally tracked and then going to tree does not, I think removing it would match ignore local modifications rule, as subdir/a that is tracked in the index and also in going to tree does get overwritten to match the state recorded in the tree. -- 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[2]: Issue with sparse checkout
Hi Duy, Thanks for taking a look. So it does feel like a bug to me: why are files with ^S set remaining in the working version after git read-tree -mu HEAD ? I don't know. Maybe the bits are set, but then the remove operation fails (silently). I tried to reproduce on Linux without success. I also tried to make a small repo to reproduce and failed. I will try to strip and send ... might take a little while to get to the point where it still happens but there's no work related stuff in there Thanks again, Martin -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] diff: add a config option to control orderfile
Jeff King p...@peff.net writes: I am mostly thinking of the problems we had with the kup tool, which expected stability across diffs that would be signed by both kernel.org. But as far as I know, they do not use patch-id. More details in case you are curious (including me arguing that we should not care, and it is kup's problem!) are here: http://thread.gmane.org/gmane.comp.version-control.git/192331/focus=192424 rerere is mentioned in that thread, but I believe that it does its own hash, and does not rely on patch-id. It does not. The reason rerere is relevant in that thread but is not directly relevant here is because the thread is about changing the diff algorithm, hence changing the common-sequence matches between preimage and postimage, resulting in a different shape of the conflicted section. The hash rerere does still depends on the patch text, but it is restricted to the conflicted region, so whatever we do in patch-id will not affect it. Also the rerere database is not keyed by pathname (a conflict in _any_ file as long as they have the same ours/theirs conflicted text is recognised as the same conflict we have already seen), so changing the orderfile would not affect it at all. -- 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[2]: sparse checkout file with windows line endings doesn't work
Hi Duy, Thanks again for taking a look at these two reports. And it does work for me with CRLF endings (again tested on Linux). Yes, will do. I will try, myself, on Linux, as well. It seems quite conceivable its the sort of thing that only happens under Windows. Regards, Martin -- 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 6/6] clone: test the new HEAD detection logic
Signed-off-by: Junio C Hamano gits...@pobox.com --- t/t5601-clone.sh | 11 +++ 1 file changed, 11 insertions(+) diff --git a/t/t5601-clone.sh b/t/t5601-clone.sh index 0629149..ccda6df 100755 --- a/t/t5601-clone.sh +++ b/t/t5601-clone.sh @@ -285,4 +285,15 @@ test_expect_success NOT_MINGW,NOT_CYGWIN 'clone local path foo:bar' ' git clone ./foo:bar foobar ' +test_expect_success 'clone from a repository with two identical branches' ' + + ( + cd src + git checkout -b another master + ) + git clone src target-11 + test z$( cd target-11 git symbolic-ref HEAD ) = zrefs/heads/another + +' + test_done -- 1.8.4-585-g8d1dcaf -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/6] Removing the guesswork of HEAD in clone
This reworks the old idea from 2008 ($gmane/102039) to teach upload-pack to say where symbolic refs are pointing at in the initial ref advertisement as a new capability sym, and allow git clone to take advantage of that knowledge when deciding what branch to point at with the HEAD of the newly created repository. Thanks go to Andreas Krey for reigniting the ember in a patch series a few weeks ago. I did not do anything more than just compile it once; all the bugs in this round are mine (it is all new code after all). Junio C Hamano (6): upload-pack.c: do not pass confusing cb_data to mark_our_ref() upload-pack: send symbolic ref information as capability upload-pack: send non-HEAD symbolic refs connect.c: make parse_feature_value() static connect: annotate refs with their symref information in get_remote_head() clone: test the new HEAD detection logic cache.h | 1 - connect.c| 63 +++- t/t5601-clone.sh | 11 ++ upload-pack.c| 51 +++-- 4 files changed, 118 insertions(+), 8 deletions(-) -- 1.8.4-585-g8d1dcaf -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/6] upload-pack: send symbolic ref information as capability
One long-standing flaw in the pack transfer protocol was that there
was no way to tell the other end which branch HEAD points at.
With a new sym capability (e.g. sym=HEAD:refs/heads/master; can
be repeated more than once to represent symbolic refs other than
HEAD, such as refs/remotes/origin/HEAD).
Add an infrastructure to collect symbolic refs, format them as extra
capabilities and put it on the wire. For now, just send information
on the HEAD and nothing else.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
upload-pack.c | 48 +++-
1 file changed, 43 insertions(+), 5 deletions(-)
diff --git a/upload-pack.c b/upload-pack.c
index a6e107f..53958b9 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -734,6 +734,16 @@ static int mark_our_ref(const char *refname, const
unsigned char *sha1, int flag
return 0;
}
+static void format_symref_info(struct strbuf *buf, struct string_list *symref)
+{
+ struct string_list_item *item;
+
+ if (!symref-nr)
+ return;
+ for_each_string_list_item(item, symref)
+ strbuf_addf(buf, sym=%s:%s, item-string, (char
*)item-util);
+}
+
static int send_ref(const char *refname, const unsigned char *sha1, int flag,
void *cb_data)
{
static const char *capabilities = multi_ack thin-pack side-band
@@ -745,32 +755,60 @@ static int send_ref(const char *refname, const unsigned
char *sha1, int flag, vo
if (mark_our_ref(refname, sha1, flag, NULL))
return 0;
- if (capabilities)
- packet_write(1, %s %s%c%s%s%s agent=%s\n,
+ if (capabilities) {
+ struct strbuf symref_info = STRBUF_INIT;
+
+ format_symref_info(symref_info, cb_data);
+ packet_write(1, %s %s%c%s%s%s%s agent=%s\n,
sha1_to_hex(sha1), refname_nons,
0, capabilities,
allow_tip_sha1_in_want ? allow-tip-sha1-in-want
: ,
stateless_rpc ? no-done : ,
+symref_info.buf,
git_user_agent_sanitized());
- else
+ strbuf_release(symref_info);
+ } else {
packet_write(1, %s %s\n, sha1_to_hex(sha1), refname_nons);
+ }
capabilities = NULL;
if (!peel_ref(refname, peeled))
packet_write(1, %s %s^{}\n, sha1_to_hex(peeled),
refname_nons);
return 0;
}
+static int find_symref(const char *refname, const unsigned char *sha1, int
flag,
+ void *cb_data)
+{
+ const char *symref_target;
+ struct string_list_item *item;
+ unsigned char unused[20];
+
+ if ((flag REF_ISSYMREF) == 0)
+ return 0;
+ symref_target = resolve_ref_unsafe(refname, unused, 0, flag);
+ if (!symref_target || (flag REF_ISSYMREF) == 0)
+ die('%s' is a symref but it is not?, refname);
+ item = string_list_append(cb_data, refname);
+ item-util = xstrdup(symref_target);
+ return 0;
+}
+
static void upload_pack(void)
{
+ struct string_list symref = STRING_LIST_INIT_DUP;
+
+ head_ref_namespaced(find_symref, symref);
+
if (advertise_refs || !stateless_rpc) {
reset_timeout();
- head_ref_namespaced(send_ref, NULL);
+ head_ref_namespaced(send_ref, symref);
for_each_namespaced_ref(send_ref, NULL);
packet_flush(1);
} else {
- head_ref_namespaced(mark_our_ref, NULL);
+ head_ref_namespaced(mark_our_ref, symref);
for_each_namespaced_ref(mark_our_ref, NULL);
}
+ string_list_clear(symref, 1);
if (advertise_refs)
return;
--
1.8.4-585-g8d1dcaf
--
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/6] upload-pack: send non-HEAD symbolic refs
With the same mechanism as used to tell where HEAD points at to
the other end, we can tell the target of other symbolic refs as
well.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
upload-pack.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/upload-pack.c b/upload-pack.c
index 53958b9..7ca6154 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -798,6 +798,7 @@ static void upload_pack(void)
struct string_list symref = STRING_LIST_INIT_DUP;
head_ref_namespaced(find_symref, symref);
+ for_each_namespaced_ref(find_symref, symref);
if (advertise_refs || !stateless_rpc) {
reset_timeout();
--
1.8.4-585-g8d1dcaf
--
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] contacts: fix to work in subdirectories
Unlike other git commands which work correctly at the top-level or in a
subdirectory, git-contacts fails when invoked in a subdirectory. This is
because it invokes git-blame with pathnames relative to the top-level,
but git-blame interprets the pathnames as relative to the current
directory. Fix this.
Signed-off-by: Eric Sunshine sunsh...@sunshineco.com
---
git-contacts (in Perl) was born from Felipe's git-related v9 [1]
Ruby script. That version did not handle invocation from within
subdirectories, however, an earlier version (v5) of his script [2] did,
and it was my intention all along to add such support, but I forgot
after being sidetracked adding the git-check-mailmap command and
git-blame multiple -L support (plus several bug fixes in existing -L
support).
Thanks to Thomas Gummerer for reminding me about this in the form of a
patch [3]. The current patch is intended to be a bit more efficient than
Thomas'.
[1]: http://thread.gmane.org/gmane.comp.version-control.git/226065
[2]: http://article.gmane.org/gmane.comp.version-control.git/224783
[3]: http://thread.gmane.org/gmane.comp.version-control.git/234877
contrib/contacts/git-contacts | 4
1 file changed, 4 insertions(+)
diff --git a/contrib/contacts/git-contacts b/contrib/contacts/git-contacts
index fb6429b..428cc1a 100755
--- a/contrib/contacts/git-contacts
+++ b/contrib/contacts/git-contacts
@@ -181,6 +181,10 @@ if (@rev_args) {
scan_rev_args(\%sources, \@rev_args)
}
+my $toplevel = `git rev-parse --show-toplevel`;
+chomp $toplevel;
+chdir($toplevel) or die chdir failure: $toplevel: $!\n;
+
my %commits;
blame_sources(\%sources, \%commits);
import_commits(\%commits);
--
1.8.4.535.g7b94f8e
--
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 4/7] upload-pack: send non-HEAD symbolic refs
With the same mechanism as used to tell where HEAD points at to
the other end, we can tell the target of other symbolic refs as
well.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
upload-pack.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/upload-pack.c b/upload-pack.c
index 979fc8e..2826909 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -798,6 +798,7 @@ static void upload_pack(void)
struct string_list symref = STRING_LIST_INIT_DUP;
head_ref_namespaced(find_symref, symref);
+ for_each_namespaced_ref(find_symref, symref);
if (advertise_refs || !stateless_rpc) {
reset_timeout();
--
1.8.4-585-g8d1dcaf
--
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 7/7] clone: test the new HEAD detection logic
Signed-off-by: Junio C Hamano gits...@pobox.com --- t/t5601-clone.sh | 11 +++ 1 file changed, 11 insertions(+) diff --git a/t/t5601-clone.sh b/t/t5601-clone.sh index 0629149..ccda6df 100755 --- a/t/t5601-clone.sh +++ b/t/t5601-clone.sh @@ -285,4 +285,15 @@ test_expect_success NOT_MINGW,NOT_CYGWIN 'clone local path foo:bar' ' git clone ./foo:bar foobar ' +test_expect_success 'clone from a repository with two identical branches' ' + + ( + cd src + git checkout -b another master + ) + git clone src target-11 + test z$( cd target-11 git symbolic-ref HEAD ) = zrefs/heads/another + +' + test_done -- 1.8.4-585-g8d1dcaf -- 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/7] Removing the guesswork of HEAD in clone
This reworks the old idea from 2008 ($gmane/102039) to teach upload-pack to say where symbolic refs are pointing at in the initial ref advertisement as a new capability symref, and allows git clone to take advantage of that knowledge when deciding what branch to point at with the HEAD of the newly created repository. Credits for re-igniting the ember with an earlier patch series goes to Andreas Krey. * The test-fix in [PATCH 1/7] is new this round. * The main patch to upload-pack.c [PATCH 3/7] has the fix I earlier sent. The capability was called sym in the previous one, but it spells out symref in this round. * The patch on the receiving end [PATCH 6/7] now comes with an update to a test that was fixed in [PATCH 1/7]. This round seems to pass all the test, and the code is fairly straight-forward, so it may be ready for at least 'pu' if not 'next'. The series is to be applied on top of v1.8.4; between there and the 'master', there is some code reorganization to create connect.h out of cache.h which may cause patch conflict, but it should be trivial to fix when merging it up (queued as an evil merge near the tip of the 'pu' branch). Junio C Hamano (7): t5505: fix set-head --auto with ambiguous HEAD test upload-pack.c: do not pass confusing cb_data to mark_our_ref() upload-pack: send symbolic ref information as capability upload-pack: send non-HEAD symbolic refs connect.c: make parse_feature_value() static connect: annotate refs with their symref information in get_remote_head() clone: test the new HEAD detection logic cache.h | 1 - connect.c | 63 ++- t/t5505-remote.sh | 16 +- t/t5601-clone.sh | 11 ++ upload-pack.c | 51 ++-- 5 files changed, 123 insertions(+), 19 deletions(-) -- 1.8.4-585-g8d1dcaf -- 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 6/7] connect: annotate refs with their symref information in get_remote_head()
By doing this, clients of upload-pack can now reliably tell what ref
a symbolic ref points at; the updated test in t5505 used to expect
failure due to the ambiguity and made sure we give diagnostics, but
we no longer need to be so pessimistic. Make sure we correctly learn
which branch HEAD points at from the other side instead.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
connect.c | 60 +++
t/t5505-remote.sh | 15 --
2 files changed, 64 insertions(+), 11 deletions(-)
diff --git a/connect.c b/connect.c
index e4c7ae6..553a80c 100644
--- a/connect.c
+++ b/connect.c
@@ -6,6 +6,7 @@
#include run-command.h
#include remote.h
#include url.h
+#include string-list.h
static char *server_capabilities;
static const char *parse_feature_value(const char *, const char *, int *);
@@ -60,6 +61,61 @@ static void die_initial_contact(int got_at_least_one_head)
and the repository exists.);
}
+static void parse_one_symref_info(struct string_list *symref, const char *val,
int len)
+{
+ char *sym, *target;
+ struct string_list_item *item;
+
+ if (!len)
+ return; /* just symref */
+ /* e.g. symref=HEAD:refs/heads/master */
+ sym = xmalloc(len + 1);
+ memcpy(sym, val, len);
+ sym[len] = '\0';
+ target = strchr(sym, ':');
+ if (!target)
+ /* just symref=something */
+ goto reject;
+ *(target++) = '\0';
+ if (check_refname_format(sym, REFNAME_ALLOW_ONELEVEL) ||
+ check_refname_format(target, REFNAME_ALLOW_ONELEVEL))
+ /* symref=bogus:pair */
+ goto reject;
+ item = string_list_append(symref, sym);
+ item-util = target;
+ return;
+reject:
+ free(sym);
+ return;
+}
+
+static void annotate_refs_with_symref_info(struct ref *ref)
+{
+ struct string_list symref = STRING_LIST_INIT_DUP;
+ const char *feature_list = server_capabilities;
+
+ while (feature_list) {
+ int len;
+ const char *val;
+
+ val = parse_feature_value(feature_list, symref, len);
+ if (!val)
+ break;
+ parse_one_symref_info(symref, val, len);
+ feature_list = val + 1;
+ }
+ sort_string_list(symref);
+
+ for (; ref; ref = ref-next) {
+ struct string_list_item *item;
+ item = string_list_lookup(symref, ref-name);
+ if (!item)
+ continue;
+ ref-symref = xstrdup((char *)item-util);
+ }
+ string_list_clear(symref, 0);
+}
+
/*
* Read all the refs from the other end
*/
@@ -67,6 +123,7 @@ struct ref **get_remote_heads(int in, char *src_buf, size_t
src_len,
struct ref **list, unsigned int flags,
struct extra_have_objects *extra_have)
{
+ struct ref **orig_list = list;
int got_at_least_one_head = 0;
*list = NULL;
@@ -114,6 +171,9 @@ struct ref **get_remote_heads(int in, char *src_buf, size_t
src_len,
list = ref-next;
got_at_least_one_head = 1;
}
+
+ annotate_refs_with_symref_info(*orig_list);
+
return list;
}
diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh
index 197d3f7..ac79dd9 100755
--- a/t/t5505-remote.sh
+++ b/t/t5505-remote.sh
@@ -160,9 +160,7 @@ cat test/expect EOF
* remote two
Fetch URL: ../two
Push URL: ../three
- HEAD branch (remote HEAD is ambiguous, may be one of the following):
-another
-master
+ HEAD branch: master
Local refs configured for 'git push':
ahead forces to master (fast-forwardable)
master pushes to another (up to date)
@@ -262,17 +260,12 @@ test_expect_success 'set-head --auto' '
)
'
-cat test/expect \EOF
-error: Multiple remote HEAD branches. Please choose one explicitly with:
- git remote set-head two another
- git remote set-head two master
-EOF
-
-test_expect_success 'set-head --auto fails w/multiple HEADs' '
+test_expect_success 'set-head --auto has no problem w/multiple HEADs' '
(
cd test
git fetch two refs/heads/*:refs/remotes/two/*
- test_must_fail git remote set-head --auto two output 21
+ git remote set-head --auto two output 21
+ echo two/HEAD set to master expect
test_i18ncmp expect output
)
'
--
1.8.4-585-g8d1dcaf
--
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/7] upload-pack: send symbolic ref information as capability
One long-standing flaw in the pack transfer protocol was that there
was no way to tell the other end which branch HEAD points at.
With a capability symref=HEAD:refs/heads/master, let the sender to
tell the receiver what symbolic ref points at what ref.
This capability can be repeated more than once to represent symbolic
refs other than HEAD, such as refs/remotes/origin/HEAD).
Add an infrastructure to collect symbolic refs, format them as extra
capabilities and put it on the wire. For now, just send information
on the HEAD and nothing else.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
upload-pack.c | 48 +++-
1 file changed, 43 insertions(+), 5 deletions(-)
diff --git a/upload-pack.c b/upload-pack.c
index a6e107f..979fc8e 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -734,6 +734,16 @@ static int mark_our_ref(const char *refname, const
unsigned char *sha1, int flag
return 0;
}
+static void format_symref_info(struct strbuf *buf, struct string_list *symref)
+{
+ struct string_list_item *item;
+
+ if (!symref-nr)
+ return;
+ for_each_string_list_item(item, symref)
+ strbuf_addf(buf, symref=%s:%s, item-string, (char
*)item-util);
+}
+
static int send_ref(const char *refname, const unsigned char *sha1, int flag,
void *cb_data)
{
static const char *capabilities = multi_ack thin-pack side-band
@@ -745,32 +755,60 @@ static int send_ref(const char *refname, const unsigned
char *sha1, int flag, vo
if (mark_our_ref(refname, sha1, flag, NULL))
return 0;
- if (capabilities)
- packet_write(1, %s %s%c%s%s%s agent=%s\n,
+ if (capabilities) {
+ struct strbuf symref_info = STRBUF_INIT;
+
+ format_symref_info(symref_info, cb_data);
+ packet_write(1, %s %s%c%s%s%s%s agent=%s\n,
sha1_to_hex(sha1), refname_nons,
0, capabilities,
allow_tip_sha1_in_want ? allow-tip-sha1-in-want
: ,
stateless_rpc ? no-done : ,
+symref_info.buf,
git_user_agent_sanitized());
- else
+ strbuf_release(symref_info);
+ } else {
packet_write(1, %s %s\n, sha1_to_hex(sha1), refname_nons);
+ }
capabilities = NULL;
if (!peel_ref(refname, peeled))
packet_write(1, %s %s^{}\n, sha1_to_hex(peeled),
refname_nons);
return 0;
}
+static int find_symref(const char *refname, const unsigned char *sha1, int
flag,
+ void *cb_data)
+{
+ const char *symref_target;
+ struct string_list_item *item;
+ unsigned char unused[20];
+
+ if ((flag REF_ISSYMREF) == 0)
+ return 0;
+ symref_target = resolve_ref_unsafe(refname, unused, 0, flag);
+ if (!symref_target || (flag REF_ISSYMREF) == 0)
+ die('%s' is a symref but it is not?, refname);
+ item = string_list_append(cb_data, refname);
+ item-util = xstrdup(symref_target);
+ return 0;
+}
+
static void upload_pack(void)
{
+ struct string_list symref = STRING_LIST_INIT_DUP;
+
+ head_ref_namespaced(find_symref, symref);
+
if (advertise_refs || !stateless_rpc) {
reset_timeout();
- head_ref_namespaced(send_ref, NULL);
- for_each_namespaced_ref(send_ref, NULL);
+ head_ref_namespaced(send_ref, symref);
+ for_each_namespaced_ref(send_ref, symref);
packet_flush(1);
} else {
head_ref_namespaced(mark_our_ref, NULL);
for_each_namespaced_ref(mark_our_ref, NULL);
}
+ string_list_clear(symref, 1);
if (advertise_refs)
return;
--
1.8.4-585-g8d1dcaf
--
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/7] upload-pack.c: do not pass confusing cb_data to mark_our_ref()
The callee does not use cb_data, and the caller is an intermediate function in a callchain that later wants to use the cb_data for its own use. Clarify the code by breaking the dataflow explicitly by not passing cb_data down to mark_our_ref(). Signed-off-by: Junio C Hamano gits...@pobox.com --- upload-pack.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/upload-pack.c b/upload-pack.c index 127e59a..a6e107f 100644 --- a/upload-pack.c +++ b/upload-pack.c @@ -742,7 +742,7 @@ static int send_ref(const char *refname, const unsigned char *sha1, int flag, vo const char *refname_nons = strip_namespace(refname); unsigned char peeled[20]; - if (mark_our_ref(refname, sha1, flag, cb_data)) + if (mark_our_ref(refname, sha1, flag, NULL)) return 0; if (capabilities) -- 1.8.4-585-g8d1dcaf -- 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/7] t5505: fix set-head --auto with ambiguous HEAD test
When two or more branches point at the same commit and HEAD is pointing at one of them, without the symref extension, there is no way to remotely tell which one of these branches HEAD points at. The test in question attempts to make sure that this situation is diagnosed and results in a failure. However, even if there _were_ a way to reliably tell which branch the HEAD points at, set-head --auto would fail if there is no remote tracking branch. Make sure that this test does not fail for that wrong reason. Signed-off-by: Junio C Hamano gits...@pobox.com --- * New in this round. t/t5505-remote.sh | 1 + 1 file changed, 1 insertion(+) diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh index 8f6e392..197d3f7 100755 --- a/t/t5505-remote.sh +++ b/t/t5505-remote.sh @@ -271,6 +271,7 @@ EOF test_expect_success 'set-head --auto fails w/multiple HEADs' ' ( cd test + git fetch two refs/heads/*:refs/remotes/two/* test_must_fail git remote set-head --auto two output 21 test_i18ncmp expect output ) -- 1.8.4-585-g8d1dcaf -- 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 5/7] connect.c: make parse_feature_value() static
Signed-off-by: Junio C Hamano gits...@pobox.com
---
cache.h | 1 -
connect.c | 3 ++-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/cache.h b/cache.h
index 85b544f..2c853ba 100644
--- a/cache.h
+++ b/cache.h
@@ -1098,7 +1098,6 @@ extern struct ref **get_remote_heads(int in, char
*src_buf, size_t src_len,
extern int server_supports(const char *feature);
extern int parse_feature_request(const char *features, const char *feature);
extern const char *server_feature_value(const char *feature, int *len_ret);
-extern const char *parse_feature_value(const char *feature_list, const char
*feature, int *len_ret);
extern struct packed_git *parse_pack_index(unsigned char *sha1, const char
*idx_path);
diff --git a/connect.c b/connect.c
index a0783d4..e4c7ae6 100644
--- a/connect.c
+++ b/connect.c
@@ -8,6 +8,7 @@
#include url.h
static char *server_capabilities;
+static const char *parse_feature_value(const char *, const char *, int *);
static int check_ref(const char *name, int len, unsigned int flags)
{
@@ -116,7 +117,7 @@ struct ref **get_remote_heads(int in, char *src_buf, size_t
src_len,
return list;
}
-const char *parse_feature_value(const char *feature_list, const char *feature,
int *lenp)
+static const char *parse_feature_value(const char *feature_list, const char
*feature, int *lenp)
{
int len;
--
1.8.4-585-g8d1dcaf
--
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
