Re: [PATCH v2] rev-list docs: clarify --topo-order description
On Wed, Aug 15, 2012 at 1:02 PM, Junio C Hamano gits...@pobox.com wrote: diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt index 6a4b635..9404d08 100644 --- a/Documentation/rev-list-options.txt +++ b/Documentation/rev-list-options.txt @@ -578,16 +578,33 @@ Commit Ordering By default, the commits are shown in reverse chronological order. As I said before, this led me to believe that the commits are shown in reverse chronological order when neither of --topo-order or --date-order is passed. I agree that we should avoid specifying more than necessary about the default case. But in this case, what is specified is not exactly true (in the face of clock skew). Or am I misunderstanding or misinterpreting something? I still don't understand the revision walker well enough to be able to provide a better wording, but I think even the rather crude By default, the order is unspecified. would at least not be as easy to misinterpret (if that's what I did) and is definitely not over-specified. Of course, if someone can think of something better, I'm all for it. Regardless of the above comment about the patch context, what your patch actually changes looks good. Thanks again. -- 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] rev-list docs: clarify --topo-order description
Martin von Zweigbergk martin.von.zweigbe...@gmail.com writes: On Wed, Aug 15, 2012 at 1:02 PM, Junio C Hamano gits...@pobox.com wrote: diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt index 6a4b635..9404d08 100644 --- a/Documentation/rev-list-options.txt +++ b/Documentation/rev-list-options.txt @@ -578,16 +578,33 @@ Commit Ordering By default, the commits are shown in reverse chronological order. As I said before, this led me to believe that the commits are shown in reverse chronological order when neither of --topo-order or --date-order is passed. I agree that we should avoid specifying more than necessary about the default case. But in this case, what is specified is not exactly true (in the face of clock skew). Or am I misunderstanding or misinterpreting something? I still don't understand the revision walker well enough to be able to provide a better wording, but I think even the rather crude By default, the order is unspecified. would at least not be as easy to misinterpret (if that's what I did) and is definitely not over-specified. Of course, if someone can think of something better, I'm all for it. Regardless of the above comment about the patch context, what your patch actually changes looks good. Thanks again. We could remove it if you find it confusing. I think the original motivation that line was added was to help people who see git log (without any frills) output for the first time not to be alarmed when they see newer things first: In general, the time flows from bottom to top, but the time in that sentence is not necessarily the timestamp of either committer nor author field. -- 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] rev-list docs: clarify --topo-order description
Junio C Hamano gits...@pobox.com writes: We could remove it if you find it confusing. I think the original motivation that line was added was to help people who see git log (without any frills) output for the first time not to be alarmed when they see newer things first: In general, the time flows from bottom to top, but the time in that sentence is not necessarily the timestamp of either committer nor author field. Just to clarify, I am not defending the current wording that I did not touch in my patch with the above. I am just giving historical background to help _other_ people (including you) to come up with a better wording, as I do not think of a better replacement myself. -- 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
Is there a way to find out which commit git rebase --skip skipped?
If I do git rebase --skip, is there a way to find out the commit SHA that was skipped (other than just parsing the output of the command) ? I'd like to modify git-p4 so that it can automatically skip past conflicting changes, but I'd like it to keep a log of which commits were skipped. Thanks, Luke -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] rev-list docs: clarify --topo-order description
Junio C Hamano gits...@pobox.com writes:
Junio C Hamano gits...@pobox.com writes:
We could remove it if you find it confusing.
I think the original motivation that line was added was to help
people who see git log (without any frills) output for the first
time not to be alarmed when they see newer things first: In
general, the time flows from bottom to top, but the time in
that sentence is not necessarily the timestamp of either committer
nor author field.
Just to clarify, I am not defending the current wording that I did
not touch in my patch with the above. I am just giving historical
background to help _other_ people (including you) to come up with a
better wording, as I do not think of a better replacement myself.
I tend to agree with Martin, the existing header for the list
By default, the commits are shown in reverse chronological order.
is misleading. I suppose the real problem is that the true ordering
is completely obvious as the one ordering that does not require
preprocessing, but ugly to specify in words. Perhaps we can bikeshed a
little? How about
By default, commits are shown in an order that coincides with
`--date-order` on well-behaved history, but is faster to compute.
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] man: git pull -r is a short for --rebase
--- Documentation/git-pull.txt |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt index defb544..67fa5ee 100644 --- a/Documentation/git-pull.txt +++ b/Documentation/git-pull.txt @@ -101,6 +101,7 @@ include::merge-options.txt[] :git-pull: 1 +-r:: --rebase:: Rebase the current branch on top of the upstream branch after fetching. If there is a remote-tracking branch corresponding to -- 1.7.7 -- 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/RFC v4 02/13] read-cache.c: Re-read index if index file changed
Add the possibility of re-reading the index file, if it changed
while reading.
The index file might change during the read, causing outdated
information to be displayed. We check if the index file changed
by using its stat data as heuristic.
Signed-off-by: Thomas Gummerer t.gumme...@gmail.com
---
read-cache.c | 87 +---
1 file changed, 60 insertions(+), 27 deletions(-)
diff --git a/read-cache.c b/read-cache.c
index 6a8b4b1..cdd8480 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -1170,11 +1170,34 @@ int read_index(struct index_state *istate)
return read_index_from(istate, get_index_file());
}
+static int index_changed(struct stat st_old, struct stat st_new)
+{
+ int changed = 0;
+
+ if (st_old.st_mtime != st_new.st_mtime ||
+ st_old.st_uid != st_new.st_uid ||
+ st_old.st_gid != st_new.st_gid ||
+ st_old.st_ino != st_new.st_ino ||
+ st_old.st_size != st_new.st_size)
+ changed = 1;
+#ifdef USE_NSEC
+ if (ST_MTIME_NSEC(st_old) != ST_MTIME_NSEC(st_new))
+ changed = 1;
+#endif
+
+#ifdef USE_STDEV
+ if (st_old.st_dev != st_new.st_dev)
+ changed = 1;
+#endif
+
+ return changed;
+}
+
/* remember to discard_cache() before reading a different cache! */
int read_index_from(struct index_state *istate, const char *path)
{
- int fd;
- struct stat st;
+ int fd, err, i = 0;
+ struct stat st_old, st_new;
struct cache_version_header *hdr;
void *mmap;
size_t mmap_size;
@@ -1186,38 +1209,48 @@ int read_index_from(struct index_state *istate, const
char *path)
errno = ENOENT;
istate-timestamp.sec = 0;
istate-timestamp.nsec = 0;
- fd = open(path, O_RDONLY);
- if (fd 0) {
- if (errno == ENOENT)
- return 0;
- die_errno(index file open failed);
- }
+ do {
+ err = 0;
+ fd = open(path, O_RDONLY);
+ if (fd 0) {
+ if (errno == ENOENT)
+ return 0;
+ die_errno(index file open failed);
+ }
- if (fstat(fd, st))
- die_errno(cannot stat the open index);
+ if (fstat(fd, st_old))
+ die_errno(cannot stat the open index);
- errno = EINVAL;
- mmap_size = xsize_t(st.st_size);
- mmap = xmmap(NULL, mmap_size, PROT_READ | PROT_WRITE, MAP_PRIVATE, fd,
0);
- close(fd);
- if (mmap == MAP_FAILED)
- die_errno(unable to map index file);
+ errno = EINVAL;
+ mmap_size = xsize_t(st_old.st_size);
+ mmap = xmmap(NULL, mmap_size, PROT_READ | PROT_WRITE,
MAP_PRIVATE, fd, 0);
+ close(fd);
+ if (mmap == MAP_FAILED)
+ die_errno(unable to map index file);
- hdr = mmap;
- if (verify_hdr_version(istate, hdr, mmap_size) 0)
- goto unmap;
+ hdr = mmap;
+ if (verify_hdr_version(istate, hdr, mmap_size) 0)
+ err = 1;
- if (istate-ops-verify_hdr(mmap, mmap_size) 0)
- goto unmap;
+ if (istate-ops-verify_hdr(mmap, mmap_size) 0)
+ err = 1;
- istate-ops-read_index(istate, mmap, mmap_size);
- istate-timestamp.sec = st.st_mtime;
- istate-timestamp.nsec = ST_MTIME_NSEC(st);
+ if (istate-ops-read_index(istate, mmap, mmap_size) 0)
+ err = 1;
+ istate-timestamp.sec = st_old.st_mtime;
+ istate-timestamp.nsec = ST_MTIME_NSEC(st_old);
+ if (lstat(path, st_new))
+ die_errno(cannot stat the open index);
- munmap(mmap, mmap_size);
- return istate-cache_nr;
+ munmap(mmap, mmap_size);
+
+ if (!index_changed(st_old, st_new) !err)
+ return istate-cache_nr;
+
+ usleep(10*1000);
+ i++;
+ } while ((err || index_changed(st_old, st_new)) i 50);
-unmap:
munmap(mmap, mmap_size);
die(index file corrupt);
}
--
1.7.11.2
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC v4 03/13] t2104: Don't fail for index versions other than [23]
t2104 currently checks for the exact index version 2 or 3, depending if there is a skip-worktree flag or not. Other index versions do not use extended flags and thus cannot be tested for version changes. Make this test update the index to version 2 at the beginning of the test. Testing the skip-worktree flags for the default index format is still covered by t7011 and t7012. Signed-off-by: Thomas Gummerer t.gumme...@gmail.com --- t/t2104-update-index-skip-worktree.sh | 1 + 1 file changed, 1 insertion(+) diff --git a/t/t2104-update-index-skip-worktree.sh b/t/t2104-update-index-skip-worktree.sh index 1d0879b..bd9644f 100755 --- a/t/t2104-update-index-skip-worktree.sh +++ b/t/t2104-update-index-skip-worktree.sh @@ -22,6 +22,7 @@ H sub/2 EOF test_expect_success 'setup' ' + git update-index --index-version=2 mkdir sub touch ./1 ./2 sub/1 sub/2 git add 1 2 sub/1 sub/2 -- 1.7.11.2 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC v4 12/13] update-index.c: rewrite index when index-version is given
Make update-index always rewrite the index when a index-version
is given, even if the index already has the right version.
This option is used for performance testing the writer and
reader.
Signed-off-by: Thomas Gummerer t.gumme...@gmail.com
---
builtin/update-index.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/builtin/update-index.c b/builtin/update-index.c
index 4ce341c..c31d176 100644
--- a/builtin/update-index.c
+++ b/builtin/update-index.c
@@ -6,6 +6,7 @@
#include cache.h
#include quote.h
#include cache-tree.h
+#include read-cache.h
#include tree-walk.h
#include builtin.h
#include refs.h
@@ -861,6 +862,7 @@ int cmd_update_index(int argc, const char **argv, const
char *prefix)
if (the_index.version != preferred_index_format)
active_cache_changed = 1;
the_index.version = preferred_index_format;
+ set_istate_ops(the_index);
}
if (read_from_stdin) {
@@ -886,7 +888,7 @@ int cmd_update_index(int argc, const char **argv, const
char *prefix)
strbuf_release(buf);
}
- if (active_cache_changed) {
+ if (active_cache_changed || preferred_index_format) {
if (newfd 0) {
if (refresh_args.flags REFRESH_QUIET)
exit(128);
--
1.7.11.2
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC v4 13/13] p0002-index.sh: add perf test for the index formats
From: Thomas Rast tr...@student.ethz.ch Add a performance test for index version [23]/4/5 by using git update-index --index-version=x, thus testing both the reader and the writer speed of all index formats. Signed-off-by: Thomas Rast tr...@student.ethz.ch Signed-off-by: Thomas Gummerer t.gumme...@gmail.com --- t/perf/p0002-index.sh | 33 + 1 file changed, 33 insertions(+) create mode 100755 t/perf/p0002-index.sh diff --git a/t/perf/p0002-index.sh b/t/perf/p0002-index.sh new file mode 100755 index 000..140c7a0 --- /dev/null +++ b/t/perf/p0002-index.sh @@ -0,0 +1,33 @@ +#!/bin/sh + +test_description=Tests index versions [23]/4/5 + +. ./perf-lib.sh + +test_perf_large_repo + +test_expect_success 'convert to v3' ' + git update-index --index-version=3 +' + +test_perf 'v[23]: update-index' ' + git update-index --index-version=3 /dev/null +' + +test_expect_success 'convert to v4' ' + git update-index --index-version=4 +' + +test_perf 'v4: update-index' ' + git update-index --index-version=4 /dev/null +' + +test_expect_success 'convert to v5' ' + git update-index --index-version=5 +' + +test_perf 'v5: update-index' ' + git update-index --index-version=5 /dev/null +' + +test_done -- 1.7.11.2 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC v4 11/13] Write resolve-undo data for index-v5
Make git read the resolve-undo data from the index.
Since the resolve-undo data is joined with the conflicts in
the ondisk format of the index file version 5, conflicts and
resolved data is read at the same time, and the resolve-undo
data is then converted to the in-memory format.
Helped-by: Thomas Rast tr...@student.ethz.ch
Signed-off-by: Thomas Gummerer t.gumme...@gmail.com
---
read-cache-v5.c | 96 +
1 file changed, 96 insertions(+)
diff --git a/read-cache-v5.c b/read-cache-v5.c
index d740d0b..ce2375a 100644
--- a/read-cache-v5.c
+++ b/read-cache-v5.c
@@ -907,6 +907,99 @@ static void cache_tree_to_ondisk_v5(struct hash_table
*table, struct cache_tree
convert_one_to_ondisk_v5(table, root, , 0, 0);
}
+static void resolve_undo_to_ondisk_v5(struct hash_table *table,
+ struct string_list *resolve_undo,
+ unsigned int *ndir, int *total_dir_len,
+ struct directory_entry *de)
+{
+ struct string_list_item *item;
+ struct directory_entry *search;
+
+ if (!resolve_undo)
+ return;
+ for_each_string_list_item(item, resolve_undo) {
+ struct conflict_entry *conflict_entry;
+ struct resolve_undo_info *ui = item-util;
+ char *super;
+ int i, dir_len, len;
+ uint32_t crc;
+ struct directory_entry *found, *current, *new_tree;
+
+ if (!ui)
+ continue;
+
+ super = super_directory(item-string);
+ if (!super)
+ dir_len = 0;
+ else
+ dir_len = strlen(super);
+ crc = crc32(0, (Bytef*)super, dir_len);
+ found = lookup_hash(crc, table);
+ current = NULL;
+ new_tree = NULL;
+
+ while (!found) {
+ struct directory_entry *new;
+
+ new = init_directory_entry(super, dir_len);
+ if (!current)
+ current = new;
+ insert_directory_entry(new, table, total_dir_len, ndir,
crc);
+ if (new_tree != NULL)
+ new-de_nsubtrees = 1;
+ new-next = new_tree;
+ new_tree = new;
+ super = super_directory(super);
+ if (!super)
+ dir_len = 0;
+ else
+ dir_len = strlen(super);
+ crc = crc32(0, (Bytef*)super, dir_len);
+ found = lookup_hash(crc, table);
+ }
+ search = found;
+ while (search-next_hash strcmp(super, search-pathname) !=
0)
+ search = search-next_hash;
+ if (search !current)
+ current = search;
+ if (!search !current)
+ current = new_tree;
+ if (!super new_tree) {
+ new_tree-next = de-next;
+ de-next = new_tree;
+ de-de_nsubtrees++;
+ } else if (new_tree) {
+ struct directory_entry *temp;
+
+ search = de-next;
+ while (strcmp(super, search-pathname))
+ search = search-next;
+ temp = new_tree;
+ while (temp-next)
+ temp = temp-next;
+ search-de_nsubtrees++;
+ temp-next = search-next;
+ search-next = new_tree;
+ }
+
+ len = strlen(item-string);
+ conflict_entry = create_new_conflict(item-string, len,
current-de_pathlen);
+ add_conflict_to_directory_entry(current, conflict_entry);
+ for (i = 0; i 3; i++) {
+ if (ui-mode[i]) {
+ struct conflict_part *cp;
+
+ cp = xmalloc(sizeof(struct conflict_part));
+ cp-flags = (i + 1) CONFLICT_STAGESHIFT;
+ cp-entry_mode = ui-mode[i];
+ cp-next = NULL;
+ hashcpy(cp-sha1, ui-sha1[i]);
+ add_part_to_conflict_entry(current,
conflict_entry, cp);
+ }
+ }
+ }
+}
+
static struct directory_entry *compile_directory_data(struct index_state
*istate,
int nfile,
unsigned int *ndir,
@@ -1012,6 +1105,9 @@ static struct directory_entry
*compile_directory_data(struct
[PATCH/RFC v4 08/13] Read cache-tree in index-v5
Since the cache-tree data is saved as part of the directory data,
we already read it at the beginning of the index. The cache-tree
is only converted from this directory data.
The cache-tree data is arranged in a tree, with the children sorted by
pathlen at each node, while the ondisk format is sorted lexically.
So we have to rebuild this format from the on-disk directory list.
Signed-off-by: Thomas Gummerer t.gumme...@gmail.com
---
cache-tree.c| 2 +-
cache-tree.h| 6
read-cache-v5.c | 98 +
3 files changed, 105 insertions(+), 1 deletion(-)
diff --git a/cache-tree.c b/cache-tree.c
index 28ed657..61544d8 100644
--- a/cache-tree.c
+++ b/cache-tree.c
@@ -31,7 +31,7 @@ void cache_tree_free(struct cache_tree **it_p)
*it_p = NULL;
}
-static int subtree_name_cmp(const char *one, int onelen,
+int subtree_name_cmp(const char *one, int onelen,
const char *two, int twolen)
{
if (onelen twolen)
diff --git a/cache-tree.h b/cache-tree.h
index d8cb2e9..7416007 100644
--- a/cache-tree.h
+++ b/cache-tree.h
@@ -20,10 +20,16 @@ struct cache_tree {
struct cache_tree_sub **down;
};
+struct directory_queue {
+ struct directory_queue *down;
+ struct directory_entry *de;
+};
+
struct cache_tree *cache_tree(void);
void cache_tree_free(struct cache_tree **);
void cache_tree_invalidate_path(struct cache_tree *, const char *);
struct cache_tree_sub *cache_tree_sub(struct cache_tree *, const char *);
+int subtree_name_cmp(const char *, int, const char *, int);
void cache_tree_write(struct strbuf *, struct cache_tree *root);
struct cache_tree *cache_tree_read(const char *buffer, unsigned long size);
diff --git a/read-cache-v5.c b/read-cache-v5.c
index fb549de..b497726 100644
--- a/read-cache-v5.c
+++ b/read-cache-v5.c
@@ -448,6 +448,103 @@ static int read_conflicts(struct conflict_entry **head,
return 0;
}
+static struct cache_tree *convert_one(struct directory_queue *queue, int dirnr)
+{
+ int i, subtree_nr;
+ struct cache_tree *it;
+ struct directory_queue *down;
+
+ it = cache_tree();
+ it-entry_count = queue[dirnr].de-de_nentries;
+ subtree_nr = queue[dirnr].de-de_nsubtrees;
+ if (0 = it-entry_count)
+ hashcpy(it-sha1, queue[dirnr].de-sha1);
+
+ /*
+ * Just a heuristic -- we do not add directories that often but
+ * we do not want to have to extend it immediately when we do,
+ * hence +2.
+ */
+ it-subtree_alloc = subtree_nr + 2;
+ it-down = xcalloc(it-subtree_alloc, sizeof(struct cache_tree_sub *));
+ down = queue[dirnr].down;
+ for (i = 0; i subtree_nr; i++) {
+ struct cache_tree *sub;
+ struct cache_tree_sub *subtree;
+ char *buf, *name;
+
+ name = ;
+ buf = strtok(down[i].de-pathname, /);
+ while (buf) {
+ name = buf;
+ buf = strtok(NULL, /);
+ }
+ sub = convert_one(down, i);
+ if(!sub)
+ goto free_return;
+ subtree = cache_tree_sub(it, name);
+ subtree-cache_tree = sub;
+ }
+ if (subtree_nr != it-subtree_nr)
+ die(cache-tree: internal error);
+ return it;
+ free_return:
+ cache_tree_free(it);
+ return NULL;
+}
+
+static int compare_cache_tree_elements(const void *a, const void *b)
+{
+ const struct directory_entry *de1, *de2;
+
+ de1 = ((const struct directory_queue *)a)-de;
+ de2 = ((const struct directory_queue *)b)-de;
+ return subtree_name_cmp(de1-pathname, de1-de_pathlen,
+ de2-pathname, de2-de_pathlen);
+}
+
+static struct directory_entry *sort_directories(struct directory_entry *de,
+ struct directory_queue *queue)
+{
+ int i, nsubtrees;
+
+ nsubtrees = de-de_nsubtrees;
+ for (i = 0; i nsubtrees; i++) {
+ struct directory_entry *new_de;
+ de = de-next;
+ new_de = xmalloc(directory_entry_size(de-de_pathlen));
+ memcpy(new_de, de, directory_entry_size(de-de_pathlen));
+ queue[i].de = new_de;
+ if (de-de_nsubtrees) {
+ queue[i].down = xcalloc(de-de_nsubtrees,
+ sizeof(struct directory_queue));
+ de = sort_directories(de,
+ queue[i].down);
+ }
+ }
+ qsort(queue, nsubtrees, sizeof(struct directory_queue),
+ compare_cache_tree_elements);
+ return de;
+}
+
+/*
+ * This function modifys the directory argument that is given to it.
+ * Don't use it if the directory entries are still needed after.
+ */
+static struct cache_tree
[PATCH/RFC v4 10/13] Write index-v5 cache-tree data
Write the cache-tree data for the index version 5 file format. The
in-memory cache-tree data is converted to the ondisk format, by adding
it to the directory entries, that were compiled from the cache-entries
in the step before.
Signed-off-by: Thomas Gummerer t.gumme...@gmail.com
---
read-cache-v5.c | 51 +++
1 file changed, 51 insertions(+)
diff --git a/read-cache-v5.c b/read-cache-v5.c
index a2afc94..d740d0b 100644
--- a/read-cache-v5.c
+++ b/read-cache-v5.c
@@ -856,6 +856,57 @@ static struct conflict_entry
*create_conflict_entry_from_ce(struct cache_entry *
return create_new_conflict(ce-name, ce_namelen(ce), pathlen);
}
+static void convert_one_to_ondisk_v5(struct hash_table *table, struct
cache_tree *it,
+ const char *path, int pathlen, uint32_t crc)
+{
+ int i;
+ struct directory_entry *found, *search;
+
+ crc = crc32(crc, (Bytef*)path, pathlen);
+ found = lookup_hash(crc, table);
+ search = found;
+ while (search strcmp(path, search-pathname + search-de_pathlen -
strlen(path)) != 0)
+ search = search-next_hash;
+ if (!search)
+ return;
+ /*
+* The number of subtrees is already calculated by
+* compile_directory_data, therefore we only need to
+* add the entry_count
+*/
+ search-de_nentries = it-entry_count;
+ if (0 = it-entry_count)
+ hashcpy(search-sha1, it-sha1);
+ if (strcmp(path, ) != 0)
+ crc = crc32(crc, (Bytef*)/, 1);
+
+#if DEBUG
+ if (0 = it-entry_count)
+ fprintf(stderr, cache-tree %.*s (%d ent, %d subtree) %s\n,
+ pathlen, path, it-entry_count, it-subtree_nr,
+ sha1_to_hex(it-sha1));
+ else
+ fprintf(stderr, cache-tree %.*s (%d subtree) invalid\n,
+ pathlen, path, it-subtree_nr);
+#endif
+
+ for (i = 0; i it-subtree_nr; i++) {
+ struct cache_tree_sub *down = it-down[i];
+ if (i) {
+ struct cache_tree_sub *prev = it-down[i-1];
+ if (subtree_name_cmp(down-name, down-namelen,
+prev-name, prev-namelen) = 0)
+ die(fatal - unsorted cache subtree);
+ }
+ convert_one_to_ondisk_v5(table, down-cache_tree, down-name,
down-namelen, crc);
+ }
+}
+
+static void cache_tree_to_ondisk_v5(struct hash_table *table, struct
cache_tree *root)
+{
+ convert_one_to_ondisk_v5(table, root, , 0, 0);
+}
+
static struct directory_entry *compile_directory_data(struct index_state
*istate,
int nfile,
unsigned int *ndir,
--
1.7.11.2
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC v4 07/13] Read resolve-undo data
Make git read the resolve-undo data from the index.
Since the resolve-undo data is joined with the conflicts in
the ondisk format of the index file version 5, conflicts and
resolved data is read at the same time, and the resolve-undo
data is then converted to the in-memory format.
Helped-by: Thomas Rast tr...@student.ethz.ch
Signed-off-by: Thomas Gummerer t.gumme...@gmail.com
---
read-cache-v5.c | 38 ++
1 file changed, 38 insertions(+)
diff --git a/read-cache-v5.c b/read-cache-v5.c
index 2031969..fb549de 100644
--- a/read-cache-v5.c
+++ b/read-cache-v5.c
@@ -1,5 +1,6 @@
#include cache.h
#include read-cache.h
+#include string-list.h
#include resolve-undo.h
#include cache-tree.h
@@ -447,6 +448,42 @@ static int read_conflicts(struct conflict_entry **head,
return 0;
}
+static void resolve_undo_convert_v5(struct index_state *istate,
+ struct conflict_entry *ce)
+{
+ int i;
+
+ while (ce) {
+ struct string_list_item *lost;
+ struct resolve_undo_info *ui;
+ struct conflict_part *cp;
+
+ if (ce-entries (ce-entries-flags CONFLICT_CONFLICTED)
!= 0) {
+ ce = ce-next;
+ continue;
+ }
+ if (!istate-resolve_undo) {
+ istate-resolve_undo = xcalloc(1, sizeof(struct
string_list));
+ istate-resolve_undo-strdup_strings = 1;
+ }
+
+ lost = string_list_insert(istate-resolve_undo, ce-name);
+ if (!lost-util)
+ lost-util = xcalloc(1, sizeof(*ui));
+ ui = lost-util;
+
+ cp = ce-entries;
+ for (i = 0; i 3; i++)
+ ui-mode[i] = 0;
+ while (cp) {
+ ui-mode[conflict_stage(cp) - 1] = cp-entry_mode;
+ hashcpy(ui-sha1[conflict_stage(cp) - 1], cp-sha1);
+ cp = cp-next;
+ }
+ ce = ce-next;
+ }
+}
+
static int read_entries(struct index_state *istate, struct directory_entry
**de,
unsigned long *entry_offset, void **mmap,
unsigned long mmap_size, int *nr,
@@ -460,6 +497,7 @@ static int read_entries(struct index_state *istate, struct
directory_entry **de,
conflict_queue = NULL;
if (read_conflicts(conflict_queue, *de, mmap, mmap_size) 0)
return -1;
+ resolve_undo_convert_v5(istate, conflict_queue);
for (i = 0; i (*de)-de_nfiles; i++) {
if (read_entry(ce,
*de,
--
1.7.11.2
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC v4 06/13] Read index-v5
Make git read the index file version 5 without complaining.
This version of the reader doesn't read neither the cache-tree
nor the resolve undo data, but doesn't choke on an index that
includes such data.
Helped-by: Junio C Hamano gits...@pobox.com
Helped-by: Nguyen Thai Ngoc Duy pclo...@gmail.com
Helped-by: Thomas Rast tr...@student.ethz.ch
Signed-off-by: Thomas Gummerer t.gumme...@gmail.com
---
Makefile| 1 +
cache.h | 73
read-cache-v5.c | 556
3 files changed, 630 insertions(+)
create mode 100644 read-cache-v5.c
diff --git a/Makefile b/Makefile
index 3ccd3a8..ef55509 100644
--- a/Makefile
+++ b/Makefile
@@ -770,6 +770,7 @@ LIB_OBJS += quote.o
LIB_OBJS += reachable.o
LIB_OBJS += read-cache.o
LIB_OBJS += read-cache-v2.o
+LIB_OBJS += read-cache-v5.o
LIB_OBJS += reflog-walk.o
LIB_OBJS += refs.o
LIB_OBJS += remote.o
diff --git a/cache.h b/cache.h
index bfe3099..bec9402 100644
--- a/cache.h
+++ b/cache.h
@@ -110,6 +110,15 @@ struct cache_time {
unsigned int nsec;
};
+/*
+ * The *next pointer is used in read_entries_v5 for holding
+ * all the elements of a directory, and points to the next
+ * cache_entry in a directory.
+ *
+ * It is reset by the add_name_hash call in set_index_entry
+ * to set it to point to the next cache_entry in the
+ * correct in-memory format ordering.
+ */
struct cache_entry {
struct cache_time ce_ctime;
struct cache_time ce_mtime;
@@ -128,11 +137,59 @@ struct cache_entry {
char name[FLEX_ARRAY]; /* more */
};
+struct directory_entry {
+ struct directory_entry *next;
+ struct directory_entry *next_hash;
+ struct cache_entry *ce;
+ struct cache_entry *ce_last;
+ struct conflict_entry *conflict;
+ struct conflict_entry *conflict_last;
+ unsigned int conflict_size;
+ unsigned int de_foffset;
+ unsigned int de_cr;
+ unsigned int de_ncr;
+ unsigned int de_nsubtrees;
+ unsigned int de_nfiles;
+ unsigned int de_nentries;
+ unsigned char sha1[20];
+ unsigned short de_flags;
+ unsigned int de_pathlen;
+ char pathname[FLEX_ARRAY];
+};
+
+struct conflict_part {
+ struct conflict_part *next;
+ unsigned short flags;
+ unsigned short entry_mode;
+ unsigned char sha1[20];
+};
+
+struct conflict_entry {
+ struct conflict_entry *next;
+ unsigned int nfileconflicts;
+ struct conflict_part *entries;
+ unsigned int namelen;
+ unsigned int pathlen;
+ char name[FLEX_ARRAY];
+};
+
+struct ondisk_conflict_part {
+ unsigned short flags;
+ unsigned short entry_mode;
+ unsigned char sha1[20];
+};
+
+#define CE_NAMEMASK (0x0fff)
#define CE_STAGEMASK (0x3000)
#define CE_EXTENDED (0x4000)
#define CE_VALID (0x8000)
+#define CE_SMUDGED (0x0400) /* index v5 only flag */
#define CE_STAGESHIFT 12
+#define CONFLICT_CONFLICTED (0x8000)
+#define CONFLICT_STAGESHIFT 13
+#define CONFLICT_STAGEMASK (0x6000)
+
/*
* Range 0x in ce_flags is divided into
* two parts: in-memory flags and on-disk ones.
@@ -166,6 +223,18 @@ struct cache_entry {
#define CE_EXTENDED_FLAGS (CE_INTENT_TO_ADD | CE_SKIP_WORKTREE)
/*
+ * Representation of the extended on-disk flags in the v5 format.
+ * They must not collide with the ordinary on-disk flags, and need to
+ * fit in 16 bits. Note however that v5 does not save the name
+ * length.
+ */
+#define CE_INTENT_TO_ADD_V5 (0x4000)
+#define CE_SKIP_WORKTREE_V5 (0x0800)
+#if (CE_VALID|CE_STAGEMASK) (CE_INTENTTOADD_V5|CE_SKIPWORKTREE_V5)
+#error v5 on-disk flags collide with ordinary on-disk flags
+#endif
+
+/*
* Safeguard to avoid saving wrong flags:
* - CE_EXTENDED2 won't get saved until its semantic is known
* - Bits in 0x have been saved in ce_flags already
@@ -203,6 +272,8 @@ static inline unsigned create_ce_flags(unsigned stage)
#define ce_skip_worktree(ce) ((ce)-ce_flags CE_SKIP_WORKTREE)
#define ce_mark_uptodate(ce) ((ce)-ce_flags |= CE_UPTODATE)
+#define conflict_stage(c) ((CONFLICT_STAGEMASK (c)-flags)
CONFLICT_STAGESHIFT)
+
#define ce_permissions(mode) (((mode) 0100) ? 0755 : 0644)
static inline unsigned int create_ce_mode(unsigned int mode)
{
@@ -249,6 +320,8 @@ static inline unsigned int canon_mode(unsigned int mode)
}
#define cache_entry_size(len) (offsetof(struct cache_entry,name) + (len) + 1)
+#define directory_entry_size(len) (offsetof(struct directory_entry,pathname) +
(len) + 1)
+#define conflict_entry_size(len) (offsetof(struct conflict_entry,name) + (len)
+ 1)
struct index_state {
struct cache_entry **cache;
diff --git a/read-cache-v5.c b/read-cache-v5.c
new file mode 100644
index 000..2031969
--- /dev/null
+++ b/read-cache-v5.c
@@ -0,0 +1,556 @@
+#include cache.h
+#include read-cache.h
+#include resolve-undo.h
+#include cache-tree.h
+
+#define ptr_add(x,y) ((void *)(((char *)(x)) + (y)))
+
[PATCH/RFC v4 05/13] Make in-memory format aware of stat_crc
Make the in-memory format aware of the stat_crc used by index-v5.
It is simply ignored by index version prior to v5.
Signed-off-by: Thomas Gummerer t.gumme...@gmail.com
---
cache.h | 1 +
read-cache.c | 25 +
2 files changed, 26 insertions(+)
diff --git a/cache.h b/cache.h
index c77cdbe..bfe3099 100644
--- a/cache.h
+++ b/cache.h
@@ -122,6 +122,7 @@ struct cache_entry {
unsigned int ce_flags;
unsigned int ce_namelen;
unsigned char sha1[20];
+ uint32_t ce_stat_crc;
struct cache_entry *next;
struct cache_entry *dir_next;
char name[FLEX_ARRAY]; /* more */
diff --git a/read-cache.c b/read-cache.c
index cdd8480..9d2bd62 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -51,6 +51,29 @@ void rename_index_entry_at(struct index_state *istate, int
nr, const char *new_n
add_index_entry(istate, new,
ADD_CACHE_OK_TO_ADD|ADD_CACHE_OK_TO_REPLACE);
}
+static uint32_t calculate_stat_crc(struct cache_entry *ce)
+{
+ unsigned int ctimens = 0;
+ uint32_t stat, stat_crc;
+
+ stat = htonl(ce-ce_ctime.sec);
+ stat_crc = crc32(0, (Bytef*)stat, 4);
+#ifdef USE_NSEC
+ ctimens = ce-ce_ctime.nsec;
+#endif
+ stat = htonl(ctimens);
+ stat_crc = crc32(stat_crc, (Bytef*)stat, 4);
+ stat = htonl(ce-ce_ino);
+ stat_crc = crc32(stat_crc, (Bytef*)stat, 4);
+ stat = htonl(ce-ce_dev);
+ stat_crc = crc32(stat_crc, (Bytef*)stat, 4);
+ stat = htonl(ce-ce_uid);
+ stat_crc = crc32(stat_crc, (Bytef*)stat, 4);
+ stat = htonl(ce-ce_gid);
+ stat_crc = crc32(stat_crc, (Bytef*)stat, 4);
+ return stat_crc;
+}
+
/*
* This only updates the non-critical parts of the directory
* cache, ie the parts that aren't tracked by GIT, and only used
@@ -73,6 +96,8 @@ void fill_stat_cache_info(struct cache_entry *ce, struct stat
*st)
if (S_ISREG(st-st_mode))
ce_mark_uptodate(ce);
+
+ ce-ce_stat_crc = calculate_stat_crc(ce);
}
static int ce_compare_data(struct cache_entry *ce, struct stat *st)
--
1.7.11.2
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC v4 01/13] Move index v2 specific functions to their own file
Move index version 2 specific functions to their own file,
to prepare for the addition of a new index file format. With
the split into two files we have the non-index specific
functions in read-cache.c and the index-v2 specific functions
in read-cache-v2.c
Helped-by: Nguyen Thai Ngoc Duy pclo...@gmail.com
Signed-off-by: Thomas Gummerer t.gumme...@gmail.com
---
Makefile | 2 +
cache.h | 13 +-
read-cache-v2.c | 581
read-cache.c | 612 +++
read-cache.h | 57 +
test-index-version.c | 7 +-
6 files changed, 682 insertions(+), 590 deletions(-)
create mode 100644 read-cache-v2.c
create mode 100644 read-cache.h
diff --git a/Makefile b/Makefile
index 6b0c961..3ccd3a8 100644
--- a/Makefile
+++ b/Makefile
@@ -645,6 +645,7 @@ LIB_H += progress.h
LIB_H += prompt.h
LIB_H += quote.h
LIB_H += reachable.h
+LIB_H += read-cache.h
LIB_H += reflog-walk.h
LIB_H += refs.h
LIB_H += remote.h
@@ -768,6 +769,7 @@ LIB_OBJS += prompt.o
LIB_OBJS += quote.o
LIB_OBJS += reachable.o
LIB_OBJS += read-cache.o
+LIB_OBJS += read-cache-v2.o
LIB_OBJS += reflog-walk.o
LIB_OBJS += refs.o
LIB_OBJS += remote.o
diff --git a/cache.h b/cache.h
index 67f28b4..c77cdbe 100644
--- a/cache.h
+++ b/cache.h
@@ -94,16 +94,8 @@ unsigned long git_deflate_bound(git_zstream *, unsigned
long);
*/
#define DEFAULT_GIT_PORT 9418
-/*
- * Basic data structures for the directory cache
- */
#define CACHE_SIGNATURE 0x44495243 /* DIRC */
-struct cache_header {
- unsigned int hdr_signature;
- unsigned int hdr_version;
- unsigned int hdr_entries;
-};
#define INDEX_FORMAT_LB 2
#define INDEX_FORMAT_UB 4
@@ -267,6 +259,7 @@ struct index_state {
unsigned name_hash_initialized : 1,
initialized : 1;
struct hash_table name_hash;
+ struct index_ops *ops;
};
extern struct index_state the_index;
@@ -471,8 +464,8 @@ extern int index_name_is_other(const struct index_state *,
const char *, int);
#define CE_MATCH_RACY_IS_DIRTY 02
/* do stat comparison even if CE_SKIP_WORKTREE is true */
#define CE_MATCH_IGNORE_SKIP_WORKTREE 04
-extern int ie_match_stat(const struct index_state *, struct cache_entry *,
struct stat *, unsigned int);
-extern int ie_modified(const struct index_state *, struct cache_entry *,
struct stat *, unsigned int);
+extern int ie_match_stat(struct index_state *, struct cache_entry *, struct
stat *, unsigned int);
+extern int ie_modified(struct index_state *, struct cache_entry *, struct stat
*, unsigned int);
struct pathspec {
const char **raw; /* get_pathspec() result, not freed by
free_pathspec() */
diff --git a/read-cache-v2.c b/read-cache-v2.c
new file mode 100644
index 000..2c5e78b
--- /dev/null
+++ b/read-cache-v2.c
@@ -0,0 +1,581 @@
+#include cache.h
+#include read-cache.h
+#include resolve-undo.h
+#include cache-tree.h
+#include varint.h
+
+/* Mask for the name length in ce_flags in the on-disk index */
+#define CE_NAMEMASK (0x0fff)
+
+struct cache_header {
+ unsigned int hdr_entries;
+};
+
+/*
+ * Index File I/O
+ */
+
+/*
+ * dev/ino/uid/gid/size are also just tracked to the low 32 bits
+ * Again - this is just a (very strong in practice) heuristic that
+ * the inode hasn't changed.
+ *
+ * We save the fields in big-endian order to allow using the
+ * index file over NFS transparently.
+ */
+struct ondisk_cache_entry {
+ struct cache_time ctime;
+ struct cache_time mtime;
+ unsigned int dev;
+ unsigned int ino;
+ unsigned int mode;
+ unsigned int uid;
+ unsigned int gid;
+ unsigned int size;
+ unsigned char sha1[20];
+ unsigned short flags;
+ char name[FLEX_ARRAY]; /* more */
+};
+
+/*
+ * This struct is used when CE_EXTENDED bit is 1
+ * The struct must match ondisk_cache_entry exactly from
+ * ctime till flags
+ */
+struct ondisk_cache_entry_extended {
+ struct cache_time ctime;
+ struct cache_time mtime;
+ unsigned int dev;
+ unsigned int ino;
+ unsigned int mode;
+ unsigned int uid;
+ unsigned int gid;
+ unsigned int size;
+ unsigned char sha1[20];
+ unsigned short flags;
+ unsigned short flags2;
+ char name[FLEX_ARRAY]; /* more */
+};
+
+/* These are only used for v3 or lower */
+#define align_flex_name(STRUCT,len) ((offsetof(struct STRUCT,name) + (len) +
8) ~7)
+#define ondisk_cache_entry_size(len) align_flex_name(ondisk_cache_entry,len)
+#define ondisk_cache_entry_extended_size(len)
align_flex_name(ondisk_cache_entry_extended,len)
+#define ondisk_ce_size(ce) (((ce)-ce_flags CE_EXTENDED) ? \
+ ondisk_cache_entry_extended_size(ce_namelen(ce)) : \
+
[PATCH/RFC v4 04/13] Add documentation of the index-v5 file format
Add a documentation of the index file format version 5 to
Documentation/technical.
Helped-by: Michael Haggerty mhag...@alum.mit.edu
Helped-by: Junio C Hamano gits...@pobox.com
Helped-by: Thomas Rast tr...@student.ethz.ch
Helped-by: Nguyen Thai Ngoc Duy pclo...@gmail.com
Helped-by: Robin Rosenberg robin.rosenb...@dewire.com
Signed-off-by: Thomas Gummerer t.gumme...@gmail.com
---
Documentation/technical/index-file-format-v5.txt | 296 +++
1 file changed, 296 insertions(+)
create mode 100644 Documentation/technical/index-file-format-v5.txt
diff --git a/Documentation/technical/index-file-format-v5.txt
b/Documentation/technical/index-file-format-v5.txt
new file mode 100644
index 000..563d830
--- /dev/null
+++ b/Documentation/technical/index-file-format-v5.txt
@@ -0,0 +1,296 @@
+GIT index format
+
+
+== The git index
+
+ The git index file (.git/index) documents the status of the files
+ in the git staging area.
+
+ The staging area is used for preparing commits, merging, etc.
+
+== The git index file format
+
+ All binary numbers are in network byte order. Version 5 is described
+ here. The index file consists of various sections. They appear in
+ the following order in the file.
+
+ - header: the description of the index format, including it's signature,
+ version and various other fields that are used internally.
+
+ - diroffsets (ndir entries of direcotry offset): A 4-byte offset
+ relative to the beginning of the direntries block (see below)
+ for each of the ndir directories in the index, sorted by pathname
+ (of the directory it's pointing to). [1]
+
+ - direntries (ndir entries of directory offset): A directory entry
+ for each of the ndir directories in the index, sorted by pathname
+ (see below). [2]
+
+ - fileoffsets (nfile entries of file offset): A 4-byte offset
+ relative to the beginning of the fileentries block (see below)
+ for each of the nfile files in the index. [1]
+
+ - fileentries (nfile entries of file entry): A file entry for
+ each of the nfile files in the index (see below).
+
+ - crdata: A number of entries for conflicted data/resolved conflicts
+ (see below).
+
+ - Extensions (Currently none, see below in the future)
+
+ Extensions are identified by signature. Optional extensions can
+ be ignored if GIT does not understand them.
+
+ GIT supports an arbitrary number of extension, but currently none
+ is implemented. [3]
+
+ extsig (32-bits): extension signature. If the first byte is 'A'..'Z'
+ the extension is optional and can be ignored.
+
+ extsize (32-bits): size of the extension, excluding the header
+ (extsig, extsize, extchecksum).
+
+ extchecksum (32-bits): crc32 checksum of the extension signature
+ and size.
+
+- Extension data.
+
+== Header
+ sig (32-bits): Signature:
+ The signature is { 'D', 'I', 'R', 'C' } (stands for dircache)
+
+ vnr (32-bits): Version number:
+ The current supported versions are 2, 3, 4 and 5.
+
+ ndir (32-bits): number of directories in the index.
+
+ nfile (32-bits): number of file entries in the index.
+
+ fblockoffset (32-bits): offset to the file block, relative to the
+ beginning of the file.
+
+ - Offset to the extensions.
+
+ nextensions (32-bits): number of extensions.
+
+ extoffset (32-bits): offset to the extension. (Possibly none, as
+ many as indicated in the 4-byte number of extensions)
+
+ headercrc (32-bits): crc checksum including the header and the
+ offsets to the extensions.
+
+
+== Directory offsets (diroffsets)
+
+ diroffset (32-bits): offset to the directory relative to the beginning
+of the index file. There are ndir + 1 offsets in the diroffset table,
+the last is pointing to the end of the last direntry. With this last
+entry, we are able to replace the strlen of when reading the directory
+name, by calculating it from diroffset[n+1]-diroffset[n]-61. 61 is the
+size of the directory data, which follows each each directory + the
+crc sum + the NUL byte.
+
+ This part is needed for making the directory entries bisectable and
+thus allowing a binary search.
+
+== Directory entry (direntries)
+
+ Directory entries are sorted in lexicographic order by the name
+of their path starting with the root.
+
+ pathname (variable length, nul terminated): relative to top level
+directory (without the leading slash). '/' is used as path
+separator. A string of length 0 ('') indicates the root directory.
+The special path components ., and .. (without quotes) are
+disallowed. The path also includes a trailing slash. [9]
+
+ foffset (32-bits): offset to the lexicographically first file in
+the file offsets (fileoffsets), relative to the beginning of
+the fileoffset block.
+
+ cr (32-bits): offset to conflicted/resolved data at the end of the
+index.
Re: [PATCH v2] rev-list docs: clarify --topo-order description
On 08/16/2012 10:51 AM, Thomas Rast wrote: [...] is misleading. I suppose the real problem is that the true ordering is completely obvious as the one ordering that does not require preprocessing, but ugly to specify in words. Perhaps we can bikeshed a little? How about By default, commits are shown in an order that coincides with `--date-order` on well-behaved history, but is faster to compute. Maybe the problem is not the description of the options, but the options themselves. Why does the behavior default to some mysterious order that we don't even want to document? Only for the sake of computational efficiency. This is the tail wagging the dog. Why not turn the behavior on its head: * Change the default behavior to be something well-defined, easy to document, and convenient for humans, such as topological order with ties broken by timestamp or approximate timestamp order, but respecting dependencies. * Add a new option, --arbitrary-order, that explicitly chooses efficiency instead of a defined order. That way the easiest thing to type is also the most convenient, whereas when you care about efficiency and *don't* care about order (i.e., mainly in scripts) you can explicitly request the high-performance option. Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.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 v2] rev-list docs: clarify --topo-order description
Michael Haggerty mhag...@alum.mit.edu writes:
On 08/16/2012 10:51 AM, Thomas Rast wrote:
I suppose the real problem is that the true ordering
is completely obvious as the one ordering that does not require
preprocessing, but ugly to specify in words. Perhaps we can bikeshed a
little? How about
By default, commits are shown in an order that coincides with
`--date-order` on well-behaved history, but is faster to compute.
Maybe the problem is not the description of the options, but the
options themselves. Why does the behavior default to some mysterious
order that we don't even want to document? Only for the sake of
computational efficiency. This is the tail wagging the dog.
Why not turn the behavior on its head:
* Change the default behavior to be something well-defined, easy to
document, and convenient for humans, such as topological order with
ties broken by timestamp or approximate timestamp order, but
respecting dependencies.
* Add a new option, --arbitrary-order, that explicitly chooses
efficiency instead of a defined order.
I think that would be a rather bad decision, largely because (taking my
git.git as an example):
$ time git log | head -1
commit e5e6172f9060c958e3f0d679cd7049d4007eed2c
real0m0.033s
user0m0.026s
sys 0m0.007s
$ time git log --date-order | head -1
commit e5e6172f9060c958e3f0d679cd7049d4007eed2c
real0m0.429s
user0m0.359s
sys 0m0.031s
That is, even in medium-sized projects like git.git, any -order option
incurs a significant preprocessing time until git-log can show the first
commit. It scales linearly with the number of commits in the range, and
in a linux.git lying around here is already around 3.9s for the same
command.
So if --date-order or --topo-order were the default, you'd have a
significant delay even if you just use 'git log' to quickly see the last
few commits. At least to me, the optimization makes perfect sense.
The right fix would be to dig up Peff's work on generation number
caching, and modify the algorithm to take generation numbers into
account. Then the default order would magically become the same as
--date-order at no speed loss, *and* we'd get a huge speed boost to 'git
log --graph' startup times.
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Is there a way to find out which commit git rebase --skip skipped?
Luke Diamand l...@diamand.org writes: If I do git rebase --skip, is there a way to find out the commit SHA that was skipped (other than just parsing the output of the command) ? There currently isn't, and I do not think it is doable in general when the command ever gives control back to the user to futz with the history, expecting the user only to fix up the conflict and make a single commit (in which case you would want to say that old commit was replayed as this commit with different patch id) or say rebase --skip (in which case you could record that old commit was manually skipped), but the user can do other things like resetting the head to lose commits that have been rebased already, adding new commits manually before continuing, etc., all of which will be done outside of your control. -- 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/RFC] index-pack: produce pack index version 3
On Wed, Aug 15, 2012 at 10:42 PM, Junio C Hamano gits...@pobox.com wrote: Shawn Pearce spea...@spearce.org writes: ... But I think its worth giving him a few weeks to finish getting the code ready, vs. rushing something in that someone else thinks might help. We have waited more than 6 years or whatever to improve packing. Colby's experiments are showing massive improvements (40s enumeration cut to 100ms) with low disk usage increase (10%) and no pack file format changes. No matter what you do, you would be saving the bitmap somewhere outside the *.pack file, yes? Will it be in some extended section of the new *.idx file? Yes, because it is derived from the pack stream its stored external from it. We have chosen to append it as a new section below the CRC-32 table in the *.idx file. It could also go into a new file stream (*.bdx?) but I don't think this is worthwhile. Its a bikeshed that can be painted once the algorithm has proven its value. If it can't do that, its irrelevant where its stored. With the bitmap, your object enumeration phase may go very fast, and you would be able to figure out, in response to a fetch request I have these tips of refs; please update me with these refs of yours, the set of objects you would need to pack (i.e. the ones that are reachable from your refs that were asked for, but that are not reachable from the refs the requestor has). Yes. Not only that, but we are finding that the number of objects to send is fewer, resulting in a much smaller data stream. The bitmap gives us near perfect knowledge of everything the client has, not just the objects on the edge of the graph cut expressed by the ACKed have lines. Objects that existed earlier than the cut don't have to be reset. So the object enumeration phase goes very fast. The compressing objects phase is also time reduced, as fewer objects are needed to be considered, as fewer objects are being sent. With more complete knowledge of the have side, more deltas can be reused as-is, rather than re-encoded on the fly. This reduces the compressing objects phase time even further. And with fewer objects to send, we have easily seen trivial cases of a Linux kernel fetch that is 1 week behind Linus' tip save like 200K on an 800K transfer. Its hard to hate having all of the phases go faster, and transmit less data to the client. Among these objects, there will be ones that are expressed as a delta against what you are going to send, or as a delta against what you know the recipient must already have (if you are using thin pack transfer) in the packfiles you have, and you can send these deltas as-is without recomputation. Yes. I point that out above before even reading this far in your message. :-( But there will be ones that are either expressed as a base in your packfile, or as a delta against something you are not going to send and you know that the recipient does not have. In order to turn these objects into deltas, it may be necessary to have a way to record which delta chain each object belongs to Excellent observation. Instead of performing a hacky delta base search by looking at identical path names in the have set, finding another candidate in the same cluster of deltas that the object is currently encoded against would yield a pretty efficient delta on the wire. It doesn't have to be another object in the same chain, it could also be a sibling object that shares a similar transitive delta base. , and if you are introducing the mechanism to have extended sections in the new *.idx file, that may be a good place to do so. Thus far we haven't done an extended sections modification to the *.idx format. Its just a 'E003' version that requires the bitmaps to be present below the CRC-32 table. But I can see how framing this as a group of optional extensions would be worthwhile. When you need to express an object that your bitmap told you to send (as opposed to rev-list walking told you with the paths to the objects), you can find other objects that belong to the same delta chain and that you know are available to the recipient when it starts to fixing the thin pack using that extra piece of information, in order to find the optimal delta base to encode such an object against. Yes. Just for fun, I applied the attached patch and repacked the history leading to v1.7.12-rc3 with the default depth/window: git rev-list --objects --all | git pack-objects \ --no-reuse-delta --no-reuse-object --delta-base-offset \ [--no-namehash] pack with and without the experimental --no-namehash option. The result is staggering. With name-hash to group objects from the same path close together in the delta window, the resulting pack is 33M. Without the name-hash hint, the same pack is 163M! Needless to say, keeping the objects that should be hashed together inside a delta window is really important. Cute experiment. Yes that name hash works as a decent predictor of
Re: [PATCH v2] rev-list docs: clarify --topo-order description
Thomas Rast tr...@student.ethz.ch writes: Why not turn the behavior on its head: * Change the default behavior to be something well-defined, easy to document, and convenient for humans, such as topological order with ties broken by timestamp or approximate timestamp order, but respecting dependencies. * Add a new option, --arbitrary-order, that explicitly chooses efficiency instead of a defined order. I think that would be a rather bad decision, largely because (taking my git.git as an example): $ time git log | head -1 $ time git log --date-order | head -1 You are correct to point out that introducing --arbitrary-order and force sorting by default is stupid for one reason, but forgot to stress the other equally important reason, I think. Even though you came close to it here: ... if you just use 'git log' to quickly see the last few commits. At least to me, the optimization makes perfect sense. you may not have fully internalized that other reason yourself, I suspect, for the reason I mention in my last two paragraphs below. When you run git log, you are asking only to see the last few commits. The size of few actually depends on the occasion and the user, but the important thing to notice is that the definition of the last is fuzzily defined. In such a request over a history like this: ---A---B---C---D \ ---1---2---3---4---* = HEAD the user does not care the exact order, as long as the ones closer (again, a fuzzy definition) to HEAD come out earlier than the ones farther (and all of them have to come out eventually but that goes without saying). In the case of the above sample history, even with clock skews, the ones labeled with alphabets appear in the expected order among themselves, and the ones labeled with numbers also do, with or without sorting. And all three orders match the use case of git log to view the last few commits just fine. When we have the default, topo and date orders, all of which would give us output suitable for the purpose of showing the last few, picking the one with the least latency is the right thing to do. In other words, latency is important, but a short-latency solution is acceptable and preferred only if it gives a reasonable result. Giving useless output with small latency is not what we are aiming to do. The right fix would be to dig up Peff's work on generation number caching, and modify the algorithm to take generation numbers into account. I think you are totally wrong here, unless you are talking about a generation number that is different from what I recall from the older discussion. Think of the sample history above, and imagine that the numbered ones are based on the current 'master', but that the alphabet ones are based on an ancient maintenance release that is 1000 generations behind (think of me running the command after finishing the day's integration cycle, sitting at the tip of 'pu', where the last topic merged is meant to be eventually merged to maint-1.7.9). All of the commits depicted in the picture will have the commit timestamps in the past few hours. Ancestors of A and 1, not drawn in the picture, were made yesterday or before. The current default output will give all of the depicted commits before showing the older commits that are not in the picture, and that is absolutely the right thing to do when you ask git log to view the last few commits. Imagine what you will see if you used generation numbers instead of the commit timestamp. You will see commits on the maintenance topic that can later be merged to an older codebase, only after you saw all the development history on the master branch since 1.7.9 release. I do not think we want to call such an output the right fix. -- 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: Your branch and 'origin/master' have diverged
On Wed, Aug 15, 2012 at 08:59:02AM +0200, Thomas Rast wrote: I have never had a need for a fetch that doesn't update the remote namespace, nor heard anyone on IRC who has. OTOH, I do have anecdotal evidence in support of the current state is confusing: this thread, or the fact that Jan's IRC bot grew bot-quotes !fetch4/!pull4 that people use to warn users of 'git pull origin master' (it's apparently very common). The 1.8.0 thread is here, and Peff even said he had a patch he uses in his tree: http://thread.gmane.org/gmane.comp.version-control.git/165720/focus=165758 There's even a newer thread suggesting the same: http://thread.gmane.org/gmane.comp.version-control.git/192252 Yeah, I have been running with that patch for ages, and it has never been a problem for me. Of course, the problem cases are very specific workflows that I do not happen to use. There are definitely regressions for some workflows; the question is whether or not anybody is using those workflows (and/or would be bothered to adapt to using the reflog instead). Also note that there are several test failures with the patch, but I haven't investigated them (i.e., I don't know if the patch is buggy, if it is breaking a test in a way that is different than the expected regression, or if the test simply happens to depend on the current behavior and should be fixed). -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] man: git pull -r is a short for --rebase
Miklos Vajna vmik...@suse.cz writes: --- Documentation/git-pull.txt |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt index defb544..67fa5ee 100644 --- a/Documentation/git-pull.txt +++ b/Documentation/git-pull.txt @@ -101,6 +101,7 @@ include::merge-options.txt[] :git-pull: 1 +-r:: --rebase:: Rebase the current branch on top of the upstream branch after fetching. If there is a remote-tracking branch corresponding to I am not sure if this is worth it, as it comes from a natural abbreviated options support, i.e. -r|--r|--re|--reb|--reba|--rebas|--rebase) rebase=true And I do not think we particularly want to do +-r:: +--r:: +--re:: +--reb:: +--reba:: +--rebas:: --rebase:: Rebase the current... for obvious reasons. -- 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: Your branch and 'origin/master' have diverged
On Wed, Aug 15, 2012 at 12:22:28PM -0700, Junio C Hamano wrote: The updated rule would be more complex. If a remote nickname is used, and a refspec given from the command line is without colon, a new special rule overrides the current behaviour and tries to match with a configured refspec. You would need to desribe what happens in that case. It would be something like this. When you tell git fetch to fetch one or more refs from a configured remote by explicitly listing them on the command line, e.g. git fetch remote name... each name... goes through the following process: - The name is turned into the full ref at the remote that starts from refs/ form by applying the usual fetch dwimmery (if name is a name of a branch, refs/heads/name would likely to be the one that is fetched). - Then, configured fetch refspecs for remote is looked up from remote.remote.fetch configuration variable(s), or Pull: line(s) of .git/remotes/remote file. - If the LHS of a refspec found in the previous step matches the full ref we computed in the first step, then the ref at the RHS of the refspec (i.e. remote tracking branch), if any, is updated. If there is no configured refspecs that match the name given from the command line, no remote tracking ref is updated. That is almost exactly what my patch does, except I am not sure that it respects the without a colon bit from your first message. In other words, any time it sees that we have fetched a ref from a particular remote, it applies the mapping from the config and adds the result to the list of refs to be updated. -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: How to pull from windows box
On Thu, 16 Aug 2012 07:11:28 -0600 J.V. jvsr...@gmail.com wrote: We have a central/shared bare repo setup on a Linux box by our scc/build team. Each developer pulls/pushes to this repo. I have two windows boxes where I have cloned the repo. I want to commit and then on my second windows box pull from my other box and keep those in sync until it is time to push to central. What do I need to setup on each Windows 7 box to get this working? Create a regular Windows share for the project directory on the box you want to fetch from, ensure your user from another box is able to successfully authenticate on that share, and then on that box add the created share as a remote like this: git remote add otherbox file:thatbox/sharename To fetch from that otherbox remote you then go like this: 1) Run Windows Explorer, navigate to \\thatbox\sharename, authenticate (if needed). This will ensure all the next accesses will be automatically authenticated. 2) Do `git fetch otherbox`. Of course, you can just attach that share as a network drive and then modify the URL for your remote accordingly. Note that since the repos are normal (non-bare) this will work well only for fetches (see the FAQ for more info). -- 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] rev-list docs: clarify --topo-order description
On 08/16/2012 02:00 PM, Thomas Rast wrote: Michael Haggerty mhag...@alum.mit.edu writes: On 08/16/2012 10:51 AM, Thomas Rast wrote: I suppose the real problem is that the true ordering is completely obvious as the one ordering that does not require preprocessing, but ugly to specify in words. Perhaps we can bikeshed a little? How about By default, commits are shown in an order that coincides with `--date-order` on well-behaved history, but is faster to compute. Maybe the problem is not the description of the options, but the options themselves. Why does the behavior default to some mysterious order that we don't even want to document? Only for the sake of computational efficiency. This is the tail wagging the dog. Why not turn the behavior on its head: * Change the default behavior to be something well-defined, easy to document, and convenient for humans, such as topological order with ties broken by timestamp or approximate timestamp order, but respecting dependencies. * Add a new option, --arbitrary-order, that explicitly chooses efficiency instead of a defined order. I think that would be a rather bad decision, largely because (taking my git.git as an example): $ time git log | head -1 commit e5e6172f9060c958e3f0d679cd7049d4007eed2c real0m0.033s user0m0.026s sys 0m0.007s $ time git log --date-order | head -1 commit e5e6172f9060c958e3f0d679cd7049d4007eed2c real0m0.429s user0m0.359s sys 0m0.031s That is, even in medium-sized projects like git.git, any -order option incurs a significant preprocessing time until git-log can show the first commit. It scales linearly with the number of commits in the range, and in a linux.git lying around here is already around 3.9s for the same command. Thanks for timing this; I didn't realize how costly this would be. Just to make it even more obvious that this performance regression would bite in daily life, consider $ time git log -1 real0m0.013s user0m0.000s sys 0m0.004s $ time git log -1 --topo-order real0m0.334s user0m0.316s sys 0m0.012s Ouch. Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.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] help: correct behavior for is_executable on Windows
Hi Junio, On Wed, Aug 15, 2012 at 07:02:31PM -0700, Junio C Hamano wrote: Junio C Hamano gits...@pobox.com writes: My preference is to remove static int is_executable() function from help.c, have an... ... I wouldn't mind seeing the implementation of posix_is_executable() in help.c, which will be dead-code on Windows and Cygwin, if that makes linking and Makefile easier. An outline of such a change might look like this. Thanks for the outline and the clarification, I will use it to cook up something. Cheers Heiko -- 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: Your branch and 'origin/master' have diverged
Jeff King p...@peff.net writes: On Wed, Aug 15, 2012 at 12:22:28PM -0700, Junio C Hamano wrote: The updated rule would be more complex. If a remote nickname is used, and a refspec given from the command line is without colon, a new special rule overrides the current behaviour and tries to match with a configured refspec. You would need to desribe what happens in that case. It would be something like this. When you tell git fetch to fetch one or more refs from a configured remote by explicitly listing them on the command line, e.g. git fetch remote name... each name... goes through the following process: - The name is turned into the full ref at the remote that starts from refs/ form by applying the usual fetch dwimmery (if name is a name of a branch, refs/heads/name would likely to be the one that is fetched). - Then, configured fetch refspecs for remote is looked up from remote.remote.fetch configuration variable(s), or Pull: line(s) of .git/remotes/remote file. - If the LHS of a refspec found in the previous step matches the full ref we computed in the first step, then the ref at the RHS of the refspec (i.e. remote tracking branch), if any, is updated. If there is no configured refspecs that match the name given from the command line, no remote tracking ref is updated. That is almost exactly what my patch does, except I am not sure that it respects the without a colon bit from your first message. Yeah, I forgot to repeat it in this message, but the above three-bullet list needs the 0-th item - If name has already colon in it, following special case rules do not apply. in front of it. Even though I suspect the updated behaviour may be more useful for casual users (while making the semantics a bit more difficult to explain, like the above documentation update), it is a major regression to existing users if it closes the last escape hatch, so I guess with your patch we are almost there but not quite there yet. -- 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
FW: Git
From: Jean Tappan Sent: Thursday, August 16, 2012 12:33 PM To: 'git@vger.kernel.org' Subject: Git I am looking for a tool that will control not only versioning for software, but also the software's associated user and support manuals. I haven't been able to find anything that addresses this particular topic. Can you tell me about this or reference a site or page that discusses it? Thank you. Jean Tappan | Senior Technical Writer | eDOC Innovations| When Strategy Matters ... P:800.425.7766 x420 | F:435.657.2989 | Â jtap...@edoclogic.com Legal Notification: This e-mail and any files transmitted with it are the property of eDOC Innovations, Inc. and/or its affiliates, are confidential, and are intended solely for the use of recipient or entity to whom this e-mail is addressed. If you are not one of the named recipient's or otherwise have reason to believe that you have received this e-mail in error, please notify the sender and delete this message immediately from your computer. Any other use, retention, dissemination, forwarding, printing or copying of this e-mail is strictly prohibited. -- 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
git workflow - merging upwards
I read through gitworkflows and want to use the Merge Upwards rule in my projects: Always commit your fixes to the oldest supported branch that require them. Then (periodically) merge the integration branches upwards into each other. This looks great but I have some trouble in the case if I want to have a change in an older branch and don't want to propagate the change to the newer branches. Let's say I have a v1.1 and a v1.2 and now a have a bug fix/workaround which only affects version v1.1 but not v1.2. If I commit to v1.1 then the periodical merge would merge the change to v1.2 which is what I don't want. Any ideas/workarounds for that problem? -- 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: [PATCH] man: git pull -r is a short for --rebase
From: Junio C Hamano gits...@pobox.com Sent: Thursday, August 16, 2012 5:22 PM Miklos Vajna vmik...@suse.cz writes: --- Documentation/git-pull.txt |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt index defb544..67fa5ee 100644 --- a/Documentation/git-pull.txt +++ b/Documentation/git-pull.txt @@ -101,6 +101,7 @@ include::merge-options.txt[] :git-pull: 1 +-r:: --rebase:: Rebase the current branch on top of the upstream branch after fetching. If there is a remote-tracking branch corresponding to I am not sure if this is worth it, as it comes from a natural abbreviated options support, i.e. I wasn't aware of the abbreviated options capability. Is meant to be in the man pages as I couldn't find it, or is it described differently? Just adding the '-r' part of the option did seem sensible to me as a relative newbie. -r|--r|--re|--reb|--reba|--rebas|--rebase) rebase=true And I do not think we particularly want to do +-r:: +--r:: +--re:: +--reb:: +--reba:: +--rebas:: --rebase:: Rebase the current... for obvious reasons. -- The extra one liner (-r|--r|--re|--reb|--reba|--rebas) would be readable though not pretty, but the seven line version would be horrible! Philip -- 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] man: git pull -r is a short for --rebase
Miklos Vajna vmik...@suse.cz writes: On Thu, Aug 16, 2012 at 09:22:14AM -0700, Junio C Hamano gits...@pobox.com wrote: I am not sure if this is worth it, as it comes from a natural abbreviated options support, i.e. -r|--r|--re|--reb|--reba|--rebas|--rebase) rebase=true I sent the patch as a (newcomer) friend today asked if it's intentional that -r is undocumented in 'man git-pull'. It is more intentional than it is by accident that we don't. We would really think hard to avoid breaking when introducing new options whose long name could begin with v or q to avoid breaking -v and -q that are common across commands, but it is entirely plausible that we want to add a new option whose name begins with re, and at that point, -r or --re stop being the unique short form to trigger git pull --rebase. If somebody figures out git pull --reba or even git pull -r works by accident _today_ and gets used to using it, that is fine, but we do not want to guarantee the future. We reserve the right to introduce git pull --repurpose in a later version of Git, and make git pull --re error out for ambiguity, breaking fingers of such people who relied on used to be but no longer unique abbreviations. ... I agree, however, we already document -q and --quiet, or -v and --verbose in the same manpage, so I think it would be consistent to have -r there as well. See above. 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] man: git pull -r is a short for --rebase
Philip Oakley philipoak...@iee.org writes: I wasn't aware of the abbreviated options capability. Is meant to be in the man pages as I couldn't find it, or is it described differently? $ git help gitcli is the closest that comes to mind. If it is not reachable from git help git, we may want to sprinkle some more linkgit:gitfoo[$n] around the documentation sources. I didn't check. -- 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] man: git pull -r is a short for --rebase
Junio C Hamano gits...@pobox.com writes: We would really think hard to avoid breaking when introducing new options whose long name could begin with v or q to avoid breaking -v and -q that are common across commands [today's lesson for me; do not type while eating] Sorry. We would really think hard to avoid breaking -v and -q that are common across commands, when introducing new options whose long names could begin with v or q. I tried to rephrase/reorganize the sentence a few times by moving words around, but did a terrible job at it. -- 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: git workflow - merging upwards
Patrick Sabin patrick.just4...@gmail.com writes: I read through gitworkflows and want to use the Merge Upwards rule in my projects: Always commit your fixes to the oldest supported branch that require them. Then (periodically) merge the integration branches upwards into each other. This looks great but I have some trouble in the case if I want to have a change in an older branch and don't want to propagate the change to the newer branches. Let's say I have a v1.1 and a v1.2 and now a have a bug fix/workaround which only affects version v1.1 but not v1.2. If I commit to v1.1 then the periodical merge would merge the change to v1.2 which is what I don't want. Any ideas/workarounds for that problem? The document may describe the upwards in a bit too simplified way for readability. If you have two fixes to 1.1, one applicable only to 1.1 and the other applicable to both, you would fork them from tip of maint-1.1, like so: git checkout -b fix-1.1-only maint-1.1; do your work and commit git checkout -b fix-1.1-onwards maint-1.1; do your work and commit and when they are proven to be good, you would merge both of them to maint-1.1 branch: git checkout maint-1.1 git merge fix-1.1-only git merge fix-1.1-onwards But merging the resulting maint-1.1 into maint-1.2 will pull the history and the change of fix-1.1-only that you do not want to have in maint-1.2. You want the history so that later merge will not pull it to maint-1.2, but you do not want the change. The first thing to think about is if fix-1.1-only is really a fix that only should go to maint-1.1. If the change is only for 1.1.x release (e.g. update version number from 1.1.4 to 1.1.5), you may not even want to have such a change directly on the maint-1.1 branch in the first place. You would rather want to have release-1.1 branch that is forked from maint-1.1 branch, that contains the whole of maint-1.1 branch, and also contains the update version number from 1.1.x to 1.1.y changes that are not in the maint-1.1 branch [*1*]. That arrangement may be sufficient to allow you merge maint-1.1 to maint-1.2 sanely. Otherwise, you would fork another branch after merging fix-1.1-* branches to maint-1.1 to merge it upwards. After these two merges illustrated above, while still on maint-1.1, you would do: git checkout -B merge-1.1-to-1.2 maint-1.1 git revert -m 1 maint-1.1~1 ;# revert the fix-1.1-only merge which would result in a state as if you merged fix-1.1-onwards but not fix-1.1-only to the original maint-1.1 branch. But the history of this branch contains both fix-1.1-only and fix-1.1-onwards. And merge that result to maint-1.2, i.e. git checkout maint-1.2 git merge merge-1.1-to-1.2 git branch -d merge-1.1-to-1.2 That way, future merges from maint-1.1 to maint-1.2 will not drag the change of fix-1.1-only. [Footnote] *1* This principle applies not just to release numbers. If you want both maint-1.1 and maint-1.2 as generic two codebases, tweaks meant only for customers of maint-1.1 track should *not* go to maint-1.1, but customer-1.1 branch that forks from maint-1.1. That way, you can keep the generic branches clean from this is only for that branch kind of changes. -- 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] man: git pull -r is a short for --rebase
Johannes Sixt j...@kdbg.org writes: Are you sure? This adds '-r', not '--r', i.e., the single-letter option 'r', to the documentation, which is not something we want to hide, usually. I actually think --rebase squatting on short-and-sweet -r was an accident, and we are saved by not endorsing pull -r by documenting it. We can still use -r for --recurse-submodules if that proves to give more value than --rebase to our users. So I dunno. I personally do not think either deserves a short-and-sweet single letter option. -- 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: fatal: cannot pread pack file, version 1.7.5.4
Jeff King p...@peff.net writes: On Tue, Jul 03, 2012 at 11:25:16AM +0700, Nguyen Thai Ngoc Duy wrote: On Tue, Jul 3, 2012 at 10:45 AM, Jeff King p...@peff.net wrote: On Tue, Jul 03, 2012 at 12:43:42AM +0200, Andreas Schwab wrote: Jeff King p...@peff.net writes: It's very odd for pread to report ENOENT (since it is always operating on an already-opened file descriptor). It doesn't, but gettext will clobber errno: n = pread(pack_fd, inbuf, n, from); if (n 0) die_errno(_(cannot pread pack file)); There is nothing that saves errno. This isn't limited to i18n though, any function call in the arguments may potentially clobber errno. That's horribly lame of gettext. I don't expect arbitrary functions to save errno, but when the entire purpose of a function is to be a non-intrusive wrapper to massage messages to the user, it seems kind of evil to overwrite errno. Isn't the whole point of calling it _ that you don't want to or have to notice it? Agreed. Hmm. According to gettext(3): ERRORS errno is not modified. And googling for gettext and errno reveals several bugfixes in GNU gettext to make sure that gettext preserves errno. I wonder if there are systems where that is not the case, though; I don't know what non-GNU gettext implementations are in common use these days. I'd still be curious to hear what platform the server is for this bug report. Hrm, has this ever been resolved? -- 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] Fix Q-encoded multi-octet-char split in email.
Jeff King p...@peff.net writes: On Tue, Jul 17, 2012 at 10:10:25PM -0700, Junio C Hamano wrote: Ping on a seemingly stalled thread. Hrm. I could swear that Takeharu sent a follow-up using pick_one_utf8_char directly that looked OK, but now I can't seem to find it in the list archives. I wonder if it was off-list and I didn't realize it. If I did not simply dream it, can you re-post the latest patch you sent? Another ping on a seemingly stalled thread. -- 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] branch: make --set-upstream saner without an explicit starting point
Carlos MartÃn Nieto c...@elego.de writes: On Tue, 2012-07-17 at 22:56 -0700, Junio C Hamano wrote: Ping on a seemingly stalled discussion (no need to rush but just checking). I've implemented the feedback, but been slacking on writing the tests which is what's stopped me from re-sending the series. Another mild ping. -- 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/2] test: git-stash conflict sets up rerere
Phil Hord phil.h...@gmail.com writes: So, the next roll will remove the tests for MERGE_RR and will be more explicit about the potential for mergetool confusion and/or the fact that it is not explicitly tested here. I'll wait a little longer for any further comments. Mild ping to a seemingly stalled topic. -- 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: fatal: cannot pread pack file, version 1.7.5.4
Junio C Hamano: Jeff King p...@peff.net writes: On Tue, Jul 03, 2012 at 11:25:16AM +0700, Nguyen Thai Ngoc Duy wrote: On Tue, Jul 3, 2012 at 10:45 AM, Jeff King p...@peff.net wrote: On Tue, Jul 03, 2012 at 12:43:42AM +0200, Andreas Schwab wrote: Jeff King p...@peff.net writes: It's very odd for pread to report ENOENT (since it is always operating on an already-opened file descriptor). It doesn't, but gettext will clobber errno: n = pread(pack_fd, inbuf, n, from); if (n 0) die_errno(_(cannot pread pack file)); There is nothing that saves errno. This isn't limited to i18n though, any function call in the arguments may potentially clobber errno. That's horribly lame of gettext. I don't expect arbitrary functions to save errno, but when the entire purpose of a function is to be a non-intrusive wrapper to massage messages to the user, it seems kind of evil to overwrite errno. Isn't the whole point of calling it _ that you don't want to or have to notice it? Agreed. Hmm. According to gettext(3): ERRORS errno is not modified. And googling for gettext and errno reveals several bugfixes in GNU gettext to make sure that gettext preserves errno. I wonder if there are systems where that is not the case, though; I don't know what non-GNU gettext implementations are in common use these days. I'd still be curious to hear what platform the server is for this bug report. Hrm, has this ever been resolved? Thank you for asking. My local git version is 1.7.5.4, the server version that I actually ended up pushing the files to was however still some 1.6.x. So it was a false alarm. Sorry about that. As far as I can follow, there is no non-GNU gettext involved. Thanks for digging that deep into the problem, but it was my fault, probably not something about lost errno. -- 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] man: git pull -r is a short for --rebase
From: Junio C Hamano gits...@pobox.com Sent: Thursday, August 16, 2012 9:23 PM Philip Oakley philipoak...@iee.org writes: I wasn't aware of the abbreviated options capability. Is meant to be in the man pages as I couldn't find it, or is it described differently? $ git help gitcli is the closest that comes to mind. If it is not reachable from git help git, we may want to sprinkle some more linkgit:gitfoo[$n] around the documentation sources. I didn't check. I eventually found a reference in the parse-options API to the fact that 'Long options may be abbreviated, as long as the abbreviation is unambiguous.' It may be worth bringing some of those parse-options API basics bullets' forward into the gitcli page, if appropriate. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] relative future date
Jundong Xue tomxue0...@gmail.com writes: tomxue@ubuntu:~/mycode/life$ git todo * d768da9 - (in the future: 3 hours later) Meeting with vendor * 5fcd556 - (in the future: 12 days later) Take my personal ho * 9dd280b - (in the future: 11 months later) * 4680099 - (in the future: 9 months later) * 59d5266 - (in the future: 8 months later) * b5308da - (in the future: 7 months later) ... I was re-reading the backlog and after looking at it again, I do not think what the patch tries to do is a bad thing per-se. There are changes I want to see _how_ it is done, though. Especially, the duplication of the exact same logic in the future and in the past was an unmaintainable mess. Here is an attempt to clean it up. Opinions? If the list finds this is a worthwhile thing to do (I am neutral), it needs help from i18n people to mark format messages up properly again. Thanks. Junio C Hamano (2): date: refactor the relative date logic from presentation date: show relative dates in the future date.c | 187 +++- t/t0006-date.sh | 2 + 2 files changed, 146 insertions(+), 43 deletions(-) -- 1.7.12.rc3.69.gaf0166d -- 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] date: refactor the relative date logic from presentation
Separate the logic to decide which presentation (e.g. N months) to
use based on the length of the time from the present and actual
presentation (i.e. strbuf_addf()). This is not strictly needed
but will make the next step easier to read.
The format strings lost N_() markings along the way; help from the
i18n folks to come up with the best and sane way to mark them up is
very much appreciated.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
date.c | 170 -
1 file changed, 127 insertions(+), 43 deletions(-)
diff --git a/date.c b/date.c
index 57331ed..b6ff04e 100644
--- a/date.c
+++ b/date.c
@@ -86,78 +86,162 @@ static int local_tzoffset(unsigned long time)
return offset * eastwest;
}
-void show_date_relative(unsigned long time, int tz,
- const struct timeval *now,
- struct strbuf *timebuf)
+enum relative_style {
+ rd_seconds = 0, rd_minutes, rd_hours, rd_days, rd_weeks, rd_months,
rd_years
+};
+
+struct relative_date {
+ int seconds;
+ int minutes;
+ int hours;
+ int days;
+ int weeks;
+ int months;
+ int years;
+};
+
+static enum relative_style format_relative_date(unsigned long diff,
+ struct relative_date *rd)
{
- unsigned long diff;
- if (now-tv_sec time) {
- strbuf_addstr(timebuf, _(in the future));
- return;
- }
- diff = now-tv_sec - time;
+ memset(rd, 0, sizeof(*rd));
if (diff 90) {
- strbuf_addf(timebuf,
-Q_(%lu second ago, %lu seconds ago, diff), diff);
- return;
+ rd-seconds = diff;
+ return rd_seconds;
}
/* Turn it into minutes */
diff = (diff + 30) / 60;
if (diff 90) {
- strbuf_addf(timebuf,
-Q_(%lu minute ago, %lu minutes ago, diff), diff);
- return;
+ rd-minutes = diff;
+ return rd_minutes;
}
/* Turn it into hours */
diff = (diff + 30) / 60;
if (diff 36) {
- strbuf_addf(timebuf,
-Q_(%lu hour ago, %lu hours ago, diff), diff);
- return;
+ rd-hours = diff;
+ return rd_hours;
}
/* We deal with number of days from here on */
diff = (diff + 12) / 24;
if (diff 14) {
- strbuf_addf(timebuf,
-Q_(%lu day ago, %lu days ago, diff), diff);
- return;
+ rd-days = diff;
+ return rd_days;
}
/* Say weeks for the past 10 weeks or so */
if (diff 70) {
- strbuf_addf(timebuf,
-Q_(%lu week ago, %lu weeks ago, (diff + 3) / 7),
-(diff + 3) / 7);
- return;
+ rd-weeks = (diff + 3) / 7;
+ return rd_weeks;
}
/* Say months for the past 12 months or so */
if (diff 365) {
- strbuf_addf(timebuf,
-Q_(%lu month ago, %lu months ago, (diff + 15) /
30),
-(diff + 15) / 30);
- return;
+ rd-months = (diff + 15) / 30;
+ return rd_months;
}
/* Give years and months for 5 years or so */
if (diff 1825) {
unsigned long totalmonths = (diff * 12 * 2 + 365) / (365 * 2);
- unsigned long years = totalmonths / 12;
- unsigned long months = totalmonths % 12;
- if (months) {
+ rd-years = totalmonths / 12;
+ rd-months = totalmonths % 12;
+ return rd_years;
+ }
+ /* Otherwise, just years. Centuries is probably overkill. */
+ rd-years = (diff + 183) / 365;
+ return rd_years;
+}
+
+void show_date_relative(unsigned long time, int tz,
+ const struct timeval *now,
+ struct strbuf *timebuf)
+{
+ unsigned long diff;
+ struct relative_date rd;
+ int pf = 0; /* past or future */
+
+ struct {
+ struct { const char *s, *p; } msg_seconds;
+ struct { const char *s, *p; } msg_minutes;
+ struct { const char *s, *p; } msg_hours;
+ struct { const char *s, *p; } msg_days;
+ struct { const char *s, *p; } msg_weeks;
+ struct { const char *s, *p; } msg_months;
+ struct { const char *s, *p; } msg_years_only;
+ struct { const char *s, *p; } msg_years_months;
+ struct { const char *s, *p; } msg_years;
+ } msg[1] = {
+ {
+ { %lu second ago, %lu seconds ago },
+ { %lu minute ago, %lu minutes ago },
[PATCH 2/2] date: show relative dates in the future
Inspired by an earlier patch on the list by Tom Xue, but I think
this is done in a much more maintainable way.
It still remains to be seen if this feature makes sense, though.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
date.c | 27 ++-
t/t0006-date.sh | 2 ++
2 files changed, 24 insertions(+), 5 deletions(-)
diff --git a/date.c b/date.c
index b6ff04e..f897955 100644
--- a/date.c
+++ b/date.c
@@ -166,7 +166,7 @@ void show_date_relative(unsigned long time, int tz,
struct { const char *s, *p; } msg_years_only;
struct { const char *s, *p; } msg_years_months;
struct { const char *s, *p; } msg_years;
- } msg[1] = {
+ } msg[2] = {
{
{ %lu second ago, %lu seconds ago },
{ %lu minute ago, %lu minutes ago },
@@ -182,14 +182,31 @@ void show_date_relative(unsigned long time, int tz,
%s, %lu months ago
},
{ %lu year ago, %lu years ago },
- }
+ },
+ {
+ { %lu second in the future, %lu seconds in the
future },
+ { %lu minute in the future, %lu minutes in the
future },
+ { %lu hour in the future, %lu hours in the future },
+ { %lu day in the future, %lu days in the future },
+ { %lu week in the future, %lu weeks in the future },
+ { %lu month in the future, %lu months in the future
},
+ { %lu year, %lu years },
+ {
+ /* TRANSLATORS: %s is n years */
+ %s, %lu month in the future,
+ /* TRANSLATORS: %s is n years */
+ %s, %lu months in the future
+ },
+ { %lu year in the future, %lu years in the future },
+ },
};
if (now-tv_sec time) {
- strbuf_addstr(timebuf, _(in the future));
- return;
+ diff = time - now-tv_sec;
+ pf = 1; /* in the future */
+ } else {
+ diff = now-tv_sec - time;
}
- diff = now-tv_sec - time;
switch (format_relative_date(diff, rd)) {
case rd_seconds:
diff --git a/t/t0006-date.sh b/t/t0006-date.sh
index 1d29810..eef932c 100755
--- a/t/t0006-date.sh
+++ b/t/t0006-date.sh
@@ -26,6 +26,8 @@ check_show 55188000 '1 year, 9 months ago'
check_show 63000 '20 years ago'
check_show 31449600 '12 months ago'
check_show 62985600 '2 years ago'
+check_show -5 '5 seconds in the future'
+check_show -55188000 '1 year, 9 months in the future'
check_parse() {
echo $1 - $2 expect
--
1.7.12.rc3.69.gaf0166d
--
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: fatal: cannot pread pack file, version 1.7.5.4
Lars Winterfeld lars.winterf...@tu-ilmenau.de writes: Hrm, has this ever been resolved? Thank you for asking. My local git version is 1.7.5.4, the server version that I actually ended up pushing the files to was however still some 1.6.x. So it was a false alarm. Sorry about that. Not really. Pushing or fetching by a new version of Git against old version of Git *should* work; otherwise it is a bug. -- 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: Feature request: fetch --prune by default
Dan Johnson computerdr...@gmail.com writes: On Thu, Jul 19, 2012 at 7:55 AM, Jeff King p...@peff.net wrote: ... So I think it would be a lot more palatable if we kept reflogs on deleted branches. That, in turn, has a few open issues, such as how to manage namespace conflicts (e.g., the fact that a deleted foo branch can conflict with a new foo/bar branch). In the meantime, would it make sense to introduce a configuration variable to request this behavior? If so, should it be global? fetch.prune = always or per-remote? remote.name.prune = always The global option seems to be more in line with what Alexey is looking for, but the per-remote one is similar to the tagopt option, which is a similar idea. Of course, this might be just a waste of time to introduce a feature no one would use, in which case we obviously should not introduce such options. I was reading through the backlog today and noticed that this topic veered into the reflog graveyard tangent. I wasn't involved in the main topic, but I think having both configuration variables, remote.remote.prune taking precedence over fetch.prune, as long as we make sure fetch --no-prune will override any configured default, is not a bad thing per-se. As long as the users who elect to use this feature are aware of the pruning of the refs and logs, that is, but branch [-r] -d has been the way to lose both the branch and its log for a long time, so I do not see a big issue there, either. The log graveyard is an independently interesting idea, which I may ping separately, but I consider it pretty much orthogonal to this particular topic. -- 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: Feature request: fetch --prune by default
Alexey Muranov alexey.mura...@gmail.com writes: On 20 Jul 2012, at 09:11, Johannes Sixt wrote: ... Note the difference between tracking branch and remote tracking branch! The remote tracking branches are the refs in the refs/remotes/ hierarchy. The tracking branches are your own local branches that you have created with 'git branch topic thatremote/topic' (or perhaps 'git checkout -b'). The paragraph talks about the latter. Hannes, thanks for the explanation, so i was confused once again. Various blog posts do not make the terminology clear, for example http://gitready.com/beginner/2009/03/09/remote-tracking-branches.html sais that there are only two types of branches: local, and remote-tracking... ... I think i was also misguided by Konstantin, who wrote that you create a remote tracking branch when you intend to actually *develop* something on that branch :). I was re-reading the backlog today, and saw this topic fizzled out. We obviously cannot fix third-party documentation that teach lies to people, but is there something we can do to improve our own documentation with respect to this confusion? As I wrote it elsewhere, I try to avoid the bareword tracking in general, and call the local branch you build on something like your 'next' branch that forked from origin/next remote tracking branch myself. Perhaps we can start from checking the documentation with such a phrasing discipline? -- 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] retain reflogs for deleted refs
Junio C Hamano gits...@pobox.com writes: I like the general direction. Perhaps a long distant future direction could be to also use the same trick in the ref namespace so that we can have 'next' branch itself, and 'next/foo', 'next/bar' forks that are based on the 'next' branch at the same time (it obviously is a totally unrelated topic)? I notice that I was responsible for making this topic veer in the wrong direction by bringing up a new feature having 'next' and 'next/bar' at the same time which nobody asked. Perhaps we can drop that for now to simplify the scope of the topic, to bring the log graveyard back on track? -- 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 00/12] git p4: submit conflict handling
These patches rework how git p4 deals with conflicts that arise during a git p4 submit. These may arise due to changes that happened in p4 since the last git p4 sync. Luke: I especially wanted to get this out as you suggested that you had a different way of dealing with skipped commits. The part that needs the most attention is the interaction loop that happens when a commit failed. Currently, three options are offered: [s]kip this commit, but continue to apply others [a]pply the commit forcefully, generating .rej files [w]rite the commit to a patch.txt file and the implicit ctrl-c to stop After this series, it offers two: [c]ontinue to apply others [q]uit to stop This feels more natural to me, and I like the term continue rather than skip as it matches what rebase uses. I'd like to know what others think of the new flow. Other observable changes are new command-line options: Alias -v for --verbose, similar to other git commands. The --dry-run option addresses Luke's concern in http://thread.gmane.org/gmane.comp.version-control.git/201004/focus=201022 when I removed an unused self.interactive variable that did a similar thing if you edited the code. It prints commits that would be applied to p4. Option --prepare-p4-only is similar to --dry-run, in that it does not submit anything to p4, but it does prepare the p4 workspace, then prints long instructions about how to submit everything properly. It also serves, perhaps, as a replacement for the [a]pply option in the submit-conflict loop. Pete Wyckoff (12): git p4 test: remove bash-ism of combined export/assignment git p4 test: use p4d -L option to suppress log messages git p4: gracefully fail if some commits could not be applied git p4: remove submit failure options [a]pply and [w]rite git p4: move conflict prompt into run, use [c]ontinue and [q]uit git p4: standardize submit cancel due to unchanged template git p4: test clean-up after failed submit, fix added files git p4: rearrange submit template construction git p4: revert deleted files after submit cancel git p4: accept -v for --verbose git p4: add submit --dry-run option git p4: add submit --prepare-p4-only option Documentation/git-p4.txt | 13 +- git-p4.py | 213 +++-- t/lib-git-p4.sh| 10 +- t/t9805-git-p4-skip-submit-edit.sh | 2 +- t/t9807-git-p4-submit.sh | 65 +++ t/t9810-git-p4-rcs.sh | 50 + t/t9815-git-p4-submit-fail.sh | 367 + 7 files changed, 612 insertions(+), 108 deletions(-) create mode 100755 t/t9815-git-p4-submit-fail.sh -- 1.7.11.4 -- 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 01/12] git p4 test: remove bash-ism of combined export/assignment
Signed-off-by: Pete Wyckoff p...@padd.com
---
t/lib-git-p4.sh | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/t/lib-git-p4.sh b/t/lib-git-p4.sh
index 2d753ab..482eeac 100644
--- a/t/lib-git-p4.sh
+++ b/t/lib-git-p4.sh
@@ -26,9 +26,10 @@ testid=${this_test#t}
git_p4_test_start=9800
P4DPORT=$((10669 + ($testid - $git_p4_test_start)))
-export P4PORT=localhost:$P4DPORT
-export P4CLIENT=client
-export P4EDITOR=:
+P4PORT=localhost:$P4DPORT
+P4CLIENT=client
+P4EDITOR=:
+export P4PORT P4CLIENT P4EDITOR
db=$TRASH_DIRECTORY/db
cli=$(test-path-utils real_path $TRASH_DIRECTORY/cli)
--
1.7.11.4
--
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 02/12] git p4 test: use p4d -L option to suppress log messages
Send p4d output to a logfile in the $TRASH_DIRECTORY.
Its messages add no value to testing.
Signed-off-by: Pete Wyckoff p...@padd.com
---
t/lib-git-p4.sh | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/t/lib-git-p4.sh b/t/lib-git-p4.sh
index 482eeac..edb4033 100644
--- a/t/lib-git-p4.sh
+++ b/t/lib-git-p4.sh
@@ -35,12 +35,13 @@ db=$TRASH_DIRECTORY/db
cli=$(test-path-utils real_path $TRASH_DIRECTORY/cli)
git=$TRASH_DIRECTORY/git
pidfile=$TRASH_DIRECTORY/p4d.pid
+logfile=$TRASH_DIRECTORY/p4d.log
start_p4d() {
mkdir -p $db $cli $git
rm -f $pidfile
(
- p4d -q -r $db -p $P4DPORT
+ p4d -q -r $db -p $P4DPORT -L $logfile
echo $! $pidfile
)
--
1.7.11.4
--
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 03/12] git p4: gracefully fail if some commits could not be applied
If a commit fails to apply cleanly to the p4 tree, an interactive prompt asks what to do next. In all cases (skip, apply, write), the behavior after the prompt had a few problems. Change it so that it does not claim erroneously that all commits were applied. Instead list the set of the patches under consideration, and mark with an asterisk those that were applied successfully. Like this example: Applying 592f1f9 line5 in file1 will conflict ... Unfortunately applying the change failed! What do you want to do? [s]kip this patch / [a]pply the patch forcibly and with .rej files / [w]rite the patch to a file (patch.txt) s Skipping! Good luck with the next patches... //depot/file1#4 - was edit, reverted Applying b8db1c6 okay_commit_after_skip ... Change 6 submitted. Applied only the commits marked with '*': 592f1f9 line5 in file1 will conflict * b8db1c6 okay_commit_after_skip Do not try to sync and rebase unless all patches were applied. If there was a conflict during the submit, there is sure to be one at the rebase. Let the user to do the sync and rebase manually. This changes how a couple tets in t9810-git-p4-rcs.sh behave: - git p4 now does not leave files open and edited in the client - If a git commit contains a change to a file that was deleted in p4, the test used to check that the sync/rebase loop happened after the failure to apply the change. Since now sync/rebase does not happen after failure, do not test this. Normal rebase machinery, outside of git p4, will let rebase --skip work. Signed-off-by: Pete Wyckoff p...@padd.com --- git-p4.py | 42 ++- t/t9810-git-p4-rcs.sh | 50 ++- t/t9815-git-p4-submit-fail.sh | 93 +++ 3 files changed, 129 insertions(+), 56 deletions(-) create mode 100755 t/t9815-git-p4-submit-fail.sh diff --git a/git-p4.py b/git-p4.py index e67d37d..2405f38 100755 --- a/git-p4.py +++ b/git-p4.py @@ -1088,7 +1088,10 @@ class P4Submit(Command, P4UserMap): return False def applyCommit(self, id): -print Applying %s % (read_pipe(git log --max-count=1 --pretty=oneline %s % id)) +Apply one commit, return True if it succeeded. + +print Applying, read_pipe([git, show, -s, + --format=format:%h %s, id]) (p4User, gitEmail) = self.p4UserForCommit(id) @@ -1206,7 +1209,7 @@ class P4Submit(Command, P4UserMap): p4_revert(f) for f in filesToAdd: os.remove(f) -return +return False elif response == a: os.system(applyPatchCmd) if len(filesToAdd) 0: @@ -1312,6 +1315,7 @@ class P4Submit(Command, P4UserMap): os.remove(f) os.remove(fileName) +return True # success # Export git tags as p4 labels. Create a p4 label and then tag # with that. @@ -1487,14 +1491,16 @@ class P4Submit(Command, P4UserMap): if gitConfig(git-p4.detectCopiesHarder, --bool) == true: self.diffOpts += --find-copies-harder -while len(commits) 0: -commit = commits[0] -commits = commits[1:] -self.applyCommit(commit) +applied = [] +for commit in commits: +ok = self.applyCommit(commit) +if ok: +applied.append(commit) -if len(commits) == 0: -print All changes applied! -chdir(self.oldWorkingDirectory) +chdir(self.oldWorkingDirectory) + +if len(commits) == len(applied): +print All commits applied! sync = P4Sync() sync.run([]) @@ -1502,6 +1508,20 @@ class P4Submit(Command, P4UserMap): rebase = P4Rebase() rebase.rebase() +else: +if len(applied) == 0: +print No commits applied. +else: +print Applied only the commits marked with '*': +for c in commits: +if c in applied: +star = * +else: +star = +print star, read_pipe([git, show, -s, + --format=format:%h %s, c]) +print You will have to do 'git p4 sync' and rebase. + if gitConfig(git-p4.exportLabels, --bool) == true: self.exportLabels = True @@ -1512,6 +1532,10 @@ class P4Submit(Command, P4UserMap): missingGitTags = gitTags - p4Labels self.exportGitTags(missingGitTags) +# exit with error unless everything applied perfecly +if len(commits) != len(applied): +sys.exit(1) + return True class View(object): diff --git
[PATCH 04/12] git p4: remove submit failure options [a]pply and [w]rite
When a patch failed to apply, these interactive options offered to: 1) apply the patch anyway, leaving reject (.rej) files around, or, 2) write the patch to a file (patch.txt) In both cases it suggested to invoke git p4 submit --continue, an unimplemented option. While manually fixing the rejects and submitting the result might work, there are many steps that must be done to the job properly: * apply patch * invoke p4 add and delete * change executable bits * p4 sync -f renamed/copied files * extract commit message into p4 change description and move Jobs lines out of description section * set changelist owner for --preserve-user Plus the following manual sync/rebase will cause conflicts too, which must be resolved once again. Drop these workflows. Instead users should do a sync/rebase in git, fix the conflicts there, and do a clean git p4 submit. Signed-off-by: Pete Wyckoff p...@padd.com --- git-p4.py | 20 ++-- 1 file changed, 2 insertions(+), 18 deletions(-) diff --git a/git-p4.py b/git-p4.py index 2405f38..e08fea1 100755 --- a/git-p4.py +++ b/git-p4.py @@ -1200,9 +1200,8 @@ class P4Submit(Command, P4UserMap): if not patch_succeeded: print What do you want to do? response = x -while response != s and response != a and response != w: -response = raw_input([s]kip this patch / [a]pply the patch forcibly - and with .rej files / [w]rite the patch to a file (patch.txt) ) +while response != s: +response = raw_input([s]kip this patch ) if response == s: print Skipping! Good luck with the next patches... for f in editedFiles: @@ -1210,21 +1209,6 @@ class P4Submit(Command, P4UserMap): for f in filesToAdd: os.remove(f) return False -elif response == a: -os.system(applyPatchCmd) -if len(filesToAdd) 0: -print You may also want to call p4 add on the following files: -print .join(filesToAdd) -if len(filesToDelete): -print The following files should be scheduled for deletion with p4 delete: -print .join(filesToDelete) -die(Please resolve and submit the conflict manually and -+ continue afterwards with git p4 submit --continue) -elif response == w: -system(diffcmd + patch.txt) -print Patch saved to patch.txt in %s ! % self.clientPath -die(Please resolve and submit the conflict manually and -continue afterwards with git p4 submit --continue) system(applyPatchCmd) -- 1.7.11.4 -- 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: fatal: cannot pread pack file, version 1.7.5.4
Junio C Hamano schrieb: Lars Winterfeld lars.winterf...@tu-ilmenau.de writes: Hrm, has this ever been resolved? Thank you for asking. My local git version is 1.7.5.4, the server version that I actually ended up pushing the files to was however still some 1.6.x. So it was a false alarm. Sorry about that. Not really. Pushing or fetching by a new version of Git against old version of Git *should* work; otherwise it is a bug. Well, okay. The (outdated) server runs on openSUSE 11.1, has kernel 2.6.27.39-0.2-default x86_64 GNU/Linux, uses git version 1.6.0.2 and gettext (GNU gettext-runtime) 0.17 . As I said earlier, `git push` worked in the beginning and just stopped working one day. I can still reproduce this error, so let me know if you want more info. -- 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 06/12] git p4: standardize submit cancel due to unchanged template
When editing the submit template, if no change was made to it, git p4 offers a prompt Submit anyway?. Answering no cancels the submit. Previously, a no answer behaves like a [s]kip answer to the failed-patch prompt, in that it proceeded to try to apply the rest of the commits. Instead, put users back into the new [s]kip / [c]ontinue loop so that they can decide. This makes both cases of patch failure behave identically. The return code of git p4 after a no answer is now the same as that for a skip due to failed patch; update a test to understand this. Signed-off-by: Pete Wyckoff p...@padd.com --- git-p4.py | 4 +++- t/t9805-git-p4-skip-submit-edit.sh | 2 +- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/git-p4.py b/git-p4.py index 1d5194d..075f477 100755 --- a/git-p4.py +++ b/git-p4.py @@ -1262,6 +1262,7 @@ class P4Submit(Command, P4UserMap): if self.edit_template(fileName): # read the edited message and submit +ret = True tmpFile = open(fileName, rb) message = tmpFile.read() tmpFile.close() @@ -1285,6 +1286,7 @@ class P4Submit(Command, P4UserMap): else: # skip this patch +ret = False print Submission cancelled, undoing p4 changes. for f in editedFiles: p4_revert(f) @@ -1293,7 +1295,7 @@ class P4Submit(Command, P4UserMap): os.remove(f) os.remove(fileName) -return True # success +return ret # Export git tags as p4 labels. Create a p4 label and then tag # with that. diff --git a/t/t9805-git-p4-skip-submit-edit.sh b/t/t9805-git-p4-skip-submit-edit.sh index fb3c8ec..ff2cc79 100755 --- a/t/t9805-git-p4-skip-submit-edit.sh +++ b/t/t9805-git-p4-skip-submit-edit.sh @@ -38,7 +38,7 @@ test_expect_success 'no config, unedited, say no' ' cd $git echo line file1 git commit -a -m change 3 (not really) - printf bad response\nn\n | git p4 submit + printf bad response\nn\n | test_expect_code 1 git p4 submit p4 changes //depot/... wc test_line_count = 2 wc ) -- 1.7.11.4 -- 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 07/12] git p4: test clean-up after failed submit, fix added files
Test a variety of cases where a patch failed to apply to
p4 and had to be cleaned up.
If the patch failed to apply cleanly, do not try to remove
to-be-added files, as they have not really been added yet.
Signed-off-by: Pete Wyckoff p...@padd.com
---
git-p4.py | 2 -
t/t9815-git-p4-submit-fail.sh | 132 ++
2 files changed, 132 insertions(+), 2 deletions(-)
diff --git a/git-p4.py b/git-p4.py
index 075f477..13c62c6 100755
--- a/git-p4.py
+++ b/git-p4.py
@@ -1200,8 +1200,6 @@ class P4Submit(Command, P4UserMap):
if not patch_succeeded:
for f in editedFiles:
p4_revert(f)
-for f in filesToAdd:
-os.remove(f)
return False
system(applyPatchCmd)
diff --git a/t/t9815-git-p4-submit-fail.sh b/t/t9815-git-p4-submit-fail.sh
index f6204eb..876b90f 100755
--- a/t/t9815-git-p4-submit-fail.sh
+++ b/t/t9815-git-p4-submit-fail.sh
@@ -109,6 +109,138 @@ test_expect_success 'conflict on first of two commits,
quit' '
)
'
+#
+# Cleanup after submit fail, all cases. Some modifications happen
+# before trying to apply the patch. Make sure these are unwound
+# properly. Put each one in a diff along with something that will
+# obviously conflict. Make sure it is back to normal after.
+#
+
+test_expect_success 'cleanup edit p4 populate' '
+ (
+ cd $cli
+ echo text file text
+ p4 add text
+ echo text+x file text+x
+ chmod 755 text+x
+ p4 add text+x
+ p4 submit -d populate p4
+ )
+'
+
+setup_conflict() {
+ # clone before modifying file1 to force it to conflict
+ test_when_finished cleanup_git
+ git p4 clone --dest=$git //depot
+ # ticks outside subshells
+ test_tick
+ (
+ cd $cli
+ p4 open file1
+ echo $test_tick file1
+ p4 submit -d $test_tick in file1
+ )
+ test_tick
+ (
+ cd $git
+ git config git-p4.skipSubmitEdit true
+ # easy conflict
+ echo $test_tick file1
+ git add file1
+ # caller will add more and submit
+ )
+}
+
+test_expect_success 'cleanup edit after submit fail' '
+ setup_conflict
+ (
+ cd $git
+ echo another line text
+ git add text
+ git commit -m conflict
+ test_expect_code 1 git p4 submit
+ )
+ (
+ cd $cli
+ # make sure it is not open
+ ! p4 fstat -T action text
+ )
+'
+
+test_expect_success 'cleanup add after submit fail' '
+ setup_conflict
+ (
+ cd $git
+ echo new file textnew
+ git add textnew
+ git commit -m conflict
+ test_expect_code 1 git p4 submit
+ )
+ (
+ cd $cli
+ # make sure it is not there
+ # and that p4 thinks it is not added
+ # P4 returns 0 both for not there but added and
+ # not there, so grep.
+ test_path_is_missing textnew
+ p4 fstat -T action textnew 21 | grep no such file
+ )
+'
+
+test_expect_success 'cleanup delete after submit fail' '
+ setup_conflict
+ (
+ cd $git
+ git rm text+x
+ git commit -m conflict
+ test_expect_code 1 git p4 submit
+ )
+ (
+ cd $cli
+ # make sure it is there
+ test_path_is_file text+x
+ ! p4 fstat -T action text+x
+ )
+'
+
+test_expect_success 'cleanup copy after submit fail' '
+ setup_conflict
+ (
+ cd $git
+ cp text text2
+ git add text2
+ git commit -m conflict
+ git config git-p4.detectCopies true
+ git config git-p4.detectCopiesHarder true
+ # make sure setup is okay
+ git diff-tree -r -C --find-copies-harder HEAD | grep text2 |
grep C100
+ test_expect_code 1 git p4 submit
+ )
+ (
+ cd $cli
+ test_path_is_missing text2
+ p4 fstat -T action text2 21 | grep no such file
+ )
+'
+
+test_expect_success 'cleanup rename after submit fail' '
+ setup_conflict
+ (
+ cd $git
+ git mv text text2
+ git commit -m conflict
+ git config git-p4.detectRenames true
+ # make sure setup is okay
+ git diff-tree -r -M HEAD | grep text2 | grep R100
+ test_expect_code 1 git p4 submit
+ )
+ (
+ cd $cli
+ test_path_is_missing text2
+
[PATCH 08/12] git p4: rearrange submit template construction
Put all items in order as they appear, and add comments. Signed-off-by: Pete Wyckoff p...@padd.com --- git-p4.py | 29 + 1 file changed, 21 insertions(+), 8 deletions(-) diff --git a/git-p4.py b/git-p4.py index 13c62c6..0e874cb 100755 --- a/git-p4.py +++ b/git-p4.py @@ -1202,6 +1202,9 @@ class P4Submit(Command, P4UserMap): p4_revert(f) return False +# +# Apply the patch for real, and do add/delete/+x handling. +# system(applyPatchCmd) for f in filesToAdd: @@ -1215,6 +1218,10 @@ class P4Submit(Command, P4UserMap): mode = filesToChangeExecBit[f] setP4ExecBit(f, mode) +# +# Build p4 change description, starting with the contents +# of the git commit message. +# logMessage = extractLogMessageFromGitCommit(id) logMessage = logMessage.strip() (logMessage, jobs) = self.separate_jobs_from_description(logMessage) @@ -1223,8 +1230,16 @@ class P4Submit(Command, P4UserMap): submitTemplate = self.prepareLogMessage(template, logMessage, jobs) if self.preserveUser: - submitTemplate = submitTemplate + (\n Actual user %s, modified after commit\n % p4User) + submitTemplate += \n Actual user %s, modified after commit\n % p4User + +if self.checkAuthorship and not self.p4UserIsMe(p4User): +submitTemplate += git author %s does not match your p4 account.\n % gitEmail +submitTemplate += Use option --preserve-user to modify authorship.\n +submitTemplate += Variable git-p4.skipUserNameCheck hides this message.\n + +separatorLine = everything below this line is just the diff ###\n +# diff if os.environ.has_key(P4DIFF): del(os.environ[P4DIFF]) diff = @@ -1232,6 +1247,7 @@ class P4Submit(Command, P4UserMap): diff += p4_read_pipe(['diff', '-du', wildcard_encode(editedFile)]) +# new file diff newdiff = for newFile in filesToAdd: newdiff += new file \n @@ -1242,13 +1258,7 @@ class P4Submit(Command, P4UserMap): newdiff += + + line f.close() -if self.checkAuthorship and not self.p4UserIsMe(p4User): -submitTemplate += git author %s does not match your p4 account.\n % gitEmail -submitTemplate += Use option --preserve-user to modify authorship.\n -submitTemplate += Variable git-p4.skipUserNameCheck hides this message.\n - -separatorLine = everything below this line is just the diff ###\n - +# change description file: submitTemplate, separatorLine, diff, newdiff (handle, fileName) = tempfile.mkstemp() tmpFile = os.fdopen(handle, w+) if self.isWindows: @@ -1258,6 +1268,9 @@ class P4Submit(Command, P4UserMap): tmpFile.write(submitTemplate + separatorLine + diff + newdiff) tmpFile.close() +# +# Let the user edit the change description, then submit it. +# if self.edit_template(fileName): # read the edited message and submit ret = True -- 1.7.11.4 -- 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 09/12] git p4: revert deleted files after submit cancel
The user can decide not to continue with a submission, by not saving the p4 submit template, then answering no to the Submit anyway? prompt. In this case, be sure to return the p4 client to its initial state. Deleted files were not reverted; fix this and test all cases. Signed-off-by: Pete Wyckoff p...@padd.com --- git-p4.py | 2 + t/t9815-git-p4-submit-fail.sh | 119 ++ 2 files changed, 121 insertions(+) diff --git a/git-p4.py b/git-p4.py index 0e874cb..02b4e44 100755 --- a/git-p4.py +++ b/git-p4.py @@ -1304,6 +1304,8 @@ class P4Submit(Command, P4UserMap): for f in filesToAdd: p4_revert(f) os.remove(f) +for f in filesToDelete: +p4_revert(f) os.remove(fileName) return ret diff --git a/t/t9815-git-p4-submit-fail.sh b/t/t9815-git-p4-submit-fail.sh index 876b90f..d2e7e54 100755 --- a/t/t9815-git-p4-submit-fail.sh +++ b/t/t9815-git-p4-submit-fail.sh @@ -241,6 +241,125 @@ test_expect_success 'cleanup rename after submit fail' ' ) ' +# +# Cleanup after deciding not to submit during editTemplate. This +# involves unwinding more work, because files have been added, deleted +# and chmod-ed now. Same approach as above. +# + +test_expect_success 'cleanup edit after submit cancel' ' + test_when_finished cleanup_git + git p4 clone --dest=$git //depot + ( + cd $git + echo line text + git add text + git commit -m text + echo n | test_expect_code 1 git p4 submit + git reset --hard HEAD^ + ) + ( + cd $cli + ! p4 fstat -T action text + test_cmp $git/text text + ) +' + +test_expect_success 'cleanup add after submit cancel' ' + test_when_finished cleanup_git + git p4 clone --dest=$git //depot + ( + cd $git + echo line textnew + git add textnew + git commit -m textnew + echo n | test_expect_code 1 git p4 submit + ) + ( + cd $cli + test_path_is_missing textnew + p4 fstat -T action textnew 21 | grep no such file + ) +' + +test_expect_success 'cleanup delete after submit cancel' ' + test_when_finished cleanup_git + git p4 clone --dest=$git //depot + ( + cd $git + git rm text + git commit -m rm text + echo n | test_expect_code 1 git p4 submit + ) + ( + cd $cli + test_path_is_file text + ! p4 fstat -T action text + ) +' + +test_expect_success 'cleanup copy after submit cancel' ' + test_when_finished cleanup_git + git p4 clone --dest=$git //depot + ( + cd $git + cp text text2 + git add text2 + git commit -m text2 + git config git-p4.detectCopies true + git config git-p4.detectCopiesHarder true + git diff-tree -r -C --find-copies-harder HEAD | grep text2 | grep C100 + echo n | test_expect_code 1 git p4 submit + ) + ( + cd $cli + test_path_is_missing text2 + p4 fstat -T action text2 21 | grep no such file + ) +' + +test_expect_success 'cleanup rename after submit cancel' ' + test_when_finished cleanup_git + git p4 clone --dest=$git //depot + ( + cd $git + git mv text text2 + git commit -m text2 + git config git-p4.detectRenames true + git diff-tree -r -M HEAD | grep text2 | grep R100 + echo n | test_expect_code 1 git p4 submit + ) + ( + cd $cli + test_path_is_missing text2 + p4 fstat -T action text2 21 | grep no such file + test_path_is_file text + ! p4 fstat -T action text + ) +' + +test_expect_success 'cleanup chmod after submit cancel' ' + test_when_finished cleanup_git + git p4 clone --dest=$git //depot + ( + cd $git + chmod u+x text + chmod u-x text+x + git add text text+x + git commit -m chmod texts + echo n | test_expect_code 1 git p4 submit + ) + ( + cd $cli + test_path_is_file text + ! p4 fstat -T action text + stat --format=%A text | egrep ^-r-- + test_path_is_file text+x + ! p4 fstat -T action text+x + stat --format=%A text+x | egrep ^-r-x + ) +' + test_expect_success 'kill p4d' ' kill_p4d ' -- 1.7.11.4 -- To unsubscribe from this list: send the line
[PATCH 10/12] git p4: accept -v for --verbose
The short form -v is common in many git commands as an alias for --verbose. Signed-off-by: Pete Wyckoff p...@padd.com --- Documentation/git-p4.txt | 2 +- git-p4.py| 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/git-p4.txt b/Documentation/git-p4.txt index 8228f33..4b03356 100644 --- a/Documentation/git-p4.txt +++ b/Documentation/git-p4.txt @@ -163,7 +163,7 @@ All commands except clone accept these options. --git-dir dir:: Set the 'GIT_DIR' environment variable. See linkgit:git[1]. ---verbose:: +--verbose, -v:: Provide more progress information. Sync options diff --git a/git-p4.py b/git-p4.py index 02b4e44..c844d00 100755 --- a/git-p4.py +++ b/git-p4.py @@ -3028,7 +3028,7 @@ def main(): args = sys.argv[2:] -options.append(optparse.make_option(--verbose, dest=verbose, action=store_true)) +options.append(optparse.make_option(--verbose, -v, dest=verbose, action=store_true)) if cmd.needsGit: options.append(optparse.make_option(--git-dir, dest=gitdir)) -- 1.7.11.4 -- 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 11/12] git p4: add submit --dry-run option
A new option, git p4 submit --dry-run can be used to verify what commits and labels would be moved into p4. Signed-off-by: Pete Wyckoff p...@padd.com --- Documentation/git-p4.txt | 4 git-p4.py| 43 ++- t/t9807-git-p4-submit.sh | 41 + 3 files changed, 75 insertions(+), 13 deletions(-) diff --git a/Documentation/git-p4.txt b/Documentation/git-p4.txt index 4b03356..1f32b8e 100644 --- a/Documentation/git-p4.txt +++ b/Documentation/git-p4.txt @@ -269,6 +269,10 @@ These options can be used to modify 'git p4 submit' behavior. Export tags from git as p4 labels. Tags found in git are applied to the perforce working directory. +--dry-run, -n:: + Show just what commits would be submitted to p4; do not change + state in git or p4. + Rebase options ~~ These options can be used to modify 'git p4 rebase' behavior. diff --git a/git-p4.py b/git-p4.py index c844d00..161d106 100755 --- a/git-p4.py +++ b/git-p4.py @@ -853,12 +853,14 @@ class P4Submit(Command, P4UserMap): # preserve the user, requires relevant p4 permissions optparse.make_option(--preserve-user, dest=preserveUser, action=store_true), optparse.make_option(--export-labels, dest=exportLabels, action=store_true), +optparse.make_option(--dry-run, -n, dest=dry_run, action=store_true), ] self.description = Submit changes from git to the perforce depot. self.usage += [name of git branch to submit into perforce depot] self.origin = self.detectRenames = False self.preserveUser = gitConfig(git-p4.preserveUser).lower() == true +self.dry_run = False self.isWindows = (platform.system() == Windows) self.exportLabels = False self.p4HasMoveCommand = p4_has_command(move) @@ -1366,14 +1368,17 @@ class P4Submit(Command, P4UserMap): for mapping in clientSpec.mappings: labelTemplate += \t%s\n % mapping.depot_side.path -p4_write_pipe([label, -i], labelTemplate) +if self.dry_run: +print Would create p4 label %s for tag % name +else: +p4_write_pipe([label, -i], labelTemplate) -# Use the label -p4_system([tag, -l, name] + - [%s@%s % (mapping.depot_side.path, changelist) for mapping in clientSpec.mappings]) +# Use the label +p4_system([tag, -l, name] + + [%s@%s % (mapping.depot_side.path, changelist) for mapping in clientSpec.mappings]) -if verbose: -print created p4 label for tag %s % name +if verbose: +print created p4 label for tag %s % name def run(self, args): if len(args) == 0: @@ -1432,12 +1437,15 @@ class P4Submit(Command, P4UserMap): os.makedirs(self.clientPath) chdir(self.clientPath) -print Synchronizing p4 checkout... -if new_client_dir: -# old one was destroyed, and maybe nobody told p4 -p4_sync(..., -f) +if self.dry_run: +print Would synchronize p4 checkout in %s % self.clientPath else: -p4_sync(...) +print Synchronizing p4 checkout... +if new_client_dir: +# old one was destroyed, and maybe nobody told p4 +p4_sync(..., -f) +else: +p4_sync(...) self.check() commits = [] @@ -1488,10 +1496,17 @@ class P4Submit(Command, P4UserMap): # Apply the commits, one at a time. On failure, ask if should # continue to try the rest of the patches, or quit. # +if self.dry_run: +print Would apply applied = [] last = len(commits) - 1 for i, commit in enumerate(commits): -ok = self.applyCommit(commit) +if self.dry_run: +print , read_pipe([git, show, -s, + --format=format:%h %s, commit]) +ok = True +else: +ok = self.applyCommit(commit) if ok: applied.append(commit) else: @@ -1515,7 +1530,9 @@ class P4Submit(Command, P4UserMap): chdir(self.oldWorkingDirectory) -if len(commits) == len(applied): +if self.dry_run: +pass +elif len(commits) == len(applied): print All commits applied! sync = P4Sync() diff --git a/t/t9807-git-p4-submit.sh b/t/t9807-git-p4-submit.sh index 9394fd4..9cb6aa7 100755 --- a/t/t9807-git-p4-submit.sh +++ b/t/t9807-git-p4-submit.sh @@ -54,6 +54,47 @@ test_expect_success 'submit --origin' ' ) ' +test_expect_success 'submit --dry-run' ' + test_when_finished
[PATCH 12/12] git p4: add submit --prepare-p4-only option
This option can be used to prepare the client workspace for submission, only. It does not invoke the final p4 submit. A message describes how to proceed, either submitting the changes or reverting. Signed-off-by: Pete Wyckoff p...@padd.com --- Documentation/git-p4.txt | 7 +++ git-p4.py| 46 ++ t/t9807-git-p4-submit.sh | 24 3 files changed, 77 insertions(+) diff --git a/Documentation/git-p4.txt b/Documentation/git-p4.txt index 1f32b8e..4be4290 100644 --- a/Documentation/git-p4.txt +++ b/Documentation/git-p4.txt @@ -273,6 +273,13 @@ These options can be used to modify 'git p4 submit' behavior. Show just what commits would be submitted to p4; do not change state in git or p4. +--prepare-p4-only:: + Apply a commit to the p4 workspace, opening, adding and deleting + files in p4 as for a normal submit operation. Do not issue the + final p4 submit, but instead print a message about how to + submit manually or revert. This option always stops after the + first (oldest) commit. Git tags are not exported to p4. + Rebase options ~~ These options can be used to modify 'git p4 rebase' behavior. diff --git a/git-p4.py b/git-p4.py index 161d106..6d2f47e 100755 --- a/git-p4.py +++ b/git-p4.py @@ -854,6 +854,7 @@ class P4Submit(Command, P4UserMap): optparse.make_option(--preserve-user, dest=preserveUser, action=store_true), optparse.make_option(--export-labels, dest=exportLabels, action=store_true), optparse.make_option(--dry-run, -n, dest=dry_run, action=store_true), +optparse.make_option(--prepare-p4-only, dest=prepare_p4_only, action=store_true), ] self.description = Submit changes from git to the perforce depot. self.usage += [name of git branch to submit into perforce depot] @@ -861,6 +862,7 @@ class P4Submit(Command, P4UserMap): self.detectRenames = False self.preserveUser = gitConfig(git-p4.preserveUser).lower() == true self.dry_run = False +self.prepare_p4_only = False self.isWindows = (platform.system() == Windows) self.exportLabels = False self.p4HasMoveCommand = p4_has_command(move) @@ -1270,6 +1272,41 @@ class P4Submit(Command, P4UserMap): tmpFile.write(submitTemplate + separatorLine + diff + newdiff) tmpFile.close() +if self.prepare_p4_only: +# +# Leave the p4 tree prepared, and the submit template around +# and let the user decide what to do next +# +print +print P4 workspace prepared for submission. +print To submit or revert, go to client workspace +print+ self.clientPath +print +print To submit, use \p4 submit\ to write a new description, +print or \p4 submit -i %s\ to use the one prepared by \ + \git p4\. % fileName +print You can delete the file \%s\ when finished. % fileName + +if self.preserveUser and p4User and not self.p4UserIsMe(p4User): +print To preserve change ownership by user %s, you must\n \ + do \p4 change -f change\ after submitting and\n \ + edit the User field. +if pureRenameCopy: +print After submitting, renamed files must be re-synced. +print Invoke \p4 sync -f\ on each of these files: +for f in pureRenameCopy: +print+ f + +print +print To revert the changes, use \p4 revert ...\, and delete +print the submit template file \%s\ % fileName +if filesToAdd: +print Since the commit adds new files, they must be deleted: +for f in filesToAdd: +print+ f +print +return True + # # Let the user edit the change description, then submit it. # @@ -1370,6 +1407,9 @@ class P4Submit(Command, P4UserMap): if self.dry_run: print Would create p4 label %s for tag % name +elif self.prepare_p4_only: +print Not creating p4 label %s for tag due to option \ + --prepare-p4-only % name else: p4_write_pipe([label, -i], labelTemplate) @@ -1510,6 +1550,10 @@ class P4Submit(Command, P4UserMap): if ok: applied.append(commit) else: +if self.prepare_p4_only and i last: +print Processing only the first commit due to option \ + --prepare-p4-only +break if i last: quit = False while True: @@ -1532,6 +1576,8 @@ class
Re: [ANNOUNCE] Git v1.7.12-rc3
Hi Junio, There is one commit on Swedish translation, and it can be added to the final 1.7.12 release. The following changes since commit 61b472ed8b090a3e9240590c85041120a54dd268: git svn: reset invalidates the memoized mergeinfo caches (2012-08-10 19:53:18 +) are available in the git repository at: git://github.com/git-l10n/git-po master for you to fetch changes up to 5b8056c1552a18e289f185f57b86a4b05253716d: l10n: Fixes to Swedish translation (2012-08-16 13:57:51 +0100) Peter Krefting (1): l10n: Fixes to Swedish translation po/sv.po | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) -- 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: fatal: cannot pread pack file, version 1.7.5.4
Jeff King p...@peff.net writes: On Thu, Aug 16, 2012 at 04:05:22PM -0700, Junio C Hamano wrote: Lars Winterfeld lars.winterf...@tu-ilmenau.de writes: Hrm, has this ever been resolved? Thank you for asking. My local git version is 1.7.5.4, the server version that I actually ended up pushing the files to was however still some 1.6.x. So it was a false alarm. Sorry about that. Not really. Pushing or fetching by a new version of Git against old version of Git *should* work; otherwise it is a bug. Yes, but there may be old bugs in the server version that have since been fixed. For example, the bug fixed by 838cd346 might be the cause of this (that fix went into 1.6.0.3). Yeah, Lars said 1.6.x above, but in the response it turns out the version used is 1.6.0.2, so lack of that commit is a very likely reason. 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
[PATCH] git-gui: Fix semi-working shortcuts for unstage and revert
From: Vitaly _Vi Shukela vi0...@gmail.com
Make Ctrl+U for unstaging and Ctrl+J for reverting selection behave
more like Ctrl+T for adding.
They were working only when one area was focused (diff or commit message),
now they should work everywhere.
Signed-off-by: Vitaly _Vi Shukela vi0...@gmail.com
---
No reply to previous email received,
re-sending with new Cc: as recommented on #git-devel.
git-gui/git-gui.sh |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/git-gui/git-gui.sh b/git-gui/git-gui.sh
index ba4e5c1..6618016 100755
--- a/git-gui/git-gui.sh
+++ b/git-gui/git-gui.sh
@@ -3710,6 +3710,8 @@ bind $ui_diff $M1B-Key-v {break}
bind $ui_diff $M1B-Key-V {break}
bind $ui_diff $M1B-Key-a {%W tag add sel 0.0 end;break}
bind $ui_diff $M1B-Key-A {%W tag add sel 0.0 end;break}
+bind $ui_diff $M1B-Key-j {do_revert_selection;break}
+bind $ui_diff $M1B-Key-J {do_revert_selection;break}
bind $ui_diff Key-Up {catch {%W yview scroll -1 units};break}
bind $ui_diff Key-Down {catch {%W yview scroll 1 units};break}
bind $ui_diff Key-Left {catch {%W xview scroll -1 units};break}
@@ -3742,6 +3744,8 @@ bind . $M1B-Key-s do_signoff
bind . $M1B-Key-S do_signoff
bind . $M1B-Key-t do_add_selection
bind . $M1B-Key-T do_add_selection
+bind . $M1B-Key-u do_unstage_selection
+bind . $M1B-Key-U do_unstage_selection
bind . $M1B-Key-j do_revert_selection
bind . $M1B-Key-J do_revert_selection
bind . $M1B-Key-i do_add_all
--
1.7.8.5
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Make 'git submodule update --force' always check out submodules.
Jens Lehmann jens.lehm...@web.de writes: Am 25.07.2012 20:44, schrieb Junio C Hamano: Stefan Zager sza...@google.com writes: Currently, it will only do a checkout if the sha1 registered in the containing repository doesn't match the HEAD of the submodule, regardless of whether the submodule is dirty. As discussed on the mailing list, the '--force' flag is a strong indicator that the state of the submodule is suspect, and should be reset to HEAD. Signed-off-by: Stefan Zager sza...@google.com --- Looks sensible (again -- see http://thread.gmane.org/gmane.comp.version-control.git/197532 for the original discussion). Can submodule folks Ack it? I like it. Still I'd vote for amending the documentation like the original thread proposed and would appreciate to have a test or two, but apart from that I have no objections. Mind ping on missing follow-ups. -- 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 v9] git on Mac OS and precomposed unicode
Junio C Hamano gits...@pobox.com writes: Robin Rosenberg robin.rosenb...@dewire.com writes: Just a couple of nitpicks. Polishing is always good and better late than never, but for a topic that has long been graduated to 'master' already, it would be easier to review and discuss if it came as a patch form relative to the codebase _after_ the topic has been applied. Mild ping for a possible follow-ups that didn't seem to have happened... -- 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: git stash data loss
Jeff King p...@peff.net writes: On Fri, Jul 27, 2012 at 09:29:53AM -0400, Jeff King wrote: If we put actual files inside x, which git does track, then they would be part of the stash, and should be properly retained. But they're not: $ rm x mkdir x echo foo x/file Now we have some precious contents in the form of x/file. They are untracked by git, but git should be careful about removing them. $ git stash Saved working directory and index state WIP on master: 2d32d3a initial HEAD is now at 2d32d3a initial $ ls -l x -rw-r--r-- 1 peff peff 0 Jul 27 09:19 x $ git stash show --raw :100644 00 e69de29... 000... D x Now this _is_ data loss. Stash blows away untracked files inside the directory, but does not record them in the resulting stash. And that should be fixed. Hrm. The problem is that after creating the stash, we then run git reset --hard to drop the changes that we just stashed. But that is not always accurate. It will not usually touch untracked files, but it might if they have D/F conflicts with tracked files. So we need to replace that git reset --hard with some safer command that will notice we are about to overwrite untracked files. But I am not sure what that command would be. Is this something we still want to keep track of? As readers can probably guess, I am trying to come up with a list of loose ends for the next cycle. This may be one of the low-hanging ones. -- 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] contrib: add win32 credential-helper
Erik Faye-Lund kusmab...@gmail.com writes: On Fri, Jul 27, 2012 at 7:10 PM, Erik Faye-Lund kusmab...@gmail.com wrote: Since the Windows port of Git expects binary pipes, we need to make sure the helper-end also sets up binary pipes. Side-step CRLF-issue in test to make it pass. Signed-off-by: Erik Faye-Lund kusmab...@gmail.com --- Sorry for the delay, but here's the third iteration of my credential helper for Windows' credential API. The only change since v2 is that it now supports protocols without a host component, as suggested by Jeff King. ...aaand just as I sent it out, I realized that my Makefile was a bit on the light side. Imagine this patch on top for now, please :) diff --git a/contrib/credential/wincred/Makefile b/contrib/credential/wincred/Makefile index b4f098f..bad45ca 100644 --- a/contrib/credential/wincred/Makefile +++ b/contrib/credential/wincred/Makefile @@ -4,5 +4,11 @@ CC = gcc RM = rm -f CFLAGS = -O2 -Wall +-include ../../../config.mak.autogen +-include ../../../config.mak + git-credential-wincred.exe : git-credential-wincred.c $(LINK.c) $^ $(LOADLIBES) $(LDLIBS) -o $@ + +clean: + $(RM) git-credential-wincred.exe I notice that I didn't queue either of these; are you still polishing them, or are they in good enough shape that it wouldn't make things harder for you if I queue it, with a plan to merge it soon after 1.7.12? -- 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] man: git pull -r is a short for --rebase
On Thu, Aug 16, 2012 at 02:09:33PM -0700, Junio C Hamano gits...@pobox.com wrote: The reason I do not think pull -r gives much value to the users to trigger pull --rebase is because the use of pull --rebase is very project specific. If you are working on a project that forbids merges, you would _always_ want to run pull --rebase, which means you would likely have it configured and would not be typing from the command line. I agree that it's a bit strange, but based on a quick search, it seems multiple projects already advertise git pull -r (i.e. not --rebase and not a configuration option): http://lilypond.org/doc/v2.15/Documentation/contributor/pulling-and-rebasing http://wiki.documentfoundation.org/Git_For_LibreOffice_Developers http://www.wiremod.com/forum/wiremod-general-chat/29517-git-introduction-incomplete-unformatted.html So it seems making -r refer to --recurse-submodules would already cause quite some pain to users. -- 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
