Re: [PATCH 0/2] optimizing pack access on read only fetch repos
On Sat, Jan 26, 2013 at 10:32 PM, Junio C Hamano gits...@pobox.com wrote: Jeff King p...@peff.net writes: This is a repost from here: http://thread.gmane.org/gmane.comp.version-control.git/211176 which got no response initially. Basically the issue is that read-only repos (e.g., a CI server) whose workflow is something like: git fetch $some_branch git checkout -f $some_branch make test will never run git-gc, and will accumulate a bunch of small packs and loose objects, leading to poor performance. ... I also wonder if we would be helped by another repack mode that coalesces small packs into a single one with minimum overhead, and run that often from gc --auto, so that we do not end up having to have 50 packfiles. Yes. This does help When we have 2 or more small and young packs, we could: - iterate over idx files for these packs to enumerate the objects to be packed, replacing read_object_list_from_stdin() step; - always choose to copy the data we have in these existing packs, instead of doing a full prepare_pack(); and - use the order the objects appear in the original packs, bypassing compute_write_order(). Hmm, sounds familiar. Seems like its what we do in JGit for Android. :-) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] upload-pack: avoid parsing objects during ref advertisement
On Fri, Jan 6, 2012 at 11:17 AM, Jeff King p...@peff.net wrote: When we advertise a ref, the first thing we do is parse the pointed-to object. This gives us two things: ... The downside is that we are no longer verifying objects that we advertise by fully parsing them (however, we do still know we actually have them, because sha1_object_info must find them to get the type). While we might fail to detect a corrupt object here, if the client actually fetches the object, we will parse (and verify) it then. As you explain, its not necessary to verify during the advertisement phase. Its fine to delay verification to when a client actually wants the object. On a repository with 120K refs, the advertisement portion of upload-pack goes from ~3.4s to 3.2s (the failure to speed up more is largely due to the fact that most of these refs are tags, which need dereferenced to find the tag destination anyway). Why aren't we using the peeled information from the packed-refs file? JGit does this and it saves a lot of time on advertisements from a well packed repository. -- 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: Cloning remote HTTP repository: Can only see 'master' branch
On Tue, Jan 29, 2013 at 04:54:13PM +1100, Michael Tyson wrote: I've a readonly git repository that I'm hosting via HTTP (a bare git repository located within the appropriate directory on the server). I push to it via my own SSH account (local repository with a remote pointing to the ssh:// URL). This has all worked fine so far - I push via ssh, and others can clone and pull via the HTTP URL. I've recently added a branch - beta - which pushed just fine, but now cloning via the HTTP URL doesn't seem to show the new branch - just master: If you are using the dumb http protocol (i.e., the web server knows nothing about git, and just serves the repo files), you need to run git update-server-info after each push in order to update the static file that tells the git client about each ref. You can have git do it automatically for you by setting receive.updateServerInfo in the server repo's config. If the server is yours to control, consider setting up the smart http protocol, as it is much more efficient. Details are in git help http-backend. -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 0/2] optimizing pack access on read only fetch repos
On Sat, Jan 26, 2013 at 10:32:42PM -0800, Junio C Hamano wrote: Both makes sense to me. I also wonder if we would be helped by another repack mode that coalesces small packs into a single one with minimum overhead, and run that often from gc --auto, so that we do not end up having to have 50 packfiles. When we have 2 or more small and young packs, we could: - iterate over idx files for these packs to enumerate the objects to be packed, replacing read_object_list_from_stdin() step; - always choose to copy the data we have in these existing packs, instead of doing a full prepare_pack(); and - use the order the objects appear in the original packs, bypassing compute_write_order(). I'm not sure. If I understand you correctly, it would basically just be concatenating packs without trying to do delta compression between the objects which are ending up in the same pack. So it would save us from having to do (up to) 50 binary searches to find an object in a pack, but would not actually save us much space. I would be interested to see the timing on how quick it is compared to a real repack, as the I/O that happens during a repack is non-trivial (although if you are leaving aside the big main pack, then it is probably not bad). But how do these somewhat mediocre concatenated packs get turned into real packs? Pack-objects does not consider deltas between objects in the same pack. And when would you decide to make a real pack? How do you know you have 50 young and small packs, and not 50 mediocre coalesced packs? -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] git p4: chdir resolves symlinks only for relative paths
[resending as plain text] If a p4 client is configured to /p/foo which is a symlink to /vol/bar/projects/foo, then resolving symlink, which is done by git-p4's chdir will confuse p4: Path /vol/bar/projects/foo/... is not under client root /p/foo While AltRoots in p4 client specification can be used as a workaround on p4 side, git-p4 should not resolve symlinks in client paths. chdir(dir) uses os.getcwd() after os.chdir(dir) to resolve relative paths, but as a side effect it resolves symlinks too. Now it checks if the dir is relative before resolving. Signed-off-by: Miklós Fazekas mfaze...@szemafor.com --- git-p4.py |5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/git-p4.py b/git-p4.py index 2da5649..5d74649 100755 --- a/git-p4.py +++ b/git-p4.py @@ -64,7 +64,10 @@ def chdir(dir): # not using the shell, we have to set it ourselves. This path could # be relative, so go there first, then figure out where we ended up. os.chdir(dir) -os.environ['PWD'] = os.getcwd() +if os.path.isabs(dir): +os.environ['PWD'] = dir +else: +os.environ['PWD'] = os.getcwd() def die(msg): if verbose: -- 1.7.10.2 (Apple Git-33) -- 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 0/6] commit caching
This is the cleaned-up version of the commit caching patches I mentioned here: http://article.gmane.org/gmane.comp.version-control.git/212329 The basic idea is to generate a cache file that sits alongside a packfile and contains the timestamp, tree, and parents in a more compact and easy-to-access format. The timings from this one are roughly similar to what I posted earlier. Unlike the earlier version, this one keeps the data for a single commit together for better cache locality (though I don't think it made a big difference in my tests, since my cold-cache timing test ends up touching every commit anyway). The short of it is that for an extra 31M of disk space (~4%), I get a warm-cache speedup for git rev-list --all of ~4.2s to ~0.66s. The big thing it does not (yet) do is use offsets to reference sha1s, as Shawn suggested. This would potentially drop the on-disk size from 84 bytes to 16 bytes per commit (or about 6M total for linux.git). Coupled with using compression level 0 for trees (which do not compress well at all, and yield only a 2% increase in size when left uncompressed), my git rev-list --objects --all time drops from ~40s to ~25s. Perf reveals that we're spending most of the remaining time in lookup_object. I've spent a fair bit of time trying to optimize that, but with no luck; I think it's fairly close to optimal. The problem is just that we call it a very large number of times, since it is the mechanism by which we recognize that we have already processed each sha1. [1/6]: csum-file: make sha1write const-correct [2/6]: strbuf: add string-chomping functions [3/6]: introduce pack metadata cache files [4/6]: introduce a commit metapack [5/6]: add git-metapack command [6/6]: commit: look up commit info in metapack -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/6] csum-file: make sha1write const-correct
We do not modify the buffer we are asked to write; mark it
with const so that callers with const buffers do not get
unnecessary complaints from the compiler.
Signed-off-by: Jeff King p...@peff.net
---
csum-file.c | 6 +++---
csum-file.h | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/csum-file.c b/csum-file.c
index 53f5375..465971c 100644
--- a/csum-file.c
+++ b/csum-file.c
@@ -11,7 +11,7 @@
#include progress.h
#include csum-file.h
-static void flush(struct sha1file *f, void *buf, unsigned int count)
+static void flush(struct sha1file *f, const void *buf, unsigned int count)
{
if (0 = f-check_fd count) {
unsigned char check_buffer[8192];
@@ -86,13 +86,13 @@ int sha1write(struct sha1file *f, void *buf, unsigned int
count)
return fd;
}
-int sha1write(struct sha1file *f, void *buf, unsigned int count)
+int sha1write(struct sha1file *f, const void *buf, unsigned int count)
{
while (count) {
unsigned offset = f-offset;
unsigned left = sizeof(f-buffer) - offset;
unsigned nr = count left ? left : count;
- void *data;
+ const void *data;
if (f-do_crc)
f-crc32 = crc32(f-crc32, buf, nr);
diff --git a/csum-file.h b/csum-file.h
index 3b540bd..9dedb03 100644
--- a/csum-file.h
+++ b/csum-file.h
@@ -34,7 +34,7 @@ extern int sha1close(struct sha1file *, unsigned char *,
unsigned int);
extern struct sha1file *sha1fd_check(const char *name);
extern struct sha1file *sha1fd_throughput(int fd, const char *name, struct
progress *tp);
extern int sha1close(struct sha1file *, unsigned char *, unsigned int);
-extern int sha1write(struct sha1file *, void *, unsigned int);
+extern int sha1write(struct sha1file *, const void *, unsigned int);
extern void sha1flush(struct sha1file *f);
extern void crc32_begin(struct sha1file *);
extern uint32_t crc32_end(struct sha1file *);
--
1.8.0.2.16.g72e2fc9
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/6] strbuf: add string-chomping functions
Sometimes it is handy to cut a trailing string off the end
of a strbuf (e.g., a file extension). These helper functions
make it a one-liner.
Signed-off-by: Jeff King p...@peff.net
---
strbuf.c | 11 +++
strbuf.h | 2 ++
2 files changed, 13 insertions(+)
diff --git a/strbuf.c b/strbuf.c
index 9a373be..8199ced 100644
--- a/strbuf.c
+++ b/strbuf.c
@@ -106,6 +106,17 @@ void strbuf_ltrim(struct strbuf *sb)
sb-buf[sb-len] = '\0';
}
+void strbuf_chompmem(struct strbuf *sb, const void *data, size_t len)
+{
+ if (sb-len = len !memcmp(data, sb-buf + sb-len - len, len))
+ strbuf_setlen(sb, sb-len - len);
+}
+
+void strbuf_chompstr(struct strbuf *sb, const char *str)
+{
+ strbuf_chompmem(sb, str, strlen(str));
+}
+
struct strbuf **strbuf_split_buf(const char *str, size_t slen,
int terminator, int max)
{
diff --git a/strbuf.h b/strbuf.h
index ecae4e2..3aeb815 100644
--- a/strbuf.h
+++ b/strbuf.h
@@ -42,6 +42,8 @@ extern void strbuf_ltrim(struct strbuf *);
extern void strbuf_trim(struct strbuf *);
extern void strbuf_rtrim(struct strbuf *);
extern void strbuf_ltrim(struct strbuf *);
+extern void strbuf_chompmem(struct strbuf *, const void *, size_t);
+extern void strbuf_chompstr(struct strbuf *, const char *);
extern int strbuf_cmp(const struct strbuf *, const struct strbuf *);
/*
--
1.8.0.2.16.g72e2fc9
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/6] introduce pack metadata cache files
The on-disk packfile format is nicely compact, but it does
not always provide the fastest format for looking up
information. This patch introduces the concept of
metapacks, optional metadata files which can live
alongside packs and represent their data in different ways.
This can allow space-time tradeoffs in accessing certain
object data.
Such space-time tradeoffs have traditionally gone into the
.idx file (e.g., the fact that we can quickly find an
object's offset in the packfile is due to the index). In
theory, cached data could also go into the .idx file.
However, keeping it in a separate file makes backwards
compatibility much simpler. Older versions of git can simply
ignore the extra files and use the existing methods for
accessing object data. This also makes metapacks optional,
so you can easily tune the space-time tradeoff on a per-repo
basis.
TODO: document on-disk format in Documentation/technical
TODO: document api
Signed-off-by: Jeff King p...@peff.net
---
Makefile | 2 +
metapack.c | 158 +
metapack.h | 42
3 files changed, 202 insertions(+)
create mode 100644 metapack.c
create mode 100644 metapack.h
diff --git a/Makefile b/Makefile
index 731b6a8..3e4ae1b 100644
--- a/Makefile
+++ b/Makefile
@@ -660,6 +660,7 @@ LIB_H += mergesort.h
LIB_H += merge-blobs.h
LIB_H += merge-recursive.h
LIB_H += mergesort.h
+LIB_H += metapack.h
LIB_H += notes-cache.h
LIB_H += notes-merge.h
LIB_H += notes.h
@@ -778,6 +779,7 @@ LIB_OBJS += mergesort.o
LIB_OBJS += merge-blobs.o
LIB_OBJS += merge-recursive.o
LIB_OBJS += mergesort.o
+LIB_OBJS += metapack.o
LIB_OBJS += name-hash.o
LIB_OBJS += notes.o
LIB_OBJS += notes-cache.o
diff --git a/metapack.c b/metapack.c
new file mode 100644
index 000..c859c95
--- /dev/null
+++ b/metapack.c
@@ -0,0 +1,158 @@
+#include cache.h
+#include metapack.h
+#include csum-file.h
+
+static struct sha1file *create_meta_tmp(void)
+{
+ char tmp[PATH_MAX];
+ int fd;
+
+ fd = odb_mkstemp(tmp, sizeof(tmp), pack/tmp_meta_XX);
+ return sha1fd(fd, xstrdup(tmp));
+}
+
+static void write_meta_header(struct metapack_writer *mw, const char *id,
+ uint32_t version)
+{
+ version = htonl(version);
+
+ sha1write(mw-out, META, 4);
+ sha1write(mw-out, \0\0\0\1, 4);
+ sha1write(mw-out, mw-pack-sha1, 20);
+ sha1write(mw-out, id, 4);
+ sha1write(mw-out, version, 4);
+}
+
+void metapack_writer_init(struct metapack_writer *mw,
+ const char *pack_idx,
+ const char *name,
+ int version)
+{
+ struct strbuf path = STRBUF_INIT;
+
+ memset(mw, 0, sizeof(*mw));
+
+ mw-pack = add_packed_git(pack_idx, strlen(pack_idx), 1);
+ if (!mw-pack || open_pack_index(mw-pack))
+ die(unable to open packfile '%s', pack_idx);
+
+ strbuf_addstr(path, pack_idx);
+ strbuf_chompstr(path, .idx);
+ strbuf_addch(path, '.');
+ strbuf_addstr(path, name);
+ mw-path = strbuf_detach(path, NULL);
+
+ mw-out = create_meta_tmp();
+ write_meta_header(mw, name, version);
+}
+
+void metapack_writer_finish(struct metapack_writer *mw)
+{
+ const char *tmp = mw-out-name;
+
+ sha1close(mw-out, NULL, CSUM_FSYNC);
+ if (rename(tmp, mw-path))
+ die_errno(unable to rename temporary metapack file);
+
+ close_pack_index(mw-pack);
+ free(mw-pack);
+ free(mw-path);
+ free((char *)tmp);
+}
+
+void metapack_writer_add(struct metapack_writer *mw, const void *data, int len)
+{
+ sha1write(mw-out, data, len);
+}
+
+void metapack_writer_add_uint32(struct metapack_writer *mw, uint32_t v)
+{
+ v = htonl(v);
+ metapack_writer_add(mw, v, 4);
+}
+
+void metapack_writer_foreach(struct metapack_writer *mw,
+metapack_writer_each_fn cb,
+void *data)
+{
+ const unsigned char *sha1;
+ uint32_t i = 0;
+
+ /*
+* We'll feed these to the callback in sorted order, since that is the
+* order that they are stored in the .idx file.
+*/
+ while ((sha1 = nth_packed_object_sha1(mw-pack, i++)))
+ cb(mw, sha1, data);
+}
+
+int metapack_init(struct metapack *m,
+ struct packed_git *pack,
+ const char *name,
+ uint32_t *version)
+{
+ struct strbuf path = STRBUF_INIT;
+ int fd;
+ struct stat st;
+
+ memset(m, 0, sizeof(*m));
+
+ strbuf_addstr(path, pack-pack_name);
+ strbuf_chompstr(path, .pack);
+ strbuf_addch(path, '.');
+ strbuf_addstr(path, name);
+
+ fd = open(path.buf, O_RDONLY);
+ strbuf_release(path);
+ if (fd 0)
+ return -1;
+ if (fstat(fd, st) 0) {
+ close(fd);
+ return -1;
+ }
+
+
[PATCH 4/6] introduce a commit metapack
When we are doing a commit traversal that does not need to
look at the commit messages themselves (e.g., rev-list,
merge-base, etc), we spend a lot of time accessing,
decompressing, and parsing the commit objects just to find
the parent and timestamp information. We can make a
space-time tradeoff by caching that information on disk in a
compact, uncompressed format.
TODO: document on-disk format in Documentation/technical
TODO: document API
Signed-off-by: Jeff King p...@peff.net
---
Makefile | 2 +
commit-metapack.c | 175 ++
commit-metapack.h | 12
3 files changed, 189 insertions(+)
create mode 100644 commit-metapack.c
create mode 100644 commit-metapack.h
diff --git a/Makefile b/Makefile
index 3e4ae1b..6ca5320 100644
--- a/Makefile
+++ b/Makefile
@@ -619,6 +619,7 @@ LIB_H += column.h
LIB_H += cache.h
LIB_H += color.h
LIB_H += column.h
+LIB_H += commit-metapack.h
LIB_H += commit.h
LIB_H += compat/bswap.h
LIB_H += compat/cygwin.h
@@ -730,6 +731,7 @@ LIB_OBJS += combine-diff.o
LIB_OBJS += color.o
LIB_OBJS += column.o
LIB_OBJS += combine-diff.o
+LIB_OBJS += commit-metapack.o
LIB_OBJS += commit.o
LIB_OBJS += compat/obstack.o
LIB_OBJS += compat/terminal.o
diff --git a/commit-metapack.c b/commit-metapack.c
new file mode 100644
index 000..2c19f48
--- /dev/null
+++ b/commit-metapack.c
@@ -0,0 +1,175 @@
+#include cache.h
+#include commit-metapack.h
+#include metapack.h
+#include commit.h
+#include sha1-lookup.h
+
+struct commit_metapack {
+ struct metapack mp;
+ uint32_t nr;
+ unsigned char *index;
+ unsigned char *data;
+ struct commit_metapack *next;
+};
+static struct commit_metapack *commit_metapacks;
+
+static struct commit_metapack *alloc_commit_metapack(struct packed_git *pack)
+{
+ struct commit_metapack *it = xcalloc(1, sizeof(*it));
+ uint32_t version;
+
+ if (metapack_init(it-mp, pack, commits, version) 0) {
+ free(it);
+ return NULL;
+ }
+ if (version != 1) {
+ /*
+* This file comes from a more recent git version. Don't bother
+* warning the user, as we'll just fallback to reading the
+* commits.
+*/
+ metapack_close(it-mp);
+ free(it);
+ return NULL;
+ }
+
+ if (it-mp.len 4) {
+ warning(commit metapack for '%s' is truncated,
pack-pack_name);
+ metapack_close(it-mp);
+ free(it);
+ return NULL;
+ }
+ memcpy(it-nr, it-mp.data, 4);
+ it-nr = ntohl(it-nr);
+
+ /*
+* We need 84 bytes for each entry: sha1(20), date(4), tree(20),
+* parents(40).
+*/
+ if (it-mp.len (84 * it-nr + 4)) {
+ warning(commit metapack for '%s' is truncated,
pack-pack_name);
+ metapack_close(it-mp);
+ free(it);
+ return NULL;
+ }
+
+ it-index = it-mp.data + 4;
+ it-data = it-index + 20 * it-nr;
+
+ return it;
+}
+
+static void prepare_commit_metapacks(void)
+{
+ static int initialized;
+ struct commit_metapack **tail = commit_metapacks;
+ struct packed_git *p;
+
+ if (initialized)
+ return;
+
+ prepare_packed_git();
+ for (p = packed_git; p; p = p-next) {
+ struct commit_metapack *it = alloc_commit_metapack(p);
+
+ if (it) {
+ *tail = it;
+ tail = it-next;
+ }
+ }
+
+ initialized = 1;
+}
+
+int commit_metapack(unsigned char *sha1,
+ uint32_t *timestamp,
+ unsigned char **tree,
+ unsigned char **parent1,
+ unsigned char **parent2)
+{
+ struct commit_metapack *p;
+
+ prepare_commit_metapacks();
+ for (p = commit_metapacks; p; p = p-next) {
+ unsigned char *data;
+ int pos = sha1_entry_pos(p-index, 20, 0, 0, p-nr, p-nr,
sha1);
+ if (pos 0)
+ continue;
+
+ /* timestamp(4) + tree(20) + parents(40) */
+ data = p-data + 64 * pos;
+ *timestamp = *(uint32_t *)data;
+ *timestamp = ntohl(*timestamp);
+ data += 4;
+ *tree = data;
+ data += 20;
+ *parent1 = data;
+ data += 20;
+ *parent2 = data;
+
+ return 0;
+ }
+
+ return -1;
+}
+
+static void get_commits(struct metapack_writer *mw,
+ const unsigned char *sha1,
+ void *data)
+{
+ struct commit_list ***tail = data;
+ enum object_type type = sha1_object_info(sha1, NULL);
+ struct commit *c;
+
+ if (type != OBJ_COMMIT)
+ return;
+
+ c =
[PATCH 5/6] add git-metapack command
This is a plumbing command for generating metapack files.
Right now it understands only the commits metapack (and
there is not yet a reader). Eventually we may want to build
this metapack automatically when we generate a new pack.
Let's be conservative for now, though, and let the idea
prove itself in practice before turning it on for everyone.
The commits metapack generated by this command is 84 bytes
per commit; for linux-2.6.git, this is about 31M.
TODO: documentation
Signed-off-by: Jeff King p...@peff.net
---
.gitignore | 1 +
Makefile | 1 +
builtin.h | 1 +
builtin/metapack.c | 73 ++
git-repack.sh | 2 +-
git.c | 1 +
6 files changed, 78 insertions(+), 1 deletion(-)
create mode 100644 builtin/metapack.c
diff --git a/.gitignore b/.gitignore
index 6669bf0..3f67a36 100644
--- a/.gitignore
+++ b/.gitignore
@@ -93,6 +93,7 @@
/git-merge-subtree
/git-mergetool
/git-mergetool--lib
+/git-metapack
/git-mktag
/git-mktree
/git-name-rev
diff --git a/Makefile b/Makefile
index 6ca5320..3899699 100644
--- a/Makefile
+++ b/Makefile
@@ -905,6 +905,7 @@ BUILTIN_OBJS += builtin/merge-tree.o
BUILTIN_OBJS += builtin/merge-ours.o
BUILTIN_OBJS += builtin/merge-recursive.o
BUILTIN_OBJS += builtin/merge-tree.o
+BUILTIN_OBJS += builtin/metapack.o
BUILTIN_OBJS += builtin/mktag.o
BUILTIN_OBJS += builtin/mktree.o
BUILTIN_OBJS += builtin/mv.o
diff --git a/builtin.h b/builtin.h
index faef559..30108ab 100644
--- a/builtin.h
+++ b/builtin.h
@@ -97,6 +97,7 @@ extern int cmd_merge_tree(int argc, const char **argv, const
char *prefix);
extern int cmd_merge_file(int argc, const char **argv, const char *prefix);
extern int cmd_merge_recursive(int argc, const char **argv, const char
*prefix);
extern int cmd_merge_tree(int argc, const char **argv, const char *prefix);
+extern int cmd_metapack(int argc, const char **argv, const char *prefix);
extern int cmd_mktag(int argc, const char **argv, const char *prefix);
extern int cmd_mktree(int argc, const char **argv, const char *prefix);
extern int cmd_mv(int argc, const char **argv, const char *prefix);
diff --git a/builtin/metapack.c b/builtin/metapack.c
new file mode 100644
index 000..5fee6cf
--- /dev/null
+++ b/builtin/metapack.c
@@ -0,0 +1,73 @@
+#include builtin.h
+#include parse-options.h
+#include commit-metapack.h
+
+static const char *metapack_usage[] = {
+ N_(git metapack [options] packindex...),
+ NULL
+};
+
+#define METAPACK_COMMITS (10)
+
+static void metapack_one(const char *idx, int type)
+{
+ if (type METAPACK_COMMITS)
+ commit_metapack_write(idx);
+}
+
+static void metapack_all(int type)
+{
+ struct strbuf path = STRBUF_INIT;
+ size_t dirlen;
+ DIR *dh;
+ struct dirent *de;
+
+ strbuf_addstr(path, get_object_directory());
+ strbuf_addstr(path, /pack);
+ dirlen = path.len;
+
+ dh = opendir(path.buf);
+ if (!dh)
+ die_errno(unable to open pack directory '%s', path.buf);
+ while ((de = readdir(dh))) {
+ if (!has_extension(de-d_name, .idx))
+ continue;
+
+ strbuf_addch(path, '/');
+ strbuf_addstr(path, de-d_name);
+ metapack_one(path.buf, type);
+ strbuf_setlen(path, dirlen);
+ }
+
+ closedir(dh);
+ strbuf_release(path);
+}
+
+int cmd_metapack(int argc, const char **argv, const char *prefix)
+{
+ int all = 0;
+ int type = 0;
+ struct option opts[] = {
+ OPT_BOOL(0, all, all, N_(create metapacks for all packs)),
+ OPT_BIT(0, commits, type, N_(create commit metapacks),
+ METAPACK_COMMITS),
+ OPT_END()
+ };
+
+ argc = parse_options(argc, argv, prefix, opts, metapack_usage, 0);
+
+ if (all argc)
+ usage_msg_opt(_(pack arguments do not make sense with --all),
+ metapack_usage, opts);
+ if (!type)
+ usage_msg_opt(_(no metapack type specified),
+ metapack_usage, opts);
+
+ if (all)
+ metapack_all(type);
+ else
+ for (; *argv; argv++)
+ metapack_one(*argv, type);
+
+ return 0;
+}
diff --git a/git-repack.sh b/git-repack.sh
index 7579331..e6a9773 100755
--- a/git-repack.sh
+++ b/git-repack.sh
@@ -180,7 +180,7 @@ then
do
case $fullbases in
* $e *) ;;
- *) rm -f $e.pack $e.idx $e.keep ;;
+ *) rm -f $e.pack $e.idx $e.keep
$e.commits;;
esac
done
)
diff --git a/git.c b/git.c
index b10c18b..f6e5552 100644
--- a/git.c
+++ b/git.c
@@ -365,6 +365,7 @@ static void handle_internal_command(int argc, const char
**argv)
[PATCH 6/6] commit: look up commit info in metapack
Now that we have the plumbing in place to generate and read
commit metapacks, we can hook them up to parse_commit to
fill in the traversal information much more quickly.
We only do so if save_commit_buffer is turned off;
otherwise, the callers will expect to be able to read
commit-buffer after parse_commit returns (and since our
cache obviously does not have that information, we must
leave it NULL). As callers learn to handle a NULL
commit-buffer, we can eventually relax this (while it might
seem like a useless no-op to use the cache if we are going
to load the commit anyway, many callers may first filter
based on the traversal, and end up loading the commit
message for only a subset of the commits).
With this patch (and having run git metapack --all
--commits), my best-of-five warm-cache git rev-list
--count --all traversal of linux-2.6.git drops from 4.219s
to 0.659s.
Similarly, cold-cache drops from 13.696s to 4.763s due to
the compactness of the cache data (but you are penalized, of
course, if you then want to actually look at the commit
messages, since you have not warmed them into the cache).
Signed-off-by: Jeff King p...@peff.net
---
commit.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/commit.c b/commit.c
index e8eb0ae..b326201 100644
--- a/commit.c
+++ b/commit.c
@@ -8,6 +8,7 @@
#include notes.h
#include gpg-interface.h
#include mergesort.h
+#include commit-metapack.h
static struct commit_extra_header *read_commit_extra_header_lines(const char
*buf, size_t len, const char **);
@@ -306,6 +307,24 @@ int parse_commit_buffer(struct commit *item, const void
*buffer, unsigned long s
return 0;
}
+static int parse_commit_metapack(struct commit *item)
+{
+ unsigned char *tree, *p1, *p2;
+ uint32_t ts;
+
+ if (commit_metapack(item-object.sha1, ts, tree, p1, p2) 0)
+ return -1;
+
+ item-date = ts;
+ item-tree = lookup_tree(tree);
+ commit_list_insert(lookup_commit(p1), item-parents);
+ if (!is_null_sha1(p2))
+ commit_list_insert(lookup_commit(p2), item-parents-next);
+
+ item-object.parsed = 1;
+ return 0;
+}
+
int parse_commit(struct commit *item)
{
enum object_type type;
@@ -317,6 +336,10 @@ int parse_commit(struct commit *item)
return -1;
if (item-object.parsed)
return 0;
+
+ if (!save_commit_buffer !parse_commit_metapack(item))
+ return 0;
+
buffer = read_sha1_file(item-object.sha1, type, size);
if (!buffer)
return error(Could not read %s,
--
1.8.0.2.16.g72e2fc9
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] strbuf: add string-chomping functions
On 01/29/2013 10:15 AM, Jeff King wrote:
Sometimes it is handy to cut a trailing string off the end
of a strbuf (e.g., a file extension). These helper functions
make it a one-liner.
Signed-off-by: Jeff King p...@peff.net
---
strbuf.c | 11 +++
strbuf.h | 2 ++
2 files changed, 13 insertions(+)
diff --git a/strbuf.c b/strbuf.c
index 9a373be..8199ced 100644
--- a/strbuf.c
+++ b/strbuf.c
@@ -106,6 +106,17 @@ void strbuf_ltrim(struct strbuf *sb)
sb-buf[sb-len] = '\0';
}
+void strbuf_chompmem(struct strbuf *sb, const void *data, size_t len)
+{
+ if (sb-len = len !memcmp(data, sb-buf + sb-len - len, len))
+ strbuf_setlen(sb, sb-len - len);
+}
+
+void strbuf_chompstr(struct strbuf *sb, const char *str)
+{
+ strbuf_chompmem(sb, str, strlen(str));
+}
+
struct strbuf **strbuf_split_buf(const char *str, size_t slen,
int terminator, int max)
{
diff --git a/strbuf.h b/strbuf.h
index ecae4e2..3aeb815 100644
--- a/strbuf.h
+++ b/strbuf.h
@@ -42,6 +42,8 @@ extern void strbuf_ltrim(struct strbuf *);
extern void strbuf_trim(struct strbuf *);
extern void strbuf_rtrim(struct strbuf *);
extern void strbuf_ltrim(struct strbuf *);
+extern void strbuf_chompmem(struct strbuf *, const void *, size_t);
+extern void strbuf_chompstr(struct strbuf *, const char *);
extern int strbuf_cmp(const struct strbuf *, const struct strbuf *);
/*
It might be handy to have these functions return true/false based on
whether the suffix was actually found.
Please document the new functions in
Documentation/technical/api-strbuf.txt. Personally I would also
advocate a docstring in the header file, but obviously that preference
is the exception rather than the rule in the git project :-(
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 4/6] introduce a commit metapack
On 01/29/2013 10:16 AM, Jeff King wrote: When we are doing a commit traversal that does not need to look at the commit messages themselves (e.g., rev-list, merge-base, etc), we spend a lot of time accessing, decompressing, and parsing the commit objects just to find the parent and timestamp information. We can make a space-time tradeoff by caching that information on disk in a compact, uncompressed format. TODO: document on-disk format in Documentation/technical TODO: document API Would this be a good place to add the commit generation number that is so enthusiastically discussed on the mailing list from time to time? 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
[PATCH] README: fix broken mailing list archive link
marc.theaimsgroup.com does not exist anymore, so replace it with a link to the archive on GMane. Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- README |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README b/README index 49713ea..3aae16a 100644 --- a/README +++ b/README @@ -47,8 +47,8 @@ requests, comments and patches to git@vger.kernel.org (read Documentation/SubmittingPatches for instructions on patch submission). To subscribe to the list, send an email with just subscribe git in the body to majord...@vger.kernel.org. The mailing list archives are -available at http://marc.theaimsgroup.com/?l=git and other archival -sites. +available at http://thread.gmane.org/gmane.comp.version-control.git/ +and other archival sites. The messages titled A note from the maintainer, What's in git.git (stable) and What's cooking in git.git (topics) and -- 1.7.10.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] gitk-git/.gitignore: add rule for gitk-wish
8f26aa4 (Makefile: remove tracking of TCLTK_PATH, 2012-12-18) removed /gitk-git/gitk-wish from the toplevel .gitignore, with the intent of moving it to gitk-git/.gitignore in a later patch. This was never realized. Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- Minor patch, so I didn't bother sending it through Paul. gitk-git/.gitignore |1 + 1 file changed, 1 insertion(+) create mode 100644 gitk-git/.gitignore diff --git a/gitk-git/.gitignore b/gitk-git/.gitignore new file mode 100644 index 000..1dc38be --- /dev/null +++ b/gitk-git/.gitignore @@ -0,0 +1 @@ +/gitk-wish -- 1.7.10.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: [PATCH 0/2] optimizing pack access on read only fetch repos
On Sun, Jan 27, 2013 at 1:32 PM, Junio C Hamano gits...@pobox.com wrote: I also wonder if we would be helped by another repack mode that coalesces small packs into a single one with minimum overhead, and run that often from gc --auto, so that we do not end up having to have 50 packfiles. When we have 2 or more small and young packs, we could: - iterate over idx files for these packs to enumerate the objects to be packed, replacing read_object_list_from_stdin() step; - always choose to copy the data we have in these existing packs, instead of doing a full prepare_pack(); and - use the order the objects appear in the original packs, bypassing compute_write_order(). Isn't it easier and cheaper to create the master index, something like bup does? -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] strbuf: add string-chomping functions
On Tue, Jan 29, 2013 at 11:15:34AM +0100, Michael Haggerty wrote:
+void strbuf_chompmem(struct strbuf *sb, const void *data, size_t len)
+{
+ if (sb-len = len !memcmp(data, sb-buf + sb-len - len, len))
+ strbuf_setlen(sb, sb-len - len);
+}
+
+void strbuf_chompstr(struct strbuf *sb, const char *str)
+{
+ strbuf_chompmem(sb, str, strlen(str));
+}
+
It might be handy to have these functions return true/false based on
whether the suffix was actually found.
Yeah, that sounds reasonable.
Please document the new functions in
Documentation/technical/api-strbuf.txt. Personally I would also
advocate a docstring in the header file, but obviously that preference
is the exception rather than the rule in the git project :-(
Will do. I need to document the metapack functions, too, so I was thinking
about experimenting with some inline documentation systems.
-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 4/6] introduce a commit metapack
On Tue, Jan 29, 2013 at 11:24:45AM +0100, Michael Haggerty wrote: On 01/29/2013 10:16 AM, Jeff King wrote: When we are doing a commit traversal that does not need to look at the commit messages themselves (e.g., rev-list, merge-base, etc), we spend a lot of time accessing, decompressing, and parsing the commit objects just to find the parent and timestamp information. We can make a space-time tradeoff by caching that information on disk in a compact, uncompressed format. TODO: document on-disk format in Documentation/technical TODO: document API Would this be a good place to add the commit generation number that is so enthusiastically discussed on the mailing list from time to time? Yes, that is one of my goals. We may even be able to just replace the timestamp field in the cache with a generation number. When it gets pretty-printed we pull it out of the commit message again anyway, so in theory the only use inside struct commit is for ordering. But I haven't looked at all of the use sites yet to be sure nobody is depending on it being an actual date stamp. -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 v2 0/4] Auto-generate mergetool lists
John Keeping wrote:
On Mon, Jan 28, 2013 at 01:50:19PM -0800, Junio C Hamano wrote:
What are the situations where a valid user-defined tools is
unavailable, by the way?
The same as a built-in tool: the command isn't available.
Currently I'm extracting the command word using:
cmd=$(eval -- set -- $(git config mergetool.$tool.cmd); echo
\$1\)
Shouldnt this work?
cmd=$((git config mergetool.$tool.cmd || git config difftool.$tool.cmd)
| awk '{print $1}')
(it's slightly more complicated due to handling difftool.$tool.cmd as
well, but that's essentially it). Then it just uses the same type
$cmd test as for built-in tools.
I don't know if there's a better way to extract the first word, but
that's the best I've come up with so far.
John
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/4] Auto-generate mergetool lists
On Tue, Jan 29, 2013 at 12:56:58PM +0100, Joachim Schmitz wrote:
John Keeping wrote:
Currently I'm extracting the command word using:
cmd=$(eval -- set -- $(git config mergetool.$tool.cmd); echo
\$1\)
Shouldnt this work?
cmd=$((git config mergetool.$tool.cmd || git config difftool.$tool.cmd)
| awk '{print $1}')
That doesn't handle paths with spaces in, whereas the eval in a subshell
does:
$ cmd='my command $BASE $LOCAL $REMOTE'
$ echo $cmd | awk '{print $1}'
my
$ ( eval -- set -- $cmd; echo \\$1\ )
my command
John
--
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] status: show branch name if possible in in-progress info
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- Seems like a good thing to do. t/t7512-status-help.sh | 36 +++ wt-status.c| 58 ++ wt-status.h| 1 + 3 files changed, 68 insertions(+), 27 deletions(-) diff --git a/t/t7512-status-help.sh b/t/t7512-status-help.sh index b3f6eb9..096ba6f 100755 --- a/t/t7512-status-help.sh +++ b/t/t7512-status-help.sh @@ -76,7 +76,7 @@ test_expect_success 'status when rebase in progress before resolving conflicts' test_must_fail git rebase HEAD^ --onto HEAD^^ cat expected -\EOF # Not currently on any branch. - # You are currently rebasing. + # You are currently rebasing '\''rebase_conflicts'\''. # (fix conflicts and then run git rebase --continue) # (use git rebase --skip to skip this patch) # (use git rebase --abort to check out the original branch) @@ -102,7 +102,7 @@ test_expect_success 'status when rebase in progress before rebase --continue' ' git add main.txt cat expected -\EOF # Not currently on any branch. - # You are currently rebasing. + # You are currently rebasing '\''rebase_conflicts'\''. # (all conflicts fixed: run git rebase --continue) # # Changes to be committed: @@ -133,7 +133,7 @@ test_expect_success 'status during rebase -i when conflicts unresolved' ' test_must_fail git rebase -i rebase_i_conflicts cat expected -\EOF # Not currently on any branch. - # You are currently rebasing. + # You are currently rebasing '\''rebase_i_conflicts_second'\''. # (fix conflicts and then run git rebase --continue) # (use git rebase --skip to skip this patch) # (use git rebase --abort to check out the original branch) @@ -158,7 +158,7 @@ test_expect_success 'status during rebase -i after resolving conflicts' ' git add main.txt cat expected -\EOF # Not currently on any branch. - # You are currently rebasing. + # You are currently rebasing '\''rebase_i_conflicts_second'\''. # (all conflicts fixed: run git rebase --continue) # # Changes to be committed: @@ -185,7 +185,7 @@ test_expect_success 'status when rebasing -i in edit mode' ' git rebase -i HEAD~2 cat expected -\EOF # Not currently on any branch. - # You are currently editing a commit during a rebase. + # You are currently editing a commit while rebasing '\''rebase_i_edit'\''. # (use git commit --amend to amend the current commit) # (use git rebase --continue once you are satisfied with your changes) # @@ -210,7 +210,7 @@ test_expect_success 'status when splitting a commit' ' git reset HEAD^ cat expected -\EOF # Not currently on any branch. - # You are currently splitting a commit during a rebase. + # You are currently splitting a commit while rebasing '\''split_commit'\''. # (Once your working directory is clean, run git rebase --continue) # # Changes not staged for commit: @@ -240,7 +240,7 @@ test_expect_success 'status after editing the last commit with --amend during a git commit --amend -m foo cat expected -\EOF # Not currently on any branch. - # You are currently editing a commit during a rebase. + # You are currently editing a commit while rebasing '\''amend_last'\''. # (use git commit --amend to amend the current commit) # (use git rebase --continue once you are satisfied with your changes) # @@ -269,7 +269,7 @@ test_expect_success 'status: (continue first edit) second edit' ' git rebase --continue cat expected -\EOF # Not currently on any branch. - # You are currently editing a commit during a rebase. + # You are currently editing a commit while rebasing '\''several_edits'\''. # (use git commit --amend to amend the current commit) # (use git rebase --continue once you are satisfied with your changes) # @@ -290,7 +290,7 @@ test_expect_success 'status: (continue first edit) second edit and split' ' git reset HEAD^ cat expected -\EOF # Not currently on any branch. - # You are currently splitting a commit during a rebase. + # You are currently splitting a commit while rebasing '\''several_edits'\''. # (Once your working directory is clean, run git rebase --continue) # # Changes not staged for commit: @@ -316,7 +316,7 @@ test_expect_success 'status: (continue first edit) second edit and amend' ' git commit --amend -m foo cat expected -\EOF # Not currently on any branch. - # You are currently editing a commit during a rebase. + # You are currently editing a commit while
[PATCH] branch: show (rebasing) or (bisecting) instead of (no branch) when possible
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
In the spirit of status' in-progress info. I think showing this is
more useful than (no branch). I tend to do git br more often than
git st and this catches my eyes.
builtin/branch.c| 10 +-
t/t6030-bisect-porcelain.sh | 2 +-
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/builtin/branch.c b/builtin/branch.c
index 873f624..b0c5a20 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -557,7 +557,15 @@ static void show_detached(struct ref_list *ref_list)
if (head_commit is_descendant_of(head_commit,
ref_list-with_commit)) {
struct ref_item item;
- item.name = xstrdup(_((no branch)));
+ struct stat st;
+ if ((!stat(git_path(rebase-apply), st)
+stat(git_path(rebase-apply/applying), st)) ||
+ !stat(git_path(rebase-merge), st))
+ item.name = xstrdup(_((rebasing)));
+ else if (!stat(git_path(BISECT_LOG), st))
+ item.name = xstrdup(_((bisecting)));
+ else
+ item.name = xstrdup(_((no branch)));
item.width = utf8_strwidth(item.name);
item.kind = REF_LOCAL_BRANCH;
item.dest = NULL;
diff --git a/t/t6030-bisect-porcelain.sh b/t/t6030-bisect-porcelain.sh
index 3e0e15f..bc21bc9 100755
--- a/t/t6030-bisect-porcelain.sh
+++ b/t/t6030-bisect-porcelain.sh
@@ -164,7 +164,7 @@ test_expect_success 'bisect start: existing
.git/BISECT_START not modified if
cp .git/BISECT_START saved
test_must_fail git bisect start $HASH4 foo --
git branch branch.output
- test_i18ngrep * (no branch) branch.output /dev/null
+ test_i18ngrep * (bisecting) branch.output /dev/null
test_cmp saved .git/BISECT_START
'
test_expect_success 'bisect start: no .git/BISECT_START if mistaken rev' '
--
1.8.1.1.459.g5970e58
--
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] status: show branch name if possible in in-progress info
I like the idea.
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
diff --git a/t/t7512-status-help.sh b/t/t7512-status-help.sh
index b3f6eb9..096ba6f 100755
--- a/t/t7512-status-help.sh
+++ b/t/t7512-status-help.sh
@@ -76,7 +76,7 @@ test_expect_success 'status when rebase in progress before
resolving conflicts'
test_must_fail git rebase HEAD^ --onto HEAD^^
cat expected -\EOF
# Not currently on any branch.
- # You are currently rebasing.
+ # You are currently rebasing '\''rebase_conflicts'\''.
Perhaps rebasing *branch* 'rebase_conflicts'
Or even rebasing branch 'rebase_conflicts' on sha1sum
?
@@ -923,7 +947,7 @@ static void show_bisect_in_progress(struct wt_status *s,
struct wt_status_state *state,
const char *color)
{
- status_printf_ln(s, color, _(You are currently bisecting.));
+ status_printf_ln(s, color, _(You are currently bisecting '%s'.),
state-branch);
if (advice_status_hints)
status_printf_ln(s, color,
_( (use \git bisect reset\ to get back to the
original branch)));
In the rebase case, you test state-branch for null-ness. Don't you
need the same test here? (What happens if you start a bisect from a
detached HEAD state?)
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] status: show branch name if possible in in-progress info
Duy Nguyen pclo...@gmail.com writes: On Tue, Jan 29, 2013 at 7:31 PM, Matthieu Moy matthieu@grenoble-inp.fr wrote: I like the idea. Nguyễn Thái Ngọc Duy pclo...@gmail.com writes: diff --git a/t/t7512-status-help.sh b/t/t7512-status-help.sh index b3f6eb9..096ba6f 100755 --- a/t/t7512-status-help.sh +++ b/t/t7512-status-help.sh @@ -76,7 +76,7 @@ test_expect_success 'status when rebase in progress before resolving conflicts' test_must_fail git rebase HEAD^ --onto HEAD^^ cat expected -\EOF # Not currently on any branch. - # You are currently rebasing. + # You are currently rebasing '\''rebase_conflicts'\''. Perhaps rebasing *branch* 'rebase_conflicts' Looks good. One minor thing, if the ref happens to be refs/somewhere-not-in-heads, should we still say rebasing branch 'refs/...' or just rebasing 'refs/...', or something else? I think this should not happen, since HEAD can either point to a branch or directly to a sha1 in normal conditions. But it doesn't harm to be defensive, in case ... Or even rebasing branch 'rebase_conflicts' on sha1sum sha1sum being SHA-1 of HEAD? Not HEAD, but .git/rebase-merge/onto, i.e. the target of the rebase. Ideally, I would have loved to see rebasing master on origin/master, but I do not think the target ref name is stored during rebase. Why would you need it? The typical use-case is starting a rebase, do something else, come back the day after and wonder wft. Which branch is being rebased is probably the most useful, but the target may help too. But I can live without ;-). In short version, not full SHA-1? If you add it, the short one (long version would make overly long line with limited use). -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] status: show the branch name if possible in in-progress info
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- - fix bisecting on detached HEAD - show onto sha-1 for rebase t/t7512-status-help.sh | 36 ++-- wt-status.c| 91 ++ wt-status.h| 2 ++ 3 files changed, 105 insertions(+), 24 deletions(-) diff --git a/t/t7512-status-help.sh b/t/t7512-status-help.sh index b3f6eb9..67ece6b 100755 --- a/t/t7512-status-help.sh +++ b/t/t7512-status-help.sh @@ -76,7 +76,7 @@ test_expect_success 'status when rebase in progress before resolving conflicts' test_must_fail git rebase HEAD^ --onto HEAD^^ cat expected -\EOF # Not currently on any branch. - # You are currently rebasing. + # You are currently rebasing branch '\''rebase_conflicts'\'' on '\''000106f'\''. # (fix conflicts and then run git rebase --continue) # (use git rebase --skip to skip this patch) # (use git rebase --abort to check out the original branch) @@ -102,7 +102,7 @@ test_expect_success 'status when rebase in progress before rebase --continue' ' git add main.txt cat expected -\EOF # Not currently on any branch. - # You are currently rebasing. + # You are currently rebasing branch '\''rebase_conflicts'\'' on '\''000106f'\''. # (all conflicts fixed: run git rebase --continue) # # Changes to be committed: @@ -133,7 +133,7 @@ test_expect_success 'status during rebase -i when conflicts unresolved' ' test_must_fail git rebase -i rebase_i_conflicts cat expected -\EOF # Not currently on any branch. - # You are currently rebasing. + # You are currently rebasing branch '\''rebase_i_conflicts_second'\'' on '\''e0164e4'\''. # (fix conflicts and then run git rebase --continue) # (use git rebase --skip to skip this patch) # (use git rebase --abort to check out the original branch) @@ -158,7 +158,7 @@ test_expect_success 'status during rebase -i after resolving conflicts' ' git add main.txt cat expected -\EOF # Not currently on any branch. - # You are currently rebasing. + # You are currently rebasing branch '\''rebase_i_conflicts_second'\'' on '\''e0164e4'\''. # (all conflicts fixed: run git rebase --continue) # # Changes to be committed: @@ -185,7 +185,7 @@ test_expect_success 'status when rebasing -i in edit mode' ' git rebase -i HEAD~2 cat expected -\EOF # Not currently on any branch. - # You are currently editing a commit during a rebase. + # You are currently editing a commit while rebasing branch '\''rebase_i_edit'\'' on '\''f90e540'\''. # (use git commit --amend to amend the current commit) # (use git rebase --continue once you are satisfied with your changes) # @@ -210,7 +210,7 @@ test_expect_success 'status when splitting a commit' ' git reset HEAD^ cat expected -\EOF # Not currently on any branch. - # You are currently splitting a commit during a rebase. + # You are currently splitting a commit while rebasing branch '\''split_commit'\'' on '\''19b175e'\''. # (Once your working directory is clean, run git rebase --continue) # # Changes not staged for commit: @@ -240,7 +240,7 @@ test_expect_success 'status after editing the last commit with --amend during a git commit --amend -m foo cat expected -\EOF # Not currently on any branch. - # You are currently editing a commit during a rebase. + # You are currently editing a commit while rebasing branch '\''amend_last'\'' on '\''dd030b9'\''. # (use git commit --amend to amend the current commit) # (use git rebase --continue once you are satisfied with your changes) # @@ -269,7 +269,7 @@ test_expect_success 'status: (continue first edit) second edit' ' git rebase --continue cat expected -\EOF # Not currently on any branch. - # You are currently editing a commit during a rebase. + # You are currently editing a commit while rebasing branch '\''several_edits'\'' on '\''eb16a7e'\''. # (use git commit --amend to amend the current commit) # (use git rebase --continue once you are satisfied with your changes) # @@ -290,7 +290,7 @@ test_expect_success 'status: (continue first edit) second edit and split' ' git reset HEAD^ cat expected -\EOF # Not currently on any branch. - # You are currently splitting a commit during a rebase. + # You are currently splitting a commit while rebasing branch '\''several_edits'\'' on '\''eb16a7e'\''. # (Once your working directory is clean, run git rebase --continue) # # Changes not staged for commit: @@ -316,7 +316,7 @@ test_expect_success 'status:
Re: Updating shared ref from remote helper, or fetch hook
Hi Jed, all, On 28.01.2013, at 06:19, Jed Brown wrote: I'm working on an hg remote helper that uses git notes for the sha1 revision, so that git users can more easily refer to specific commits when communicating with hg users. For the record, I am also working on that very same thing; it is yet another git-remote-hg alternative, based on Felipe's code but with many improvements. You can find it here: https://github.com/buchuki/gitifyhg. Anyway, back to Jed's (and also my) question: Since there may be multiple concurrent fast-import streams, I write the notes to a private ref (refs/notes/hg-REMOTE), to be merged eventually using git notes --ref hg merge hg-REMOTE* There will never be conflicts because each hg commit translates to a unique git commit, thus even if multiple concurrent remotes process the same commit, the corresponding note will match. Unfortunately, I couldn't find a safe way to get this run after a fetch or clone. Of course I can ask the user to arrange to have this command run, but it would be a better interface to have it run automatically since it is a natural responsibility of the remote helper. Am I missing a way to do this or a viable alternative approach? One idea we (well, Jed :-) had when brain storming about this was that perhaps one could (or even should?) (ab)use the checkpoint feature for that. Basically, when the remote-helper is almost done with everything, issue a checkpoint command, to flush out everything we just imported to the HD. Then once this completed, we can perform the notes merge. The main remaining problem with that is: How would we know when the checkpoint actually completed? Any ideas? Perhaps a way to do that would be to make use of the new bidi-import remote helper capability -- if I understand it right, then this effectively connects the fast-import stdout to the stdin of the remote helper. Thus, if one were to follow the checkpoint by a progress command, then by waiting for that progress command's output to appear back on stdin, the remote helper could determine whether the import succeeded, and perform finalization actions (like merging notes, as in our case). Does that sound viable? Crazy? Anybody got better a idea? Cheers, Max-- 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 0/2] optimizing pack access on read only fetch repos
Jeff King p...@peff.net wrote: On Sat, Jan 26, 2013 at 10:32:42PM -0800, Junio C Hamano wrote: Both makes sense to me. I also wonder if we would be helped by another repack mode that coalesces small packs into a single one with minimum overhead, and run that often from gc --auto, so that we do not end up having to have 50 packfiles. When we have 2 or more small and young packs, we could: - iterate over idx files for these packs to enumerate the objects to be packed, replacing read_object_list_from_stdin() step; - always choose to copy the data we have in these existing packs, instead of doing a full prepare_pack(); and - use the order the objects appear in the original packs, bypassing compute_write_order(). I'm not sure. If I understand you correctly, it would basically just be concatenating packs without trying to do delta compression between the objects which are ending up in the same pack. So it would save us from having to do (up to) 50 binary searches to find an object in a pack, but would not actually save us much space. I would be interested to see the timing on how quick it is compared to a real repack, as the I/O that happens during a repack is non-trivial (although if you are leaving aside the big main pack, then it is probably not bad). But how do these somewhat mediocre concatenated packs get turned into real packs? Pack-objects does not consider deltas between objects in the same pack. And when would you decide to make a real pack? How do you know you have 50 young and small packs, and not 50 mediocre coalesced packs? If we are reconsidering repacking strategies, I would like to propose an approach that might be a more general improvement to repacking which would help in more situations. You could roll together any packs which are close in size, say within 50% of each other. With this strategy you will end up with files which are spread out by size exponentially. I implementated this strategy on top of the current gc script using keep files, it works fairly well: https://gerrit-review.googlesource.com/#/c/35215/3/contrib/git-exproll.sh This saves some time, but mostly it saves I/O when repacking regularly. I suspect that if this strategy were used in core git that further optimizations could be made to also reduce the repack time, but I don't know enough about repacking to know? We run it nightly on our servers, both write and read only mirrors. We us are a ratio of 5 currently to drastically reduce large repack file rollovers, -Martin -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2] git-multimail: a replacement for post-receive-email
On Sun, Jan 27, 2013 at 9:37 AM, Michael Haggerty mhag...@alum.mit.edu wrote: A while ago, I submitted an RFC for adding a new email notification script to contrib [1]. The reaction seemed favorable and it was suggested that the new script should replace post-receive-email rather than be added separately, ideally with some kind of migration support. I just want to say since I think this thread hasn't been getting the attention it deserves: I'm all for this. I've used git-multimail and it's a joy to configure and extend compared to the existing hacky shellscript. I'm not running it at $work yet because I still need to write some extensions for to port some of of our local hacks to the old shellscript over. I fully support replacing the existing mailing script with git-multimail, it's better in every way, and unlike the current script has an active maintainer. -- 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 0/2] optimizing pack access on read only fetch repos
Jeff King p...@peff.net writes: I also wonder if we would be helped by another repack mode that coalesces small packs into a single one with minimum overhead, and run that often from gc --auto, so that we do not end up having to have 50 packfiles. ... I'm not sure. If I understand you correctly, it would basically just be concatenating packs without trying to do delta compression between the objects which are ending up in the same pack. So it would save us from having to do (up to) 50 binary searches to find an object in a pack, but would not actually save us much space. The point is not about space. Disk is cheap, and it is not making it any worse than what happens to your target audience, that is a fetch-only repository with only gc --auto in it, where nobody passes -f to repack to cause recomputation of delta. What I was trying to seek was a way to reduce the runtime penalty we pay every time we run git in such a repository. - Object look-up cost will become log2(50*n) from 50*log2(n), which is about 50/log2(50) improvement; - System resource cost we incur by having to keep 50 file descriptors open and maintaining 50 mmap windows will reduce by 50 fold. - Anything else I missed? I would be interested to see the timing on how quick it is compared to a real repack,... Yes, that is what I meant by wonder if we would be helped by ;-) But how do these somewhat mediocre concatenated packs get turned into real packs? How do they get processed in a fetch-only repositories that sometimes run gc --auto today? By runninng repack -a -d -f occasionally, perhaps? At some point, you would need to run a repack that involves a real object-graph traversal that feeds you the paths for objects to obtain a reasonably compressed pack. We can inspect existing packs and guess a rough traversal order for commits, but for trees and blobs, you cannot unify existing delta chains from multiple packs effectively with data in the pack alone. -- 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] status: show branch name if possible in in-progress info
Matthieu Moy matthieu@grenoble-inp.fr writes: Not HEAD, but .git/rebase-merge/onto, i.e. the target of the rebase. Ideally, I would have loved to see rebasing master on origin/master, but I do not think the target ref name is stored during rebase. Perhaps do it with --format=%s then. It often is useless to know only the commit object name (or the branch name for that matter, as you wouldn't know what exact commit the branch tip happens to have) you are rebasing onto. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] The design of new pathspec features
Duy Nguyen pclo...@gmail.com writes: On Tue, Jan 29, 2013 at 11:35 AM, Duy Nguyen pclo...@gmail.com wrote: :(glob) magic = This magic is for people who want globbing. However, it does _not_ use the same matching mechanism the non-magic pathspec does today. It uses wildmatch(WM_PATHNAME), which basically means '*' does not match slashes and ** does. Global option --glob-pathspecs is added to add :(glob) to all pathspec. :(literal) magic overrides this global option. I forgot one thing. The current pathspec behavior, the pattern [a-z] would match a file named [a-z] (iow, wildcards are also considered literal characters). That sounds like a blatant bug to me (unless you are talking about literal case). We should fix it before we include it in any released version, I think. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] The design of new pathspec features
Junio C Hamano gits...@pobox.com writes: Duy Nguyen pclo...@gmail.com writes: On Tue, Jan 29, 2013 at 11:35 AM, Duy Nguyen pclo...@gmail.com wrote: :(glob) magic = This magic is for people who want globbing. However, it does _not_ use the same matching mechanism the non-magic pathspec does today. It uses wildmatch(WM_PATHNAME), which basically means '*' does not match slashes and ** does. Global option --glob-pathspecs is added to add :(glob) to all pathspec. :(literal) magic overrides this global option. I forgot one thing. The current pathspec behavior, the pattern [a-z] would match a file named [a-z] (iow, wildcards are also considered literal characters). That sounds like a blatant bug to me (unless you are talking about literal case). We should fix it before we include it in any released version, I think. Ah, no, I misread what you meant. Yes, historically when matching a path with a pattern a/b[c-d]/e, we tried to first literally match the path with it (this allows the path a/b[c-d]/e to match with the pattern), and if it did not match, used fnmatch(3) to allow a/bc/e to also match. This was an ugly hack to cope with the possiblity that such a funny path is actually used in projects. With :(literal) magic and its friends you are working into the system, the hack should disappear at the same time when you stop running fnmatch(3) without FNM_PATHNAME. That should happen no later than Git 2.0. But until then, we should keep matching both paths a/bc/e and a/b[c-d]/e with pattern a/b[c-d]/e, for backward compatibility. Sorry about the earlier confusion. -- 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] README: fix broken mailing list archive link
Ramkumar Ramachandra artag...@gmail.com writes: marc.theaimsgroup.com does not exist anymore, so replace it with a link to the archive on GMane. I think it has been at http://marc.info/?l=git for some time. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/4] Auto-generate mergetool lists
On Tue, Jan 29, 2013 at 08:15:15AM -0800, Junio C Hamano wrote:
With any backend that is non-trivial, it would not be unusual for
the *tool.cmd to look like:
[mergetool]
mytool = sh -c '
... some massaging to prepare the command line
... to run the real tool backend comes here, and
... then ...
my_real_tool $arg1 $arg2 ...
'
and you will end up detecting the presence of the shell, which is
not very useful.
I think it is perfectly fine to say you configured it, so it must
exist; it may fail when we try to run it but it is your problem.
It is simpler to explain and requires one less eval.
I think you're right. The even worse case from this point of view is if
you configure it as:
[mergetool]
mytool = 'f() {
... code to actually run the tool here ...
}; f $BASE $REMOTE $LOCAL $MERGED'
which results in a false unavailable rather than just a useless check.
John
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] introduce pack metadata cache files
Jeff King p...@peff.net writes:
+static void write_meta_header(struct metapack_writer *mw, const char *id,
+ uint32_t version)
+{
+ version = htonl(version);
+
+ sha1write(mw-out, META, 4);
+ sha1write(mw-out, \0\0\0\1, 4);
+ sha1write(mw-out, mw-pack-sha1, 20);
+ sha1write(mw-out, id, 4);
+ sha1write(mw-out, version, 4);
+}
It seems that you are very close to actually having a plumbing that
could also do the pack .idx files. Until/unless that can be done, I
am not sure how much benefit we would be getting from a file format
that records a subtype id and a generic META type, instead of
just a single id as the type ehader. But it is OK to use 8 extra
bytes if we can potentially gain something later.
Shouldn't id be validated with at least something like
if (strlen(id) 3)
die(Bad id: %s, id);
to catch a call
write_meta_header(mw, me, 47);
that will stuff 'm', 'e', NUL and the garbage the compiler/linker
combo has placed after that constant string in the 4-byte id field?
+void metapack_writer_init(struct metapack_writer *mw,
+ const char *pack_idx,
+ const char *name,
+ int version)
+{
+ struct strbuf path = STRBUF_INIT;
+
+ memset(mw, 0, sizeof(*mw));
+
+ mw-pack = add_packed_git(pack_idx, strlen(pack_idx), 1);
+ if (!mw-pack || open_pack_index(mw-pack))
+ die(unable to open packfile '%s', pack_idx);
+
+ strbuf_addstr(path, pack_idx);
+ strbuf_chompstr(path, .idx);
+ strbuf_addch(path, '.');
+ strbuf_addstr(path, name);
Your chompstr() does not even validate if the given name ends with
.idx, so this sounds like a glorified way to say
strbuf_splice(path, path-len - strlen(idx), strlen(idx),
name, strlen(name));
to me.
+ mw-path = strbuf_detach(path, NULL);
+
+ mw-out = create_meta_tmp();
+ write_meta_header(mw, name, version);
+}
+
+void metapack_writer_finish(struct metapack_writer *mw)
+{
+ const char *tmp = mw-out-name;
+
+ sha1close(mw-out, NULL, CSUM_FSYNC);
+ if (rename(tmp, mw-path))
+ die_errno(unable to rename temporary metapack file);
Who is responsible for running adjust_shared_perm()? The caller, or
this function?
--
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 4/6] introduce a commit metapack
Jeff King p...@peff.net writes:
+int commit_metapack(unsigned char *sha1,
+ uint32_t *timestamp,
+ unsigned char **tree,
+ unsigned char **parent1,
+ unsigned char **parent2)
+{
+ struct commit_metapack *p;
+
+ prepare_commit_metapacks();
+ for (p = commit_metapacks; p; p = p-next) {
+ unsigned char *data;
+ int pos = sha1_entry_pos(p-index, 20, 0, 0, p-nr, p-nr,
sha1);
This is a tangent, but isn't it about time to rip out the check for
GIT_USE_LOOKUP in find_pack_entry_one(), I wonder.
+ prepare_commit_metapacks();
+ for (p = commit_metapacks; p; p = p-next) {
+ unsigned char *data;
+ int pos = sha1_entry_pos(p-index, 20, 0, 0, p-nr, p-nr,
sha1);
+ if (pos 0)
+ continue;
+
+ /* timestamp(4) + tree(20) + parents(40) */
+ data = p-data + 64 * pos;
+ *timestamp = *(uint32_t *)data;
+ *timestamp = ntohl(*timestamp);
+ data += 4;
+ *tree = data;
+ data += 20;
+ *parent1 = data;
+ data += 20;
+ *parent2 = data;
+
+ return 0;
+ }
+
+ return -1;
+}
I am torn on this one.
These cached properties of a single commit will not change no matter
which pack it appears in, and it feels logically wrong, especially
when you record these object names in the full SHA-1 form, to tie a
commit metapack to a pack. Logically there needs only one commit
metapack that describes all the commits known to the repository when
the metapack was created.
In order to reduce the disk footprint and I/O cost, the future
direction for this mechanism may want to point into an existing
store of SHA-1 hashes with a shorter file offset, and the .idx file
could be such a store, and in order to move in that direction, you
cannot avoid tying a metapack to a pack.
+static void get_commits(struct metapack_writer *mw,
+ const unsigned char *sha1,
+ void *data)
+{
+ struct commit_list ***tail = data;
+ enum object_type type = sha1_object_info(sha1, NULL);
+ struct commit *c;
+
+ if (type != OBJ_COMMIT)
+ return;
+
+ c = lookup_commit(sha1);
+ if (!c || parse_commit(c))
+ die(unable to read commit %s, sha1_to_hex(sha1));
+
+ /*
+ * Our fixed-size parent list cannot represent root commits, nor
+ * octopus merges. Just skip those commits, as we can fallback
+ * in those rare cases to reading the actual commit object.
+ */
+ if (!c-parents ||
+ (c-parents c-parents-next c-parents-next-next))
+ return;
+
+ *tail = commit_list_insert(c, *tail)-next;
+}
It feels somewhat wasteful to:
- use commit_list for this, rather than an array of commit
objects. If you have a rough estimate of the number of commits
in the pack, you could just preallocate a single array and use
ALLOC_GROW() on it, no?
- iterate over the .idx file and run sha1_object_info() and
parse_commit() on many objects in the SHA-1 order. Iterating in
the way builtin/pack-objects.c::get_object_details() does avoids
jumping around in existing packfiles, which may be more
efficient, no?
+void commit_metapack_write(const char *idx)
+{
+ struct metapack_writer mw;
+ struct commit_list *commits = NULL, *p;
+ struct commit_list **tail = commits;
+ uint32_t nr = 0;
+
+ metapack_writer_init(mw, idx, commits, 1);
+
+ /* Figure out how many eligible commits we've got in this pack. */
+ metapack_writer_foreach(mw, get_commits, tail);
+ for (p = commits; p; p = p-next)
+ nr++;
--
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] README: fix broken mailing list archive link
Junio C Hamano wrote: Ramkumar Ramachandra artag...@gmail.com writes: marc.theaimsgroup.com does not exist anymore, so replace it with a link to the archive on GMane. I think it has been at http://marc.info/?l=git for some time. Isn't GMane what all of us refer to on the list though? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] README: fix broken mailing list archive link
Ramkumar Ramachandra artag...@gmail.com writes: Junio C Hamano wrote: Ramkumar Ramachandra artag...@gmail.com writes: marc.theaimsgroup.com does not exist anymore, so replace it with a link to the archive on GMane. I think it has been at http://marc.info/?l=git for some time. Isn't GMane what all of us refer to on the list though? Then your original log message is wrong, no? You earlier said that we should replace it because marc no longer exists. Now you are saying we replace it because we prefer gmane. I do not mind listing both, but I think we should limit the enumeration to the minimum and let and other archival sites cover the rest. -- 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] The images from picon and gravatar are always used over http://, and browsers give mixed contents warning when gitweb is served over https://.
Jonathan Nieder jrnie...@gmail.com writes:
Odd. https://www.gravatar.com/; also seems to work. I've put in a
technical support query to find out what the Gravatar admins prefer.
Thanks; will hold onto Andrej's patch until we hear what the story
is.
Of course we could do something like this (untested).
gitweb/gitweb.perl | 24 +++-
1 file changed, 19 insertions(+), 5 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index c6bafe6..b59773b 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -313,6 +313,14 @@ sub evaluate_uri {
'override' = 0,
'default' = [0]},
+ # Use https:// URL for embedded picons/gravatar images, to be used
+ # on installations that server gitweb over https://
+ 'subcontentssl' = {
+ 'sub' = sub { feature_bool('subcontentssl', @_) },
+ 'override' = 0,
+ 'default' = [0]},
+ }
+
# Enable the 'snapshot' link, providing a compressed archive of any
# tree. This can potentially generate high traffic if you have large
# project.
@@ -,6 +1119,7 @@ sub evaluate_git_dir {
}
our (@snapshot_fmts, $git_avatar);
+our ($gravatar_base_url, $picon_base_url);
sub configure_gitweb_features {
# list of supported snapshot formats
our @snapshot_fmts = gitweb_get_feature('snapshot');
@@ -1121,10 +1130,17 @@ sub configure_gitweb_features {
# if the provider name is invalid or the dependencies are not met,
# reset $git_avatar to the empty string.
our ($git_avatar) = gitweb_get_feature('avatar');
+ my $use_https = gitweb_check_feature('subcontentssl');
+
if ($git_avatar eq 'gravatar') {
$git_avatar = '' unless (eval { require Digest::MD5; 1; });
+ $gravatar_base_url = $use_https ?
+ https://secure.gravatar.com/avatar/; :
+ http://www.gravatar.com/avatar/;;
} elsif ($git_avatar eq 'picon') {
- # no dependencies
+ $picon_base_url = $use_https ?
+
http://www.cs.indiana.edu/cgi-pub/kinzler/piconsearch.cgi/; :
+
https://www.cs.indiana.edu/cgi-pub/kinzler/piconsearch.cgi/;;
} else {
$git_avatar = '';
}
@@ -2068,7 +2084,7 @@ sub picon_url {
if (!$avatar_cache{$email}) {
my ($user, $domain) = split('@', $email);
$avatar_cache{$email} =
-
http://www.cs.indiana.edu/cgi-pub/kinzler/piconsearch.cgi/; .
+ $picon_base_url .
$domain/$user/ .
users+domains+unknown/up/single;
}
@@ -2082,9 +2098,7 @@ sub picon_url {
sub gravatar_url {
my $email = lc shift;
my $size = shift;
- $avatar_cache{$email} ||=
- http://www.gravatar.com/avatar/; .
- Digest::MD5::md5_hex($email) . ?s=;
+ $avatar_cache{$email} ||= $gravatar_base_url .
Digest::MD5::md5_hex($email) . ?s=;
return $avatar_cache{$email} . $size;
}
--
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] status: show the branch name if possible in in-progress info
Hi Duy, Nguyễn Thái Ngọc Duy wrote: --- a/t/t7512-status-help.sh +++ b/t/t7512-status-help.sh @@ -76,7 +76,7 @@ test_expect_success 'status when rebase in progress before resolving conflicts' test_must_fail git rebase HEAD^ --onto HEAD^^ cat expected -\EOF # Not currently on any branch. - # You are currently rebasing. + # You are currently rebasing branch '\''rebase_conflicts'\'' on '\''000106f'\''. SHA1-in-tests radar blinking. Would it be possible to compute the expected output, as in dest=$(git rev-parse --short HEAD^^) cat expected -EOF # Not currently on any branch. # You are currently rebasing branch '\''rebase_conflicts'\'' on '\''$dest'\''. ? I'm not sure what to think about the actual change itself yet. Can you give an example of when you felt the need for this, so it can be included in the commit message or documentation? Thanks. Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] README: fix broken mailing list archive link
How about doing this instead, to update all outdated or incorrect information in that file? In addition to the marc.info update, - refer to gmane; - git-scm.org gives a CNAME with less commercial feeling to the same thing; - A note from the maintainer is not usually followed by useful discussion to discuss status, direction nor tasks; - There is no separate What's in git (stable/topics). README | 17 - 1 file changed, 8 insertions(+), 9 deletions(-) diff --git a/README b/README index 49713ea..5b83a9a 100644 --- a/README +++ b/README @@ -38,7 +38,7 @@ CVS users may also want to read Documentation/gitcvs-migration.txt (man gitcvs-migration or git help cvs-migration if git is installed). -Many Git online resources are accessible from http://git-scm.com/ +Many Git online resources are accessible from http://git-scm.org/ including full documentation and Git related tools. The user discussion and development of Git take place on the Git @@ -47,11 +47,10 @@ requests, comments and patches to git@vger.kernel.org (read Documentation/SubmittingPatches for instructions on patch submission). To subscribe to the list, send an email with just subscribe git in the body to majord...@vger.kernel.org. The mailing list archives are -available at http://marc.theaimsgroup.com/?l=git and other archival -sites. - -The messages titled A note from the maintainer, What's in -git.git (stable) and What's cooking in git.git (topics) and -the discussion following them on the mailing list give a good -reference for project status, development direction and -remaining tasks. +available at http://news.gmane.org/gmane.comp.version-control.git/, +http://marc.info/?l=git and other archival sites. + +The maintainer frequently sends the What's cooking reports that +list the current status of various development topics to the mailing +list. The discussion following them give a good reference for +project status, development direction and remaining tasks. -- 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: show (rebasing) or (bisecting) instead of (no branch) when possible
Nguyễn Thái Ngọc Duy wrote:
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
In the spirit of status' in-progress info. I think showing this is
more useful than (no branch). I tend to do git br more often than
git st and this catches my eyes.
Very nice idea. This would also have been a nice way to avoid
confusion when my officemate used bisect for the first time.
Any particular reason the above explanation is after the triple-dash
instead of before it?
[...]
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -557,7 +557,15 @@ static void show_detached(struct ref_list *ref_list)
if (head_commit is_descendant_of(head_commit,
ref_list-with_commit)) {
struct ref_item item;
- item.name = xstrdup(_((no branch)));
+ struct stat st;
+ if ((!stat(git_path(rebase-apply), st)
+ stat(git_path(rebase-apply/applying), st)) ||
+ !stat(git_path(rebase-merge), st))
Here's a straight translation of contrib/completion/prompt.sh for
comparison, skipping the cases that don't involve automatically
detaching HEAD:
if (!stat(git_path(rebase-merge), st) S_ISDIR(st.st_mode))
item.name = xstrdup(_((rebasing)));
else if (!access(git_path(rebase-apply/rebasing), F_OK))
item.name = xstrdup(_((rebasing)));
else if (!access(git_path(BISECT_LOG), F_OK))
item.name = xstrdup(_((bisecting)));
else
item.name = xstrdup(_((no branch)));
That would mean:
* using access() instead of stat() to avoid unnecessary work
* relying on rebase--am to write .git/rebase-apply/rebasing when
appropriate instead of guessing
Not important, though. :)
Jonathan
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] git-send-email: add ~/.authinfo parsing
From: Michal Nazarewicz min...@mina86.com
Make git-send-email read password from a ~/.authinfo file instead of
requiring it to be stored in git configuration, passed as command line
argument or typed in.
There are various other applications that use this file for
authentication information so letting users use it for git-send-email
is convinient. Furthermore, some users store their ~/.gitconfig file
in a public repository and having to store password there makes it
easy to publish the password.
Not to introduce any new dependencies, ~/.authinfo file is parsed only
if Text::CSV Perl module is installed. If it's not, a notification is
printed and the file is ignored.
Signed-off-by: Michal Nazarewicz min...@mina86.com
---
Documentation/git-send-email.txt | 15 +++--
git-send-email.perl | 69 +---
2 files changed, 70 insertions(+), 14 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index eeb561c..b83576e 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -158,14 +158,25 @@ Sending
--smtp-pass[=password]::
Password for SMTP-AUTH. The argument is optional: If no
argument is specified, then the empty string is used as
- the password. Default is the value of 'sendemail.smtppass',
- however '--smtp-pass' always overrides this value.
+ the password. Default is the value of 'sendemail.smtppass'
+ or value read from '~/.authinfo' file, however '--smtp-pass'
+ always overrides this value.
+
Furthermore, passwords need not be specified in configuration files
or on the command line. If a username has been specified (with
'--smtp-user' or a 'sendemail.smtpuser'), but no password has been
specified (with '--smtp-pass' or 'sendemail.smtppass'), then the
user is prompted for a password while the input is masked for privacy.
++
+The '~/.authinfo' file is read if Text::CSV Perl module is installed
+on the system; if it's missing, a notification message will be printed
+and the file ignored altogether. The file should contain a line with
+the following format:
++
+ machine domain port port login user password pass
++
+Contrary to other tools, 'git-send-email' does not support symbolic
+port names like 'imap' thus `port` must be a number.
--smtp-server=host::
If set, specifies the outgoing SMTP server to use (e.g.
diff --git a/git-send-email.perl b/git-send-email.perl
index be809e5..d824098 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -1045,6 +1045,62 @@ sub maildomain {
return maildomain_net() || maildomain_mta() || 'localhost.localdomain';
}
+
+sub read_password_from_stdin {
+ my $line;
+
+ system stty -echo;
+
+ do {
+ print Password: ;
+ $line = STDIN;
+ print \n;
+ } while (!defined $line);
+
+ system stty echo;
+
+ chomp $line;
+ return $line;
+}
+
+sub read_password_from_authinfo {
+ my $fd;
+ if (!open $fd, '', $ENV{'HOME'} . '/.authinfo') {
+ return;
+ }
+
+ if (!eval { require Text::CSV; 1 }) {
+ print STDERR Text::CSV missing, won't read ~/.authinfo\n;
+ close $fd;
+ return;
+ }
+
+ my $csv = Text::CSV-new( { sep_char = ' ' } );
+ my $password;
+ while (my $line = $fd) {
+ chomp $line;
+ $csv-parse($line);
+ my %row = $csv-fields();
+ if (defined $row{'machine'}
+ defined $row{'login'}
+ defined $row{'port'}
+ defined $row{'password'}
+ $row{'machine'} eq $smtp_server
+ $row{'login'} eq $smtp_authuser
+ $row{'port'} eq $smtp_server_port) {
+ $password = $row{'password'};
+ last;
+ }
+ }
+
+ close $fd;
+ return $password;
+}
+
+sub read_password {
+ return read_password_from_authinfo || read_password_from_stdin;
+}
+
# Returns 1 if the message was sent, and 0 otherwise.
# In actuality, the whole program dies when there
# is an error sending a message.
@@ -1194,18 +1250,7 @@ X-Mailer: git-send-email $gitversion
};
if (!defined $smtp_authpass) {
-
- system stty -echo;
-
- do {
- print Password: ;
- $_ = STDIN;
- print \n;
- } while (!defined $_);
-
- chomp($smtp_authpass = $_);
-
- system stty echo;
+ $smtp_authpass = read_password
}
$auth ||= $smtp-auth(
[RFC/PATCH v2] CodingGuidelines: add Python coding guidelines
These are kept short by simply deferring to PEP-8. Most of the Python code in Git is already very close to this style (some things in contrib/ are not). Rationale for version suggestions: - Amongst the noise in [1], there isn't any disagreement about using 2.6 as a base (see also [2]), although Brandon Casey recently added support for 2.4 and 2.5 to git-p4 [3]. - Restricting ourselves to 2.6+ makes aiming for Python 3 compatibility significantly easier [4]. - Advocating Python 3 support in all scripts is currently unrealistic because: - 'p4 -G' provides output in a format that is very hard to use with Python 3 (and its documentation claims Python 3 is unsupported). - Mercurial does not support Python 3. - Bazaar does not support Python 3. - But we should try to make new scripts compatible with Python 3 because all new Python development is happening on version 3 and the Python community will eventually stop supporting Python 2 [5]. - Python 3.1 is required to support the 'surrogateescape' error handler for encoding/decodng filenames to/from Unicode strings and Python 3.0 is not longer supported. [1] http://thread.gmane.org/gmane.comp.version-control.git/210329 [2] http://article.gmane.org/gmane.comp.version-control.git/210429 [3] http://thread.gmane.org/gmane.comp.version-control.git/214579 [4] http://docs.python.org/3.3/howto/pyporting.html#try-to-support-python-2-6-and-newer-only [5] http://www.python.org/dev/peps/pep-0404/ --- Changes since v1: - Set 3.1 as the minimum Python 3 version - Remove the section on Unicode literals - it just adds confusion and doesn't apply to the current code; we can deal with any issues if they ever arise. Documentation/CodingGuidelines | 13 + 1 file changed, 13 insertions(+) diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines index 69f7e9b..db7a416 100644 --- a/Documentation/CodingGuidelines +++ b/Documentation/CodingGuidelines @@ -179,6 +179,19 @@ For C programs: - Use Git's gettext wrappers to make the user interface translatable. See Marking strings for translation in po/README. +For Python scripts: + + - We follow PEP-8 (http://www.python.org/dev/peps/pep-0008/). + + - As a minimum, we aim to be compatible with Python 2.6 and 2.7. + + - Where required libraries do not restrict us to Python 2, we try to + also be compatible with Python 3.1 and later. + + - We use the 'b' prefix for bytes literals. Note that even though + the Python documentation for version 2.6 does not mention this + prefix it is supported since version 2.6.0. + Writing Documentation: Every user-visible change should be reflected in the documentation. -- 1.8.1.1.644.g4977e08 -- 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/4] mergetool--lib: Simplify command expressions
On Sun, Jan 27, 2013 at 04:52:23PM -0800, David Aguilar wrote:
Update variable assignments to always use $(command $arg)
in their RHS instead of $(command $arg) as the latter
is harder to read. Make get_merge_tool_cmd() simpler by
avoiding echo and $(command) substitutions completely.
Signed-off-by: David Aguilar dav...@gmail.com
---
@@ -300,9 +292,9 @@ get_merge_tool_path () {
fi
if test -z $merge_tool_path
then
- merge_tool_path=$(translate_merge_tool_path $merge_tool)
+ merge_tool_path=$(translate_merge_tool_path $merge_tool)
fi
- if test -z $(get_merge_tool_cmd $merge_tool)
+ if test -z $(get_merge_tool_cmd $merge_tool)
This change should be reverted to avoid calling test -z without any
other arguments, as Johannes pointed out in v1.
The rest of this patch looks good to me.
! type $merge_tool_path /dev/null 21
then
echo 2 The $TOOL_MODE tool $merge_tool is not available as\
--
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] README: fix broken mailing list archive link
Junio C Hamano wrote: - refer to gmane; GMane has a wonderful interface, and deserves to be advertised. - git-scm.org gives a CNAME with less commercial feeling to the same thing; Nice touch. - A note from the maintainer is not usually followed by useful discussion to discuss status, direction nor tasks; True. - There is no separate What's in git (stable/topics). Right. Looks good to me. 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: [RFC/PATCH v2] CodingGuidelines: add Python coding guidelines
John Keeping j...@keeping.me.uk writes: Changes since v1: - Set 3.1 as the minimum Python 3 version - Remove the section on Unicode literals - it just adds confusion and doesn't apply to the current code; we can deal with any issues if they ever arise. ... + - We use the 'b' prefix for bytes literals. Note that even though + the Python documentation for version 2.6 does not mention this + prefix it is supported since version 2.6.0. Do we still need to single out the 'b' prefix? Even if it were necessary, I'd like to see it toned down a bit to make it clear that most of the time you can write strings as strings without having to worry about the is it unicode string or a string string mess. Like - When you must make distinction between Unicode literals and byte string literals, it is OK to use 'b' prefix. Even though ... perhaps? -- 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
gitk doesn't always shows boths tags in gitk tag1..tag2
For a cloned BOINC git tree : $ git clone git://boinc.berkeley.edu/boinc.git the following 2 commands shows both starting and ending revisions : $ gitk client_release_7.0.41..client_release_7.0.42 $ gitk client_release_7.0.43..client_release_7.0.44 however this command doesn't show the tag client_release_7.0.44 : $ gitk client_release_7.0.44..client_release_7.0.45 Now I'm wondering whether this is a side effect of the developer model of BOINC or an issue in gitk ? -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/4] mergetool--lib: Add functions for finding available tools
On Sun, Jan 27, 2013 at 04:52:25PM -0800, David Aguilar wrote:
--- a/git-mergetool--lib.sh
+++ b/git-mergetool--lib.sh
@@ -2,6 +2,35 @@
# git-mergetool--lib is a library for common merge tool functions
MERGE_TOOLS_DIR=$(git --exec-path)/mergetools
+mode_ok () {
+ diff_mode can_diff ||
+ merge_mode can_merge
+}
+
+is_available () {
+ merge_tool_path=$(translate_merge_tool_path $1)
+ type $merge_tool_path /dev/null 21
+}
+
+show_tool_names () {
+ condition=${1:-true} per_line_prefix=${2:-} preamble=${3:-}
+
+ ( cd $MERGE_TOOLS_DIR ls -1 * ) |
Is the '*' necessary here? I would expect ls to list the current
directory if given no arguments, but perhaps some platforms behave
differently?
+ while read toolname
+ do
+ if setup_tool $toolname 2/dev/null
+ (eval $condition $toolname)
+ then
+ if test -n $preamble
+ then
+ echo $preamble
+ preamble=
+ fi
+ printf %s%s\n $per_line_prefix $tool
+ fi
+ done
+}
+
diff_mode() {
test $TOOL_MODE = diff
}
@@ -199,35 +228,21 @@ list_merge_tool_candidates () {
}
show_tool_help () {
- unavailable= available= LF='
-'
- for i in $MERGE_TOOLS_DIR/*
- do
- tool=$(basename $i)
- setup_tool $tool 2/dev/null || continue
-
- merge_tool_path=$(translate_merge_tool_path $tool)
- if type $merge_tool_path /dev/null 21
- then
- available=$available$tool$LF
- else
- unavailable=$unavailable$tool$LF
- fi
- done
-
- cmd_name=${TOOL_MODE}tool
+ tool_opt='git ${TOOL_MODE}tool --tool-tool'
+ available=$(show_tool_names 'mode_ok is_available' '\t\t' \
+ $tool_opt may be set to one of the following:)
+ unavailable=$(show_tool_names 'mode_ok ! is_available' '\t\t' \
+ The following tools are valid, but not currently available:)
if test -n $available
then
- echo 'git $cmd_name --tool=tool' may be set to one of the
following:
- echo $available | sort | sed -e 's/^/ /'
+ echo $available
else
echo No suitable tool for 'git $cmd_name --tool=tool' found.
fi
if test -n $unavailable
then
echo
- echo 'The following tools are valid, but not currently
available:'
- echo $unavailable | sort | sed -e 's/^/ /'
+ echo $unavailable
fi
if test -n $unavailable$available
then
You haven't taken full advantage of the simplification Junio suggested
in response to v1 here. We can change the unavailable block to be:
show_tool_names 'mode_ok ! is_available' $TAB$TAB \
${LF}The following tools are valid, but not currently available:
If you also add a not_found_msg parameter to show_tool_names then the
available case is also simplified:
show_tool_names 'mode_ok is_available' $TAB$TAB \
$tool_opt may be set to one of the following: \
No suitable tool for 'git $cmd_name --tool=tool' found.
with this at the end of show_tool_names:
test -n $preamble test -n $not_found_msg \
echo $not_found_msg
John
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-send-email: add ~/.authinfo parsing
Michal Nazarewicz m...@google.com writes: From: Michal Nazarewicz min...@mina86.com Make git-send-email read password from a ~/.authinfo file instead of requiring it to be stored in git configuration, passed as command line argument or typed in. Makes one wonder why .authinfo and not .netrc; http://www.gnu.org/software/emacs/manual/html_node/auth/Help-for-users.html phrases it amusingly: “Netrc” files are usually called .authinfo or .netr nowadays .authinfo seems to be more popular and the auth-source library encourages this confusion by accepting both Either way it still encourages a plaintext password to be on disk, which may not be what we want, even though it may be slight if not really much of an improvement. Again the Help-for-users has this amusing bit: You could just say (but we don't recommend it, we're just showing that it's possible) password mypassword to use the same password everywhere. Again, DO NOT DO THIS or you will be pwned as the kids say. +The '~/.authinfo' file is read if Text::CSV Perl module is installed +on the system; if it's missing, a notification message will be printed +and the file ignored altogether. The file should contain a line with +the following format: ++ + machine domain port port login user password pass It is rather strange to require a comma-separated-values parser to read a file format this simple, isn't it? ++ +Contrary to other tools, 'git-send-email' does not support symbolic +port names like 'imap' thus `port` must be a number. Perhaps you can convert at least some popular ones yourself? After all, the user may be using an _existing_ .authinfo/.netrc that she has been using with other programs that do understand symbolic port names. Rather than forcing all such users to update their files, the patch can work a bit harder for them and the world will be a better place, no? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH v2] CodingGuidelines: add Python coding guidelines
On Tue, Jan 29, 2013 at 11:34:31AM -0800, Junio C Hamano wrote: John Keeping j...@keeping.me.uk writes: Changes since v1: - Set 3.1 as the minimum Python 3 version - Remove the section on Unicode literals - it just adds confusion and doesn't apply to the current code; we can deal with any issues if they ever arise. ... + - We use the 'b' prefix for bytes literals. Note that even though + the Python documentation for version 2.6 does not mention this + prefix it is supported since version 2.6.0. Do we still need to single out the 'b' prefix? Even if it were necessary, I'd like to see it toned down a bit to make it clear that most of the time you can write strings as strings without having to worry about the is it unicode string or a string string mess. Like - When you must make distinction between Unicode literals and byte string literals, it is OK to use 'b' prefix. Even though ... perhaps? Yeah, that's better. I want to include it because if you look in the Python documentation then you'll be misled into thinking that it's not available on 2.6 and we will be supporting that for a while since it is the version included in RHEL 6. John -- 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: gitk doesn't always shows boths tags in gitk tag1..tag2
Hi Toralf, Toralf Förster wrote: $ git clone git://boinc.berkeley.edu/boinc.git the following 2 commands shows both starting and ending revisions : $ gitk client_release_7.0.41..client_release_7.0.42 gitk is running something similar to git log --graph --decorate --boundary --oneline revs In this example, that means 7.0.41 is shown with an open circle because it is at the boundary of the requested commit set (it is not in that set and one of its children is). [...] however this command doesn't show the tag client_release_7.0.44 : $ gitk client_release_7.0.44..client_release_7.0.45 As you guessed, 7.0.45 seems to live in a different area of history. :) I don't know why it was built that way --- there may or may not be a good reason. gitk --simplify-by-decoration client_release_7.0.44...client_release_7.0.45 can help to compare the positions of the two tags in history. Thanks for a fun example. Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: gitk doesn't always shows boths tags in gitk tag1..tag2
On 01/29/2013 08:57 PM, Jonathan Nieder wrote: As you guessed, 7.0.45 seems to live in a different area of history. :) Well, seems be point to the root cause .. BTW $ gitk --simplify-by-decoration client_release_7.0.44..client_release_7.0.45 only 3 rows in the main window where $ gitk client_release_7.0.44..client_release_7.0.45 shows 468 rows. Thx for the quick answer :-) -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/4] mergetool--lib: Add functions for finding available tools
John Keeping j...@keeping.me.uk writes:
On Sun, Jan 27, 2013 at 04:52:25PM -0800, David Aguilar wrote:
--- a/git-mergetool--lib.sh
+++ b/git-mergetool--lib.sh
@@ -2,6 +2,35 @@
# git-mergetool--lib is a library for common merge tool functions
MERGE_TOOLS_DIR=$(git --exec-path)/mergetools
+mode_ok () {
+diff_mode can_diff ||
+merge_mode can_merge
+}
+
+is_available () {
+merge_tool_path=$(translate_merge_tool_path $1)
+type $merge_tool_path /dev/null 21
+}
+
+show_tool_names () {
+condition=${1:-true} per_line_prefix=${2:-} preamble=${3:-}
+
+( cd $MERGE_TOOLS_DIR ls -1 * ) |
Is the '*' necessary here?
No, it was just from a bad habit (I have ls aliased to ls -A or ls
-a in my interactive environment, which trained my fingers to this).
I also think you can lose -1, although it does not hurt.
+tool_opt='git ${TOOL_MODE}tool --tool-tool'
+available=$(show_tool_names 'mode_ok is_available' '\t\t' \
+$tool_opt may be set to one of the following:)
+unavailable=$(show_tool_names 'mode_ok ! is_available' '\t\t' \
+The following tools are valid, but not currently available:)
if test -n $available
then
-echo 'git $cmd_name --tool=tool' may be set to one of the
following:
-echo $available | sort | sed -e 's/^/ /'
+echo $available
else
echo No suitable tool for 'git $cmd_name --tool=tool' found.
fi
if test -n $unavailable
then
echo
-echo 'The following tools are valid, but not currently
available:'
-echo $unavailable | sort | sed -e 's/^/ /'
+echo $unavailable
fi
if test -n $unavailable$available
then
You haven't taken full advantage of the simplification Junio suggested
in response to v1 here. We can change the unavailable block to be:
show_tool_names 'mode_ok ! is_available' $TAB$TAB \
${LF}The following tools are valid, but not currently available:
Actually I was hoping that we can enhance show_tool_names so that we
can do without the $available and $unavailable variables at all.
If you also add a not_found_msg parameter to show_tool_names then the
available case is also simplified:
show_tool_names 'mode_ok is_available' $TAB$TAB \
$tool_opt may be set to one of the following: \
No suitable tool for 'git $cmd_name --tool=tool' found.
with this at the end of show_tool_names:
test -n $preamble test -n $not_found_msg \
echo $not_found_msg
Yes, something along that line.
--
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] git-blame.el: truncate author to avoid jagged left edge of code
Sorry for being absent a long time. I hope you have managed to sort out the git-blame fixes anyway. Jonathan Nieder jrnie...@gmail.com writes: Without this patch, the author column in git-blame-mode spills over in some rows: 822a7d ram...@ramsay1.demon.co.uk:const char git_usage_ f2dd8c jon.seym...@gmail.com: git [--version] [--exec- a1bea2 j...@joshtriplett.org:[-p|--paginat a1bea2 j...@joshtriplett.org:[--git-dir=p 293b07 tr...@student.ethz.ch:[-c name=valu 62b469 stepan.ne...@gmail.com: comm 822a7d ram...@ramsay1.demon.co.uk: As a result, code meant to line up does not line up correctly and the colored code area has a jagged left edge. Specify a maximum width for the autohr email address in the default blame prefix (i.e., use %20.20A instead of %20A) to fix it. 822a7d ramsay@ramsay1.demon.c:const char git_usage_strin f2dd8c jon.seym...@gmail.com: git [--version] [--exec- The (format) function used to implement format-spec has supported precision specifiers like .20 in emacs since 2002-12-09, so this should be safe. Helped-by: Kevin Ryde use...@zip.com.au Signed-off-by: Jonathan Nieder jrnie...@gmail.com --- In February of 2011, I wrote: - email addresses are often longer than 20 characters. Does format-spec provide a way to truncate to a certain length, so the prefixes can line up? Better late than never, I guess. Sensible? contrib/emacs/git-blame.el |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contrib/emacs/git-blame.el b/contrib/emacs/git-blame.el index d351cfb6..137d5ba9 100644 --- a/contrib/emacs/git-blame.el +++ b/contrib/emacs/git-blame.el @@ -102,7 +102,7 @@ :group 'git-blame) (defcustom git-blame-prefix-format - %h %20A: + %h %20.20A: The format of the prefix added to each line in `git-blame' mode. The format is passed to `format-spec' with the following format keys: -- David Kågedal -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2] git-send-email: add ~/.authinfo parsing
From: Michal Nazarewicz min...@mina86.com
Make git-send-email read password from a ~/.authinfo or a ~/.netrc
file instead of requiring it to be stored in git configuration, passed
as command line argument or typed in.
There are various other applications that use this file for
authentication information so letting users use it for git-send-email
is convinient. Furthermore, some users store their ~/.gitconfig file
in a public repository and having to store password there makes it
easy to publish the password.
Signed-off-by: Michal Nazarewicz min...@mina86.com
---
Documentation/git-send-email.txt | 34 +--
git-send-email.perl | 124 +++
2 files changed, 140 insertions(+), 18 deletions(-)
On Tue, Jan 29 2013, Junio C Hamano wrote:
Makes one wonder why .authinfo and not .netrc;
Fine… Let's parse both. ;)
Either way it still encourages a plaintext password to be on disk,
which may not be what we want, even though it may be slight if not
really much of an improvement.
Well… Users store passwords on disks in a lot of places. I wager that
most have mail clients configured not to ask for password but instead
store it on hard drive. I don't see that changing any time soon, so
at least we can try and minimise number of places where a password is
stored.
It is rather strange to require a comma-separated-values parser to
read a file format this simple, isn't it?
I was worried about spaces in password. CVS should handle such case
nicely, whereas simple split won't. Nonetheless, I guess that in the
end this is not likely enough to add the dependency.
Perhaps you can convert at least some popular ones yourself? After
all, the user may be using an _existing_ .authinfo/.netrc that she
has been using with other programs that do understand symbolic port
names. Rather than forcing all such users to update their files,
the patch can work a bit harder for them and the world will be a
better place, no?
Parsing /etc/services added.
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index eeb561c..ee20714 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -158,14 +158,36 @@ Sending
--smtp-pass[=password]::
Password for SMTP-AUTH. The argument is optional: If no
argument is specified, then the empty string is used as
- the password. Default is the value of 'sendemail.smtppass',
- however '--smtp-pass' always overrides this value.
+ the password. Default is the value of 'sendemail.smtppass'
+ or value read from ~/.authinfo file, however '--smtp-pass'
+ always overrides this value.
+
-Furthermore, passwords need not be specified in configuration files
-or on the command line. If a username has been specified (with
+Furthermore, passwords need not be specified in configuration files or
+on the command line. If a username has been specified (with
'--smtp-user' or a 'sendemail.smtpuser'), but no password has been
-specified (with '--smtp-pass' or 'sendemail.smtppass'), then the
-user is prompted for a password while the input is masked for privacy.
+specified (with '--smtp-pass', 'sendemail.smtppass' or via
+~/.authinfo file), then the user is prompted for a password while
+the input is masked for privacy.
++
+The ~/.authinfo file should contain a line with the following
+format:
++
+ machine domain port port login user password pass
++
+Each pair (expect for `password pass`) can be omitted which will
+skip matching of the given value. Lines are interpreted in order and
+password from the first line that matches will be used. `port` can
+be either an integer or a symbolic name. In the latter case, it is
+looked up in `/etc/services` file (if it exists). For instance, you
+can put
++
+ machine example.com login testuser port ssmtp password smtppassword
+ machine example.com login testuserpassword testpassword
++
+if you want to use `smtppassword` for authenticating to a service at
+port 465 (SSMTP) and `testpassword` for all other services. As shown
+in the example, `port` can use If ~/.authinfo file is
+missing, 'git-send-email' will also try ~/.netrc file.
--smtp-server=host::
If set, specifies the outgoing SMTP server to use (e.g.
diff --git a/git-send-email.perl b/git-send-email.perl
index be809e5..2d8fd1b 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -1045,6 +1045,117 @@ sub maildomain {
return maildomain_net() || maildomain_mta() || 'localhost.localdomain';
}
+
+sub read_password_from_stdin {
+ my $line;
+
+ system stty -echo;
+
+ do {
+ print Password: ;
+ $line = STDIN;
+ print \n;
+ } while (!defined $line);
+
+ system stty echo;
+
+ chomp $line;
+ return $line;
+}
+
+sub read_etc_services {
+ my $fd;
+ if (!open $fd, '', '/etc/services') {
+ return {};
+
Re: [PATCH 0/2] optimizing pack access on read only fetch repos
On Tue, Jan 29, 2013 at 07:58:01AM -0800, Junio C Hamano wrote: The point is not about space. Disk is cheap, and it is not making it any worse than what happens to your target audience, that is a fetch-only repository with only gc --auto in it, where nobody passes -f to repack to cause recomputation of delta. What I was trying to seek was a way to reduce the runtime penalty we pay every time we run git in such a repository. - Object look-up cost will become log2(50*n) from 50*log2(n), which is about 50/log2(50) improvement; Yes and no. Our heuristic is to look at the last-used pack for an object. So assuming we have locality of requests, we should quite often get lucky and find the object in the first log2 search. Even if we don't assume locality, a situation with one large pack and a few small packs will have the large one as last used more often than the others, and it will also have the looked-for object more often than the others So I can see how it is something we could potentially optimize, but I could also see it being surprisingly not a big deal. I'd be very interested to see real measurements, even of something as simple as a master index which can reference multiple packfiles. - System resource cost we incur by having to keep 50 file descriptors open and maintaining 50 mmap windows will reduce by 50 fold. I wonder how measurable that is (and if it matters on Linux versus less efficient platforms). I would be interested to see the timing on how quick it is compared to a real repack,... Yes, that is what I meant by wonder if we would be helped by ;-) There is only one way to find out... :) Maybe I am blessed with nice machines, but I have mostly found the repack process not to be that big a deal these days (especially with threaded delta compression). But how do these somewhat mediocre concatenated packs get turned into real packs? How do they get processed in a fetch-only repositories that sometimes run gc --auto today? By runninng repack -a -d -f occasionally, perhaps? Do we run repack -adf regularly? The usual git gc procedure will not use -f, and without that, we will not even consider making deltas between objects that were formerly in different packs (but now are in the same pack). So you are avoiding doing medium-effort packs (repack -ad) in favor of doing potentially quick packs, but occasionally doing a big-effort pack (repack -adf). It may be reasonable advice to repack -adf occasionally, but I suspect most people are not doing it regularly (if only because git gc does not do it by default). -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 v2 1/4] mergetool--lib: Simplify command expressions
On Tue, Jan 29, 2013 at 11:22 AM, John Keeping j...@keeping.me.uk wrote:
On Sun, Jan 27, 2013 at 04:52:23PM -0800, David Aguilar wrote:
Update variable assignments to always use $(command $arg)
in their RHS instead of $(command $arg) as the latter
is harder to read. Make get_merge_tool_cmd() simpler by
avoiding echo and $(command) substitutions completely.
Signed-off-by: David Aguilar dav...@gmail.com
---
@@ -300,9 +292,9 @@ get_merge_tool_path () {
fi
if test -z $merge_tool_path
then
- merge_tool_path=$(translate_merge_tool_path $merge_tool)
+ merge_tool_path=$(translate_merge_tool_path $merge_tool)
fi
- if test -z $(get_merge_tool_cmd $merge_tool)
+ if test -z $(get_merge_tool_cmd $merge_tool)
This change should be reverted to avoid calling test -z without any
other arguments, as Johannes pointed out in v1.
The rest of this patch looks good to me.
You're right. My eyes have probably been staring at it too long and I
missed this (even though I thought I had checked).
Junio, how would you like these patches?
Incrementals on top of da/mergetool-docs?
I won't be able to get to them until later tonight (PST) at the
earliest, though.
--
David
--
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 0/2] optimizing pack access on read only fetch repos
Jeff King p...@peff.net writes: But how do these somewhat mediocre concatenated packs get turned into real packs? How do they get processed in a fetch-only repositories that sometimes run gc --auto today? By runninng repack -a -d -f occasionally, perhaps? Do we run repack -adf regularly? The usual git gc procedure will not use -f, and without that, we will not even consider making deltas between objects that were formerly in different packs (but now are in the same pack). Correct. It is not a new problem, and while I think it would need some solution, the coalesce 50 small young packs into one is not an attempt to address it. So you are avoiding doing medium-effort packs (repack -ad) in favor of doing potentially quick packs, but occasionally doing a big-effort pack (repack -adf). So I think but occasionally part is not correct. In either way, the packs use suboptimal delta, and you have to eventually pack with -f, whether you coalesce 50 packs into 1 often or keep paying the cost of having 50 packs longer. The trade-off is purely between one potentially quick coalescing per fetch in fetch-only repository vs any use of the data in the fetch-only repository (what do they do? build? serving gitweb locally?) has to deal with 25 packs on average, and we still need to pay medium repack cost every 50 fetches. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/4] mergetool--lib: Add functions for finding available tools
On Tue, Jan 29, 2013 at 12:22 PM, Junio C Hamano gits...@pobox.com wrote:
John Keeping j...@keeping.me.uk writes:
On Sun, Jan 27, 2013 at 04:52:25PM -0800, David Aguilar wrote:
--- a/git-mergetool--lib.sh
+++ b/git-mergetool--lib.sh
@@ -2,6 +2,35 @@
# git-mergetool--lib is a library for common merge tool functions
MERGE_TOOLS_DIR=$(git --exec-path)/mergetools
+mode_ok () {
+diff_mode can_diff ||
+merge_mode can_merge
+}
+
+is_available () {
+merge_tool_path=$(translate_merge_tool_path $1)
+type $merge_tool_path /dev/null 21
+}
+
+show_tool_names () {
+condition=${1:-true} per_line_prefix=${2:-} preamble=${3:-}
+
+( cd $MERGE_TOOLS_DIR ls -1 * ) |
Is the '*' necessary here?
No, it was just from a bad habit (I have ls aliased to ls -A or ls
-a in my interactive environment, which trained my fingers to this).
I also think you can lose -1, although it does not hurt.
+tool_opt='git ${TOOL_MODE}tool --tool-tool'
+available=$(show_tool_names 'mode_ok is_available' '\t\t' \
+$tool_opt may be set to one of the following:)
+unavailable=$(show_tool_names 'mode_ok ! is_available' '\t\t' \
+The following tools are valid, but not currently available:)
if test -n $available
then
-echo 'git $cmd_name --tool=tool' may be set to one of the
following:
-echo $available | sort | sed -e 's/^/ /'
+echo $available
else
echo No suitable tool for 'git $cmd_name --tool=tool'
found.
fi
if test -n $unavailable
then
echo
-echo 'The following tools are valid, but not currently
available:'
-echo $unavailable | sort | sed -e 's/^/ /'
+echo $unavailable
fi
if test -n $unavailable$available
then
You haven't taken full advantage of the simplification Junio suggested
in response to v1 here. We can change the unavailable block to be:
show_tool_names 'mode_ok ! is_available' $TAB$TAB \
${LF}The following tools are valid, but not currently available:
Actually I was hoping that we can enhance show_tool_names so that we
can do without the $available and $unavailable variables at all.
If you also add a not_found_msg parameter to show_tool_names then the
available case is also simplified:
show_tool_names 'mode_ok is_available' $TAB$TAB \
$tool_opt may be set to one of the following: \
No suitable tool for 'git $cmd_name --tool=tool' found.
with this at the end of show_tool_names:
test -n $preamble test -n $not_found_msg \
echo $not_found_msg
Yes, something along that line.
I don't want to stomp on your feet and poke at this file too much if
you're planning on building on top of it (I already did a few times
;-). My git time is a bit limited for the next few days so I don't
want to hold you up. I can help shepherd through small fixups that
come up until the weekend rolls around and I have more time, but I
also don't want to hold you back until then.
I will have some time tonight. If you guys would prefer an
incremental patch I can send one that changes the ls expression and
the way the unavailable block is structured. Otherwise, I can send
replacements to handle the test -z thing, $TAB$TAB, and the
simplification of the unavailable block.
Later patches (that are working towards the new feature) can
generalize show_tool_names() further and eliminate the need for the
available/unavailable variables altogether. John, I would imagine
that you'd want to pick that up since you're driving towards having
--tool-help honor custom tools.
What do you think?
--
David
--
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/4] mergetool--lib: Simplify command expressions
David Aguilar dav...@gmail.com writes:
On Tue, Jan 29, 2013 at 11:22 AM, John Keeping j...@keeping.me.uk wrote:
On Sun, Jan 27, 2013 at 04:52:23PM -0800, David Aguilar wrote:
Update variable assignments to always use $(command $arg)
in their RHS instead of $(command $arg) as the latter
is harder to read. Make get_merge_tool_cmd() simpler by
avoiding echo and $(command) substitutions completely.
Signed-off-by: David Aguilar dav...@gmail.com
---
@@ -300,9 +292,9 @@ get_merge_tool_path () {
fi
if test -z $merge_tool_path
then
- merge_tool_path=$(translate_merge_tool_path $merge_tool)
+ merge_tool_path=$(translate_merge_tool_path $merge_tool)
fi
- if test -z $(get_merge_tool_cmd $merge_tool)
+ if test -z $(get_merge_tool_cmd $merge_tool)
This change should be reverted to avoid calling test -z without any
other arguments, as Johannes pointed out in v1.
The rest of this patch looks good to me.
You're right. My eyes have probably been staring at it too long and I
missed this (even though I thought I had checked).
By now you (and people who were following this thread) are beginning
to see why I said I'd feel safer with extra dq ;-)
I'll amend locally and push the result out.
--
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: [PATCHv2] git-send-email: add ~/.authinfo parsing
Michal Nazarewicz m...@google.com writes: It is rather strange to require a comma-separated-values parser to read a file format this simple, isn't it? I was worried about spaces in password. CVS should handle such case nicely, whereas simple split won't. Nonetheless, I guess that in the end this is not likely enough to add the dependency. But .netrc/.authinfo format separates its entries with SP, HT, or LF. An entry begins with machine remote-hostname token pair. split(/\s+/) will not work for an entry that span multiple lines but CSV will not help, either. Is it bad to use Net::Netrc instead? This looks like exactly the use case that module was written for, no? Perhaps you can convert at least some popular ones yourself? After all, the user may be using an _existing_ .authinfo/.netrc that she has been using with other programs that do understand symbolic port names. Rather than forcing all such users to update their files, the patch can work a bit harder for them and the world will be a better place, no? Parsing /etc/services added. Hmph. I would have expected to see getservbyname. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/4] mergetool--lib: Add functions for finding available tools
David Aguilar dav...@gmail.com writes: I don't want to stomp on your feet and poke at this file too much if you're planning on building on top of it (I already did a few times ;-). My git time is a bit limited for the next few days so I don't want to hold you up. I can help shepherd through small fixups that come up until the weekend rolls around and I have more time, but I also don't want to hold you back until then. I can work with John to get this part into a shape to support his extended use sometime toward the end of this week, by which time hopefully you have some time to comment on the result. John, how does that sound? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/4] mergetool--lib: Add functions for finding available tools
On Tue, Jan 29, 2013 at 02:27:21PM -0800, David Aguilar wrote: I don't want to stomp on your feet and poke at this file too much if you're planning on building on top of it (I already did a few times ;-). My git time is a bit limited for the next few days so I don't want to hold you up. I can help shepherd through small fixups that come up until the weekend rolls around and I have more time, but I also don't want to hold you back until then. I will have some time tonight. If you guys would prefer an incremental patch I can send one that changes the ls expression and the way the unavailable block is structured. Otherwise, I can send replacements to handle the test -z thing, $TAB$TAB, and the simplification of the unavailable block. Later patches (that are working towards the new feature) can generalize show_tool_names() further and eliminate the need for the available/unavailable variables altogether. John, I would imagine that you'd want to pick that up since you're driving towards having --tool-help honor custom tools. What do you think? I was planning to hold off until this series is in a reasonable state - there's no rush as far as I'm concerned, but if Junio's happy to leave these patches with just the small fixups I'm happy to build on that with a patch that removes the available and unavailable variables before adding the tools from git-config. John -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/4] mergetool--lib: Add functions for finding available tools
On Tue, Jan 29, 2013 at 02:55:26PM -0800, Junio C Hamano wrote: David Aguilar dav...@gmail.com writes: I don't want to stomp on your feet and poke at this file too much if you're planning on building on top of it (I already did a few times ;-). My git time is a bit limited for the next few days so I don't want to hold you up. I can help shepherd through small fixups that come up until the weekend rolls around and I have more time, but I also don't want to hold you back until then. I can work with John to get this part into a shape to support his extended use sometime toward the end of this week, by which time hopefully you have some time to comment on the result. John, how does that sound? My email crossed with yours - that sounds good to me. If da/mergetool-docs is in a reasonable state by tomorrow evening (GMT) I should be able to have a look at it then - if not I'm happy to hold off longer. John -- 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
[PATCHv3] git-send-email: add ~/.authinfo parsing
From: Michal Nazarewicz min...@mina86.com
Make git-send-email read password from a ~/.authinfo or ~/.netrc file
instead of requiring it to be stored in git configuration, passed as
command line argument or typed in.
There are various other applications that use this file for
authentication information so letting users use it for git-send-email
is convinient. Furthermore, some users store their ~/.gitconfig file
in a public repository and having to store password there makes it
easy to publish the password.
Signed-off-by: Michal Nazarewicz min...@mina86.com
---
Documentation/git-send-email.txt | 47 +---
git-send-email.perl | 93 ++--
2 files changed, 122 insertions(+), 18 deletions(-)
On Tue, Jan 29 2013, Junio C Hamano wrote:
But .netrc/.authinfo format separates its entries with SP, HT, or
LF. An entry begins with machine remote-hostname token pair.
split(/\s+/) will not work for an entry that span multiple lines but
CSV will not help, either.
Is it bad to use Net::Netrc instead? This looks like exactly the
use case that module was written for, no?
I don't think that's the case. For one, Net::Netrc does not seem to
process port number.
There is a Text::Authinfo module but it just uses Text::CSV.
I can change the code to use Net::Netrc, but I dunno if that's really
the best option, since I feel people would expect parsing to be
somehow compatible with
http://www.gnu.org/software/emacs/manual/html_node/gnus/NNTP.html
rather than the original .netrc file format.
Hmph. I would have expected to see getservbyname.
Ha! Even better. :]
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index eeb561c..ac020d1 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -158,14 +158,49 @@ Sending
--smtp-pass[=password]::
Password for SMTP-AUTH. The argument is optional: If no
argument is specified, then the empty string is used as
- the password. Default is the value of 'sendemail.smtppass',
- however '--smtp-pass' always overrides this value.
+ the password. Default is the value of 'sendemail.smtppass'
+ or value read from ~/.authinfo file, however '--smtp-pass'
+ always overrides this value.
+
-Furthermore, passwords need not be specified in configuration files
-or on the command line. If a username has been specified (with
+Furthermore, passwords need not be specified in configuration files or
+on the command line. If a username has been specified (with
'--smtp-user' or a 'sendemail.smtpuser'), but no password has been
-specified (with '--smtp-pass' or 'sendemail.smtppass'), then the
-user is prompted for a password while the input is masked for privacy.
+specified (with '--smtp-pass', 'sendemail.smtppass' or via
+~/.authinfo file), then the user is prompted for a password while
+the input is masked for privacy.
++
+The ~/.authinfo file should contain a line with the following
+format:
++
+ machine domain port port login user password pass
++
+Instead of `machine domain` pair a `default` token can be used
+instead in which case all domains will match. Similarly, `port
+port` and `login user` pairs can be omitted in which case matching
+of the given value will be skipped. `port` can be either an integer
+or a symbolic name. Lines are interpreted in order and password from
+the first line that matches will be used. For instance, one may end
+up with:
++
+ machine example.com login jane port ssmtp password smtppassword
+ machine example.com login janepassword janepassword
+ default login janedoe password doepassword
++
+if she wants to use `smtppassword` for authenticating as `jane` to
+a service at example.com:465 (SSMTP), `janepassword` for all other
+services at example.com; and `doepassword` when authonticating as
+`janedoe` to any service. If ~/.authinfo file is missing,
+'git-send-email' will also try ~/.netrc file (even though parsing is
+not fully compatible with ftp's .netrc file format).
++
+Note that you should never make ~/.authinfo file world-readable. To
+help guarantee that, you might want to create the file with the
+following command:
++
+ ( umask 077; cat ~/.authinfo EOF
+ ... file contents ...
+ EOF
+ )
--smtp-server=host::
If set, specifies the outgoing SMTP server to use (e.g.
diff --git a/git-send-email.perl b/git-send-email.perl
index be809e5..a62dfa4 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -1045,6 +1045,86 @@ sub maildomain {
return maildomain_net() || maildomain_mta() || 'localhost.localdomain';
}
+
+sub read_password_from_stdin {
+ my $line;
+
+ system stty -echo;
+
+ do {
+ print Password: ;
+ $line = STDIN;
+ print \n;
+ } while (!defined $line);
+
+ system stty echo;
+
+ chomp $line;
+ return $line;
+}
+
+sub
Re: Cloning remote HTTP repository: Can only see 'master' branch
Ah! Lovely, thank you, Jeff! Alas, it's a shared server so I'm limited to what the host provides, but that solves my problem. Cheers! On 29 Jan 2013, at 19:23, Jeff King p...@peff.net wrote: On Tue, Jan 29, 2013 at 04:54:13PM +1100, Michael Tyson wrote: I've a readonly git repository that I'm hosting via HTTP (a bare git repository located within the appropriate directory on the server). I push to it via my own SSH account (local repository with a remote pointing to the ssh:// URL). This has all worked fine so far - I push via ssh, and others can clone and pull via the HTTP URL. I've recently added a branch - beta - which pushed just fine, but now cloning via the HTTP URL doesn't seem to show the new branch - just master: If you are using the dumb http protocol (i.e., the web server knows nothing about git, and just serves the repo files), you need to run git update-server-info after each push in order to update the static file that tells the git client about each ref. You can have git do it automatically for you by setting receive.updateServerInfo in the server repo's config. If the server is yours to control, consider setting up the smart http protocol, as it is much more efficient. Details are in git help http-backend. -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 -- 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] status: show the branch name if possible in in-progress info
On Wed, Jan 30, 2013 at 1:44 AM, Jonathan Nieder jrnie...@gmail.com wrote: - # You are currently rebasing. + # You are currently rebasing branch '\''rebase_conflicts'\'' on '\''000106f'\''. SHA1-in-tests radar blinking. Would it be possible to compute the expected output, as in dest=$(git rev-parse --short HEAD^^) cat expected -EOF # Not currently on any branch. # You are currently rebasing branch '\''rebase_conflicts'\'' on '\''$dest'\''. ? That may be better. Yeah. I'm not sure what to think about the actual change itself yet. Can you give an example of when you felt the need for this, so it can be included in the commit message or documentation? http://thread.gmane.org/gmane.comp.version-control.git/214932/focus=214937 -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] introduce pack metadata cache files
On Tue, Jan 29, 2013 at 4:15 PM, Jeff King p...@peff.net wrote:
+static void write_meta_header(struct metapack_writer *mw, const char *id,
+ uint32_t version)
+{
+ version = htonl(version);
+
+ sha1write(mw-out, META, 4);
+ sha1write(mw-out, \0\0\0\1, 4);
+ sha1write(mw-out, mw-pack-sha1, 20);
+ sha1write(mw-out, id, 4);
+ sha1write(mw-out, version, 4);
+}
Because you go with all-commit-info-in-one-file, perhaps we should
have an uint32_t bitmap to describe what info this cache contains? So
far we need 4 bits for date, tree, 1st and 2nd parents (yes, I still
want to check if storing 1-parent commits only gains us anything on
some other repos). When commit count comes, it can take the fifth bit.
Reachability bitmap offsets can take the sixth bit, if we just append
the bitmaps at the end of the same file.
--
Duy
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2] git-multimail: a replacement for post-receive-email
On Jan 29, 2013, at 7:25 AM, Ævar Arnfjörð Bjarmason ava...@gmail.com wrote: On Sun, Jan 27, 2013 at 9:37 AM, Michael Haggerty mhag...@alum.mit.edu wrote: A while ago, I submitted an RFC for adding a new email notification script to contrib [1]. The reaction seemed favorable and it was suggested that the new script should replace post-receive-email rather than be added separately, ideally with some kind of migration support. I just want to say since I think this thread hasn't been getting the attention it deserves: I'm all for this. I've used git-multimail and it's a joy to configure and extend compared to the existing hacky shellscript. This seems good to me as long as it's okay for git contrib to depend on python. I've started testing git-multimail in my environment. smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH v2 3/4] mergetool--lib: Add functions for finding available tools
John Keeping j...@keeping.me.uk writes:
On Tue, Jan 29, 2013 at 02:55:26PM -0800, Junio C Hamano wrote:
...
I can work with John to get this part into a shape to support his
extended use sometime toward the end of this week, by which time
hopefully you have some time to comment on the result. John, how
does that sound?
My email crossed with yours - that sounds good to me. If
da/mergetool-docs is in a reasonable state by tomorrow evening (GMT) I
should be able to have a look at it then - if not I'm happy to hold off
longer.
Heh, I actually was hoping that you will send in a replacement for
David's patch ;-)
Here is what I will squash into the one we have been discussing. In
a few hours, I expect I'll be able to push this out in the 'pu'
branch.
-- 8 --
From: Junio C Hamano gits...@pobox.com
Date: Tue, 29 Jan 2013 18:57:55 -0800
Subject: [PATCH] [SQUASH] mergetools: tweak show_tool_names and its users
Use show_tool_names as a function to produce output, not as a
function to compute a string. Indicate if any output was given
with its return status, so that the caller can say if it didn't
give any output, I'll say this instead easily.
To be squashed into the previous; no need to keep this log message.
---
git-mergetool--lib.sh | 30 +-
1 file changed, 17 insertions(+), 13 deletions(-)
diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
index 135da96..79cbdc7 100644
--- a/git-mergetool--lib.sh
+++ b/git-mergetool--lib.sh
@@ -22,7 +22,7 @@ is_available () {
show_tool_names () {
condition=${1:-true} per_line_prefix=${2:-} preamble=${3:-}
- ( cd $MERGE_TOOLS_DIR ls -1 * ) |
+ ( cd $MERGE_TOOLS_DIR ls ) |
while read toolname
do
if setup_tool $toolname 2/dev/null
@@ -36,6 +36,7 @@ show_tool_names () {
printf %s%s\n $per_line_prefix $tool
fi
done
+ test -n $preamble
}
diff_mode() {
@@ -236,27 +237,30 @@ list_merge_tool_candidates () {
show_tool_help () {
tool_opt='git ${TOOL_MODE}tool --tool-tool'
- available=$(show_tool_names 'mode_ok is_available' '\t\t' \
- $tool_opt may be set to one of the following:)
- unavailable=$(show_tool_names 'mode_ok ! is_available' '\t\t' \
- The following tools are valid, but not currently available:)
- if test -n $available
+
+ tab=' ' av_shown= unav_shown=
+
+ if show_tool_names 'mode_ok is_available' $tab$tab \
+ $tool_opt may be set to one of the following:
then
- echo $available
+ av_shown=yes
else
echo No suitable tool for 'git $cmd_name --tool=tool' found.
+ av_shown=no
fi
- if test -n $unavailable
+
+ if show_tool_names 'mode_ok ! is_available' $tab$tab \
+ The following tools are valid, but not currently available:
then
- echo
- echo $unavailable
+ unav_shown=yes
fi
- if test -n $unavailable$available
- then
+
+ case ,$av_shown,$unav_shown, in
+ *,yes,*)
echo
echo Some of the tools listed above only work in a windowed
echo environment. If run in a terminal-only session, they will
fail.
- fi
+ esac
exit 0
}
--
1.8.1.2.555.gedafe79
--
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 0/6] commit caching
On Tue, Jan 29, 2013 at 4:14 PM, Jeff King p...@peff.net wrote: The timings from this one are roughly similar to what I posted earlier. Unlike the earlier version, this one keeps the data for a single commit together for better cache locality (though I don't think it made a big difference in my tests, since my cold-cache timing test ends up touching every commit anyway). The short of it is that for an extra 31M of disk space (~4%), I get a warm-cache speedup for git rev-list --all of ~4.2s to ~0.66s. Some data point on caching 1-parent vs 2-parent commits on webkit repo, 26k commits. With your changes (caching 2-parent commits), the .commits file takes 2241600 bytes. rev-list --all --quiet: 0.06user 0.00system 0:00.08elapsed 95%CPU (0avgtext+0avgdata 26288maxresident)k 0inputs+0outputs (0major+2094minor)pagefaults 0swaps With caching 1-parent commits only, the .commits file takes 1707900 bytes (30% less), the same rev-list command: 0.07user 0.00system 0:00.07elapsed 96%CPU (0avgtext+0avgdata 24144maxresident)k 0inputs+0outputs (0major+1960minor)pagefaults 0swaps Compared to the timing without caching at all: 0.72user 0.02system 0:00.76elapsed 98%CPU (0avgtext+0avgdata 108976maxresident)k 0inputs+0outputs (0major+7272minor)pagefaults 0swaps The performance loss in 1-parent case is not significant while disk saving is (although it'll be less impressive after you do Shawn's suggestion not storing SHA-1 directly) -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/4] mergetool--lib: Add functions for finding available tools
Junio C Hamano gits...@pobox.com writes: Heh, I actually was hoping that you will send in a replacement for David's patch ;-) Here is what I will squash into the one we have been discussing. In a few hours, I expect I'll be able to push this out in the 'pu' branch. I ended up doing this a bit differently; will push out the result after merging the other topics to 'pu'. -- 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 4/6] introduce a commit metapack
On Tue, Jan 29, 2013 at 4:16 PM, Jeff King p...@peff.net wrote:
+int commit_metapack(unsigned char *sha1,
+ uint32_t *timestamp,
+ unsigned char **tree,
+ unsigned char **parent1,
+ unsigned char **parent2)
+{
Nit picking. tree, parent1 and parent2 can/should be const unsigned char **.
--
Duy
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] strbuf: add string-chomping functions
On 01/29/2013 12:10 PM, Jeff King wrote: On Tue, Jan 29, 2013 at 11:15:34AM +0100, Michael Haggerty wrote: Please document the new functions in Documentation/technical/api-strbuf.txt. Personally I would also advocate a docstring in the header file, but obviously that preference is the exception rather than the rule in the git project :-( Will do. I need to document the metapack functions, too, so I was thinking about experimenting with some inline documentation systems. That would be great; it would make future API documentation much easier and therefore (hopefully) more common. 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
[PATCH v3 1/4] mergetool--lib: simplify command expressions
Update variable assignments to always use $(command $arg)
in their RHS instead of $(command $arg) as the latter
is harder to read. Make get_merge_tool_cmd() simpler by
avoiding echo and $(command) substitutions completely.
Signed-off-by: David Aguilar dav...@gmail.com
---
This is a replacement patch for what's currently in pu to
fix the empty test -z expression.
git-mergetool--lib.sh | 42 ++
1 file changed, 18 insertions(+), 24 deletions(-)
diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
index 1d0fb12..1ff6d38 100644
--- a/git-mergetool--lib.sh
+++ b/git-mergetool--lib.sh
@@ -32,17 +32,10 @@ check_unchanged () {
fi
}
-valid_tool_config () {
- if test -n $(get_merge_tool_cmd $1)
- then
- return 0
- else
- return 1
- fi
-}
-
valid_tool () {
- setup_tool $1 || valid_tool_config $1
+ setup_tool $1 return 0
+ cmd=$(get_merge_tool_cmd $1)
+ test -n $cmd
}
setup_tool () {
@@ -96,14 +89,13 @@ setup_tool () {
}
get_merge_tool_cmd () {
- # Prints the custom command for a merge tool
merge_tool=$1
if diff_mode
then
- echo $(git config difftool.$merge_tool.cmd ||
- git config mergetool.$merge_tool.cmd)
+ git config difftool.$merge_tool.cmd ||
+ git config mergetool.$merge_tool.cmd
else
- echo $(git config mergetool.$merge_tool.cmd)
+ git config mergetool.$merge_tool.cmd
fi
}
@@ -114,7 +106,7 @@ run_merge_tool () {
GIT_PREFIX=${GIT_PREFIX:-.}
export GIT_PREFIX
- merge_tool_path=$(get_merge_tool_path $1) || exit
+ merge_tool_path=$(get_merge_tool_path $1) || exit
base_present=$2
status=0
@@ -145,7 +137,7 @@ run_merge_tool () {
# Run a either a configured or built-in diff tool
run_diff_cmd () {
- merge_tool_cmd=$(get_merge_tool_cmd $1)
+ merge_tool_cmd=$(get_merge_tool_cmd $1)
if test -n $merge_tool_cmd
then
( eval $merge_tool_cmd )
@@ -158,11 +150,11 @@ run_diff_cmd () {
# Run a either a configured or built-in merge tool
run_merge_cmd () {
- merge_tool_cmd=$(get_merge_tool_cmd $1)
+ merge_tool_cmd=$(get_merge_tool_cmd $1)
if test -n $merge_tool_cmd
then
- trust_exit_code=$(git config --bool \
- mergetool.$1.trustExitCode || echo false)
+ trust_exit_code=$(git config --bool \
+ mergetool.$1.trustExitCode || echo false)
if test $trust_exit_code = false
then
touch $BACKUP
@@ -253,7 +245,7 @@ guess_merge_tool () {
# Loop over each candidate and stop when a valid merge tool is found.
for i in $tools
do
- merge_tool_path=$(translate_merge_tool_path $i)
+ merge_tool_path=$(translate_merge_tool_path $i)
if type $merge_tool_path /dev/null 21
then
echo $i
@@ -300,9 +292,11 @@ get_merge_tool_path () {
fi
if test -z $merge_tool_path
then
- merge_tool_path=$(translate_merge_tool_path $merge_tool)
+ merge_tool_path=$(translate_merge_tool_path $merge_tool)
fi
- if test -z $(get_merge_tool_cmd $merge_tool)
+
+ merge_tool_cmd=$(get_merge_tool_cmd $merge_tool)
+ if test -z $merge_tool_cmd
! type $merge_tool_path /dev/null 21
then
echo 2 The $TOOL_MODE tool $merge_tool is not available as\
@@ -314,11 +308,11 @@ get_merge_tool_path () {
get_merge_tool () {
# Check if a merge tool has been configured
- merge_tool=$(get_configured_merge_tool)
+ merge_tool=$(get_configured_merge_tool)
# Try to guess an appropriate merge tool if no tool has been set.
if test -z $merge_tool
then
- merge_tool=$(guess_merge_tool) || exit
+ merge_tool=$(guess_merge_tool) || exit
fi
echo $merge_tool
}
--
1.8.0.9.g3370a50
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] introduce pack metadata cache files
On Tue, Jan 29, 2013 at 09:35:12AM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
+static void write_meta_header(struct metapack_writer *mw, const char *id,
+ uint32_t version)
+{
+ version = htonl(version);
+
+ sha1write(mw-out, META, 4);
+ sha1write(mw-out, \0\0\0\1, 4);
+ sha1write(mw-out, mw-pack-sha1, 20);
+ sha1write(mw-out, id, 4);
+ sha1write(mw-out, version, 4);
+}
It seems that you are very close to actually having a plumbing that
could also do the pack .idx files. Until/unless that can be done, I
am not sure how much benefit we would be getting from a file format
that records a subtype id and a generic META type, instead of
just a single id as the type ehader. But it is OK to use 8 extra
bytes if we can potentially gain something later.
Yeah, I considered going that route. I had initially envisioned having a
generic META file type that provided some services (like fixed-size
records), and then having individual subtypes below that. But as I
simplified the design, the META format became pretty much pointless. I
left it in as the 8 bytes are not really a big problem, and it means we
can treat metapacks generically in some cases without necessarily
knowing what is in them. But I don't have a specific use case in mind,
so perhaps it is just useless and confusing. I don't mind simplifying.
Shouldn't id be validated with at least something like
if (strlen(id) 3)
die(Bad id: %s, id);
to catch a call
write_meta_header(mw, me, 47);
that will stuff 'm', 'e', NUL and the garbage the compiler/linker
combo has placed after that constant string in the 4-byte id field?
Yes, the id does need to be at least 4 bytes. Since the id is intended
to be a static string, I had planned to just document the requirement in
the API documentation. I don't mind putting in a run-time check. I had
originally had a separate id parameter that could be char id[4], but
found that it was just redundant with the name parameter: you ended up
passing (commit, CMIT) or similar.
+ strbuf_addstr(path, pack_idx);
+ strbuf_chompstr(path, .idx);
+ strbuf_addch(path, '.');
+ strbuf_addstr(path, name);
Your chompstr() does not even validate if the given name ends with
.idx,
Yeah, my intent was that it would be liberal in its input (i.e., take
just pack-*). E.g., you can run git metapack pack/pack-.
so this sounds like a glorified way to say
strbuf_splice(path, path-len - strlen(idx), strlen(idx),
name, strlen(name));
to me.
Yup, though my version handles edge cases by not chomping (e.g., what
does splice do when path-len is less than 3?).
+void metapack_writer_finish(struct metapack_writer *mw)
+{
+ const char *tmp = mw-out-name;
+
+ sha1close(mw-out, NULL, CSUM_FSYNC);
+ if (rename(tmp, mw-path))
+ die_errno(unable to rename temporary metapack file);
Who is responsible for running adjust_shared_perm()? The caller, or
this function?
I didn't think about it at all, but it seems pretty obvious to me that
this function should do so. Thanks for pointing it out.
-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 3/6] introduce pack metadata cache files
On Wed, Jan 30, 2013 at 08:30:57AM +0700, Nguyen Thai Ngoc Duy wrote:
On Tue, Jan 29, 2013 at 4:15 PM, Jeff King p...@peff.net wrote:
+static void write_meta_header(struct metapack_writer *mw, const char *id,
+ uint32_t version)
+{
+ version = htonl(version);
+
+ sha1write(mw-out, META, 4);
+ sha1write(mw-out, \0\0\0\1, 4);
+ sha1write(mw-out, mw-pack-sha1, 20);
+ sha1write(mw-out, id, 4);
+ sha1write(mw-out, version, 4);
+}
Because you go with all-commit-info-in-one-file, perhaps we should
have an uint32_t bitmap to describe what info this cache contains? So
far we need 4 bits for date, tree, 1st and 2nd parents (yes, I still
want to check if storing 1-parent commits only gains us anything on
some other repos). When commit count comes, it can take the fifth bit.
Reachability bitmap offsets can take the sixth bit, if we just append
the bitmaps at the end of the same file.
I thought about having some programmatic self-describing header like
that. But it makes the implementation much harder to verify, and it is
not like there is much point in picking and choosing those bits. My plan
was to do a combination of:
1. Put truly optional bits into a separate metapack (e.g.,
reachability bitmaps).
2. When something becomes obviously obsolete (e.g., we move to
generation numbers instead of timestamps in commits), bump the
version number.
-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 v3 1/4] mergetool--lib: simplify command expressions
David Aguilar dav...@gmail.com writes: Update variable assignments to always use $(command $arg) in their RHS instead of $(command $arg) as the latter is harder to read. Make get_merge_tool_cmd() simpler by avoiding echo and $(command) substitutions completely. Signed-off-by: David Aguilar dav...@gmail.com --- This is a replacement patch for what's currently in pu to fix the empty test -z expression. Thanks. I think I already pushed out what I locally amended; will double 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 4/6] introduce a commit metapack
On Tue, Jan 29, 2013 at 09:38:10AM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
+int commit_metapack(unsigned char *sha1,
+ uint32_t *timestamp,
+ unsigned char **tree,
+ unsigned char **parent1,
+ unsigned char **parent2)
+{
+ struct commit_metapack *p;
+
+ prepare_commit_metapacks();
+ for (p = commit_metapacks; p; p = p-next) {
+ unsigned char *data;
+ int pos = sha1_entry_pos(p-index, 20, 0, 0, p-nr, p-nr,
sha1);
This is a tangent, but isn't it about time to rip out the check for
GIT_USE_LOOKUP in find_pack_entry_one(), I wonder.
Rip it out and always use sha1_entry_pos, or rip it out and never use
it? I have never been able to measure any speedup from it; I just use it
here to avoid rewriting the binary search myself. I do not think there
is any disadvantage to using it, so I'd be in favor of just
standardizing on it for any sha1 binary searches.
These cached properties of a single commit will not change no matter
which pack it appears in, and it feels logically wrong, especially
when you record these object names in the full SHA-1 form, to tie a
commit metapack to a pack. Logically there needs only one commit
metapack that describes all the commits known to the repository when
the metapack was created.
True. I had originally envisioned it as tied to the packfile to help
manage the lifecycle. You know you need to generate a metapack for some
objects when they get packed, and you know you can throw it away when
the associated pack goes away. And it means you can verify the integrity
of the metapack by matching it to a particular packfile.
However, if you just have a commit cache, you can always blow the whole
thing away and regenerate it for all objects in the repo. It does not
have tied to a pack (you do end up doing some extra work at regeneration
when you are not doing a full repack, but it is really not enough to
worry about).
In order to reduce the disk footprint and I/O cost, the future
direction for this mechanism may want to point into an existing
store of SHA-1 hashes with a shorter file offset, and the .idx file
could be such a store, and in order to move in that direction, you
cannot avoid tying a metapack to a pack.
Yes. That was not one of my original goals for the commit cache, but I
do think it's a useful direction to go in. And reachability bitmaps
(which would eventually be their own metapacks) would generally want to
be per-pack, too, for the same reason.
+ *tail = commit_list_insert(c, *tail)-next;
+}
It feels somewhat wasteful to:
- use commit_list for this, rather than an array of commit
objects. If you have a rough estimate of the number of commits
in the pack, you could just preallocate a single array and use
ALLOC_GROW() on it, no?
We don't have a rough estimate, but yes, we could just use an array and
trust ALLOC_GROW to be reasonable. The use of commit_list did not have a
particular reason other than that it was simple (an array means stuffing
the array pointer and the nr and alloc counts into a struct to get to
the callback). The performance of writing the cache is dominated by
accessing the objects themselves, anyway. I don't mind changing it,
though, if you think it's clearer as an array.
- iterate over the .idx file and run sha1_object_info() and
parse_commit() on many objects in the SHA-1 order. Iterating in
the way builtin/pack-objects.c::get_object_details() does avoids
jumping around in existing packfiles, which may be more
efficient, no?
Probably, though generating the complete commit cache for linux-2.6.git
takes only about 7 seconds on my machine. I wasn't too concerned with
optimizing generation, since it will typically be dwarfed by repacking
costs. It might make more of a difference for doing a metapack on all
objects (e.g., reachability bitmaps).
The reason I do it in .idx order is that it feeds the callback in sorted
order, so a writer could in theory just use that output as-is (and my
initial version did that, as it wrote separate metapacks for each
element). This version now puts all data elements together (for cache
locality), and builds the in-memory list so we do not have to re-do
sha1_object_info repeatedly. So it could very easily just generate the
list in pack order and sort it at the end.
I'll look into that for the next version.
-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 4/6] introduce a commit metapack
On Wed, Jan 30, 2013 at 10:36:10AM +0700, Nguyen Thai Ngoc Duy wrote:
On Tue, Jan 29, 2013 at 4:16 PM, Jeff King p...@peff.net wrote:
+int commit_metapack(unsigned char *sha1,
+ uint32_t *timestamp,
+ unsigned char **tree,
+ unsigned char **parent1,
+ unsigned char **parent2)
+{
Nit picking. tree, parent1 and parent2 can/should be const unsigned char **.
Thanks, I'll fix it in the next version.
-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/RFC 0/6] commit caching
On Wed, Jan 30, 2013 at 10:31:43AM +0700, Nguyen Thai Ngoc Duy wrote: On Tue, Jan 29, 2013 at 4:14 PM, Jeff King p...@peff.net wrote: The timings from this one are roughly similar to what I posted earlier. Unlike the earlier version, this one keeps the data for a single commit together for better cache locality (though I don't think it made a big difference in my tests, since my cold-cache timing test ends up touching every commit anyway). The short of it is that for an extra 31M of disk space (~4%), I get a warm-cache speedup for git rev-list --all of ~4.2s to ~0.66s. Some data point on caching 1-parent vs 2-parent commits on webkit repo, 26k commits. With your changes (caching 2-parent commits), the .commits file takes 2241600 bytes. rev-list --all --quiet: Hmm. My webkit repo has zero merges in it (though it is the older svn-based one). What percentage of the one you have are merges? How does your 1-parent cache perform on something like git.git, where about 25% of all commits are merges? The performance loss in 1-parent case is not significant while disk saving is (although it'll be less impressive after you do Shawn's suggestion not storing SHA-1 directly) Yeah, I think moving to offsets instead of sha1s is going to be a big enough win that it won't matter anymore. -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 v2 0/3] transfer.hiderefs
Junio C Hamano gits...@pobox.com writes: Please take this as just a preview of early WIP. I think I may end up doing moderate amount of refactoring as a preparatory step before these patches, so nitpick-reviews are likely to become waste of reviewer's time at this point. I've pushed out a mostly-done reroll on 'pu'; I'll send them out as patches for review tomorrow. I think I am making a good progress. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-send-email: add ~/.authinfo parsing
On Tue, Jan 29, 2013 at 11:53:19AM -0800, Junio C Hamano wrote: Either way it still encourages a plaintext password to be on disk, which may not be what we want, even though it may be slight if not really much of an improvement. Again the Help-for-users has this amusing bit: I do not mind a .netrc or .authinfo parser, because while those formats do have security problems, they are standard files that may already be in use. So as long as we are not encouraging their use, I do not see a problem in supporting them (and we already do the same with curl's netrc support). But it would probably make sense for send-email to support the existing git-credential subsystem, so that it can take advantage of secure system-specific storage. And that is where we should be pointing new users. I think contrib/mw-to-git even has credential support written in perl, so it would just need to be factored out to Git.pm. -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
