Re: [PATCH] git-status: show short sequencer state
Phil Hord ho...@cisco.com writes:
+ merge a git-merge is in progress
+ am a git-am is in progress
+ rebase a git-rebase is in progress
+ rebase-interactive a git-rebase--interactive is in progress
+ cherry-picka git-cherry-pick is in progress
+ bisect a git-bisect is in progress
Avoid using git-foo syntax in documentation, it suggests that this is
valid command, which isn't true anymore. `git foo` seems the most common
syntax. Also, git-rebase--interactive is not user-visible = `git rebase
--interactive`.
- if (state-am_empty_patch)
+ if (state-substate==WT_SUBSTATE_NOMINAL)
status_printf_ln(s, color,
_(The current patch is empty.));
This looks weird. First, spaces around == (here and below). Then, the
logic is unintuitive. The if suggests everything is allright, and the
message below is very specific. This at least deserves a comment.
if (advice_status_hints) {
- if (!state-am_empty_patch)
+ if (state-substate==WT_SUBSTATE_CONFLICTED)
Spaces around ==.
+static void wt_print_token(struct wt_status *s, const char *color, const
char *token)
+{
+ color_fprintf(s-fp, color, %s, token);
+ fputc(s-null_termination ? '\0' : '\n', s-fp);
+}
The output format seems to be meant only for machine-consumption. Is
there any case when we'd want color? I'd say we can disable coloring
completely for this format (normally, color=auto does the right thing,
but I prefer being 100% sure I'll get no color when writing scripts)
+static void wt_shortstatus_print_sequencer(struct wt_status *s)
[...]
+void wt_sequencer_print(struct wt_status *s)
+{
+ wt_shortstatus_print_sequencer(s);
+}
+
Why do you need this trivial wrapper?
Other than that, I like the idea (although I have no concrete use-case
in mind), but I didn't actually test the patch.
--
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: git merge man page, upstream
Angelo Borsotti angelo.borso...@gmail.com writes: Hello, the git merge man page, OPTIONS, commit ... states: If no commit is given from the command line, and if merge.defaultToUpstream configuration variable is set, merge the remote tracking branches that the current branch is configured to use as its upstream. See also the configuration section of this manual page. Actually, in this case git merge merges the upstream branch, not the remote tracking branch. It merges the upstream branch, which is a remote-tracking branch (notice the - between remote and tracking, it's a branch that tracks a remote branch, not a remote branch that tracks something). I'll send a patch to fix that. -- 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
git-pull suggests deprecated git-branch --set-upstream flag
I just ran git pull, and it suggested that I should use `git branch --set-upstream`. Yet when I used it, git-branch told me that the flag is deprecated. Git version 1.8.0. tom -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git push slowly under 1000M/s network
Well, after checked pushing directly to git which takes only 6 seconds. So it should be not a issue of git in c. But might be an issue with jgit or gerrit. 2012/10/23 Joey Jiao joey.jia...@gmail.com: Hi Git Listeners, I'm facing one problem when pushing to git repository via gerrit port. Don't stop to look into the below content, as I doubt it might be a git problem. The pushing takes me 7mins~11mins each time every I had git gc on remote. The remote server is 24 core with scsi disk. And the connection is within 1000M/s intranet. The pushing is only slowly on this kernel project, but faster on other android projects, takes seconds only. I tried on 4 core and 24 core clients to do the push, the time is almost the same. So I think it's not the client problem. The command I use as below. I also tried to pushing to git repository directly, it is also slow, only some seconds benifit. So I think it might be not the gerrit problem. $ git push -v ssh://remote_url:29418/kernel/msm.git HEAD:refs/changes/33599 The stderr stops at remote: Resolving deltas: 0% (0/2) for 99% of the time. I added some timestamp in the git source code, Like git version 1.8.0. The receive_status called by send_pack inside send-pack.c takes the 99% of the time. It looks like the client is waiting the pushing result status from server although by checking server side, the real object has already been upload succeed. Below is the log after adding time info. $ time git push -v ssh://git.qrd.qualcomm.com:29418/kernel/msm.git HEAD:refs/changes/33599 21|tee -a log.txt Pushing to ssh://git.qrd.qualcomm.com:29418/kernel/msm.git error: Time start packet_flush: Tue Oct 23 14:14:47 2012 error: Time finish packet_trace: Tue Oct 23 14:14:47 2012 error: Time finish safe_write: Tue Oct 23 14:14:47 2012 error: Time start receive_status: Tue Oct 23 14:14:47 2012 remote: Resolving deltas: 0% (0/2) remote: (W) afafdad: no files changed, message updated error: Time start packet_read_line: Tue Oct 23 14:24:41 2012 , len=10 error: Time packet_read_line: Tue Oct 23 14:24:41 2012 , len=22 error: Time packet_read_line: Tue Oct 23 14:24:41 2012 , len=0 error: Time finish receive_status: Tue Oct 23 14:24:41 2012 To ssh://git.qrd.qualcomm.com:29418/kernel/msm.git * [new branch] HEAD - refs/changes/33599 real9m56.928s user0m0.364s sys 0m0.160s -- -Joey Jiao -- -Joey Jiao -- To unsubscribe from this list: send the line 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] Document git-svn fetch --log-window-size parameter
The --log-window-size parameter to git-svn fetch is undocumented. Minimally describe what it does and why the user might change it. Signed-off-by: Gunnlaugur Þór Briem gunnlau...@gmail.com --- Documentation/git-svn.txt | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt index cfe8d2b..64756c9 100644 --- a/Documentation/git-svn.txt +++ b/Documentation/git-svn.txt @@ -146,6 +146,12 @@ Skip branches and tags of first level directories;; -- +--log-window-size=n;; +Fetch n log entries per request when scanning Subversion history. +The default is 100. For very large Subversion repositories, larger +values may be needed for 'clone'/'fetch' to complete in reasonable +time. But overly large values may lead to request timeouts. + 'clone':: Runs 'init' and 'fetch'. It will automatically create a directory based on the basename of the URL passed to it; -- 1.7.12.3 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Documentation: remote tracking branch - remote-tracking branch
This change was already done by 0e615b252f3 (Matthieu Moy, Tue Nov 2 2010, Replace remote tracking with remote-tracking), but new instances of remote tracking (without dash) were introduced in the meantime. Signed-off-by: Matthieu Moy matthieu@imag.fr --- Here's the patch. I'm not opposed to dropping completely the remote-tracking part in the case of merge (i.e. remote-tracking branches that the current branch is configured to use as its upstream - upstream branch) on top of that, but if we do this, merge-config.txt should be updated too). Documentation/git-clone.txt| 4 ++-- Documentation/git-merge.txt| 2 +- Documentation/git-push.txt | 2 +- Documentation/merge-config.txt | 4 ++-- 4 files changed, 6 insertions(+), 6 deletions(-) diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt index 6d98ef3..7fefdb0 100644 --- a/Documentation/git-clone.txt +++ b/Documentation/git-clone.txt @@ -196,9 +196,9 @@ objects from the source repository into a pack in the cloned repository. `--no-single-branch` is given to fetch the histories near the tips of all branches. Further fetches into the resulting repository will only update the - remote tracking branch for the branch this option was used for the + remote-tracking branch for the branch this option was used for the initial cloning. If the HEAD at the remote did not point at any - branch when `--single-branch` clone was made, no remote tracking + branch when `--single-branch` clone was made, no remote-tracking branch is created. --recursive:: diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt index 20f9228..d34ea3c 100644 --- a/Documentation/git-merge.txt +++ b/Documentation/git-merge.txt @@ -99,7 +99,7 @@ commit or stash your changes before running 'git merge'. more than two parents (affectionately called an Octopus merge). + If no commit is given from the command line, and if `merge.defaultToUpstream` -configuration variable is set, merge the remote tracking branches +configuration variable is set, merge the remote-tracking branches that the current branch is configured to use as its upstream. See also the configuration section of this manual page. diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt index 22d2580..fe46c42 100644 --- a/Documentation/git-push.txt +++ b/Documentation/git-push.txt @@ -175,7 +175,7 @@ useful if you write an alias or script around 'git push'. --recurse-submodules=check|on-demand:: Make sure all submodule commits used by the revisions to be - pushed are available on a remote tracking branch. If 'check' is + pushed are available on a remote-tracking branch. If 'check' is used git will verify that all submodule commits that changed in the revisions to be pushed are available on at least one remote of the submodule. If any commits are missing the push will be diff --git a/Documentation/merge-config.txt b/Documentation/merge-config.txt index 861bd6f..9bb4956 100644 --- a/Documentation/merge-config.txt +++ b/Documentation/merge-config.txt @@ -9,11 +9,11 @@ merge.conflictstyle:: merge.defaultToUpstream:: If merge is called without any commit argument, merge the upstream branches configured for the current branch by using their last - observed values stored in their remote tracking branches. + observed values stored in their remote-tracking branches. The values of the `branch.current branch.merge` that name the branches at the remote named by `branch.current branch.remote` are consulted, and then they are mapped via `remote.remote.fetch` - to their corresponding remote tracking branches, and the tips of + to their corresponding remote-tracking branches, and the tips of these tracking branches are merged. merge.ff:: -- 1.7.12.410.g5f38766 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git merge man page, upstream
Angelo Borsotti angelo.borso...@gmail.com writes: Hi Matthieu, the upstream branch can also be a local branch. In this case, it's: [branch branch] remote = . merge = refs/heads/master which can arguably be considered as a special case of remote branch whose location happens to be .. But as said in the patch, I don't mind if someone wants to drop the remote-tracking mention on top of my patch. -- 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
[RFC PATCH 0/2] Localize log output
In v1.8.0, I saw a regression in, among other, git show --stat in that it would no longer output the diffstat in Swedish. This turned out to be intentional, to fix format-patch and friends, but I liked the old behaviour. This series tries to fix that, and related code such as git log, while making sure that git format-patch still outputs in English. I am posting this as a RFC, as I might very well have broken something else in the process, from not knowing the code well enough. The branch is also available from https://github.com/nafmo/git-l10n-sv/commits/fix-diff-translation-20121023-1.8.0 with an updated Swedish translation. Peter Krefting (2): Use localized date in log output Localize diff and log output builtin/apply.c | 2 +- builtin/commit.c | 4 +-- builtin/log.c| 6 ++-- commit.h | 3 +- date.c | 4 ++- diff.c | 22 +- diff.h | 5 +++- gettext.c| 1 + log-tree.c | 11 +-- pretty.c | 87 +++- strbuf.c | 10 +++ strbuf.h | 1 + 12 files changed, 119 insertions(+), 37 deletions(-) -- 1.8.0 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 1/2] Use localized date in log output
When outputting a normal log, without having specified which date format
to use, we should output the current user locale's default format. Do this
by initializing LC_TIME properly and using strftime() to format the date.
---
date.c| 4 +++-
gettext.c | 1 +
strbuf.c | 10 ++
strbuf.h | 1 +
4 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/date.c b/date.c
index 57331ed..88f928c 100644
--- a/date.c
+++ b/date.c
@@ -203,7 +203,7 @@ const char *show_date(unsigned long time, int tz, enum
date_mode mode)
weekday_names[tm-tm_wday], tm-tm_mday,
month_names[tm-tm_mon], tm-tm_year + 1900,
tm-tm_hour, tm-tm_min, tm-tm_sec, tz);
- else
+ else if (mode == DATE_RAW)
strbuf_addf(timebuf, %.3s %.3s %d %02d:%02d:%02d %d%c%+05d,
weekday_names[tm-tm_wday],
month_names[tm-tm_mon],
@@ -212,6 +212,8 @@ const char *show_date(unsigned long time, int tz, enum
date_mode mode)
tm-tm_year + 1900,
(mode == DATE_LOCAL) ? 0 : ' ',
tz);
+ else
+ strbuf_strftime(timebuf,%c,tm);
return timebuf.buf;
}
diff --git a/gettext.c b/gettext.c
index 71e9545..a87d144 100644
--- a/gettext.c
+++ b/gettext.c
@@ -126,6 +126,7 @@ void git_setup_gettext(void)
podir = GIT_LOCALE_PATH;
bindtextdomain(git, podir);
setlocale(LC_MESSAGES, );
+ setlocale(LC_TIME, );
init_gettext_charset(git);
textdomain(git);
}
diff --git a/strbuf.c b/strbuf.c
index 0510f76..d393de9 100644
--- a/strbuf.c
+++ b/strbuf.c
@@ -228,6 +228,16 @@ void strbuf_vaddf(struct strbuf *sb, const char *fmt,
va_list ap)
strbuf_setlen(sb, sb-len + len);
}
+void strbuf_strftime(struct strbuf *sb, const char *fmt, struct tm *tm)
+{
+ int len;
+
+ if (!strbuf_avail(sb))
+ strbuf_grow(sb, 256);
+ len = strftime(sb-buf + sb-len, sb-alloc - sb-len, fmt, tm);
+ strbuf_setlen(sb, sb-len + len);
+}
+
void strbuf_expand(struct strbuf *sb, const char *format, expand_fn_t fn,
void *context)
{
diff --git a/strbuf.h b/strbuf.h
index be941ee..9ca1d59 100644
--- a/strbuf.h
+++ b/strbuf.h
@@ -99,6 +99,7 @@ __attribute__((format (printf,2,3)))
extern void strbuf_addf(struct strbuf *sb, const char *fmt, ...);
__attribute__((format (printf,2,0)))
extern void strbuf_vaddf(struct strbuf *sb, const char *fmt, va_list ap);
+extern void strbuf_strfime(struct strbuf *sb, const char *fmt, struct tm *tm);
extern void strbuf_add_lines(struct strbuf *sb, const char *prefix, const char
*buf, size_t size);
--
1.8.0
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 2/2] Localize diff and log output
The output of git diff --stat, git show --stat and git log should be
translated to the local user language. The output of git format-patch
should not, however. Add localization where needed, and add a flag for
making sure that format-patch's output remains in English.
This partially reverts commit 218ad064c436115dbcd5705a0e2c42e90a25 (Revert
diffstat back to English; 2012-09-13).
---
builtin/apply.c | 2 +-
builtin/commit.c | 4 +--
builtin/log.c| 6 ++--
commit.h | 3 +-
diff.c | 22 +-
diff.h | 5 +++-
log-tree.c | 11 +--
pretty.c | 87 +++-
8 files changed, 104 insertions(+), 36 deletions(-)
diff --git a/builtin/apply.c b/builtin/apply.c
index 156b3ce..9ead305 100644
--- a/builtin/apply.c
+++ b/builtin/apply.c
@@ -3644,7 +3644,7 @@ static void stat_patch_list(struct patch *patch)
show_stats(patch);
}
- print_stat_summary(stdout, files, adds, dels);
+ print_stat_summary(stdout, files, adds, dels, NULL);
}
static void numstat_patch_list(struct patch *patch)
diff --git a/builtin/commit.c b/builtin/commit.c
index a17a5df..406346e 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -1248,11 +1248,11 @@ static void print_summary(const char *prefix, const
unsigned char *sha1,
format_commit_message(commit, %an %ae, author_ident, pctx);
format_commit_message(commit, %cn %ce, committer_ident, pctx);
if (strbuf_cmp(author_ident, committer_ident)) {
- strbuf_addstr(format, \n Author: );
+ strbuf_addstr(format, _(\n Author: ));
strbuf_addbuf_percentquote(format, author_ident);
}
if (!user_ident_sufficiently_given()) {
- strbuf_addstr(format, \n Committer: );
+ strbuf_addstr(format, _(\n Committer: ));
strbuf_addbuf_percentquote(format, committer_ident);
if (advice_implicit_identity) {
strbuf_addch(format, '\n');
diff --git a/builtin/log.c b/builtin/log.c
index 09cf43e..0c579d7 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -381,7 +381,7 @@ static void show_tagger(char *buf, int len, struct rev_info
*rev)
pp.fmt = rev-commit_format;
pp.date_mode = rev-date_mode;
- pp_user_info(pp, Tagger, out, buf, get_log_output_encoding());
+ pp_user_info(pp, _(Tagger), _(TaggerDate), 0, out, buf,
get_log_output_encoding());
printf(%s, out.buf);
strbuf_release(out);
}
@@ -804,7 +804,7 @@ static void make_cover_letter(struct rev_info *rev, int
use_stdout,
msg = body;
pp.fmt = CMIT_FMT_EMAIL;
pp.date_mode = DATE_RFC2822;
- pp_user_info(pp, NULL, sb, committer, encoding);
+ pp_user_info(pp, NULL, NULL, 0, sb, committer, encoding);
pp_title_line(pp, msg, sb, encoding, need_8bit_cte);
pp_remainder(pp, msg, sb, 0);
add_branch_description(sb, branch_name);
@@ -1222,6 +1222,8 @@ int cmd_format_patch(int argc, const char **argv, const
char *prefix)
/* Always generate a patch */
rev.diffopt.output_format |= DIFF_FORMAT_PATCH;
+ /* Never translate format-patch output */
+ rev.diffopt.output_format |= DIFF_FORMAT_ENGLISH;
if (!DIFF_OPT_TST(rev.diffopt, TEXT) !no_binary_diff)
DIFF_OPT_SET(rev.diffopt, BINARY);
diff --git a/commit.h b/commit.h
index 9f21313..2a9ac6a 100644
--- a/commit.h
+++ b/commit.h
@@ -114,7 +114,8 @@ extern void pretty_print_commit(const struct
pretty_print_context *pp,
extern void pp_commit_easy(enum cmit_fmt fmt, const struct commit *commit,
struct strbuf *sb);
void pp_user_info(const struct pretty_print_context *pp,
- const char *what, struct strbuf *sb,
+ const char *what, const char *whatdate, int extra_padding,
+ struct strbuf *sb,
const char *line, const char *encoding);
void pp_title_line(const struct pretty_print_context *pp,
const char **msg_p,
diff --git a/diff.c b/diff.c
index 35d3f07..ef655d1 100644
--- a/diff.c
+++ b/diff.c
@@ -1391,18 +1391,22 @@ static void fill_print_name(struct diffstat_file *file)
file-print_name = pname;
}
-int print_stat_summary(FILE *fp, int files, int insertions, int deletions)
+int print_stat_summary(FILE *fp, int files, int insertions, int deletions,
struct diff_options *options)
{
struct strbuf sb = STRBUF_INIT;
int ret;
+ int english = options !!(options-output_format
DIFF_FORMAT_ENGLISH);
+
if (!files) {
assert(insertions == 0 deletions == 0);
- return fprintf(fp, %s\n, 0 files changed);
+ return fprintf(fp, %s\n, english ? 0 files changed
+ : _( 0 files changed));
}
strbuf_addf(sb,
- (files
Re: Git submodule for a local branch?
On Mon, Oct 22, 2012 at 08:37:14AM -0400, W. Trevor King wrote: but cloning a remote repository (vs. checking out a local branch) seems to be baked into the submodule implementation. Perhaps --local would set submodule.$name.url to '.', and ome combination of GIT_WORK_TREE, GIT_DIR, and object references could be used to setup and manage the local submodule. -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: The config include mechanism doesn't allow for overwriting
On Mon, Oct 22, 2012 at 11:15 PM, Jeff King p...@peff.net wrote:
On Mon, Oct 22, 2012 at 05:55:00PM +0200, Ævar Arnfjörð Bjarmason wrote:
I was hoping to write something like this:
[user]
name = Luser
email = some-defa...@example.com
[include]
path = ~/.gitconfig.d/user-email
Where that file would contain:
[user]
email = local-em...@example.com
The intent is that it would work as you expect, and produce
local-em...@example.com.
But when you do that git prints:
$ git config --get user.email
some-defa...@example.com
error: More than one value for the key user.email:
local-em...@example.com
Ugh. The config code just feeds all the values sequentially to the
callback. The normal callbacks within git will overwrite old values,
whether from earlier in the file, from a file with lower priority (e.g.,
/etc/gitconfig versus ~/.gitconfig), or from an earlier included. Which
you can check with:
$ git var GIT_AUTHOR_IDENT
Luser local-em...@example.com 1350936694 -0400
But git-config takes it upon itself to detect duplicates in its
callback. Which is just silly, since it is not something that regular
git would do. git-config should behave as much like the internal git
parser as possible.
I think config inclusion is much less useful when you can't clobber
previously assigned values.
Agreed. But I think the bug is in git-config, not in the include
mechanism. I think I'd like to do something like the patch below, which
just reuses the regular config code for git-config, collects the values,
and then reports them. It does mean we use a little more memory (for the
sake of simplicity, we store values instead of streaming them out), but
the code is much shorter, less confusing, and automatically matches what
regular git_config() does.
It fails a few tests in t1300, but it looks like those tests are testing
for the behavior we have identified as wrong, and should be fixed.
I think this patch looks good.
One other thing I think is worth clarifying (and I think should be
broken) is if you write a configuration like:
[foo]
bar = one
[foo]
bar = two
[foo]
bar = three
git-{config,var} -l will both give you:
foo.bar=one
foo.bar=two
foo.bar=three
And git config --get foo.bar will give you:
$ git config -f /tmp/test --get foo.bar
one
error: More than one value for the key foo.bar: two
error: More than one value for the key foo.bar: three
I think that it would be better if the config mechanism just silently
overwrote keys that clobbered earlier keys like your patch does.
But in addition can we simplify things for the consumers of
git-{config,var} -l by only printing:
foo.bar=three
Or are there too many variables like include.path that can
legitimately appear more than once.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Launch separate program for HTTPS prompt
Hi, Could you launch a separate program for HTTPS prompt like SSH_ASKPASS? This allows GUI programs to answer the trust or not, not via stdin. Regards, ch3cooli -- To unsubscribe from this list: send the line 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: Launch separate program for HTTPS prompt
乙酸鋰 ch3co...@gmail.com writes: Hi, Could you launch a separate program for HTTPS prompt like SSH_ASKPASS? This allows GUI programs to answer the trust or not, not via stdin. Read about credential helpers, this is what they are meant for, and they do launch separate programs. -- 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 0/1] Makefile extensions for topic ta/doc-cleanup in pu
This patch adds rules to the html taget in Documentation/Makefile to create html also for the new asciidoc files in Documentation/technical and Documentation/howto which were added in this topic. --- Thomas -- To unsubscribe from this list: send the line 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/1] Wire html for all files in ./technical and ./howto in Makefile
- target html creates html for all files in Documentation/howto and Documentation/technical Signed-off-by: Thomas Ackermann th.acke...@arcor.de --- Documentation/Makefile | 26 -- 1 file changed, 24 insertions(+), 2 deletions(-) diff --git a/Documentation/Makefile b/Documentation/Makefile index 267dfe1..c4e5594 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -24,8 +24,30 @@ SP_ARTICLES = user-manual SP_ARTICLES += howto/revert-branch-rebase SP_ARTICLES += howto/using-merge-subtree SP_ARTICLES += howto/using-signed-tag-in-pull-request +SP_ARTICLES += howto/use-git-daemon +SP_ARTICLES += howto/update-hook-example +SP_ARTICLES += howto/setup-git-server-over-http +SP_ARTICLES += howto/separating-topic-branches +SP_ARTICLES += howto/revert-a-faulty-merge +SP_ARTICLES += howto/recover-corrupted-blob-object +SP_ARTICLES += howto/rebuild-from-update-hook +SP_ARTICLES += howto/rebuild-from-update-hook +SP_ARTICLES += howto/rebase-from-internal-branch +SP_ARTICLES += howto/maintain-git API_DOCS = $(patsubst %.txt,%,$(filter-out technical/api-index-skel.txt technical/api-index.txt, $(wildcard technical/api-*.txt))) SP_ARTICLES += $(API_DOCS) + +TECH_DOCS = technical/index-format +TECH_DOCS += technical/pack-format +TECH_DOCS += technical/pack-heuristics +TECH_DOCS += technical/pack-protocol +TECH_DOCS += technical/protocol-capabilities +TECH_DOCS += technical/protocol-common +TECH_DOCS += technical/racy-git +TECH_DOCS += technical/send-pack-pipeline +TECH_DOCS += technical/shallow +TECH_DOCS += technical/trivial-merge +SP_ARTICLES += $(TECH_DOCS) SP_ARTICLES += technical/api-index DOC_HTML += $(patsubst %,%.html,$(ARTICLES) $(SP_ARTICLES)) @@ -231,7 +253,7 @@ clean: $(RM) *.texi *.texi+ *.texi++ git.info gitman.info $(RM) *.pdf $(RM) howto-index.txt howto/*.html doc.dep - $(RM) technical/api-*.html technical/api-index.txt + $(RM) technical/*.html technical/api-index.txt $(RM) $(cmds_txt) *.made $(RM) manpage-base-url.xsl @@ -264,7 +286,7 @@ technical/api-index.txt: technical/api-index-skel.txt \ $(QUIET_GEN)cd technical '$(SHELL_PATH_SQ)' ./api-index.sh technical/%.html: ASCIIDOC_EXTRA += -a git-relative-html-prefix=../ -$(patsubst %,%.html,$(API_DOCS) technical/api-index): %.html : %.txt +$(patsubst %,%.html,$(API_DOCS) technical/api-index $(TECH_DOCS)): %.html : %.txt $(QUIET_ASCIIDOC)$(ASCIIDOC) -b xhtml11 -f asciidoc.conf \ $(ASCIIDOC_EXTRA) -agit_version=$(GIT_VERSION) $*.txt -- 1.7.11.msysgit.1 --- Thomas -- To unsubscribe from this list: send the line 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-status: show short sequencer state
Matthieu Moy wrote:
Phil Hord ho...@cisco.com writes:
+merge a git-merge is in progress
+am a git-am is in progress
+rebase a git-rebase is in progress
+rebase-interactive a git-rebase--interactive is in progress
+cherry-picka git-cherry-pick is in progress
+bisect a git-bisect is in progress
Avoid using git-foo syntax in documentation, it suggests that this is
valid command, which isn't true anymore. `git foo` seems the most common
syntax. Also, git-rebase--interactive is not user-visible = `git rebase
--interactive`.
Thanks.
-if (state-am_empty_patch)
+if (state-substate==WT_SUBSTATE_NOMINAL)
status_printf_ln(s, color,
_(The current patch is empty.));
This looks weird. First, spaces around == (here and below). Then, the
logic is unintuitive. The if suggests everything is allright, and the
message below is very specific. This at least deserves a comment.
Yes, I agree. It was less clear but more reasonable before I tried to
clear it up some. It's driven by the short-token printer. The state is
you're in a 'git am' but I do not see any conflicted files. Therefore,
your patch must be empty. I suspect this may be a leaving from the
git-am machinery where it did not choose to clean up after itself if the
patch was empty, but perhaps it should have. I seldom use git-am, so I
do not know if this code reflects a common and useful state.
I'll try to make this more explicit. Currently the short-status
version will say either am or am \n conflicted when a 'git am' is in
progress. The logical path to follow if I re-add 'git-am-empty' state
tracker is for this to now show either am \n am-is-empty or am \n
conflicted. But I think I should suppress the am-is-empty report in
that case. What do you think
if (advice_status_hints) {
-if (!state-am_empty_patch)
+if (state-substate==WT_SUBSTATE_CONFLICTED)
Spaces around ==.
+static void wt_print_token(struct wt_status *s, const char *color, const
char *token)
+{
+color_fprintf(s-fp, color, %s, token);
+fputc(s-null_termination ? '\0' : '\n', s-fp);
+}
The output format seems to be meant only for machine-consumption. Is
there any case when we'd want color? I'd say we can disable coloring
completely for this format (normally, color=auto does the right thing,
but I prefer being 100% sure I'll get no color when writing scripts)
Originally I had this output nested in the normal 'git status --short'
output, like a shortened form of the advice. Then, 'git-status
--porcelain' would show the tokens without color, but 'git status
--short' would show them with color. I thought I might be going back
there, or that I might combine this with full 'git status' again
somehow, and colors seemed appropriate still.
The --short status report is too confusing when tokens may or may-not
appear, and it would likely break some scripts, even though they should
be using --porcelain. And the full status already has its long versions
of the same text. So I can remove this color decorator until someone
finds a need for it.
+static void wt_shortstatus_print_sequencer(struct wt_status *s)
[...]
+void wt_sequencer_print(struct wt_status *s)
+{
+wt_shortstatus_print_sequencer(s);
+}
+
Why do you need this trivial wrapper?
Another left-over from its previous multiple versions. I'll simplify it.
Other than that, I like the idea (although I have no concrete use-case
in mind), but I didn't actually test the patch.
My own use-case involves $PS1. I keep running into you cannot
cherry-pick because you are in the middle of a rebase in submodules in
which I have long forgotten about the failed action and have gone on to
write many new commits, or switched branches, or worse. I do not know
what 'git rebase --abort' will give me in those cases, and I wonder what
work I might have lost for having been interrupted in the middle of that
action in the past. These tokens will help me decorate my prompt to
remind me I left some baggage untended.
Thanks for the feedback.
Phil
--
To unsubscribe from this list: send the line 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: tag storage format
That did the trick - thanks! On Mon, Oct 22, 2012 at 5:46 PM, Andreas Schwab sch...@linux-m68k.org wrote: Uri Moszkowicz u...@4refs.com writes: Perhaps Git should switch to a single-file block text or binary format once a large number of tags becomes present in a repository. This is what git pack-refs (called by git gc) does (by putting the refs in .git/packed-refs). Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Long clone time after done.
I have a large repository which I ran git gc --aggressive on that I'm trying to clone on a local file system. I would expect it to complete very quickly with hard links but it's taking about 6min to complete with no checkout (git clone -n). I see the message Clining into 'repos'... done. appear after a few seconds but then Git just hangs there for another 6min. Any idea what it's doing at this point and how I can speed it up? -- To unsubscribe from this list: send the line 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-status: show short sequencer state
Recently git-status learned to display the state of the git
sequencer in long form to help the user remember an interrupted
command. This information is also useful in short form to
humans and scripts, but no option is available to boil it down.
Teach git-status to report the sequencer state in short form
using a new --sequencer (-S) switch. Output zero or more
simple state token strings indicating the deduced state of the
git sequencer.
Introduce a common function to determine the current sequencer
state so the regular status function and this short version can
share common code.
Add a substate to wt_status_state to track more detailed
information about a state, such as conflicted or resolved.
Move the am_empty_patch flage out of wt_status_state and into
this new substate.
State token strings which may be emitted and their meanings:
merge a git-merge is in progress
am a git-am is in progress
rebase a git-rebase is in progress
rebase-interactive a git-rebase--interactive is in progress
cherry-picka git-cherry-pick is in progress
bisect a git-bisect is in progress
conflicted there are unresolved conflicts
resolved conflicts have been resolved
editinginteractive rebase stopped to edit a commit
edited interactive rebase edit has been edited
splitting interactive rebase, commit is being split
I also considered adding these tokens, but I decided it was not
appropriate since these changes are not sequencer-related. But
it is possible I am being too short-sighted or have chosen the
switch name poorly.
clean
index
modified
untracked
---
Documentation/git-status.txt | 18 +++
builtin/commit.c | 12 -
wt-status.c | 125 +++
wt-status.h | 14 -
4 files changed, 145 insertions(+), 24 deletions(-)
diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt
index 67e5f53..31ffabd 100644
--- a/Documentation/git-status.txt
+++ b/Documentation/git-status.txt
@@ -38,6 +38,24 @@ OPTIONS
across git versions and regardless of user configuration. See
below for details.
+-S::
+--sequence::
+ Show the git sequencer status. This shows zero or more tokens
+ describing the state of several git sequence operations. Each
+ token is separated by a newline.
++
+ merge a merge is in progress
+ am an am is in progress
+ rebase a rebase is in progress
+ rebase-interactive an interactive rebase is in progress
+ cherry-picka cherry-pick is in progress
+ bisect a bisect is in progress
+ conflicted there are unresolved conflicts
+ resolved conflicts have been resolved
+ editinginteractive rebase stopped to edit a commit
+ edited interactive rebase edit has been edited
+ splitting interactive rebase, commit is being split
+
-u[mode]::
--untracked-files[=mode]::
Show untracked files.
diff --git a/builtin/commit.c b/builtin/commit.c
index a17a5df..9706ed9 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -114,7 +114,8 @@ static struct strbuf message = STRBUF_INIT;
static enum {
STATUS_FORMAT_LONG,
STATUS_FORMAT_SHORT,
- STATUS_FORMAT_PORCELAIN
+ STATUS_FORMAT_PORCELAIN,
+ STATUS_FORMAT_SEQUENCER
} status_format = STATUS_FORMAT_LONG;
static int opt_parse_m(const struct option *opt, const char *arg, int unset)
@@ -454,6 +455,9 @@ static int run_status(FILE *fp, const char *index_file,
const char *prefix, int
case STATUS_FORMAT_PORCELAIN:
wt_porcelain_print(s);
break;
+ case STATUS_FORMAT_SEQUENCER:
+ wt_sequencer_print(s);
+ break;
case STATUS_FORMAT_LONG:
wt_status_print(s);
break;
@@ -1156,6 +1160,9 @@ int cmd_status(int argc, const char **argv, const char
*prefix)
N_(show status concisely), STATUS_FORMAT_SHORT),
OPT_BOOLEAN('b', branch, s.show_branch,
N_(show branch information)),
+ OPT_SET_INT('S', sequence, status_format,
+ N_(show sequencer state),
+ STATUS_FORMAT_SEQUENCER),
OPT_SET_INT(0, porcelain, status_format,
N_(machine-readable output),
STATUS_FORMAT_PORCELAIN),
@@ -1216,6 +1223,9 @@ int cmd_status(int argc, const char **argv, const char
*prefix)
case STATUS_FORMAT_PORCELAIN:
wt_porcelain_print(s);
break;
+ case STATUS_FORMAT_SEQUENCER:
+ wt_sequencer_print(s);
+ break;
Re: [PATCH] git-submodule add: Record branch name in .gitmodules
On 2012-10-22 09:34, W. Trevor King wrote: From: W. Trevor King wk...@tremily.us This removes a configuration step if you're trying to setup Ævar's $ git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) git pull' workflow from commit f030c96d8643fa0a1a9b2bd9c2f36a77721fb61f Author: Ævar Arnfjörð Bjarmason ava...@gmail.com Date: Fri May 21 16:10:10 2010 + git-submodule foreach: Add $toplevel variable If you're not using that workflow, I see no harm in recording the branch used to determine the original submodule commit. IMHO, the problem is that this works only for a very specific workflow. Normal git usage can very easily break this feature. For instance, the module may later be updated to a commit in branch B instead of branch A. Unless you remember to also update .gitmodule, you have then inconsistent information. A similar issue arises if branch A is deleted from the module later (for instance because it has been merged in the master branch and is not useful anymore). Then .gitmodule points to a non-existant branch. Same thing if a branch is renamed. Last issue, the branch that exists in your local repository may not exist in someone else's repository, either because the branch is purely local, or because it has a different name on the remote repo. I think a better place to store that kind of information is using git-notes. That way, if the branch is renamed or deleted, you can easily update the old notes to use the new name instead. Nahor -- To unsubscribe from this list: send the line 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-status: show short sequencer state
Updated per Matthieu's comments, adding Sign-off and fixing my prefix to have a little v2 on the end. Sorry for the extra noise. Phil -- To unsubscribe from this list: send the line 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-status: show short sequencer state
Recently git-status learned to display the state of the git
sequencer in long form to help the user remember an interrupted
command. This information is also useful in short form to
humans and scripts, but no option is available to boil it down.
Teach git-status to report the sequencer state in short form
using a new --sequencer (-S) switch. Output zero or more
simple state token strings indicating the deduced state of the
git sequencer.
Introduce a common function to determine the current sequencer
state so the regular status function and this short version can
share common code.
Add a substate to wt_status_state to track more detailed
information about a state, such as conflicted or resolved.
Move the am_empty_patch flage out of wt_status_state and into
this new substate.
State token strings which may be emitted and their meanings:
merge a git-merge is in progress
am a git-am is in progress
rebase a git-rebase is in progress
rebase-interactive a git-rebase--interactive is in progress
cherry-picka git-cherry-pick is in progress
bisect a git-bisect is in progress
conflicted there are unresolved conflicts
resolved conflicts have been resolved
editinginteractive rebase stopped to edit a commit
edited interactive rebase edit has been edited
splitting interactive rebase, commit is being split
I also considered adding these tokens, but I decided it was not
appropriate since these changes are not sequencer-related. But
it is possible I am being too short-sighted or have chosen the
switch name poorly.
clean
index
modified
untracked
Signed-off-by: Phil Hord ho...@cisco.com
---
Documentation/git-status.txt | 18 +++
builtin/commit.c | 12 -
wt-status.c | 125 +++
wt-status.h | 14 -
4 files changed, 145 insertions(+), 24 deletions(-)
diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt
index 67e5f53..31ffabd 100644
--- a/Documentation/git-status.txt
+++ b/Documentation/git-status.txt
@@ -38,6 +38,24 @@ OPTIONS
across git versions and regardless of user configuration. See
below for details.
+-S::
+--sequence::
+ Show the git sequencer status. This shows zero or more tokens
+ describing the state of several git sequence operations. Each
+ token is separated by a newline.
++
+ merge a merge is in progress
+ am an am is in progress
+ rebase a rebase is in progress
+ rebase-interactive an interactive rebase is in progress
+ cherry-picka cherry-pick is in progress
+ bisect a bisect is in progress
+ conflicted there are unresolved conflicts
+ resolved conflicts have been resolved
+ editinginteractive rebase stopped to edit a commit
+ edited interactive rebase edit has been edited
+ splitting interactive rebase, commit is being split
+
-u[mode]::
--untracked-files[=mode]::
Show untracked files.
diff --git a/builtin/commit.c b/builtin/commit.c
index a17a5df..9706ed9 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -114,7 +114,8 @@ static struct strbuf message = STRBUF_INIT;
static enum {
STATUS_FORMAT_LONG,
STATUS_FORMAT_SHORT,
- STATUS_FORMAT_PORCELAIN
+ STATUS_FORMAT_PORCELAIN,
+ STATUS_FORMAT_SEQUENCER
} status_format = STATUS_FORMAT_LONG;
static int opt_parse_m(const struct option *opt, const char *arg, int unset)
@@ -454,6 +455,9 @@ static int run_status(FILE *fp, const char *index_file,
const char *prefix, int
case STATUS_FORMAT_PORCELAIN:
wt_porcelain_print(s);
break;
+ case STATUS_FORMAT_SEQUENCER:
+ wt_sequencer_print(s);
+ break;
case STATUS_FORMAT_LONG:
wt_status_print(s);
break;
@@ -1156,6 +1160,9 @@ int cmd_status(int argc, const char **argv, const char
*prefix)
N_(show status concisely), STATUS_FORMAT_SHORT),
OPT_BOOLEAN('b', branch, s.show_branch,
N_(show branch information)),
+ OPT_SET_INT('S', sequence, status_format,
+ N_(show sequencer state),
+ STATUS_FORMAT_SEQUENCER),
OPT_SET_INT(0, porcelain, status_format,
N_(machine-readable output),
STATUS_FORMAT_PORCELAIN),
@@ -1216,6 +1223,9 @@ int cmd_status(int argc, const char **argv, const char
*prefix)
case STATUS_FORMAT_PORCELAIN:
wt_porcelain_print(s);
break;
+ case STATUS_FORMAT_SEQUENCER:
+
Re: [PATCH] git-submodule add: Record branch name in .gitmodules
Am 23.10.2012 21:16, schrieb Nahor: On 2012-10-22 09:34, W. Trevor King wrote: From: W. Trevor King wk...@tremily.us This removes a configuration step if you're trying to setup Ævar's $ git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) git pull' workflow from commit f030c96d8643fa0a1a9b2bd9c2f36a77721fb61f Author: Ævar Arnfjörð Bjarmason ava...@gmail.com Date: Fri May 21 16:10:10 2010 + git-submodule foreach: Add $toplevel variable If you're not using that workflow, I see no harm in recording the branch used to determine the original submodule commit. Except recording the branch name might raise expectations about what git will do with it. And as far as this patch goes, git won't do anything with it (yet). IMHO, the problem is that this works only for a very specific workflow. Normal git usage can very easily break this feature. For instance, the module may later be updated to a commit in branch B instead of branch A. Unless you remember to also update .gitmodule, you have then inconsistent information. A similar issue arises if branch A is deleted from the module later (for instance because it has been merged in the master branch and is not useful anymore). Then .gitmodule points to a non-existant branch. Same thing if a branch is renamed. Those are valid points. The next git submodule update will leave the submodule with a detached HEAD, making the branch configuration rather meaningless (except for your git submodule foreach ... use case of course). Last issue, the branch that exists in your local repository may not exist in someone else's repository, either because the branch is purely local, or because it has a different name on the remote repo. You'll always face this kind of problems with commits too when using submodules, so I don't see that as a problem here. I think a better place to store that kind of information is using git-notes. That way, if the branch is renamed or deleted, you can easily update the old notes to use the new name instead. I can't comment on that, as I have never been using notes so far. But I'd rather see a patch series properly implementing the always-tip mode Ævar mentions in f030c96d86 (and which is requested by some users), especially the interesting parts: What should git record as commit in that case and how are git status and git diff going to handle submodules which shall follow a specific branch. I assume git submodule update is the right point in time to fetch that branch again and check out a newer branch tip if necessary, but should that commit be added to the superproject for that submodule automagically or not? This patch falls short of this, as it does the easy part but not the interesting ones ;-) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2] git-pull: Avoid merge-base on detached head
git pull --rebase does some clever tricks to find the base
for $upstream , but it forgets that we may not have any
branch at all. When this happens, git merge-base reports its
usage help in the middle of an otherwise successful
rebase operation, because git-merge is called with one too
few parameters.
Since we do not need the merge-base trick in the case of a
detached HEAD, detect this condition and bypass the clever
trick and the usage noise.
Signed-off-by: Phil Hord ho...@cisco.com
---
git-pull.sh | 1 +
1 file changed, 1 insertion(+)
diff --git a/git-pull.sh b/git-pull.sh
index 2a10047..266e682 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -200,6 +200,7 @@ test true = $rebase {
require_clean_work_tree pull with rebase Please commit or
stash them.
fi
oldremoteref=
+ test -n $curr_branch
. git-parse-remote
remoteref=$(get_remote_merge_branch $@ 2/dev/null)
oldremoteref=$(git rev-parse -q --verify $remoteref)
--
1.8.0.2.gc921d59.dirty
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2] git-pull: Avoid merge-base on detached head
Add Signed-off-by... -- To unsubscribe from this list: send the line 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-submodule add: Record branch name in .gitmodules
On Tue, Oct 23, 2012 at 12:16:22PM -0700, Nahor wrote: On 2012-10-22 09:34, W. Trevor King wrote: For instance, the module may later be updated to a commit in branch B instead of branch A. Unless you remember to also update .gitmodule, you have then inconsistent information. But you're explicitly *using* the configured setting in git config --file $toplevel/.gitmodules submodule.$name.branch That should be a reminder that the configuration is important, and you'll remember to change it. Plus, the text from git-pull should clearly display the branch you are pulling, which gives you a second change to notice if something is going wrong. A similar issue arises if branch A is deleted from the module later (for instance because it has been merged in the master branch and is not useful anymore). Then .gitmodule points to a non-existant branch. Same thing if a branch is renamed. All of these are possible, and all would reqire manual intervention to pick out a new branch to follow. Plus, this patch is not even about the auto-pull application, it's about storing the initially cloned branch name. What you do with that name afterwards is up to you ;). I think a better place to store that kind of information is using git-notes. That way, if the branch is renamed or deleted, you can easily update the old notes to use the new name instead. Interesting. What would you attach the note too? Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
On Tue, 23 Oct 2012, Al Viro wrote: On Tue, Oct 23, 2012 at 01:30:26PM -0400, Chris Metcalf wrote: I fetched the series from your arch-tile branch and built it, and it works fine. It looks good from my inspection: Acked-by: Chris Metcalf cmetc...@tilera.com Thanks; Acked-by applied, branch pushed and put into no-rebase mode. BTW, something like detached Acked-by objects might be a good idea - i.e. commit-like git object with amendment to commit message of a given ancestor. The situation when ACKs come only after the commit has been pushed is quite common. Linus, what do you think about usefulness of such thing? Ability to append ACKed-by/Tested-by of an earlier commit to a branch instead of git commit --amend + possibly some cherry-picks + force-push, that is. I agree that this is a common issue. Acked-by/Reviewed-by mails come in after the fact that the patch has been committed to an immutable (i.e no-rebase mode) branch or if the change in question already hit Linus tree. Still it would be nice to have a recording of that in the git tree itself. Something like: git --attach SHA1 comment would be appreciated! Thanks, tglx -- To unsubscribe from this list: send the line 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] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
On Tue, Oct 23, 2012 at 10:47:28PM +0200, Thomas Gleixner wrote: I agree that this is a common issue. Acked-by/Reviewed-by mails come in after the fact that the patch has been committed to an immutable (i.e no-rebase mode) branch or if the change in question already hit Linus tree. Still it would be nice to have a recording of that in the git tree itself. Something like: git --attach SHA1 comment would be appreciated! It is spelled: git notes add -m comment SHA1 The resulting notes are stored in a separate revision-controlled branch and can be pushed and pulled like regular refs. Note, though, that the default refspecs do not yet include refs/notes, so you'd have to add them manually. The workflows around notes are not very mature yet, so if you start using them, feedback would be appreciated. -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: Git submodule for a local branch?
Am 22.10.2012 14:37, schrieb W. Trevor King: I have a bunch of branches in my repo (a, b, c, …), and I'd like to check them out into subdirectories of another branch (index). My initial inclination was to use something like $ git checkout index $ git branch a b c * index $ git submodule add -b a --reference ./ ./ dir-for-a/ $ git submodule add -b b --reference ./ ./ dir-for-b/ $ git submodule add -b c --reference ./ ./ dir-for-c/ but cloning a remote repository (vs. checking out a local branch) seems to be baked into the submodule implementation. Should I be thinking about generalizing git-submodule.sh, or am I looking under the wrong rock? My ideal syntax would be something like $ git submodule add -b c --local dir-for-c/ But then we'd have to be able to have two (or more) work trees using the same git directory, which current submodule code can't. The motivation is that I have website that contains a bunch of sub-sites, and the sub-sites share content. I have per-sub-site branches (a, b, c) and want a master branch (index) that aggregates them. Perhaps this is too much to wedge into a single repository? To me this sounds upside-down. I'd put the three sub-sites into different repositories and the shared content into a submodule that all three sub-sites use. At least that is how I do all my content sharing on the websites I have done ... does that make sense? -- To unsubscribe from this list: send the line 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-submodule: wrap branch option with in usage strings.
From: W. Trevor King wk...@tremily.us Use -b branch instead of -b branch. This brings the usage strings in line with other options, e.g. --reference repository. Signed-off-by: W. Trevor King wk...@tremily.us --- Documentation/git-submodule.txt | 2 +- git-submodule.sh| 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt index b4683bb..a65f38e 100644 --- a/Documentation/git-submodule.txt +++ b/Documentation/git-submodule.txt @@ -9,7 +9,7 @@ git-submodule - Initialize, update or inspect submodules SYNOPSIS [verse] -'git submodule' [--quiet] add [-b branch] [-f|--force] +'git submodule' [--quiet] add [-b branch] [-f|--force] [--reference repository] [--] repository [path] 'git submodule' [--quiet] status [--cached] [--recursive] [--] [path...] 'git submodule' [--quiet] init [--] [path...] diff --git a/git-submodule.sh b/git-submodule.sh index ab6b110..02f82e9 100755 --- a/git-submodule.sh +++ b/git-submodule.sh @@ -5,7 +5,7 @@ # Copyright (c) 2007 Lars Hjemli dashless=$(basename $0 | sed -e 's/-/ /') -USAGE=[--quiet] add [-b branch] [-f|--force] [--reference repository] [--] repository [path] +USAGE=[--quiet] add [-b branch] [-f|--force] [--reference repository] [--] repository [path] or: $dashless [--quiet] status [--cached] [--recursive] [--] [path...] or: $dashless [--quiet] init [--] [path...] or: $dashless [--quiet] update [--init] [-N|--no-fetch] [-f|--force] [--rebase] [--reference repository] [--merge] [--recursive] [--] [path...] -- 1.8.0.2.g09b91ca -- To unsubscribe from this list: send the line 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] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
On 23 October 2012 21:51, Jeff King p...@peff.net wrote: On Tue, Oct 23, 2012 at 10:47:28PM +0200, Thomas Gleixner wrote: I agree that this is a common issue. Acked-by/Reviewed-by mails come in after the fact that the patch has been committed to an immutable (i.e no-rebase mode) branch or if the change in question already hit Linus tree. Still it would be nice to have a recording of that in the git tree itself. Something like: git --attach SHA1 comment would be appreciated! It is spelled: git notes add -m comment SHA1 The resulting notes are stored in a separate revision-controlled branch and can be pushed and pulled like regular refs. Note, though, that the default refspecs do not yet include refs/notes, so you'd have to add them manually. The workflows around notes are not very mature yet, so if you start using them, feedback would be appreciated. What would be nice is that notes are pushed/pulled automatically with standard git push/fetch/pull commands. Usually git walks the DAG starting with the pulled commit or tag and following the parents. With notes, the reference is reversed, the note pointing to the commit and not the other way around. So handling this automatically in Git would be really useful. The other feature I'd like is that notes are automatically folded in the log during git rebase (maybe similar to the squash option). If you rebase, you lose all the notes (though this depends on the workflow, it may not be needed with published branches). -- Catalin -- To unsubscribe from this list: send the line 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] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
On Tue, Oct 23, 2012 at 10:09:46PM +0100, Catalin Marinas wrote: It is spelled: git notes add -m comment SHA1 The resulting notes are stored in a separate revision-controlled branch and can be pushed and pulled like regular refs. Note, though, that the default refspecs do not yet include refs/notes, so you'd have to add them manually. The workflows around notes are not very mature yet, so if you start using them, feedback would be appreciated. What would be nice is that notes are pushed/pulled automatically with standard git push/fetch/pull commands. Usually git walks the DAG starting with the pulled commit or tag and following the parents. With notes, the reference is reversed, the note pointing to the commit and not the other way around. So handling this automatically in Git would be really useful. Right, that's what I meant about the refspecs. You can configure git to push or pull them automatically, but it is not the default. Something like: git config --add remote.origin.fetch '+refs/notes/*:refs/notes/origin/*' would be a start, but you'd also want to git notes merge upstream's changes into your local notes (you _could_ just fetch straight into refs/notes/, but if you are making your own notes locally, you have to resolve it somehow). Exactly how to make this smooth is one of the workflow considerations; there's been discussion, but most people aren't using the feature, so we don't have a lot of data. If you are asking whether we could auto-follow notes for commits that have been fetched like we do for tags, the answer is not really. The notes tree is version-controlled as a whole, so you generally fetch the whole thing or not. And the remote does not advertise note information the same way we advertise peeled tag references, so a client does not know which notes are available for fetch. The intended strategy is to pull in the notes or not (though you can have multiple notes refs with different names, and fetch just a subset of them). The other feature I'd like is that notes are automatically folded in the log during git rebase (maybe similar to the squash option). If you rebase, you lose all the notes (though this depends on the workflow, it may not be needed with published branches). Git-rebase can automatically copy notes from one commit to another during a rebase, but you need to set notes.rewriteRef to do so (see git help config for details). The reason for this conservative default is that some notes may not be appropriate for automatic copying (e.g., a notes tree containing QA approval should probably be invalidated during a rebase, whereas one with commentary probably should). Squashing the notes into the commit message during rebase would be a useful feature (at least for some type of notes), but that feature does not currently exist (and as far as I recall, this is the first it has been proposed). Again, I think a lot of this comes down to the fact that not many people are really using notes for their daily workflow, so these itches are not coming up and getting scratched. -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] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
On Tue, 23 Oct 2012, Jeff King wrote: On Tue, Oct 23, 2012 at 10:47:28PM +0200, Thomas Gleixner wrote: I agree that this is a common issue. Acked-by/Reviewed-by mails come in after the fact that the patch has been committed to an immutable (i.e no-rebase mode) branch or if the change in question already hit Linus tree. Still it would be nice to have a recording of that in the git tree itself. Something like: git --attach SHA1 comment would be appreciated! It is spelled: git notes add -m comment SHA1 Cool! The resulting notes are stored in a separate revision-controlled branch Which branch(es) is/are that ? What are the semantics of that? Assume I commit something to branch foo Now I get that late Ack/Reviewed-by and want to associate that to that commit in branch foo. Does that go into notes/foo ? If yes, good. (Any other sensible prefix is good as well). If no, where does it go to? Later when I send a pull request to my upstream maintainer for branch foo does he get notes/foo automagically or do I have to request to pull him that separately? Either way is fine for me, though something which lets me automate that would be appreciated. I can work around that easily as my pull requests are generated via scripts, so I can add the secondary one for the dependent notes branch if necessary. Though it would be nice to avoid that. Avoiding that, i.e having a straight connection (maybe configurable) between foo and notes/foo and the commits which have not yet hit my upstream maintainer would make my life easier. I.e. I just have to check foo for stuff which is not upstream yet instead of checking both, but that might just be my laziness. Thoughts? tglx -- To unsubscribe from this list: send the line 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-submodule add: Record branch name in .gitmodules
On Tue, Oct 23, 2012 at 03:44:36PM -0400, W. Trevor King wrote: On Tue, Oct 23, 2012 at 12:16:22PM -0700, Nahor wrote: On 2012-10-22 09:34, W. Trevor King wrote: For instance, the module may later be updated to a commit in branch B instead of branch A. Unless you remember to also update .gitmodule, you have then inconsistent information. But you're explicitly *using* the configured setting in git config --file $toplevel/.gitmodules submodule.$name.branch That should be a reminder that the configuration is important, and you'll remember to change it. To make my case more cleanly, people already handle all the troublesome cases for branch.$name.remote, so handling similar upstream volatility for submodule.$name.branch should not be too difficult or surprising. On Tue, Oct 23, 2012 at 03:58:48PM -0400, Phil Hord wrote: On Mon, Oct 22, 2012 at 6:55 PM, W. Trevor King wk...@tremily.us wrote: How about -r/--record, with the recorded name being optional? --record-branch[=recorded_name] I like that just fine. This would satisfy Gerrit users that wanted to use '.', but also satisfy me with: git submodule add -rb=master foo bar However, there is a change that people would see that, and then use git submodule add -r -b=master foo bar which would checkout the HEAD from foo and store `-b=master` in submodule.$name.branch. I don't think it would. Ah, right, forcing the =name attached case would mean they'd have to use git submodule add -r=-b=master which doesn't sound like the sort of thing you'd do accidentally. Though I see in rev-parse--parseopts that the use of optional-argument options is discouraged. I'll work up a v2 patch and we'll see if anyone complains ;). -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [PATCH] git-submodule add: Record branch name in .gitmodules
On 2012-10-23 12:44, W. Trevor King wrote: On Tue, Oct 23, 2012 at 12:16:22PM -0700, Nahor wrote: On 2012-10-22 09:34, W. Trevor King wrote: For instance, the module may later be updated to a commit in branch B instead of branch A. Unless you remember to also update .gitmodule, you have then inconsistent information. But you're explicitly *using* the configured setting in git config --file $toplevel/.gitmodules submodule.$name.branch That should be a reminder that the configuration is important, and you'll remember to change it. From my experience with my colleagues at work, that's not going to happen. People are very good at forgetting to do something ;) Plus, the text from git-pull should clearly display the branch you are pulling, which gives you a second change to notice if something is going wrong. That's assuming that the user knows the branch that should be pulled and that he's paying attention to the output and not just quick-scanning for errors/warnings. Again, from my experience, that's not going to be the case. Plus, there isn't always a human being behind a git-pull, e.g. build bots. I think a better place to store that kind of information is using git-notes. That way, if the branch is renamed or deleted, you can easily update the old notes to use the new name instead. Interesting. What would you attach the note too? To the commits in the super-repo where a module branch is selected, i.e.: - where a module was added - where the module changed branch - where a super-branch was merged and there was a conflict on the module's branch name -- To unsubscribe from this list: send the line 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] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
On Tue, Oct 23, 2012 at 11:25:06PM +0200, Thomas Gleixner wrote: The resulting notes are stored in a separate revision-controlled branch Which branch(es) is/are that ? What are the semantics of that? They are stored in refs/notes/commits by default, but you can have multiple notes refs if you want to store logically distinct sets of notes. A notes ref's tree is just a tree whose entries are sha1s, and the file contents contain the notes themselves (the sha1s are broken down into subdirectories for performance, but git notes handles this behind the scenes). Technically you could check it out as a branch, edit, and commit, but git checkout is not happy to have a HEAD outside of refs/heads/, so you are stuck with plumbing like: $ git checkout `git rev-parse refs/notes/commits` $ edit edit edit $ git commit ... $ git update-ref refs/notes/commits HEAD It's probably not good for much beyond exploring how notes are implemented. See git help notes for more discussion. Assume I commit something to branch foo Now I get that late Ack/Reviewed-by and want to associate that to that commit in branch foo. Does that go into notes/foo ? No. It would go into refs/notes/commits, or you could ask it to go to refs/notes/acks if you wanted to keep them separate from your default notes. It is indexed by commit object, not by branch (so if that branch later goes away, the notes are always still attached to the commit objects, assuming they got merged in). Later when I send a pull request to my upstream maintainer for branch foo does he get notes/foo automagically or do I have to request to pull him that separately? No, he would have to pull your notes separately. Most of the discussion around sharing has been configuring the default refspec configuration to fetch notes. But in the kernel you guys use a lot of one-off pulls without configured remotes. I'm not sure what the right workflow would be. It might simply be to ask git to always pull particular notes commits at the same time (so you might push your notes to refs/notes/for-linus, and then git would automatically grab the notes when somebody pulls refs/heads/for-linus). Either way is fine for me, though something which lets me automate that would be appreciated. I can work around that easily as my pull requests are generated via scripts, so I can add the secondary one for the dependent notes branch if necessary. Though it would be nice to avoid that. Avoiding that, i.e having a straight connection (maybe configurable) between foo and notes/foo and the commits which have not yet hit my upstream maintainer would make my life easier. I.e. I just have to check foo for stuff which is not upstream yet instead of checking both, but that might just be my laziness. Thoughts? That all makes sense. Putting extra work on the puller is not a good long-term solution. So while sending them an extra also pull these notes line, even if it ends up being a cut-and-pastable single-liner, is not great (even if it is the most flexible thing). Using a convention based on name-equivalence seems like a sensible compromise. -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] git-submodule add: Record branch name in .gitmodules
On Tue, Oct 23, 2012 at 10:36:44PM +0200, Jens Lehmann wrote: Except recording the branch name might raise expectations about what git will do with it. And as far as this patch goes, git won't do anything with it (yet). As Phil pointed out, doing anything with this variable is ambiguous: On Mon, Oct 22, 2012 at 06:03:53PM -0400, Phil Hord wrote: Some projects now use the 'branch' config value to record the tracking branch for the submodule. Some ascribe different meaning to the configuration if the value is given vs. undefined. For example, see the Gerrit submodule-subscription mechanism. This change will cause those workflows to behave differently than they do now. On Tue, Oct 23, 2012 at 10:36:44PM +0200, Jens Lehmann wrote: But I'd rather see a patch series properly implementing the always-tip mode Ævar mentions in f030c96d86 (and which is requested by some users), especially the interesting parts: What should git record as commit in that case and how are git status and git diff going to handle submodules which shall follow a specific branch. I assume git submodule update is the right point in time to fetch that branch again and check out a newer branch tip if necessary, but should that commit be added to the superproject for that submodule automagically or not? This patch falls short of this, as it does the easy part but not the interesting ones ;-) I agree that I'm not working on always-tip. I'm just making that easier. For people that aren't interested in always-tip submodules (e.g. Gerrit folks), this patch is still useful. It would certainly be possible to build an always-tip implementation on top of submodule.$name.branch (as Ævar's one-liner does), but that would be another patch series. Personally, I think truly updates should be made explicitly, with a hand written commit message about why the updates are occuring. I also think that setting up and running auto-updates should be easy one-liners, not long, complicated ones ;). -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
[PATCH v2] git-submodule add: Add -r/--record option.
From: W. Trevor King wk...@tremily.us
This option allows you to record a submodule.name.branch option in
.gitmodules. Git does not currently use this configuration option for
anything, but users have used it for several things, so it makes sense
to add some syntactic sugar for initializing the value.
Current consumers:
Ævar uses this setting to designate the upstream branch for pulling
submodule updates:
$ git submodule foreach 'git checkout $(git config --file
$toplevel/.gitmodules submodule.$name.branch) git pull'
as he describes in
commit f030c96d8643fa0a1a9b2bd9c2f36a77721fb61f
Author: Ævar Arnfjörð Bjarmason ava...@gmail.com
Date: Fri May 21 16:10:10 2010 +
git-submodule foreach: Add $toplevel variable
Gerrit uses this setting to
“indicate the branch of a submodule project that when updated will
trigger automatic update of its registered gitlink.” [1]
I'm not clear on what that means, but they accept special values like
'.', so their usage is not compatible with Ævar's proposal.
By remaining agnostic on the variable usage, this patch makes
submodule setup more convenient for all parties.
[1]
https://gerrit.googlesource.com/gerrit/+/master/Documentation/user-submodules.txt
Signed-off-by: W. Trevor King wk...@tremily.us
---
Documentation/git-submodule.txt | 11 ++-
git-submodule.sh| 19 ++-
t/t7400-submodule-basic.sh | 25 +
3 files changed, 53 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index b4683bb..f9c74d6 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -9,7 +9,7 @@ git-submodule - Initialize, update or inspect submodules
SYNOPSIS
[verse]
-'git submodule' [--quiet] add [-b branch] [-f|--force]
+'git submodule' [--quiet] add [-b branch] [--record[=branch]] [-f|--force]
[--reference repository] [--] repository [path]
'git submodule' [--quiet] status [--cached] [--recursive] [--] [path...]
'git submodule' [--quiet] init [--] [path...]
@@ -209,6 +209,15 @@ OPTIONS
--branch::
Branch of repository to add as submodule.
+-r::
+--record::
+ Record a branch name used as `submodule.path.branch` in
+ `.gitmodules` for future reference. If you do not list an explicit
+ name here, the name given with `--branch` will be recorded. If that
+ is not set either, `HEAD` will be recorded. Because the branch name
+ is optional, you must use the equal-sign form (`-r=branch`), not
+ `-r branch`.
+
-f::
--force::
This option is only valid for add and update commands.
diff --git a/git-submodule.sh b/git-submodule.sh
index ab6b110..bc33112 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -5,7 +5,7 @@
# Copyright (c) 2007 Lars Hjemli
dashless=$(basename $0 | sed -e 's/-/ /')
-USAGE=[--quiet] add [-b branch] [-f|--force] [--reference repository] [--]
repository [path]
+USAGE=[--quiet] add [-b branch] [--record[=branch]] [-f|--force]
[--reference repository] [--] repository [path]
or: $dashless [--quiet] status [--cached] [--recursive] [--] [path...]
or: $dashless [--quiet] init [--] [path...]
or: $dashless [--quiet] update [--init] [-N|--no-fetch] [-f|--force]
[--rebase] [--reference repository] [--merge] [--recursive] [--] [path...]
@@ -20,6 +20,8 @@ require_work_tree
command=
branch=
+record_branch=
+record_branch_empty=
force=
reference=
cached=
@@ -257,6 +259,12 @@ cmd_add()
branch=$2
shift
;;
+ -r | --record)
+ record_branch_empty=true
+ ;;
+ -r=* | --record=*)
+ record_branch=${1#*=}
+ ;;
-f | --force)
force=$1
;;
@@ -328,6 +336,11 @@ cmd_add()
git ls-files --error-unmatch $sm_path /dev/null 21
die $(eval_gettext '\$sm_path' already exists in the index)
+ if test -z $record_branch test $record_branch_empty = true
+ then
+ record_branch=${branch:=HEAD}
+ fi
+
if test -z $force ! git add --dry-run --ignore-missing $sm_path
/dev/null 21
then
eval_gettextln The following path is ignored by one of your
.gitignore files:
@@ -366,6 +379,10 @@ Use -f if you really want to add it. 2
git config -f .gitmodules submodule.$sm_path.path $sm_path
git config -f .gitmodules submodule.$sm_path.url $repo
+ if test -n $branch
+ then
+ git config -f .gitmodules submodule.$sm_path.branch
$record_branch
+ fi
git add --force .gitmodules ||
die $(eval_gettext Failed to register submodule '\$sm_path')
}
diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh
index 5397037..88ae74c 100755
--- a/t/t7400-submodule-basic.sh
+++
Re: [PATCH] git-submodule add: Record branch name in .gitmodules
On 2012-10-23 13:36, Jens Lehmann wrote: Am 23.10.2012 21:16, schrieb Nahor: Last issue, the branch that exists in your local repository may not exist in someone else's repository, either because the branch is purely local, or because it has a different name on the remote repo. You'll always face this kind of problems with commits too when using submodules, so I don't see that as a problem here. Commits can't change or disappear during normal git operation (i.e. without using git push -f or git branch -D). A commit also has the same id in all the clones repository so there is no issue of a different name between the local and the remote repositories. -- To unsubscribe from this list: send the line 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] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
On Tue, Oct 23, 2012 at 03:06:59PM -0700, Marc Gauthier wrote: Can a later commit be eventually be made to reference some set of notes added so far, so they become part of the whole history signed by the HEAD SHA1? hence pulled/pushed automatically as well. Otherwise do you not end up with a forever growing separate tree of notes that loses some of the properties of being behind the head SHA1 (and perhaps less scalable in manageability)? Also that way notes are separate only temporarily. Interesting idea. It would be tough to do with existing objects. There are really only two ways for a commit to reference objects: 1. Via a parent header. But we would not want to include the notes tree as a separate parent. The semantics are all wrong, and would make your commit look like a nonsense merge. 2. As an entry in a tree. But we do not enforce connectivity of commits referenced in trees, because that is the way that submodules are implemented. So I think we would have to add a new header that says also, here are some notes for my history. That has two problems: 1. It's not backwards compatible. People with the new version of git will expect to have objects referenced by the new header, but older servers may not provide those objects (and vice versa). We can add a protocol extension to communicate this, but fundamentally you are going to lose the object connection any time it passes through a repo running an older git. 2. It's impure from the perspective of git's data model. Adding in the notes reference is not really a property of the commit. It's more like saying Oh, these other things happened to _past_ commits, and I'm just now mentioning them. So you pick an arbitrary commit to attach it to. What are the semantics with relation to that commit's position in the history graph? If I have a commit that is identical but without the notes reference, it will have a different sha1. But is it the same commit? So it's a bit ugly. I think I'd rather build out the transfer infrastructure to pass the notes references around more gracefully without trying to shoehorn them into the commit graph. As for automating the inclusion of notes in the flow, can that be conditional on some pattern in the note, so that e.g. the Acked-by's get included and folded in automatically, whereas others do not, according to settings? Yeah. You can store arbitrary data in notes (e.g., one of the existing uses of notes is to record metadata on the patch emails that led to a commit). Right now you typically separate it out by data type into separate refs, and then you ask git log to show you particular ones (so we see refs/notes/commits with --notes, but you can do --notes=foo to see refs/notes/foo, or even show multiple refs). For the fold-on-rebase idea, I'd think you would want something similar, like setting rebase.foldNotes to foo to say refs/notes/foo contains pseudo-headers that should be folded in like a signed-off-by. -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 0/8] fix git-config with duplicate variable entries
On Tue, Oct 23, 2012 at 04:13:44PM +0200, Ævar Arnfjörð Bjarmason wrote:
It fails a few tests in t1300, but it looks like those tests are testing
for the behavior we have identified as wrong, and should be fixed.
I think this patch looks good.
Thanks. It had a few minor flaws (like a memory leak). I fixed those,
updated the tests, and split it out into a few more readable commits. In
the process, I managed to uncover and fix a few other memory leaks in
the area. I think this version is much more readable, and writing the
rationale for patch 7 convinced me that it's the right thing to do.
Another round of review would be appreciated.
[1/8]: t1300: style updates
[2/8]: t1300: remove redundant test
[3/8]: t1300: test git config --get-all more thoroughly
[4/8]: git-config: remove memory leak of key regexp
[5/8]: git-config: fix regexp memory leaks on error conditions
[6/8]: git-config: collect values instead of immediately printing
[7/8]: git-config: do not complain about duplicate entries
[8/8]: git-config: use git_config_with_options
For those just joining us, the interesting bit is patch 7, which fixes
some inconsistencies between the git-config tool and how the internal
config callbacks work.
One other thing I think is worth clarifying (and I think should be
broken) is if you write a configuration like:
[foo]
bar = one
[foo]
bar = two
[foo]
bar = three
git-{config,var} -l will both give you:
foo.bar=one
foo.bar=two
foo.bar=three
Yes, that looks right.
And git config --get foo.bar will give you:
$ git config -f /tmp/test --get foo.bar
one
error: More than one value for the key foo.bar: two
error: More than one value for the key foo.bar: three
I think that it would be better if the config mechanism just silently
overwrote keys that clobbered earlier keys like your patch does.
Right.
But in addition can we simplify things for the consumers of
git-{config,var} -l by only printing:
foo.bar=three
Or are there too many variables like include.path that can
legitimately appear more than once.
No. Some variables can legitimately appear multiple times. E.g.,
remote.*.fetch, remote.*.push, and remote.*.url. Probably more that I am
forgetting. There are not many, but they do exist.
It's OK to tweak the regular get for them, since they are already
broken for that case[1]. You need to use --get-all if you expect the
variable to have multiple values. But when we are listing, we do not
have the hint as to what is expected, and we need to show all entries.
-Peff
[1] So the one useful thing that the current duplicate check is doing is
flagging errors where you wanted to use --get-all, but forgot to.
However, it's not really a sufficient safeguard anyway, since it
would not catch cases where the list was split across multiple
files (which does work with the internal callbacks that handle
lists, since they never even see that multiple files are involved).
It's much more important for git-config to be consistent with the
internal parsing behavior.
--
To unsubscribe from this list: send the line 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/8] t1300: style updates
The t1300 test script is quite old, and does not use our modern techniques or styles. This patch updates it in the following ways: 1. Use test_cmp instead of cmp (to make failures easier to debug). 2. Use test_cmp instead of 'test $(command) = expected'. This makes failures much easier to debug, and also makes sure that $(command) exits appropriately. 3. Write tests with the usual style of: test_expect_success 'test name' ' test commands ... ' rather than one-liners, or using backslash-continuation. This is purely a style fixup. There are still a few command happening outside of test_expect invocations, but they are all innoccuous system commands like cat and cp. In an ideal world, each test would be self sufficient and all commands would happen inside test_expect, but it is not immediately obvious how the grouping should work (some of the commands impact the subsequent tests, and some of them are setting up and modifying state that many tests depend on). This patch just picks the low-hanging style fruit, and we can do more fixes on top later. Signed-off-by: Jeff King p...@peff.net --- t/t1300-repo-config.sh | 185 ++--- 1 file changed, 113 insertions(+), 72 deletions(-) diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh index e127f35..e12dd4a 100755 --- a/t/t1300-repo-config.sh +++ b/t/t1300-repo-config.sh @@ -55,11 +55,13 @@ test_expect_success 'replace with non-match' \ test_cmp expect .git/config ' -test_expect_success 'replace with non-match' \ - 'git config core.penguin kingpin !blue' +test_expect_success 'replace with non-match' ' + git config core.penguin kingpin !blue +' -test_expect_success 'replace with non-match (actually matching)' \ - 'git config core.penguin very blue !kingpin' +test_expect_success 'replace with non-match (actually matching)' ' + git config core.penguin very blue !kingpin +' cat expect EOF [core] @@ -108,8 +110,9 @@ EOF lines EOF -test_expect_success 'unset with cont. lines' \ - 'git config --unset beta.baz' +test_expect_success 'unset with cont. lines' ' + git config --unset beta.baz +' cat expect \EOF [alpha] @@ -133,8 +136,9 @@ cp .git/config .git/config2 cp .git/config .git/config2 -test_expect_success 'multiple unset' \ - 'git config --unset-all beta.haha' +test_expect_success 'multiple unset' ' + git config --unset-all beta.haha +' cat expect EOF [beta] ; silly comment # another comment @@ -145,7 +149,9 @@ EOF [nextSection] noNewline = ouch EOF -test_expect_success 'multiple unset is correct' 'test_cmp expect .git/config' +test_expect_success 'multiple unset is correct' ' + test_cmp expect .git/config +' cp .git/config2 .git/config @@ -156,8 +162,9 @@ rm .git/config2 rm .git/config2 -test_expect_success '--replace-all' \ - 'git config --replace-all beta.haha gamma' +test_expect_success '--replace-all' ' + git config --replace-all beta.haha gamma +' cat expect EOF [beta] ; silly comment # another comment @@ -169,7 +176,9 @@ EOF [nextSection] noNewline = ouch EOF -test_expect_success 'all replaced' 'test_cmp expect .git/config' +test_expect_success 'all replaced' ' + test_cmp expect .git/config +' cat expect EOF [beta] ; silly comment # another comment @@ -200,7 +209,11 @@ test_expect_success 'really really mean test' ' test_cmp expect .git/config ' -test_expect_success 'get value' 'test alpha = $(git config beta.haha)' +test_expect_success 'get value' ' + echo alpha expect + git config beta.haha actual + test_cmp expect actual +' cat expect EOF [beta] ; silly comment # another comment @@ -231,18 +244,21 @@ test_expect_success 'ambiguous get' ' test_cmp expect .git/config ' -test_expect_success 'non-match' \ - 'git config --get nextsection.nonewline !for' +test_expect_success 'non-match' ' + git config --get nextsection.nonewline !for +' -test_expect_success 'non-match value' \ - 'test wow = $(git config --get nextsection.nonewline !for)' +test_expect_success 'non-match value' ' + test wow = $(git config --get nextsection.nonewline !for) +' test_expect_success 'ambiguous get' ' test_must_fail git config --get nextsection.nonewline ' -test_expect_success 'get multivar' \ - 'git config --get-all nextsection.nonewline' +test_expect_success 'get multivar' ' + git config --get-all nextsection.nonewline +' cat expect EOF [beta] ; silly comment # another comment @@ -290,8 +306,9 @@ test_expect_success 'correct key' 'git config 123456.a123 987' test_expect_success 'correct key' 'git config 123456.a123 987' -test_expect_success 'hierarchical section' \ - 'git config Version.1.2.3eX.Alpha beta' +test_expect_success 'hierarchical section' ' + git config Version.1.2.3eX.Alpha beta +'
[PATCH 2/8] t1300: remove redundant test
This test checks that git-config fails for an ambiguous get, but we check the exact same thing 3 tests beforehand. Signed-off-by: Jeff King p...@peff.net --- I update the matching test later in the series, and I didn't want to have to do it twice. t/t1300-repo-config.sh | 4 1 file changed, 4 deletions(-) diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh index e12dd4a..c6489dc 100755 --- a/t/t1300-repo-config.sh +++ b/t/t1300-repo-config.sh @@ -275,10 +275,6 @@ test_expect_success 'multivar replace' ' test_cmp expect .git/config ' -test_expect_success 'ambiguous value' ' - test_must_fail git config nextsection.nonewline -' - test_expect_success 'ambiguous unset' ' test_must_fail git config --unset nextsection.nonewline ' -- 1.8.0.3.g3456896 -- To unsubscribe from this list: send the line 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/8] t1300: test git config --get-all more thoroughly
We check that we can --get-all a multi-valued variable, but we do not actually confirm that the output is sensible. Doing so reveals that it works fine, but this will help us ensure we do not have regressions in the next few patches, which will touch this area. Signed-off-by: Jeff King p...@peff.net --- t/t1300-repo-config.sh | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh index c6489dc..74a297e 100755 --- a/t/t1300-repo-config.sh +++ b/t/t1300-repo-config.sh @@ -256,8 +256,13 @@ test_expect_success 'ambiguous get' ' test_must_fail git config --get nextsection.nonewline ' -test_expect_success 'get multivar' ' - git config --get-all nextsection.nonewline +test_expect_success 'multi-valued get-all returns all' ' + cat expect -\EOF + wow + wow2 for me + EOF + git config --get-all nextsection.nonewline actual + test_cmp expect actual ' cat expect EOF -- 1.8.0.3.g3456896 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/8] git-config: remove memory leak of key regexp
This is only called once per invocation, so it's not a major
leak, but it's easy to fix.
Signed-off-by: Jeff King p...@peff.net
---
builtin/config.c | 4
1 file changed, 4 insertions(+)
diff --git a/builtin/config.c b/builtin/config.c
index e1c33e0..e660d48 100644
--- a/builtin/config.c
+++ b/builtin/config.c
@@ -248,6 +248,10 @@ static int get_value(const char *key_, const char *regex_)
git_config_from_file(fn, system_wide, data);
free(key);
+ if (key_regexp) {
+ regfree(key_regexp);
+ free(key_regexp);
+ }
if (regexp) {
regfree(regexp);
free(regexp);
--
1.8.0.3.g3456896
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/8] git-config: fix regexp memory leaks on error conditions
The get_value function has a goto label for cleaning up on
errors, but it only cleans up half of what the function
might allocate. Let's also clean up the key and regexp
variables there.
Note that we need to take special care when compiling the
regex fails to clean it up ourselves, since it is in a
half-constructed state (we would want to free it, but not
regfree it).
Similarly, we fix git_config_parse_key to return NULL when it
fails, not a pointer to some already-freed memory.
Signed-off-by: Jeff King p...@peff.net
---
The diff is annoying in an interesting way: what I actually did was move
the regex cleanup code down, but it shows it as moving the bottom bits
up. I think it is just one of those ambiguous cases where either way is
equally valid and minimal.
builtin/config.c | 23 +--
config.c | 1 +
2 files changed, 14 insertions(+), 10 deletions(-)
diff --git a/builtin/config.c b/builtin/config.c
index e660d48..60d36e7 100644
--- a/builtin/config.c
+++ b/builtin/config.c
@@ -195,7 +195,8 @@ static int get_value(const char *key_, const char *regex_)
key_regexp = (regex_t*)xmalloc(sizeof(regex_t));
if (regcomp(key_regexp, key, REG_EXTENDED)) {
fprintf(stderr, Invalid key pattern: %s\n, key_);
- free(key);
+ free(key_regexp);
+ key_regexp = NULL;
ret = CONFIG_INVALID_PATTERN;
goto free_strings;
}
@@ -215,6 +216,8 @@ static int get_value(const char *key_, const char *regex_)
regexp = (regex_t*)xmalloc(sizeof(regex_t));
if (regcomp(regexp, regex_, REG_EXTENDED)) {
fprintf(stderr, Invalid pattern: %s\n, regex_);
+ free(regexp);
+ regexp = NULL;
ret = CONFIG_INVALID_PATTERN;
goto free_strings;
}
@@ -247,6 +250,15 @@ static int get_value(const char *key_, const char *regex_)
if (!do_all !seen system_wide)
git_config_from_file(fn, system_wide, data);
+ if (do_all)
+ ret = !seen;
+ else
+ ret = (seen == 1) ? 0 : seen 1 ? 2 : 1;
+
+free_strings:
+ free(repo_config);
+ free(global);
+ free(xdg);
free(key);
if (key_regexp) {
regfree(key_regexp);
@@ -257,15 +269,6 @@ static int get_value(const char *key_, const char *regex_)
free(regexp);
}
- if (do_all)
- ret = !seen;
- else
- ret = (seen == 1) ? 0 : seen 1 ? 2 : 1;
-
-free_strings:
- free(repo_config);
- free(global);
- free(xdg);
return ret;
}
diff --git a/config.c b/config.c
index 08e47e2..2fbe634 100644
--- a/config.c
+++ b/config.c
@@ -1280,6 +1280,7 @@ out_free_ret_1:
out_free_ret_1:
free(*store_key);
+ *store_key = NULL;
return -CONFIG_INVALID_KEY;
}
--
1.8.0.3.g3456896
--
To unsubscribe from this list: send the line 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 6/8] git-config: collect values instead of immediately printing
This is a refactor that will allow us to more easily tweak
the behavior for multi-valued variables, and it will
ultimately allow us to remove a lot git-config's custom code
in favor of the regular git_config code.
It does mean we're no longer streaming, and we're storing
more in memory for the --get-all case, but in practice it is
a tiny amount of data, and the results are instantaneous.
Signed-off-by: Jeff King p...@peff.net
---
The increase in line count is nicely offset by the next two patches.
builtin/config.c | 50 +++---
1 file changed, 35 insertions(+), 15 deletions(-)
diff --git a/builtin/config.c b/builtin/config.c
index 60d36e7..08e83fc 100644
--- a/builtin/config.c
+++ b/builtin/config.c
@@ -15,7 +15,6 @@ static int do_not_match;
static int use_key_regexp;
static int do_all;
static int do_not_match;
-static int seen;
static char delim = '=';
static char key_delim = ' ';
static char term = '\n';
@@ -95,8 +94,16 @@ static int show_config(const char *key_, const char *value_,
void *cb)
return 0;
}
-static int show_config(const char *key_, const char *value_, void *cb)
+struct strbuf_list {
+ struct strbuf *items;
+ int nr;
+ int alloc;
+};
+
+static int collect_config(const char *key_, const char *value_, void *cb)
{
+ struct strbuf_list *values = cb;
+ struct strbuf *buf;
char value[256];
const char *vptr = value;
int must_free_vptr = 0;
@@ -111,11 +118,15 @@ static int show_config(const char *key_, const char
*value_, void *cb)
(do_not_match ^ !!regexec(regexp, (value_?value_:), 0, NULL, 0)))
return 0;
+ ALLOC_GROW(values-items, values-nr + 1, values-alloc);
+ buf = values-items[values-nr++];
+ strbuf_init(buf, 0);
+
if (show_keys) {
- printf(%s, key_);
+ strbuf_addstr(buf, key_);
must_print_delim = 1;
}
- if (seen !do_all)
+ if (values-nr 1 !do_all)
dup_error = 1;
if (types == TYPE_INT)
sprintf(value, %d, git_config_int(key_, value_?value_:));
@@ -138,15 +149,15 @@ static int show_config(const char *key_, const char
*value_, void *cb)
vptr = ;
must_print_delim = 0;
}
- seen++;
if (dup_error) {
error(More than one value for the key %s: %s,
key_, vptr);
}
else {
if (must_print_delim)
- printf(%c, key_delim);
- printf(%s%c, vptr, term);
+ strbuf_addch(buf, key_delim);
+ strbuf_addstr(buf, vptr);
+ strbuf_addch(buf, term);
}
if (must_free_vptr)
/* If vptr must be freed, it's a pointer to a
@@ -166,6 +177,8 @@ static int get_value(const char *key_, const char *regex_)
struct config_include_data inc = CONFIG_INCLUDE_INIT;
config_fn_t fn;
void *data;
+ struct strbuf_list values = {0};
+ int i;
local = given_config_file;
if (!local) {
@@ -223,8 +236,8 @@ static int get_value(const char *key_, const char *regex_)
}
}
- fn = show_config;
- data = NULL;
+ fn = collect_config;
+ data = values;
if (respect_includes) {
inc.fn = fn;
inc.data = data;
@@ -241,19 +254,26 @@ static int get_value(const char *key_, const char *regex_)
if (do_all)
git_config_from_file(fn, local, data);
git_config_from_parameters(fn, data);
- if (!do_all !seen)
+ if (!do_all !values.nr)
git_config_from_file(fn, local, data);
- if (!do_all !seen global)
+ if (!do_all !values.nr global)
git_config_from_file(fn, global, data);
- if (!do_all !seen xdg)
+ if (!do_all !values.nr xdg)
git_config_from_file(fn, xdg, data);
- if (!do_all !seen system_wide)
+ if (!do_all !values.nr system_wide)
git_config_from_file(fn, system_wide, data);
if (do_all)
- ret = !seen;
+ ret = !values.nr;
else
- ret = (seen == 1) ? 0 : seen 1 ? 2 : 1;
+ ret = (values.nr == 1) ? 0 : values.nr 1 ? 2 : 1;
+
+ for (i = 0; i values.nr; i++) {
+ struct strbuf *buf = values.items + i;
+ fwrite(buf-buf, 1, buf-len, stdout);
+ strbuf_release(buf);
+ }
+ free(values.items);
free_strings:
free(repo_config);
--
1.8.0.3.g3456896
--
To unsubscribe from this list: send the line 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 8/8] git-config: use git_config_with_options
The git-config command has always implemented its own file
lookup and parsing order. This was necessary because its
duplicate-entry handling did not match the way git's
internal callbacks worked. Now that this is no longer the
case, we are free to reuse the existing parsing code.
This saves us a few lines of code, but most importantly, it
means that the logic for which files are examined is
contained only in one place and cannot diverge.
Signed-off-by: Jeff King p...@peff.net
---
builtin/config.c | 44 ++--
1 file changed, 2 insertions(+), 42 deletions(-)
diff --git a/builtin/config.c b/builtin/config.c
index 77efa69..f881053 100644
--- a/builtin/config.c
+++ b/builtin/config.c
@@ -165,22 +165,9 @@ static int get_value(const char *key_, const char *regex_)
static int get_value(const char *key_, const char *regex_)
{
int ret = CONFIG_GENERIC_ERROR;
- char *global = NULL, *xdg = NULL, *repo_config = NULL;
- const char *system_wide = NULL, *local;
- struct config_include_data inc = CONFIG_INCLUDE_INIT;
- config_fn_t fn;
- void *data;
struct strbuf_list values = {0};
int i;
- local = given_config_file;
- if (!local) {
- local = repo_config = git_pathdup(config);
- if (git_config_system())
- system_wide = git_etc_gitconfig();
- home_config_paths(global, xdg, config);
- }
-
if (use_key_regexp) {
char *tl;
@@ -229,32 +216,8 @@ static int get_value(const char *key_, const char *regex_)
}
}
- fn = collect_config;
- data = values;
- if (respect_includes) {
- inc.fn = fn;
- inc.data = data;
- fn = git_config_include;
- data = inc;
- }
-
- if (do_all system_wide)
- git_config_from_file(fn, system_wide, data);
- if (do_all xdg)
- git_config_from_file(fn, xdg, data);
- if (do_all global)
- git_config_from_file(fn, global, data);
- if (do_all)
- git_config_from_file(fn, local, data);
- git_config_from_parameters(fn, data);
- if (!do_all !values.nr)
- git_config_from_file(fn, local, data);
- if (!do_all !values.nr global)
- git_config_from_file(fn, global, data);
- if (!do_all !values.nr xdg)
- git_config_from_file(fn, xdg, data);
- if (!do_all !values.nr system_wide)
- git_config_from_file(fn, system_wide, data);
+ git_config_with_options(collect_config, values,
+ given_config_file, respect_includes);
ret = !values.nr;
@@ -267,9 +230,6 @@ free_strings:
free(values.items);
free_strings:
- free(repo_config);
- free(global);
- free(xdg);
free(key);
if (key_regexp) {
regfree(key_regexp);
--
1.8.0.3.g3456896
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Add -S, --gpg-sign option to manpage of git commit
git commit -S, --gpg-sign was mentioned in the program's help message, but not in the manpage. This adds an equivalent entry for the option in the manpage. Signed-off-by: Tom Jones t...@oxix.org --- On Sun, Oct 21, 2012 at 01:15:16PM -0700, Junio C Hamano wrote: Are you sure about this? The order [...] Good point. Please find a revised patch, with the newly documented option before the optional double dashes, below. Sign off? Now added, too. Documentation/git-commit.txt |6 +- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt index 9594ac8..4b78bd0 100644 --- a/Documentation/git-commit.txt +++ b/Documentation/git-commit.txt @@ -13,7 +13,7 @@ SYNOPSIS [-F file | -m msg] [--reset-author] [--allow-empty] [--allow-empty-message] [--no-verify] [-e] [--author=author] [--date=date] [--cleanup=mode] [--status | --no-status] - [-i | -o] [--] [file...] + [-i | -o] [-S[keyid]] [--] [file...] DESCRIPTION --- @@ -276,6 +276,10 @@ configuration variable documented in linkgit:git-config[1]. commit message template when using an editor to prepare the default commit message. +-S[keyid]:: +--gpg-sign[=keyid]:: + GPG-sign commit. + \--:: Do not interpret any more arguments as options. -- 1.7.2.5 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] git svn: canonicalize_url(): use svn_path_canonicalize when available
Jonathan Nieder jrnie...@gmail.com wrote:
Until Subversion 1.7 (more precisely r873487), the standard way to
canonicalize a URI was to call svn_path_canonicalize(). Use it.
This saves git svn from having to rely on our imperfect
reimplementation of the same. If the function doesn't exist or
returns undef, though, it can use the fallback code, which we keep to
be conservative. Since svn_path_canonicalize() was added before
Subversion 1.1, hopefully that doesn't happen often.
Hi Jonathan, this fails for me using http (but not file:// or svn://).
1/2 of this RFC looks fine, though.
subversion 1.6.12dfsg-6, apache2-mpm-prefork 2.2.16-6+squeeze8
(Debian squeeze)
$ SVN_HTTPD_PORT=12345 sh t9118-git-svn-funky-branch-names.sh -v
Initialized empty Git repository in /home/ew/git-core/t/trash
directory.t9118-git-svn-funky-branch-names/.git/
expecting success:
mkdir project project/trunk project/branches project/tags
echo foo project/trunk/foo
svn_cmd import -m $test_description project $svnrepo/pr ject
rm -rf project
svn_cmd cp -m fun $svnrepo/pr ject/trunk \
$svnrepo/pr ject/branches/fun plugin
svn_cmd cp -m more fun! $svnrepo/pr ject/branches/fun plugin \
$svnrepo/pr ject/branches/more fun plugin!
svn_cmd cp -m scary $svnrepo/pr ject/branches/fun plugin \
$svnrepo/pr ject/branches/$scary_uri
svn_cmd cp -m leading dot $svnrepo/pr ject/trunk \
$svnrepo/pr ject/branches/.leading_dot
svn_cmd cp -m trailing dot $svnrepo/pr ject/trunk \
$svnrepo/pr ject/branches/trailing_dot.
svn_cmd cp -m trailing .lock $svnrepo/pr ject/trunk \
$svnrepo/pr ject/branches/trailing_dotlock.lock
svn_cmd cp -m reflog $svnrepo/pr ject/trunk \
$svnrepo/pr ject/branches/not-a@{0}reflog@
start_httpd
Adding project/trunk
Adding project/trunk/foo
Adding project/branches
Adding project/tags
Committed revision 1.
Committed revision 2.
Committed revision 3.
Committed revision 4.
Committed revision 5.
Committed revision 6.
Committed revision 7.
Committed revision 8.
ok 1 - setup svnrepo
expecting success:
git svn clone -s $svnrepo/pr ject project
(
cd project
git rev-parse refs/remotes/fun%20plugin
git rev-parse refs/remotes/more%20fun%20plugin!
git rev-parse refs/remotes/$scary_ref
git rev-parse refs/remotes/%2Eleading_dot
git rev-parse refs/remotes/trailing_dot%2E
git rev-parse refs/remotes/trailing_dotlock%2Elock
git rev-parse refs/remotes/$non_reflog
)
Initialized empty Git repository in /home/ew/git-core/t/trash
directory.t9118-git-svn-funky-branch-names/project/.git/
Bad URL passed to RA layer: URL 'http://127.0.0.1:12345/pr ject' is malformed
or the scheme or host or path is missing at
/home/ew/git-core/perl/blib/lib/Git/SVN.pm line 310
not ok - 2 test clone with funky branch names
#
# git svn clone -s $svnrepo/pr ject project
# (
# cd project
# git rev-parse refs/remotes/fun%20plugin
# git rev-parse refs/remotes/more%20fun%20plugin!
# git rev-parse refs/remotes/$scary_ref
# git rev-parse refs/remotes/%2Eleading_dot
# git rev-parse refs/remotes/trailing_dot%2E
# git rev-parse refs/remotes/trailing_dotlock%2Elock
# git rev-parse refs/remotes/$non_reflog
# )
#
expecting success:
(
cd project
git reset --hard 'refs/remotes/more%20fun%20plugin!'
echo hello foo
git commit -m 'hello' -- foo
git svn dcommit
)
fatal: ambiguous argument 'refs/remotes/more%20fun%20plugin!': unknown revision
or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git command [revision...] -- [file...]'
not ok - 3 test dcommit to funky branch
#
# (
# cd project
# git reset --hard 'refs/remotes/more%20fun%20plugin!'
# echo hello foo
# git commit -m 'hello' -- foo
# git svn dcommit
# )
#
expecting success:
(
cd project
git reset --hard refs/remotes/$scary_ref
echo urls are scary foo
git commit -m eep -- foo
git svn dcommit
)
fatal: ambiguous argument 'refs/remotes/Abo-Uebernahme%20(Bug%20#994)': unknown
Re: Git submodule for a local branch?
On Tue, Oct 23, 2012 at 10:57:57PM +0200, Jens Lehmann wrote: Am 22.10.2012 14:37, schrieb W. Trevor King: but cloning a remote repository (vs. checking out a local branch) seems to be baked into the submodule implementation. Should I be thinking about generalizing git-submodule.sh, or am I looking under the wrong rock? My ideal syntax would be something like $ git submodule add -b c --local dir-for-c/ But then we'd have to be able to have two (or more) work trees using the same git directory, which current submodule code can't. And that's the problem I'm trying to solve ;). The motivation is that I have website that contains a bunch of sub-sites, and the sub-sites share content. I have per-sub-site branches (a, b, c) and want a master branch (index) that aggregates them. Perhaps this is too much to wedge into a single repository? To me this sounds upside-down. I'd put the three sub-sites into different repositories and the shared content into a submodule that all three sub-sites use. At least that is how I do all my content sharing on the websites I have done ... does that make sense? That makes sense, however the problem is not in the common content, it is in the final index: index |-- sub-site a (branch of sub-site-x) |-- sub-site b (branch of sub-site-x) `-- sub-site c (branch of sub-site-x) All of the sub-sites are branches of a single sub-site-x master: o--o--o--o sub-site-x \--o--o--o sub-site-1 \--osub-site-2 \--o sub-site-3 So they all live in the same repository. My index repository will have submodules for each of the sub-sites, and I'd like the index branch to *also* live in same repository as the subsites. This last bit is the sticky part. For a proof-of-concept example (where I currently use public repositories for the sub-site submodules), see http://wking.github.com/swc-workshop/ which uses gh-pages as the index branch, and master, 2012-10-caltech, and 2012-10-lbl for the sub-site branches. -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
[PATCH 1/2] Teach --recursive to submodule sync
The submodule sync command was somehow left out when --recursive was added to the other submodule commands. Teach sync to handle the --recursive switch by recursing when we're in a submodule we are sync'ing. Change the report during sync to show submodule-path instead of submodule-name to be consistent with the other submodule commands and to help recursed paths make sense. Signed-off-by: Phil Hord ho...@cisco.com --- git-submodule.sh | 18 +++--- 1 file changed, 15 insertions(+), 3 deletions(-) diff --git a/git-submodule.sh b/git-submodule.sh index ab6b110..6dd2338 100755 --- a/git-submodule.sh +++ b/git-submodule.sh @@ -11,7 +11,7 @@ USAGE=[--quiet] add [-b branch] [-f|--force] [--reference repository] [--] r or: $dashless [--quiet] update [--init] [-N|--no-fetch] [-f|--force] [--rebase] [--reference repository] [--merge] [--recursive] [--] [path...] or: $dashless [--quiet] summary [--cached|--files] [--summary-limit n] [commit] [--] [path...] or: $dashless [--quiet] foreach [--recursive] command - or: $dashless [--quiet] sync [--] [path...] + or: $dashless [--quiet] sync [--recursive] [--] [path...] OPTIONS_SPEC= . git-sh-setup . git-sh-i18n @@ -1008,7 +1008,9 @@ cmd_sync() case $1 in -q|--quiet) GIT_QUIET=1 - shift + ;; + --recursive) + recursive=1 ;; --) shift @@ -1021,6 +1023,8 @@ cmd_sync() break ;; esac + orig_flags=$orig_flags $(git rev-parse --sq-quote $1) + shift done cd_to_toplevel module_list $@ | @@ -1051,7 +1055,7 @@ cmd_sync() if git config submodule.$name.url /dev/null 2/dev/null then - say $(eval_gettext Synchronizing submodule url for '\$name') + say $(eval_gettext Synchronizing submodule url for '\$prefix\$sm_path') git config submodule.$name.url $super_config_url if test -e $sm_path/.git @@ -1061,6 +1065,14 @@ cmd_sync() cd $sm_path remote=$(get_default_remote) git config remote.$remote.url $sub_origin_url + + if test -n $recursive + then + ( + prefix=$prefix$sm_path/ + eval cmd_sync $orig_args + ) + fi ) fi fi -- 1.8.0.2.gcde19fc.dirty -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] Add tests for submodule sync --recursive
Signed-off-by: Phil Hord ho...@cisco.com --- t/t7403-submodule-sync.sh | 55 +-- 1 file changed, 53 insertions(+), 2 deletions(-) diff --git a/t/t7403-submodule-sync.sh b/t/t7403-submodule-sync.sh index 524d5c1..94e26c4 100755 --- a/t/t7403-submodule-sync.sh +++ b/t/t7403-submodule-sync.sh @@ -17,18 +17,25 @@ test_expect_success setup ' git commit -m upstream git clone . super git clone super submodule + (cd submodule +git submodule add ../submodule sub-submodule +test_tick +git commit -m sub-submodule + ) (cd super git submodule add ../submodule submodule test_tick git commit -m submodule ) git clone super super-clone - (cd super-clone git submodule update --init) + (cd super-clone git submodule update --init --recursive) git clone super empty-clone (cd empty-clone git submodule init) git clone super top-only-clone git clone super relative-clone - (cd relative-clone git submodule update --init) + (cd relative-clone git submodule update --init --recursive) + git clone super recursive-clone + (cd recursive-clone git submodule update --init --recursive) ' test_expect_success 'change submodule' ' @@ -46,6 +53,11 @@ test_expect_success 'change submodule url' ' git pull ) mv submodule moved-submodule + (cd moved-submodule +git config -f .gitmodules submodule.sub-submodule.url ../moved-submodule +test_tick +git commit -a -m moved-sub-submodule + ) (cd super git config -f .gitmodules submodule.submodule.url ../moved-submodule test_tick @@ -61,6 +73,9 @@ test_expect_success 'git submodule sync should update submodule URLs' ' test -d $(cd super-clone/submodule git config remote.origin.url ) + test ! -d $(cd super-clone/submodule/sub-submodule +git config remote.origin.url + ) (cd super-clone/submodule git checkout master git pull @@ -70,6 +85,25 @@ test_expect_success 'git submodule sync should update submodule URLs' ' ) ' +test_expect_success 'git submodule sync --recursive should update all submodule URLs' ' + (cd super-clone +(cd submodule + git pull --no-recurse-submodules +) +git submodule sync --recursive + ) + test -d $(cd super-clone/submodule +git config remote.origin.url + ) + test -d $(cd super-clone/submodule/sub-submodule +git config remote.origin.url + ) + (cd super-clone/submodule/sub-submodule +git checkout master +git pull + ) +' + test_expect_success 'git submodule sync should update known submodule URLs' ' (cd empty-clone git pull @@ -107,6 +141,23 @@ test_expect_success 'git submodule sync handles origin URL of the form foo/bar #actual foo/submodule test $(git config remote.origin.url) = ../foo/submodule ) + (cd submodule/sub-submodule +test $(git config remote.origin.url) != ../../foo/submodule + ) + ) +' + +test_expect_success 'git submodule sync --recursive propagates changes in origin' ' + (cd recursive-clone +git remote set-url origin foo/bar +git submodule sync --recursive + (cd submodule +#actual foo/submodule +test $(git config remote.origin.url) = ../foo/submodule + ) + (cd submodule/sub-submodule +test $(git config remote.origin.url) = ../../foo/submodule + ) ) ' -- 1.8.0.2.gcde19fc.dirty -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
git submodule sync --recursive
[PATCH 1/2] Teach --recursive to submodule sync [PATCH 2/2] Add tests for submodule sync --recursive This series implements and tests git submodule sync --recursive -- To unsubscribe from this list: send the line 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: The config include mechanism doesn't allow for overwriting
On Tue, Oct 23, 2012 at 10:13 AM, Ævar Arnfjörð Bjarmason
ava...@gmail.com wrote:
[snip]
And git config --get foo.bar will give you:
$ git config -f /tmp/test --get foo.bar
one
error: More than one value for the key foo.bar: two
error: More than one value for the key foo.bar: three
I think that it would be better if the config mechanism just silently
overwrote keys that clobbered earlier keys like your patch does.
But in addition can we simplify things for the consumers of
git-{config,var} -l by only printing:
foo.bar=three
Or are there too many variables like include.path that can
legitimately appear more than once.
I frequently use pushurl in my remotes to push my master branch both
to the original repo and my forked version. I find it very helpful in
my workflow, and would hate to lose that. That said, I do like the
idea of having a config file and the ability to override some of the
variables.
-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: The config include mechanism doesn't allow for overwriting
On Tue, Oct 23, 2012 at 08:46:47PM -0400, John Szakmeister wrote:
On Tue, Oct 23, 2012 at 10:13 AM, Ævar Arnfjörð Bjarmason
ava...@gmail.com wrote:
[snip]
And git config --get foo.bar will give you:
$ git config -f /tmp/test --get foo.bar
one
error: More than one value for the key foo.bar: two
error: More than one value for the key foo.bar: three
I think that it would be better if the config mechanism just silently
overwrote keys that clobbered earlier keys like your patch does.
But in addition can we simplify things for the consumers of
git-{config,var} -l by only printing:
foo.bar=three
Or are there too many variables like include.path that can
legitimately appear more than once.
I frequently use pushurl in my remotes to push my master branch both
to the original repo and my forked version. I find it very helpful in
my workflow, and would hate to lose that. That said, I do like the
idea of having a config file and the ability to override some of the
variables.
No, that won't go anywhere. We really do have two classes of variables:
things that are expected to be single values, and things that are
expected to be lists.
From the perspective of the config code, we don't know or care which is
which, and just feed all entries sequentially to a C callback. In
practice, the callbacks do one of two things:
1. Append the values into a list.
2. Overwrite, and end up with the final value seen.
The trouble is that git-config has to print the values in a reasonable
way, so it asks the caller to give a hint about which it wants (--get
versus --get-all). But in the single-value case did not behave like the
C callbacks, which is what my series fixes.
Using git config -l is more like asking the config machinery to just
feed us everything, which is what the C callbacks see. Which is more
flexible, but way less convenient for the caller. But it doesn't need to
be fixed, since the caller has all the information to implement whatever
semantics they like.
-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] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
On Wed, Oct 24, 2012 at 12:25 AM, Thomas Gleixner t...@linutronix.de wrote: It is spelled: git notes add -m comment SHA1 Cool! Don't use them for anything global. Use them for local codeflow, but don't expect them to be distributed. It's a separate flow, and while it *can* be distributed, it's not going to be for the kernel, for example. So no, don't start using this to ack things, because the acks *will* get lost. Linus -- To unsubscribe from this list: send the line 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] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
On Wed, Oct 24, 2012 at 04:02:49AM +0300, Linus Torvalds wrote: On Wed, Oct 24, 2012 at 12:25 AM, Thomas Gleixner t...@linutronix.de wrote: It is spelled: git notes add -m comment SHA1 Cool! Don't use them for anything global. Use them for local codeflow, but don't expect them to be distributed. It's a separate flow, and while it *can* be distributed, it's not going to be for the kernel, for example. So no, don't start using this to ack things, because the acks *will* get lost. How about git commit --allow-empty, with belated ACK for commit Acked-by: ... as commit message? I mean, that ought to work and propagate sanely, but I'm really not sure if that's something in a good taste and should be allowed as a common practice... -- To unsubscribe from this list: send the line 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] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
On Wed, Oct 24, 2012 at 4:56 AM, Al Viro v...@zeniv.linux.org.uk wrote: How about git commit --allow-empty, with belated ACK for commit Don't bother. It's not that important, and it's just distracting. It's not like this is vital information. If you pushed it out without the ack, it's out without the ack. Big deal. Linus -- To unsubscribe from this list: send the line 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: Long clone time after done.
On Wed, Oct 24, 2012 at 1:30 AM, Uri Moszkowicz u...@4refs.com wrote: I have a large repository which I ran git gc --aggressive on that I'm trying to clone on a local file system. I would expect it to complete very quickly with hard links but it's taking about 6min to complete with no checkout (git clone -n). I see the message Clining into 'repos'... done. appear after a few seconds but then Git just hangs there for another 6min. Any idea what it's doing at this point and how I can speed it up? done. is printed by clone_local(), which is called in cmd_clone(). After that there are just a few more calls. Maybe you could add a few printf in between these calls, see which one takes most time? -- 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
Large number of object files
Continuing to work on improving clone times, using git gc --aggressive has resulted in a large number of tags combining into a single file but now I have a large number of files in the objects directory - 131k for a ~2.7GB repository. Any way to reduce the number of these files to speed up clones? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
