Re: [RFD/PATCH 3/5] checkout: Use remote refspecs when DWIMming tracking branches
On Fri, Apr 19, 2013 at 9:44 PM, Junio C Hamano gits...@pobox.com wrote: I am _guessing_ that you mean a case like this: [remote origin] fetch = refs/heads/*:refs/remotes/origin/* [remote xyzzy] fetch = refs/heads/*:refs/remotes/xyzzy/nitfol/* [remote frotz] fetch = refs/heads/*:refs/remotes/frotz/nitfol/* and refs/remotes/origin/foo or refs/remotes/frotz/nitfol/foo do not exist but refs/remotes/xyzzy/nitfol/foo does. And the user says git checkout foo. Instead of finding a remote ref that matches refs/remotes/*/foo pattern (and assuming the part that matched * is the name of the remote), you can iterate the RHS of the refspecs to see if there is a unique match. Then the new branch can unambiguously find that its upstream is xyzzy's foo. Correct. I will try to phrase the problem better in the next iteration. I think it makes sense to update the semantics like that. Wouldn't the traditional case (i.e. without nitfol/ in the xyzzy/frotz remotes above) be a mere special case for this new logic? Yes. You mentioned there is a regression caught by existing tests if you go this route, but I do not see how that happens. It's technically a regression since it breaks existing tests, but as you observe in your reply to patch #5, it is really the test that relies on current implementation details. ...Johan -- Johan Herland, jo...@herland.net www.herland.net -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[QUERY] Why do we have git-completion.zsh?
Hi, I realize that we maintain a bash completion script, and a thin wrapper around it for ZSH. However, I don't understand why we maintain it, because there's a comprehensive first-class completer in ZSH core [1] which I use all the time. Shouldn't the completion folks be contributing to this instead? Thanks. [1]: https://github.com/zsh-users/zsh/blob/master/Completion/Unix/Command/_git -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Some observations on log -L
Hi, Ever since 'git log -L' made it to `pu`, I've been playing with it to see how it can be useful. Here are some of my observations: 1. Specifying line ranges by hand are too painful. I would really love it if it could parse the lines off a patch prepared by format-patch or something. 2. Specifying regex ranges are really useful to see the history of a function. But I think it could really benefit from a tool that actually understands the language (using Clang Tooling). If we were to build such a tool, git-core could benefit immensely from it: we'd have smarter merges too, for instance. 3. Often, I want to know the people to contact for a segment of code. Blame is useless here, because it only considers the most recent commit, when I want to know the authors of all the commits that helped shaped that segment of code. So, I think shortlog could really benefit from a -L. Is this easily doable? Thanks for listening. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re[2]: State of CVS-to-git conversion tools (Was: Re: cvsps: bad usage: invalid argument --norc)
Hi Eric. ESR cvs-fast-export does not have incremental-import support. ESR Whether git-cvs-import has it depend on which version you have ESR and what backend it it is using. I don't maintain that wrapper. Did you mean git-fast-import? Or do you know any wrapper that already uses cvsps3 --fast-export? I need it, because full import takes too long. The central repo of my employer is CVS, other people commit to it and I use git internally to be able to tidy my commit history before exporting to CVS. ESR You are out of luck. That feature was dependent on a very fragile ESR coupling... OK, OK, I get it. First of all, I think cvsps3 has almost everithing required for incremental import: one could just take the date of the last commit and invoke cvs ps with the '-d' flag. However, to import new commits into existing branches the stream should contain the from command in oldest commits in each branch (now missing). If the branch already exists in the target git repo, it's easy to refer it in the stream: from refs/heads/branchname^0 But if the branch is new, but it's parent commit is already imported, I guess, the only way to refer it is by its SHA-1 Eric, what parent information can cvsps provide for the first commit in a branch, when invoked with the '-d' flag? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] upload-pack: ignore 'shallow' lines with unknown obj-ids
On Sat, Apr 20, 2013 at 8:05 PM, Michael Heemskerk mheemsk...@atlassian.com wrote: When the client sends a 'shallow' line for an object that the server does not have, the server currently dies with the error: did not find object for shallow obj-id. The client may have received the object from a different server, or the object may have been garbage collected by the server. In either case, the object is not relevant for calculating the pack that is to be sent and can be safely ignored. The documentation in technical/pack-protocol.txt has been updated to remove the restriction that Clients MUST NOT mention an obj-id which it does not know exists on the server. This requirement is not realistic because clients cannot know whether an object has been garbage collected by the server. Signed-off-by: Michael Heemskerk mheemsk...@atlassian.com I'm not an expert in git protocol (or shallow extension in particular) but the reasoning sounds right and the implemention looks correct. Acked-by: Duy Nguyen pclo...@gmail.com -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gitk: workaround Tcl/Tk Cmd-TAB behavior on OSX
On Apr 20, 2013, at 9:19 AM, Paul Mackerras pau...@samba.org wrote: On Thu, Apr 11, 2013 at 01:02:48AM +0600, Tair Sabirgaliev wrote: On OSX Tcl/Tk application windows are created behind all the applications down the stack of windows. This is very annoying, because once a gitk window appears, it's the downmost window and switching to it is pain. The patch is trivial: if we are on OSX, emulate Cmd-Shift-TAB key event, so that the gitk application window is brought from bottom to top. Is this really the only way to do it? It seems a bit hacky to me. I would think you should be able to use the wm command to achieve what you want. I don't use Mac OS, so I don't know exactly how Tcl/Tk behaves on it, but this page looks like it might hold some clues for what you want to do: http://teapot.activestate.com/package/name/windowlist/ver/1.4/arch/tcl/file.tm Today I did some further investigations on reasons app windows going behind. Turns out this is not something specific to Tcl/Tk. On OSX, GUI applications can be launched from Terminal in 2 ways: 1. Interactively, directly using app executable: sh$ /Applications/Chess.app/Contents/MacOS/Chess 2. Asynchronously, using OSX 'open' facility sh$ open -a Chess The problem with 1st way is that OSX always puts the new app window behind the others, thus making sure the focus remains at Terminal input. The problem with the 2nd approach is that app is launched 'asynchronously', detached from Terminal, so when you close the app, focus doesn't necessarily return back to Terminal as it would normally do in Linux for example. So, yes, this is a really hacky workaround, but it consistently takes the interactively launched app window to foreground on most modern OSX versions. And regarding the link you provided -- I tried them, unfortunately the techniques there don't bring the application to foreground. Looks like they are mostly intended to manipulate windows within a single multi-window application. Tair.-- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: is git-p4 compatible with p4/linux?
On Thu, Apr 18, 2013 at 5:09 PM, Pete Wyckoff p...@padd.com wrote:
First issue
---
git-p4 assumes the output of 'p4 print' adds a newline to the
target. To work around this, git-p4.py strips the last char from
symlinks as shown in the following snippet:
if type_base == symlink:
git_mode = 12
# p4 print on a symlink contains target\n; remove the newline
data = ''.join(contents)
contents = [data[:-1]]
This line could be made more robust by changing it to:
contents = [data.rstrip('\n')]
That way it only strips off newlines if they exist, which essentially
papers over these rogue depot files.
Alternatively, it could use rstrip() with no arguments to cast a wider
net and catch all whitespace.
--
David
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Is there a way to speed up remote-hg?
I really like the idea of remote-hg, but it appears to be awfully slow on the clone step: ... progress revision 81499 'master' (81500/81664) progress revision 81599 'master' (81600/81664) Checking out files: 100% (3744/3744), done. git clone hg::https://bitbucket.org/python_mirrors/cpython 4484.61s user 41510.05s system 102% cpu 12:29:45.73 total That seems like an awfully high price to pay. It there a way to speed this up at all? I realize the Python hg repo has more history than others, but even a smaller project like Sphinx takes a while: git clone hg::https://bitbucket.org/birkenfeld/sphinx 56.41s user 90.86s system 98% cpu 2:28.87 total I was just curious if something more could be done here. I don't go around cloning Python all the time, so it's not a big issue, but it'd be nice if it was more performant. Thanks! -John -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/5] Documentation/shortlog improvements
Hi, I was going through the shortlog documentation and was saddened to see that it was inaccurate and inconsistent with the log documentation. I use shortlog quite a lot, and like it very much. So, here's a small series fixing some problems. [3/5] and [4/5] came out of my desire to copy out parts of git-log.txt into git-shortlog.txt (I had to fix git-log.txt first). Thanks. Ramkumar Ramachandra (5): git-shortlog.txt: remove (-h|--help) from OPTIONS builtin/shortlog.c: make usage string consistent with log git-log.txt: fix description of since..until git-log.txt: rewrite note on why -- may be required git-shortlog.txt: make SYNOPSIS match log, update OPTIONS Documentation/git-log.txt | 10 +- Documentation/git-shortlog.txt | 23 ++- builtin/shortlog.c | 4 +--- 3 files changed, 24 insertions(+), 13 deletions(-) -- 1.8.2.1.506.gbce9ff0 -- To unsubscribe from this list: send the line 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/5] git-shortlog.txt: remove (-h|--help) from OPTIONS
To be consistent with the documentation of all the other commands, remove (-h|--help) from the OPTIONS section. Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- Documentation/git-shortlog.txt | 4 1 file changed, 4 deletions(-) diff --git a/Documentation/git-shortlog.txt b/Documentation/git-shortlog.txt index c308e91..c7f7f51 100644 --- a/Documentation/git-shortlog.txt +++ b/Documentation/git-shortlog.txt @@ -26,10 +26,6 @@ reference to the current repository. OPTIONS --- --h:: ---help:: - Print a short usage message and exit. - -n:: --numbered:: Sort output according to the number of commits per author instead -- 1.8.2.1.506.gbce9ff0 -- To unsubscribe from this list: send the line 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/5] git-log.txt: fix description of since..until
First, since and until are ways to specify revisions, not commits, as gitrevisions.txt would indicate. Second, 'since..until' is simply indicative of how users would normally want to specify the rev spec: it need not conform to this form, and can take any form that gitrevisions.txt lists. A 'git log :/quuxery' is perfectly valid, for instance. Make these two corrections to the description of 'since..until' under OPTIONS. Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- Documentation/git-log.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt index 69db578..f03ae74 100644 --- a/Documentation/git-log.txt +++ b/Documentation/git-log.txt @@ -25,11 +25,11 @@ OPTIONS --- since..until:: - Show only commits between the named two commits. When + Show only commits between the named two revisions. When either since or until is omitted, it defaults to `HEAD`, i.e. the tip of the current branch. - For a more complete list of ways to spell since - and until, see linkgit:gitrevisions[7]. + For a more complete list of ways to spell since..until, + see linkgit:gitrevisions[7]. --follow:: Continue listing the history of a file beyond renames -- 1.8.2.1.506.gbce9ff0 -- To unsubscribe from this list: send the line 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/5] builtin/shortlog.c: make usage string consistent with log
-- is used to separate pathspecs from the rev specs, and not rev
specs from the options, as the shortlog_usage string currently
indicates. In correcting this usage string, make it consistent with
the log_usage string.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
builtin/shortlog.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/builtin/shortlog.c b/builtin/shortlog.c
index 240bff3..a2f54f2 100644
--- a/builtin/shortlog.c
+++ b/builtin/shortlog.c
@@ -10,9 +10,7 @@
#include parse-options.h
static char const * const shortlog_usage[] = {
- N_(git shortlog [-n] [-s] [-e] [-w] [rev-opts] [--] [commit-id...
]),
- ,
- N_([rev-opts] are documented in git-rev-list(1)),
+ N_(git shortlog [options] [since..until] [[--] [path...]]),
NULL
};
--
1.8.2.1.506.gbce9ff0
--
To unsubscribe from this list: send the line 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/5] git-shortlog.txt: make SYNOPSIS match log, update OPTIONS
There are broadly two problems with the current SYNOPSIS. First, it completely omits the detail that paths can be specified. Second, it attempts to list all the options: this is futile as, in addition to the options unique to it, it accepts all the options that git-rev-list accepts. In fixing these problems, make the SYNOPSIS consistent with that in git-log.txt. Also add the corresponding sections to OPTIONS. Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- Documentation/git-shortlog.txt | 21 +++-- 1 file changed, 19 insertions(+), 2 deletions(-) diff --git a/Documentation/git-shortlog.txt b/Documentation/git-shortlog.txt index c7f7f51..d02ac03 100644 --- a/Documentation/git-shortlog.txt +++ b/Documentation/git-shortlog.txt @@ -8,8 +8,8 @@ git-shortlog - Summarize 'git log' output SYNOPSIS [verse] -git log --pretty=short | 'git shortlog' [-h] [-n] [-s] [-e] [-w] -'git shortlog' [-n|--numbered] [-s|--summary] [-e|--email] [-w[width[,indent1[,indent2 commit... +git log --pretty=short | 'git shortlog' [options] +'git shortlog' [options] [since..until] [[\--] path...] DESCRIPTION --- @@ -26,6 +26,13 @@ reference to the current repository. OPTIONS --- +since..until:: + Consider only commits between the named two revisions. When + either since or until is omitted, it defaults to `HEAD`, + i.e. the tip of the current branch. For a more complete list + of ways to spell since..until, see + linkgit:gitrevisions[7]. + -n:: --numbered:: Sort output according to the number of commits per author instead @@ -56,6 +63,16 @@ OPTIONS If width is `0` (zero) then indent the lines of the output without wrapping them. +[\--] path...:: + Consider only commits that are enough to explain how the files + that match the specified paths came to be. See History + Simplification below for details and other simplification + modes. ++ +Paths may need to be prefixed with \-- to separate them from +options or revisions, when confusion arises. + +include::rev-list-options.txt[] MAPPING AUTHORS --- -- 1.8.2.1.506.gbce9ff0 -- To unsubscribe from this list: send the line 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/5] git-log.txt: rewrite note on why -- may be required
In its current form, the note talks about separating options from branch names and refnames in the same sentence. This is entirely inaccurate, as the rev spec need not be a set of branch names or ref names. Rewrite it to use the word revisions. Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- Documentation/git-log.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt index f03ae74..1a9c3ca 100644 --- a/Documentation/git-log.txt +++ b/Documentation/git-log.txt @@ -75,8 +75,8 @@ produced by --stat etc. Simplification below for details and other simplification modes. + -To prevent confusion with options and branch names, paths may need to -be prefixed with \-- to separate them from options or refnames. +Paths may need to be prefixed with \-- to separate them from +options or revisions, when confusion arises. include::rev-list-options.txt[] -- 1.8.2.1.506.gbce9ff0 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: is git-p4 compatible with p4/linux?
dav...@gmail.com wrote on Sat, 20 Apr 2013 03:50 -0700:
On Thu, Apr 18, 2013 at 5:09 PM, Pete Wyckoff p...@padd.com wrote:
First issue
---
git-p4 assumes the output of 'p4 print' adds a newline to the
target. To work around this, git-p4.py strips the last char from
symlinks as shown in the following snippet:
if type_base == symlink:
git_mode = 12
# p4 print on a symlink contains target\n; remove the newline
data = ''.join(contents)
contents = [data[:-1]]
This line could be made more robust by changing it to:
contents = [data.rstrip('\n')]
That way it only strips off newlines if they exist, which essentially
papers over these rogue depot files.
Alternatively, it could use rstrip() with no arguments to cast a wider
net and catch all whitespace.
I was tempted to do that, but it is possible to put \n and other
space characters in the target of symlinks. It's unfortunate
that p4 always appears to tack on a newline itself.
We'll see if Alex comes up with a pattern that shows how he ended
up with the odd symlinks.
-- Pete
--
To unsubscribe from this list: send the line 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 log -p unexpected behaviour - security risk?
On Thu, Apr 11, 2013 at 11:36:26AM +0100, John Tapsell wrote:
Is there a way to make --cc default?
If you use aliases, something like this is easy:
git config --global --add alias.lp 'log --patch --cc'
I use aliases heavily, so that's my fix for now.
But I think the current behaviour is unexpected for most (new?)
users (including me). I thought -p would display all changes in
all commits, including merges.
I guess changing -p's default behaviour to imply --cc is
problematic, so I think we should document that -p doesn't
generate patches for merges. Maybe something like this:
-- 8 --
Subject: [PATCH] Documentation/diff-options.txt: -p doesn't display merge
changes
Signed-off-by: Simon Ruderich si...@ruderich.org
---
Documentation/diff-options.txt | 4
1 file changed, 4 insertions(+)
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index 104579d..cd35ec7 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -24,6 +24,10 @@ ifndef::git-format-patch[]
--patch::
Generate patch (see section on generating patches).
{git-diff? This is the default.}
+ifdef::git-log[]
+ Changes introduced in merge commits are not displayed. Use `-c`,
+ `--cc` or `-m` to include them.
+endif::git-log[]
endif::git-format-patch[]
-Un::
--
1.8.2.1.513.gdedbb69.dirty
-- 8 --
Regards
Simon
--
+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0x92FEFDB7E44C32F9
--
To unsubscribe from this list: send the line 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-imap-send.txt: remove the use of sslverify=false in GMail example
On Thu, Apr 11, 2013 at 06:55:03PM +0300, Barbu Paul - Gheorghe wrote: Should I create a new patch removing them all? Sounds like a good idea to me. And update the commit message with Junio's suggestions. Regards Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] cat-file: do not die on --textconv without textconv filters
Jeff King venit, vidit, dixit 20.04.2013 06:17:
On Fri, Apr 19, 2013 at 06:44:46PM +0200, Michael J Gruber wrote:
-die(git cat-file --textconv: unable to run textconv on
%s,
-obj_name);
-break;
+if (textconv_object(obj_context.path, obj_context.mode, sha1,
1, buf, size))
+break;
+
+/* otherwise expect a blob */
+exp_type = blob;
case 0:
if (type_from_string(exp_type) == OBJ_BLOB) {
I'm not sure this is right. What happens with:
git cat-file --textconv HEAD:Documentation
We have failed to textconv, but should we be expecting a blob?
Very true, thanks. I'll reorder so that the --textconv case continues
(without break) into the -p case. I think it makes sense to consider
--textconv to be at least as pretty as -p.
Michael
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] t4030: demonstrate behavior of show with textconv
Jeff King venit, vidit, dixit 20.04.2013 06:04: On Fri, Apr 19, 2013 at 06:44:44PM +0200, Michael J Gruber wrote: git show commit obeys the textconc setting while git show blob does not. Demonstrate this in the test. s/textconc/textconv Thanks, plus s/obey/honor/ diff --git a/t/t4030-diff-textconv.sh b/t/t4030-diff-textconv.sh index 53ec330..f314ced 100755 --- a/t/t4030-diff-textconv.sh +++ b/t/t4030-diff-textconv.sh @@ -58,6 +58,12 @@ test_expect_success 'diff produces text' ' test_cmp expect.text actual ' +test_expect_success 'show commit produces text' ' +git show HEAD diff +find_diff diff actual +test_cmp expect.text actual +' Makes sense. +test_expect_success 'show blob produces binary' ' +git show HEAD:file actual +printf \\0\\n\\1\\n expect +test_cmp expect actual +' I think this is probably the right thing. I can see instances where one would want the converted contents, but we have cat-file --textconv for that. By that you mean that this behavior is to stay as is? My reasoning is twofold: - consistency between git show commit and git show blob - git show is a user facing command, and as such should produce output consumable by humans; whereas git cat-file is plumbing and should produce raw data unless told otherwise (-p, --textconv). Michael -- To unsubscribe from this list: send the line 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 6/6] grep: obey --textconv for the case rev:path
Jeff King venit, vidit, dixit 20.04.2013 06:24:
On Fri, Apr 19, 2013 at 06:44:49PM +0200, Michael J Gruber wrote:
@@ -820,12 +820,13 @@ int cmd_grep(int argc, const char **argv, const char
*prefix)
for (i = 0; i argc; i++) {
const char *arg = argv[i];
unsigned char sha1[20];
+struct object_context oc;
/* Is it a rev? */
-if (!get_sha1(arg, sha1)) {
+if (!get_sha1_with_context(arg, 0, sha1, oc)) {
struct object *object = parse_object_or_die(sha1, arg);
if (!seen_dashdash)
verify_non_filename(prefix, arg);
-add_object_array(object, arg, list);
+add_object_array_with_context(object, arg, list,
xmemdupz(oc, sizeof(struct object_context)));
Hrm. I'm not excited about the extra allocation here. Who frees it?
+void add_object_array(struct object *obj, const char *name, struct
object_array *array)
+{
+add_object_array_with_mode(obj, name, array, S_IFINVALID);
+}
+
+void add_object_array_with_mode(struct object *obj, const char *name,
struct object_array *array, unsigned mode)
+{
+add_object_array_with_mode_context(obj, name, array, mode, NULL);
+}
+
+void add_object_array_with_context(struct object *obj, const char *name,
struct object_array *array, struct object_context *context)
+{
+if (context)
+add_object_array_with_mode_context(obj, name, array,
context-mode, context);
+else
+add_object_array_with_mode_context(obj, name, array,
S_IFINVALID, context);
+}
And this mass of almost-the-same functions is gross, too, especially
given that the object_context contains a mode itself.
Well, it's just providing different ways to call into the one and only
function, in order to satisfy different callers' needs. It's not unheard
of (or rather: unseen) in our code, is it?
Unfortunately, I'm not sure if I have a more pleasant suggestion. I seem
to recall wrestling with this issue during the last round, too.
Yes, I think that's what we ended up with. At least it's just one
context struct per argument to grep, so it's not that bad after all.
I vaguely seem to recall we had some more general framework cooking but
I may be wrong (I was offline due to sickness for a while). It was about
attaching some additional info to something. Yes, I said vaguely ...
Michael
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] show: obey --textconv for blobs
Jeff King venit, vidit, dixit 20.04.2013 06:06: On Fri, Apr 19, 2013 at 06:44:45PM +0200, Michael J Gruber wrote: Currently, diff and cat-file for blobs obey --textconv options (with the former defaulting to --textconv and the latter to --no-textconv) whereas show does not obey this option, even though it takes diff options. Make show on blobs behave like diff, i.e. obey --textconv by default and --no-textconv when given. Wait, this does the opposite of the last patch. If we do want to do this, shouldn't the last one have been an expect_failure? The last patch just documents the status quo, which is not a bug per se. Therefore, no failure, but change in the definition of success. I'm not convinced this is the right thing to do, though. It would break: git show HEAD:file.c file.c Admittedly, such people should be using checkout or cat-file, so I do not mind too much breaking them if there is a good reason. But I am not sure what that reason is. My reasoning is twofold: - consistency between git show commit and git show blob - git show is a user facing command, and as such should produce output consumable by humans; whereas git cat-file is plumbing and should produce raw data unless told otherwise (-p, --textconv). (Sorry for the repeat.) Michael -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] grep with textconv
Junio C Hamano venit, vidit, dixit 19.04.2013 20:24: Michael J Gruber g...@drmicha.warpmail.net writes: This series teaches show and grep to obey textconv: show by default (like diff), grep only on request (--textconv). We might switch the default for the latter also, of course. I'd actually like that. Compared to an earlier (historic) series this one comes with tests. It would have been nicer if you referred to the previous thread cf. http://thread.gmane.org/gmane.comp.version-control.git/215385 Yes, sorry, I was on a slow mobile connection due to DSL breakage... grep: allow to use textconv filters This looked mostly sensible except for one minor eh, do we really need to assume textconv output is text, or wouldn't using the same codepath for raw blob and textconv result to make them consistently honor opt-binary easier to explain?. I think we assume in general that textconv produces text, which is maybe not completely surprising given its name ;) t4030: demonstrate behavior of show with textconv t7008: demonstrate behavior of grep with textconv It somehow felt they are better together in the patches that implement the features they exercise. I added them after the fact. They can be squashed in, of course. On the other hand you don't see the change in behavior that the latter patches introduce any more if you that; which is why I left them separate at least for review purposes and for camparing to the previous series which I had failed to reference. show: obey --textconv for blobs cat-file: do not die on --textconv without textconv filters grep: obey --textconv for the case rev:path I just let my eyes coast over these but didn't see anything obviously wrong. By the way, git log --no-merges | grep obey | wc -l shows that we say honor an option a lot more than obey an option. We may want to be consistent here. Okay, let's be honorable rather than obedient. Michael -- To unsubscribe from this list: send the line 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 0/8] Improving the search for remote-tracking branches
Hi, This is second iteration of this series. The initial three patches are unchanged, although the commit message of #3 has been rephrased based on Junio's comments. Patches #4-#6 fixes existing tests in preparation for patch #7, which changes the validation of the remote-tracking branch passed to --track: We now require the --track argument to refer to a ref that matches a configured refspec - otherwise, we can not reliably deduce the upstream information to store into branch.name.remote and branch.name.merge. Finally, patch #8 updates the paragraph on remote-tracking branches in the glossary to be somewhat closer to the current state of things. Have fun! :) ...Johan Johan Herland (8): t2024: Add tests verifying current DWIM behavior of 'git checkout branch' t2024: Show failure to use refspec when DWIMming remote branch names checkout: Use remote refspecs when DWIMming tracking branches t3200.39: tracking setup should fail if there is no matching refspec. t7201.24: Add refspec to keep --track working t9114.2: Don't use --track option against svn-remote-tracking branches branch.c: Validate tracking branches with refspecs instead of refs/remotes/* glossary: Update and rephrase the definition of a remote-tracking branch Documentation/git-checkout.txt | 6 +- Documentation/glossary-content.txt | 13 +++-- branch.c | 17 +- builtin/checkout.c | 42 +++--- t/t2024-checkout-dwim.sh | 116 + t/t3200-branch.sh | 8 +-- t/t7201-co.sh | 1 + t/t9114-git-svn-dcommit-merge.sh | 2 +- 8 files changed, 170 insertions(+), 35 deletions(-) create mode 100755 t/t2024-checkout-dwim.sh -- 1.8.1.3.704.g33f7d4f -- To unsubscribe from this list: send the line 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 1/8] t2024: Add tests verifying current DWIM behavior of 'git checkout branch'
The DWIM mode of checkout allows you to run git checkout foo when there is
no existing local ref or path called foo, and there is exactly one remote
with a remote-tracking branch called foo. Git will then automatically
create a new local branch called foo using the remote-tracking foo as
its starting point and configured upstream.
Signed-off-by: Johan Herland jo...@herland.net
---
t/t2024-checkout-dwim.sh | 66
1 file changed, 66 insertions(+)
create mode 100755 t/t2024-checkout-dwim.sh
diff --git a/t/t2024-checkout-dwim.sh b/t/t2024-checkout-dwim.sh
new file mode 100755
index 000..5650d21
--- /dev/null
+++ b/t/t2024-checkout-dwim.sh
@@ -0,0 +1,66 @@
+#!/bin/sh
+
+test_description='checkout branch
+
+Ensures that checkout on an unborn branch does what the user expects'
+
+. ./test-lib.sh
+
+# Arguments: branch remote remote-tracking
+#
+# Verify that we have checked out branch, and that it is at the same
+# commit as remote-tracking, and that has appropriate tracking config
+# setup against remote
+test_tracking_branch() {
+ branch=$1
+ remote=$2
+ remote_track=$3
+ test refs/heads/$branch = $(git rev-parse --symbolic-full-name
HEAD)
+ test $(git rev-parse --verify HEAD) = $(git rev-parse --verify
$remote_track)
+ test $remote = $(git config branch.$branch.remote)
+ test refs/heads/$branch = $(git config branch.$branch.merge)
+}
+
+test_expect_success 'setup' '
+ (git init repo_a
+cd repo_a
+test_commit a_master
+git checkout -b foo
+test_commit a_foo
+git checkout -b bar
+test_commit a_bar
+ )
+ (git init repo_b
+cd repo_b
+test_commit b_master
+git checkout -b foo
+test_commit b_foo
+git checkout -b baz
+test_commit b_baz
+ )
+ git remote add repo_a repo_a
+ git remote add repo_b repo_b
+ git config remote.repo_b.fetch \
+ +refs/heads/*:refs/remotes/other_b/*
+ git fetch --all
+'
+
+test_expect_success 'checkout of non-existing branch fails' '
+ test_must_fail git checkout xyzzy
+'
+
+test_expect_success 'checkout of branch from multiple remotes fails' '
+ test_must_fail git checkout foo
+'
+
+test_expect_success 'checkout of branch from a single remote succeeds #1' '
+ git checkout bar
+ test_tracking_branch bar repo_a refs/remotes/repo_a/bar
+'
+
+test_expect_success 'checkout of branch from a single remote succeeds #2' '
+ git checkout baz
+ test_tracking_branch baz repo_b refs/remotes/other_b/baz
+'
+
+test_done
--
1.8.1.3.704.g33f7d4f
--
To unsubscribe from this list: send the line 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 2/8] t2024: Show failure to use refspec when DWIMming remote branch names
When using git checkout foo to DWIM the creation of local foo from some
existing upstream foo, we assume conventional refspecs as created by git
clone or git remote add, and fail to work correctly if the current
refspecs do not follow the conventional refs/remotes/$remote/* pattern.
Signed-off-by: Johan Herland jo...@herland.net
---
t/t2024-checkout-dwim.sh | 52 +++-
1 file changed, 51 insertions(+), 1 deletion(-)
diff --git a/t/t2024-checkout-dwim.sh b/t/t2024-checkout-dwim.sh
index 5650d21..36bf52f 100755
--- a/t/t2024-checkout-dwim.sh
+++ b/t/t2024-checkout-dwim.sh
@@ -22,6 +22,7 @@ test_tracking_branch() {
}
test_expect_success 'setup' '
+ test_commit my_master
(git init repo_a
cd repo_a
test_commit a_master
@@ -49,7 +50,7 @@ test_expect_success 'checkout of non-existing branch fails' '
test_must_fail git checkout xyzzy
'
-test_expect_success 'checkout of branch from multiple remotes fails' '
+test_expect_success 'checkout of branch from multiple remotes fails #1' '
test_must_fail git checkout foo
'
@@ -63,4 +64,53 @@ test_expect_success 'checkout of branch from a single remote
succeeds #2' '
test_tracking_branch baz repo_b refs/remotes/other_b/baz
'
+test_expect_success 'setup more remotes with unconventional refspecs' '
+ git checkout master
+ git branch -D bar
+ git branch -D baz
+ test $(git rev-parse --verify HEAD) = $(git rev-parse --verify
my_master)
+ (git init repo_c
+cd repo_c
+test_commit c_master
+git checkout -b bar
+test_commit c_bar
+git checkout -b spam
+test_commit c_spam
+ )
+ (git init repo_d
+cd repo_d
+test_commit d_master
+git checkout -b baz
+test_commit f_baz
+git checkout -b eggs
+test_commit c_eggs
+ )
+ git remote add repo_c repo_c
+ git config remote.repo_c.fetch \
+ +refs/heads/*:refs/remotes/extra_dir/repo_c/extra_dir/*
+ git fetch repo_c
+ git remote add repo_d repo_d
+ git config remote.repo_d.fetch \
+ +refs/heads/*:refs/repo_d/*
+ git fetch repo_d
+'
+
+test_expect_failure 'checkout of branch from multiple remotes fails #2' '
+ test_must_fail git checkout bar
+'
+
+test_expect_failure 'checkout of branch from multiple remotes fails #3' '
+ test_must_fail git checkout baz
+'
+
+test_expect_failure 'checkout of branch from a single remote succeeds #3' '
+ git checkout spam
+ test_tracking_branch spam repo_c
refs/remotes/extra_dir/repo_c/extra_dir/spam
+'
+
+test_expect_failure 'checkout of branch from a single remote succeeds #4' '
+ git checkout eggs
+ test_tracking_branch eggs repo_d refs/repo_d/eggs
+'
+
test_done
--
1.8.1.3.704.g33f7d4f
--
To unsubscribe from this list: send the line 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 3/8] checkout: Use remote refspecs when DWIMming tracking branches
The DWIM mode of checkout allows you to run git checkout foo when there
is no existing local ref or path called foo, and there is exactly _one_
remote with a remote-tracking branch called foo. Git will automatically
create a new local branch called foo using the remote-tracking foo as
its starting point and configured upstream.
For example, consider the following unconventional (but perfectly valid)
remote setup:
[remote origin]
fetch = refs/heads/*:refs/remotes/origin/*
[remote frotz]
fetch = refs/heads/*:refs/remotes/frotz/nitfol/*
Case 1: Assume both origin and frotz have remote-tracking branches called
foo, at refs/remotes/origin/foo and refs/remotes/frotz/nitfol/foo
respectively. In this case git checkout foo should fail, because there is
more than one remote with a foo branch.
Case 2: Assume only frotz have a remote-tracking branch called foo. In
this case git checkout foo should succeed, and create a local branch foo
from refs/remotes/frotz/nitfol/foo, using remote branch foo from frotz
as its upstream.
The current code hardcodes the assumption that all remote-tracking branches
must match the refs/remotes/$remote/* pattern (which is true for remotes
with conventional refspecs, but not true for the frotz remote above).
When running git checkout foo, the current code looks for exactly one ref
matching refs/remotes/*/foo, hence in the above example, it fails to find
refs/remotes/frotz/nitfol/foo, which causes it to fail both case #1 and #2.
The better way to handle the above example is to actually study the fetch
refspecs to deduce the candidate remote-tracking branches for foo; i.e.
assume foo is a remote branch being fetched, and then map refs/heads/foo
through the refspecs in order to get the corresponding remote-tracking
branches refs/remotes/origin/foo and refs/remotes/frotz/nitfol/foo.
Finally we check which of these happens to exist in the local repo, and
if there is exactly one, we have an unambiguous match for git checkout foo,
and may proceed.
This fixes most of the failing tests introduced in the previous patch.
Signed-off-by: Johan Herland jo...@herland.net
---
Documentation/git-checkout.txt | 6 +++---
builtin/checkout.c | 42 ++
t/t2024-checkout-dwim.sh | 6 +++---
3 files changed, 28 insertions(+), 26 deletions(-)
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index 8edcdca..bf0c99c 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -131,9 +131,9 @@ entries; instead, unmerged entries are ignored.
--track in linkgit:git-branch[1] for details.
+
If no '-b' option is given, the name of the new branch will be
-derived from the remote-tracking branch. If remotes/ or refs/remotes/
-is prefixed it is stripped away, and then the part up to the
-next slash (which would be the nickname of the remote) is removed.
+derived from the remote-tracking branch, by looking at the local part of
+the refspec configured for the corresponding remote, and then stripping
+the initial part up to the *.
This would tell us to use hack as the local branch when branching
off of origin/hack (or remotes/origin/hack, or even
refs/remotes/origin/hack). If the given name has no slash, or the above
diff --git a/builtin/checkout.c b/builtin/checkout.c
index eb51872..bcb18c8 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -822,38 +822,40 @@ static int git_checkout_config(const char *var, const
char *value, void *cb)
}
struct tracking_name_data {
- const char *name;
- char *remote;
+ /* const */ char *src_ref;
+ char *dst_ref;
+ unsigned char *dst_sha1;
int unique;
};
-static int check_tracking_name(const char *refname, const unsigned char *sha1,
- int flags, void *cb_data)
+static int check_tracking_name(struct remote *remote, void *cb_data)
{
struct tracking_name_data *cb = cb_data;
- const char *slash;
-
- if (prefixcmp(refname, refs/remotes/))
- return 0;
- slash = strchr(refname + 13, '/');
- if (!slash || strcmp(slash + 1, cb-name))
+ struct refspec query;
+ memset(query, 0, sizeof(struct refspec));
+ query.src = cb-src_ref;
+ if (remote_find_tracking(remote, query) ||
+ get_sha1(query.dst, cb-dst_sha1))
return 0;
- if (cb-remote) {
+ if (cb-dst_ref) {
cb-unique = 0;
return 0;
}
- cb-remote = xstrdup(refname);
+ cb-dst_ref = xstrdup(query.dst);
return 0;
}
-static const char *unique_tracking_name(const char *name)
+static const char *unique_tracking_name(const char *name, unsigned char *sha1)
{
- struct tracking_name_data cb_data = { NULL, NULL, 1 };
- cb_data.name = name;
- for_each_ref(check_tracking_name, cb_data);
+ struct tracking_name_data
[PATCHv2 4/8] t3200.39: tracking setup should fail if there is no matching refspec.
We are formalizing a requirement that any remote-tracking branch to be used as an upstream (i.e. as an argument to --track), _must_ belong to a configured remote by being matched by the dst side of a fetch refspec. This patch encodes the new expected behavior of this test, and marks the test with test_expect_failure in anticipation of a following patch to introduce the new behavior. Signed-off-by: Johan Herland jo...@herland.net --- t/t3200-branch.sh | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh index d969f0e..1bfdadc 100755 --- a/t/t3200-branch.sh +++ b/t/t3200-branch.sh @@ -317,13 +317,13 @@ test_expect_success 'test tracking setup (non-wildcard, matching)' ' test $(git config branch.my4.merge) = refs/heads/master ' -test_expect_success 'test tracking setup (non-wildcard, not matching)' ' +test_expect_failure 'tracking setup fails on non-matching refspec' ' git config remote.local.url . git config remote.local.fetch refs/heads/s:refs/remotes/local/s (git show-ref -q refs/remotes/local/master || git fetch local) - git branch --track my5 local/master - ! test $(git config branch.my5.remote) = local - ! test $(git config branch.my5.merge) = refs/heads/master + test_must_fail git branch --track my5 local/master + test_must_fail git config branch.my5.remote + test_must_fail git config branch.my5.merge ' test_expect_success 'test tracking setup via config' ' -- 1.8.1.3.704.g33f7d4f -- To unsubscribe from this list: send the line 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 5/8] t7201.24: Add refspec to keep --track working
We are formalizing a requirement that any remote-tracking branch to be used as an upstream (i.e. as an argument to --track), _must_ belong to a configured remote by being matched by the dst side of a fetch refspec. Without this patch, this test would start failing when the new behavior is introduced. Signed-off-by: Johan Herland jo...@herland.net --- t/t7201-co.sh | 1 + 1 file changed, 1 insertion(+) diff --git a/t/t7201-co.sh b/t/t7201-co.sh index be9672e..0c9ec0a 100755 --- a/t/t7201-co.sh +++ b/t/t7201-co.sh @@ -431,6 +431,7 @@ test_expect_success 'detach a symbolic link HEAD' ' test_expect_success \ 'checkout with --track fakes a sensible -b name' ' +git config remote.origin.fetch +refs/heads/*:refs/remotes/origin/* git update-ref refs/remotes/origin/koala/bear renamer git checkout --track origin/koala/bear -- 1.8.1.3.704.g33f7d4f -- To unsubscribe from this list: send the line 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 6/8] t9114.2: Don't use --track option against svn-remote-tracking branches
We are formalizing a requirement that any remote-tracking branch to be used as an upstream (i.e. as an argument to --track), _must_ belong to a configured remote by being matched by the dst side of a fetch refspec. This test uses --track against a remotes/trunk ref which does not belong to any configured (git) remotes, but is instead created by git svn fetch operating on an svn-remote. It does not make sense to use an svn-remote as an upstream for a local branch, as a regular git pull from (or git push to) it would obviously fail (instead you would need to use git svn to communicate with this remote). Furthermore, the usage of --track in this case is unnecessary, since the upstreaming config that would be created is never used. Simply removing --track fixes the issue without changing the expected behavior of the test. Cc: Eric Wong normalper...@yhbt.net Signed-off-by: Johan Herland jo...@herland.net --- t/t9114-git-svn-dcommit-merge.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/t/t9114-git-svn-dcommit-merge.sh b/t/t9114-git-svn-dcommit-merge.sh index 3077851..f524d2f 100755 --- a/t/t9114-git-svn-dcommit-merge.sh +++ b/t/t9114-git-svn-dcommit-merge.sh @@ -48,7 +48,7 @@ test_expect_success 'setup svn repository' ' test_expect_success 'setup git mirror and merge' ' git svn init $svnrepo -t tags -T trunk -b branches git svn fetch - git checkout --track -b svn remotes/trunk + git checkout -b svn remotes/trunk git checkout -b merge echo new file new_file git add new_file -- 1.8.1.3.704.g33f7d4f -- To unsubscribe from this list: send the line 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 7/8] branch.c: Validate tracking branches with refspecs instead of refs/remotes/*
The current code for validating tracking branches (e.g. the argument to
the -t/--track option) hardcodes refs/heads/* and refs/remotes/* as the
potential locations for tracking branches. This works with the refspecs
created by git clone or git remote add, but is suboptimal in other
cases:
- If refs/remotes/foo/bar exists without any association to a remote
(i.e. there is no remote named foo, or no remote with a refspec
that matches refs/remotes/foo/bar), then it is impossible to set up
a valid upstream config that tracks it. Currently, the code defaults
to using refs/remotes/foo/bar from repo . as the upstream, which
works, but is probably not what the user had in mind when running
git branch baz --track foo/bar.
- If the user has tweaked the fetch refspec for a remote to put its
remote-tracking branches outside of refs/remotes/*, e.g. by running
git config remote.foo.fetch +refs/heads/*:refs/foo_stuff/*
then the current code will refuse to use its remote-tracking branches
as --track arguments, since they do not match refs/remotes/*.
This patch removes the refs/remotes/* requirement for upstream branches,
and replaces it with explicit checking of the refspecs for each remote to
determine whether a given --track argument is a valid remote-tracking
branch. This solves both of the above problems, since the matching refspec
guarantees that there is a both a remote name and a remote branch name
that can be used for the upstream config.
However, this means that refs located within refs/remotes/* without a
corresponding remote/refspec will no longer be usable as upstreams.
The few existing tests which depended on this behavioral quirk has
already been fixed in the preceding patches.
This patch fixes the last remaining test failure in t2024-checkout-dwim.
Signed-off-by: Johan Herland jo...@herland.net
---
branch.c | 17 -
t/t2024-checkout-dwim.sh | 2 +-
t/t3200-branch.sh| 2 +-
3 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/branch.c b/branch.c
index 6ae6a4c..beaf11d 100644
--- a/branch.c
+++ b/branch.c
@@ -197,6 +197,21 @@ int validate_new_branchname(const char *name, struct
strbuf *ref,
return 1;
}
+static int check_tracking_branch(struct remote *remote, void *cb_data)
+{
+ char *tracking_branch = cb_data;
+ struct refspec query;
+ memset(query, 0, sizeof(struct refspec));
+ query.dst = tracking_branch;
+ return !(remote_find_tracking(remote, query) ||
+prefixcmp(query.src, refs/heads/));
+}
+
+static int validate_remote_tracking_branch(char *ref)
+{
+ return !for_each_remote(check_tracking_branch, ref);
+}
+
static const char upstream_not_branch[] =
N_(Cannot setup tracking information; starting point '%s' is not a branch.);
static const char upstream_missing[] =
@@ -259,7 +274,7 @@ void create_branch(const char *head,
case 1:
/* Unique completion -- good, only if it is a real branch */
if (prefixcmp(real_ref, refs/heads/)
- prefixcmp(real_ref, refs/remotes/)) {
+ validate_remote_tracking_branch(real_ref)) {
if (explicit_tracking)
die(_(upstream_not_branch), start_name);
else
diff --git a/t/t2024-checkout-dwim.sh b/t/t2024-checkout-dwim.sh
index fc6edc9..a8f0a90 100755
--- a/t/t2024-checkout-dwim.sh
+++ b/t/t2024-checkout-dwim.sh
@@ -108,7 +108,7 @@ test_expect_success 'checkout of branch from a single
remote succeeds #3' '
test_tracking_branch spam repo_c
refs/remotes/extra_dir/repo_c/extra_dir/spam
'
-test_expect_failure 'checkout of branch from a single remote succeeds #4' '
+test_expect_success 'checkout of branch from a single remote succeeds #4' '
git checkout eggs
test_tracking_branch eggs repo_d refs/repo_d/eggs
'
diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh
index 1bfdadc..44ec6a4 100755
--- a/t/t3200-branch.sh
+++ b/t/t3200-branch.sh
@@ -317,7 +317,7 @@ test_expect_success 'test tracking setup (non-wildcard,
matching)' '
test $(git config branch.my4.merge) = refs/heads/master
'
-test_expect_failure 'tracking setup fails on non-matching refspec' '
+test_expect_success 'tracking setup fails on non-matching refspec' '
git config remote.local.url .
git config remote.local.fetch refs/heads/s:refs/remotes/local/s
(git show-ref -q refs/remotes/local/master || git fetch local)
--
1.8.1.3.704.g33f7d4f
--
To unsubscribe from this list: send the line 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 8/8] glossary: Update and rephrase the definition of a remote-tracking branch
The definition of a remote-tracking branch in the glossary have been out-of-date for a while (by e.g. referring to Pull: from old-style $GIT_DIR/remotes files). Also, the preceding patches have formalized that a remote-tracking branch must match a configured refspec in order to be usable as an upstream. This patch rewrites the paragraph on remote-tracking branches accordingly. Signed-off-by: Johan Herland jo...@herland.net --- Documentation/glossary-content.txt | 13 +++-- 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/Documentation/glossary-content.txt b/Documentation/glossary-content.txt index 2478a39..7a79f26 100644 --- a/Documentation/glossary-content.txt +++ b/Documentation/glossary-content.txt @@ -423,12 +423,13 @@ should not be combined with other pathspec. linkgit:git-push[1]. [[def_remote_tracking_branch]]remote-tracking branch:: - A regular Git def_branch,branch that is used to follow changes from - another def_repository,repository. A remote-tracking - branch should not contain direct modifications or have local commits - made to it. A remote-tracking branch can usually be - identified as the right-hand-side def_ref,ref in a Pull: - def_refspec,refspec. + A def_ref,ref that is used to follow changes from another + def_repository,repository. It typically looks like + 'refs/remotes/foo/bar' (indicating that it tracks a branch named + 'bar' in a remote named 'foo'), and matches the right-hand-side of + a configured fetch def_refspec,refspec. A remote-tracking + branch should not contain direct modifications or have local + commits made to it. [[def_repository]]repository:: A collection of def_ref,refs together with an -- 1.8.1.3.704.g33f7d4f -- To unsubscribe from this list: send the line 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: Some observations on log -L
Ramkumar Ramachandra artag...@gmail.com writes:
Ever since 'git log -L' made it to `pu`, I've been playing with it to
see how it can be useful. Here are some of my observations:
1. Specifying line ranges by hand are too painful. I would really
love it if it could parse the lines off a patch prepared by
format-patch or something.
True, but I'm not sure that starting from a patch is the right thing.
At least in my case, when I have a patch ready, I longer need to
investigate anything ;-)
Perhaps a line-log all the ranges touched by this commit would be more
useful.
You can achieve both with some hack like
eval git log 1640632 $(git show 1640632 | perl -ne '
$h=1 if /^diff /;
$f=$1 if $h and m{\+\+\+ ./(.*)$};
if (/@@ .* \+(\d+)(?:,(\d+))/) {
print -L$1,+$2:$f; $h=0;
};
')
Note that you need to specify the commit in two places. I think I'll
actually make that a script and try it to see if it's worth
implementing. Quoting of the -L args is of course an exercise left to
the reader ;-)
2. Specifying regex ranges are really useful to see the history of a
function. But I think it could really benefit from a tool that
actually understands the language (using Clang Tooling). If we were
to build such a tool, git-core could benefit immensely from it: we'd
have smarter merges too, for instance.
Is there any research on this?
I imagine you would use whatever parser you have at hand to process the
input into a syntax tree, then run diff over those trees. There should
be some research on how to get meaningful diffs of them? And then you
somehow have to turn the tree-diff into a human-readable output.
In any case you could start by prototyping such a diff algorithm on a
file basis; people could then start using it as an external diff driver.
3. Often, I want to know the people to contact for a segment of code.
Blame is useless here, because it only considers the most recent
commit, when I want to know the authors of all the commits that helped
shaped that segment of code. So, I think shortlog could really
benefit from a -L. Is this easily doable?
Not really. You're touching on a sore point of the current
implementation, which is that it's not properly tied into the log and
diff infrastructures. I figured that would block it for too long, so I
gave up on trying to do that for the first version.
So it just runs captures the history that log walks, does a separate
processing step and handcrafts a diff in its own output machinery, which
isn't very nice for many reasons, including that we can't run any other
diff- or log-like stuff on top of log -L output.
That precludes many uses, like shortlog you mentioned, or color-words.
I think Junio and me hashed out some ideas for how it *should* be tied
together in some earlier thread. The gist of it is that there are
really three separate things going on here:
* Pathspec-like filtering with proper -M support. This should be
unified with --follow. That's actually the next thing I want to try,
because it should give a properly implemented --follow along the way.
* A pass of commit filtering based on intersecting the ranges we're
interested in with the diffs of commits, and mapping them across.
This should be hooked as a cleanly separated step into the log
machinery.
* Diff output filtering based on the ranges that we found. This should
be done as a filter somewhere in the diff machinery, preferably before
word-diff.
(The first step is actually a performance optimization, but it would not
be a practical algorithm without it.)
Thanks for the input. Let me know if you manage to break it somehow :-)
And for a bit of shameless pluggery (you probably saw it on IRC already,
but mainly for other curious readers):
git://github.com/trast/git.git tr/gitk-line-log
has a version of gitk that supports -L. I hacked it up yesterday, and
while it seems to work, I want to play with it a little until I'm
satisfied that I didn't break gitk for other uses.
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Subtree: My Status
Hi folks, I apologize for being off the grid for a while. We had a baby and unexpectedly ended up in the NICU. We just got him home a week ago. Everyone is doing fine but I had to pretty much drop all non-essential work for a month or so. Rest assured that I have all of the git-subtree-related mail sitting in my inbox. It will take me some time to process it all -- looks ike there has been a lot of good work! Please remember that I don't consider myself a gatekeeper to git subtree. In fact I could use some help reviewing and approving patches. If anyone thinks a patch looks good, let Junio know. It's my responsibility to object to things, not your responsibility to wait for me. :) Life happens and I want to make sure git-subtree moves forward. Thanks everyone for understanding. -David -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [QUERY] Why do we have git-completion.zsh?
Hi, Ramkumar Ramachandra wrote: However, I don't understand why we maintain it, because there's a comprehensive first-class completer in ZSH core [1] which I use all the time. Shouldn't the completion folks be contributing to this instead? Only if they want to. Kind regards, Jonathan http://thread.gmane.org/gmane.comp.version-control.git/210022/focus=210024 -- To unsubscribe from this list: send the line 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: [QUERY] Why do we have git-completion.zsh?
Jonathan Nieder wrote: Ramkumar Ramachandra wrote: However, I don't understand why we maintain it, because there's a comprehensive first-class completer in ZSH core [1] which I use all the time. Shouldn't the completion folks be contributing to this instead? Only if they want to. [...] http://thread.gmane.org/gmane.comp.version-control.git/210022/focus=210024 Sorry, wrong link. Here's a better one: http://www.zsh.org/mla/workers/2011/msg00497.html More fundamentally, your question seems to assume some kind of shared plan regarding what people work on, rather than each person choosing to work on what they consider valuable without having to justify it to others. I am very happy with Felipe's work on git's completion code and don't think it does any harm to efforts elsewhere. Thanks for your interest, Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/8] Add new git-cc-cmd helper to contrib
Johannes Sixt j...@kdbg.org writes: But I think it can be useful outside the context of send-email as well, and having one independent tool that does one single job well is a better design. Perhaps it is better to name it less specific to send-email's cc-cmd option. git people? git whom? git reviewers? I dunno, but along those lines. Would it make sense to integrate this in git shortlog, which already does something similar? Conceptually, yes, but the end result will be much larger in scope. I am not sure if shortlog is still a good label for it. shortlog, when it internally runs log [*1*], is still about the commits within the range given to the command; shortlog A..B talks only about commits within A..B range. This new thing is about what happened to the part of the code A..B touches in the past (i.e. before A happened), which feels a bit different. [Footnote] *1* It can be used as a filter to git log output, which is a bit different animal, but it still is about shortening that incoming log, not about independently digging the history using the input as a starting point. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 1/8] t2024: Add tests verifying current DWIM behavior of 'git checkout branch'
Johan Herland wrote:
The DWIM mode of checkout allows you to run git checkout foo when there is
no existing local ref or path called foo and there is exactly one remote
with a remote-tracking branch called foo.
Thanks for testing this. I'm surprised no one suggested a test since
v1.7.0-rc0~51^2~6 (2009-10-18).
Maybe it would also be worthwhile to also test --no-guess? (c.f.
46148dd7, 2009-10-18)
[...]
+++ b/t/t2024-checkout-dwim.sh
@@ -0,0 +1,66 @@
[...]
+# Arguments: branch remote remote-tracking
+#
+# Verify that we have checked out branch, and that it is at the same
+# commit as remote-tracking, and that has appropriate tracking config
+# setup against remote
+test_tracking_branch() {
+ branch=$1
+ remote=$2
+ remote_track=$3
+ test refs/heads/$branch = $(git rev-parse --symbolic-full-name
HEAD)
+ test $(git rev-parse --verify HEAD) = $(git rev-parse --verify
$remote_track)
+ test $remote = $(git config branch.$branch.remote)
+ test refs/heads/$branch = $(git config branch.$branch.merge)
Stylistic tweaks:
* setting all local vars on one line
* avoiding command substitution so we notice if commands fail
* using test_cmp in place of test $foo = $bar for better output
when the test fails
# Is the current branch refs/heads/$1?
test_branch () {
printf %s\n refs/heads/$1 expect.HEAD
git symbolic-ref HEAD actual.HEAD
test_cmp expect.HEAD actual.HEAD
}
# Is branch refs/heads/$1 set to pull from $2/$3?
test_branch_upstream () {
printf %s\n $2 refs/heads/$3 expect.upstream
{
git config branch.$1.remote
git config branch.$1.merge
} actual.upstream
test_cmp expect.upstream actual.upstream
}
test_tracking_branch () {
branch=$1 remote=$2 remote_branch=$3
test_branch $branch
test_cmp_rev refs/remotes/$remote/$remote_branch HEAD
test_branch_upstream $branch $remote $remote_branch
}
+}
+
+test_expect_success 'setup' '
+ (git init repo_a
+ cd repo_a
+ test_commit a_master
+ git checkout -b foo
+ test_commit a_foo
+ git checkout -b bar
+ test_commit a_bar
+ )
+ (git init repo_b
+ cd repo_b
+ test_commit b_master
+ git checkout -b foo
+ test_commit b_foo
+ git checkout -b baz
+ test_commit b_baz
+ )
+ git remote add repo_a repo_a
+ git remote add repo_b repo_b
+ git config remote.repo_b.fetch \
+ +refs/heads/*:refs/remotes/other_b/*
+ git fetch --all
Style: indenting code in subshells.
test_expect_success 'setup' '
git init repo_a
(
cd repo_a
test_commit a_master
git checkout -b foo
test_commit a_foo
git checkout -b bar
test_commit a_bar
)
git init repo_b
(
cd repo_b
test_commit b_master
git checkout -b foo
test_commit b_foo
git checkout -b baz
test_commit b_baz
)
git remote add repo_a repo_a
git remote add repo_b repo_b
git config remote.repo_b.fetch \
+refs/heads/*:refs/remotes/other_b/*
git fetch --all
'
+'
+
+test_expect_success 'checkout of non-existing branch fails' '
+ test_must_fail git checkout xyzzy
+'
Maybe, to defend against state from previous tests and confirm that
the checkout didn't do anything:
git checkout -B master
test_might_fail git branch -D xyzzy
test_must_fail git checkout xyzzy
test_must_fail git rev-parse --verify refs/heads/xyzzy
test_branch master
+
+test_expect_success 'checkout of branch from multiple remotes fails' '
+ test_must_fail git checkout foo
+'
Likewise:
git checkout -B master
test_might_fail git branch -D foo
test_must_fail git checkout foo
test_must_fail git rev-parse --verify refs/heads/foo
test_branch master
+
+test_expect_success 'checkout of branch from a single remote succeeds #1' '
+ git checkout bar
+ test_tracking_branch bar repo_a refs/remotes/repo_a/bar
git checkout -B master
test_might_fail git branch -D bar
git checkout bar
test_branch bar
test_cmp_rev remotes/repo_a/bar HEAD
test_branch_upstream bar repo_a bar
+test_expect_success 'checkout of branch from a single remote succeeds #2'
Re: [PATCH/RFC] upload-pack: ignore 'shallow' lines with unknown obj-ids
Duy Nguyen pclo...@gmail.com writes: On Sat, Apr 20, 2013 at 8:05 PM, Michael Heemskerk mheemsk...@atlassian.com wrote: When the client sends a 'shallow' line for an object that the server does not have, the server currently dies with the error: did not find object for shallow obj-id. The client may have received the object from a different server, or the object may have been garbage collected by the server. In either case, the object is not relevant for calculating the pack that is to be sent and can be safely ignored. For the purpose of generating a pack, these shallow boundaries are irrelevant. The above describes only that part. But the shallow list is also used to compute the updated boundary (i.e. this client does not have a valid history behind these commits)? When we know their current shallow boundary, after sending history that crosses that boundary, we can tell them before this fetch, you did not have any history behind this commit, but we know that you now have a bit more. Update your record with these new boundaries. You still do not have any history behind these commits. That is how deepening works. When you receive a shallow boundary unknown to you, it might not hurt if you keep it and parrot it at the end, so that the fetcher will still remember that it does not have any history behind the commit. There may be reasons why doing so is not sufficient and we have to reject clients whose history is truncated at a place unknown to us. You would declare now you have everything behind that unknown shallow boundary, if you ignore an unknown shallow boundary and do not send it back. That sounds ourright wrong to me. You simply do not know enough to make such a declaration. I do not seem to find the patch you are responding to, so I do not know how the patch handled the unshallowing part, but the impression I got from reading the log message quoted is that the patch was not even aware of the issue. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
10000 tests
So this showed up after running the test suite of current master at v1.8.2.1-501-gd2949c7: fixed 0 success 9838 failed 0 broken 83 total 1 Ten thousand tests is worth celebrating. Congratulations! :) Regards, Øyvind -- To unsubscribe from this list: send the line 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] Teach git to change to a given directory using -C option
Jeff King wrote: On Fri, Apr 19, 2013 at 08:21:48PM +0800, Nazri Ramliy wrote: Often I find myself needing to find out quickly the status of a repository that is not in my currenct working directory, like this: $ (cd ~/foo; git log -1) With this patch now i can simply do: $ git -C ~/.zsh log -1 That's just one example. [...] You can _almost_ do this with git --git-dir. But it expects the actual git directory, not a starting point for finding the git directory. [...] It is redundant with (cd foo git ...) in the shell, as you note, but sometimes it is more convenient to use -C (especially if you are exec-ing git from another program and want to avoid the shell entirely for quoting reasons). When I want to run git log for a repository outside the cwd, I do use --git-dir (or more precisely, $ GIT_DIR=$HOME/src/git/.git git log ), which works. The sometimes you just want to pass a command to 'exec' use case does not convince me. I equally well might want to run git after another command, or run git if and only if a repository exists there, or do any number of other things. If someone asked me how to do that by passing a command to 'exec', I'd point them to sh -c 'cd foo git ...' as a way to answer all such questions at the same time. So we're left with --git-dir does not automatically append .git when appropriate as the problem being solved, which is a real problem. Maybe that is worth fixing more directly? It might also be convenient to be able to do something like git --git-dir=~/src/git log -- Documentation/ which this -C option makes easy. *checks* Actually it works without, but for subtle reasons. A more sensible way to spell that is git --git-dir=wherever -- :/Documentation/ which works fine. All that said, I don't mind -C terribly as long as it can maintain itself, which means including thorough documentation that covers the purpose and how pathname parameters and envvars interact with the new option and including tests under t/ to ensure it continues to work correctly in the future. Thanks for an interesting patch, and hope that helps, Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] git-log.txt: fix description of since..until
Ramkumar Ramachandra wrote: First, since and until are ways to specify revisions, not commits, as gitrevisions.txt would indicate. What's the difference between a revision and a commit? The definition in gitglossary(7) only confuses me. -- To unsubscribe from this list: send the line 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: [QUERY] Why do we have git-completion.zsh?
On Sat, Apr 20, 2013 at 1:53 PM, Jonathan Nieder jrnie...@gmail.com wrote: Jonathan Nieder wrote: Ramkumar Ramachandra wrote: However, I don't understand why we maintain it, because there's a comprehensive first-class completer in ZSH core [1] which I use all the time. Shouldn't the completion folks be contributing to this instead? Only if they want to. [...] http://thread.gmane.org/gmane.comp.version-control.git/210022/focus=210024 Sorry, wrong link. Here's a better one: http://www.zsh.org/mla/workers/2011/msg00497.html More fundamentally, your question seems to assume some kind of shared plan regarding what people work on, rather than each person choosing to work on what they consider valuable without having to justify it to others. I am very happy with Felipe's work on git's completion code and don't think it does any harm to efforts elsewhere. To complement the reason; the zsh folks (or perhaps it's only one; who works on the git stuff), absolutely prioritize correctness over speed, that means if it takes ten seconds to list all the possible files to complete, grouped nicely, that's exactly what they'll do, instead of the way the bash completion does, which lists the most likely files, which takes milliseconds. I found zsh's completion unbearably slow, which is ironic; git is the fastest DSCM on Earth, and they blow the performance away by making the completion dead slow, to the point where the completion is several orders of magnitude slower than the actual command. To me, the whole point of the completion is to make the work faster, and if the completion takes longer than me typing it, what's the point of it? And I'm not the only one, when I contributed this stuff to oh-my-zsh[1] I got a very positive response. I couldn't convince them of this obvious fact, so I choose git's bash fast completion. I have patches to improve the zsh thin wrapper to give more information, zsh style, in a way that is superior to zsh's git completion, but I'm still not happy with them, I want the user to be able to configure the output so it's not totally bloated like in zsh, and I'm still working on it. In the mean time, I want my completion to be blazingly fast, and at least as good as git's bash completion. If they wanted my contributions, that would be awesome, but that doesn't appear to be the case. And I'm kind of relieved, because zsh's completion is monstrous code, and the zsh development practices are not good (e.g. all my logically independent patches get squashed into one commit). Cheers. [1] https://github.com/robbyrussell/oh-my-zsh -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 1/8] t2024: Add tests verifying current DWIM behavior of 'git checkout branch'
On Sat, Apr 20, 2013 at 10:44 PM, Jonathan Nieder jrnie...@gmail.com wrote: Johan Herland wrote: The DWIM mode of checkout allows you to run git checkout foo when there is no existing local ref or path called foo and there is exactly one remote with a remote-tracking branch called foo. Thanks for testing this. I'm surprised no one suggested a test since v1.7.0-rc0~51^2~6 (2009-10-18). Maybe it would also be worthwhile to also test --no-guess? (c.f. 46148dd7, 2009-10-18) [...] Sane? Yes. Thanks! Will incorporate your suggestions into the next iteration. ...Johan -- Johan Herland, jo...@herland.net www.herland.net -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Is there a way to speed up remote-hg?
On Sat, Apr 20, 2013 at 6:07 AM, John Szakmeister j...@szakmeister.net wrote: I really like the idea of remote-hg, but it appears to be awfully slow on the clone step: The short answer is no. I do have a couple of patches that improve performance, but not by a huge factor. I have profiled the code, and there are two significant places where performance is wasted: 1) Fetching the file contents Extracting, decompressing, transferring, and then compressing and storing the file contents is mostly unavoidable, unless we already have the contents of such file, which in Git, it would be easy to check by analyzing the checksum (SHA-1). Unfortunately Mercurial doesn't have that information. The SHA-1 that is stored is not of the contents, but the contents and the parent checksum, which means that if you revert a modification you made to a file, or move a file, any operation that ends up in the same contents, but from a different path, the SHA-1 is different. This means the only way to know if the contents are the same, is by extracting, and calculating the SHA-1 yourself, which defeats the purpose of what you want the calculation for. I've tried, calculating the SHA-1 and use a previous reference to avoid the transfer, or do the transfer, and let Git check for existing objects doesn't make a difference. This is by Mercurial's stupid design, and there's nothing we, or anybody could do about it until they change it. 2) Checking for file changes For each commit (or revision), we need to figure out which files were modified, and for that, Mercurial has a neat shortcut that stores such modifications in the commit context itself, so it's easy to retrieve. Unfortunately, it's sometimes wrong. Since the Mercurial tools never use this information for any real work, simply to show the changes to the users, Mercurial folks never noticed the contents they were storing were wrong. Which means if you have a repository that started with old versions of mercurial, chances are this information would be wrong, and there's no real guarantee that future versions won't have this problem, since to this day this information continues to be used only display stuff to the user. So, since we cannot rely on this, we need to manually check for differences the way Mercurial does, which blows performance away, because you need to get the contents of the two parent revisions, and compare them away. My content I mean the the manifest, or list of files, which takes considerable amount of time. For 1) there's nothing we can do, and for 2) we could trust the files Mercurial thinks were modified, and that gives us a very significant boost, but the repository will sometimes end up wrong. Most of the time is spent on 2). So unfortunately there's nothing we can do, that's just Mercurial design, and it really has nothing to do with Git. Any other tool would have the same problems, even a tool that converts a Mercurial repository to Mercurial (without using tricks). It seems Bazaar is more sensible in this regard; 1) the checksums are try of the file contents, and 2) each revision does store the file modifications correctly. So a clone in Bazaar is much faster. In my opinion Mercurial just screwed up their design. Cheers. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] upload-pack: ignore 'shallow' lines with unknown obj-ids
On Sun, Apr 21, 2013 at 6:51 AM, Junio C Hamano gits...@pobox.com wrote:
Duy Nguyen pclo...@gmail.com writes:
But the shallow list is also used to compute the updated boundary
(i.e. this client does not have a valid history behind these
commits)? When we know their current shallow boundary, after
sending history that crosses that boundary, we can tell them before
this fetch, you did not have any history behind this commit, but we
know that you now have a bit more. Update your record with these new
boundaries. You still do not have any history behind these commits.
That is how deepening works.
When you receive a shallow boundary unknown to you, it might not
hurt if you keep it and parrot it at the end, so that the fetcher
will still remember that it does not have any history behind the
commit. There may be reasons why doing so is not sufficient and we
have to reject clients whose history is truncated at a place unknown
to us.
You would declare now you have everything behind that unknown
shallow boundary, if you ignore an unknown shallow boundary and do
not send it back.
That sounds ourright wrong to me. You simply do not know enough to
make such a declaration.
It's a good point. But I think the receiver does not rely solely on
shallow lines from the sender to create new shallow file. If it
receives shallow line, it registers the received sha-1 as a cut
point. If it receives unshallow line, it unregisters. If it
receives neither, the current registered cutpoints in memory are
simply written back to disk. So not sending it back should not be a
big problem (at least for C Git).
I do not seem to find the patch you are responding to, so I do not
know how the patch handled the unshallowing part, but the impression
I got from reading the log message quoted is that the patch was not
even aware of the issue.
I can't find it on gmane.org either. Patch quoted below.
On Sat, Apr 20, 2013 at 8:05 PM, Michael Heemskerk
mheemsk...@atlassian.com wrote:
diff --git a/Documentation/technical/pack-protocol.txt
b/Documentation/technical/pack-protocol.txt
index f1a51ed..b898e97 100644
--- a/Documentation/technical/pack-protocol.txt
+++ b/Documentation/technical/pack-protocol.txt
@@ -228,8 +228,7 @@ obtained through ref discovery.
The client MUST write all obj-ids which it only has shallow copies
of (meaning that it does not have the parents of a commit) as
'shallow' lines so that the server is aware of the limitations of
-the client's history. Clients MUST NOT mention an obj-id which
-it does not know exists on the server.
+the client's history.
The client now sends the maximum commit history depth it wants for
this transaction, which is the number of commits it wants from the
diff --git a/upload-pack.c b/upload-pack.c
index bfa6279..127e59a 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -592,7 +592,7 @@ static void receive_needs(void)
die(invalid shallow line: %s, line);
object = parse_object(sha1);
if (!object)
- die(did not find object for %s, line);
+ continue;
if (object-type != OBJ_COMMIT)
die(invalid shallow object %s,
sha1_to_hex(sha1));
if (!(object-flags CLIENT_SHALLOW)) {
--
1.8.0.2
--
Duy
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: t6200: avoid path mangling issue on Windows
Junio C Hamano wrote: But a _real user_ who wants to use a slash there has no way of doing so. Doesn't foo=// do that in the msys world? If I am reading mingw/msys/rt/src/winsup/cygwin/path.cc correctly then the way to pass a true double-slash is foo=///. Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Fwd: [PATCH/RFC] upload-pack: ignore 'shallow' lines with unknown obj-ids
Re-sent to the mailing list because the original was bounced (HTML subpart):
On 21 April 2013 09:56, Duy Nguyen pclo...@gmail.com wrote:
On Sun, Apr 21, 2013 at 6:51 AM, Junio C Hamano gits...@pobox.com wrote:
Duy Nguyen pclo...@gmail.com writes:
But the shallow list is also used to compute the updated boundary
(i.e. this client does not have a valid history behind these
commits)? When we know their current shallow boundary, after
sending history that crosses that boundary, we can tell them before
this fetch, you did not have any history behind this commit, but we
know that you now have a bit more. Update your record with these new
boundaries. You still do not have any history behind these commits.
That is how deepening works.
When you receive a shallow boundary unknown to you, it might not
hurt if you keep it and parrot it at the end, so that the fetcher
will still remember that it does not have any history behind the
commit. There may be reasons why doing so is not sufficient and we
have to reject clients whose history is truncated at a place unknown
to us.
You would declare now you have everything behind that unknown
shallow boundary, if you ignore an unknown shallow boundary and do
not send it back.
That sounds ourright wrong to me. You simply do not know enough to
make such a declaration.
It's a good point. But I think the receiver does not rely solely on
shallow lines from the sender to create new shallow file. If it
receives shallow line, it registers the received sha-1 as a cut
point. If it receives unshallow line, it unregisters. If it
receives neither, the current registered cutpoints in memory are
simply written back to disk. So not sending it back should not be a
big problem (at least for C Git).
With the patch applied, the server ignores the shallow line mentioned by
the server and will not send a shallow or unshallow line for it back to
the client. This scenario is not explicitly described in pack-protocol.txt
but I'd be happy to add it to. I'll also update the comment to cover this
aspect.
As Duy pointed out, it doesn't cause problems in the current C Git
implementation: the client adds a new entry to the shallow file for each
shallow line it receives from the server and removes an entry for each
unshallow line it receives. Any current shallow object that is not
mentioned by the server is still marked as shallow after the fetch.
I think that's how it should be: it should be the client's
responsibility to track
the list of objects it only has in shallow form. It should not rely on
the server
to tell it what that list is. Again, an extra line or two in pack-protocol.txt
would help to clear this up.
In testing this patch, I also discovered that the shallow file is not updated
as part of a prune operation. Arguably, any pruned commits should also
be removed from the shallow file. I haven't included a fix for this in my
patch because it's an existing issue that is best fixed in a separate patch
(in progress).
I do not seem to find the patch you are responding to, so I do not
know how the patch handled the unshallowing part, but the impression
I got from reading the log message quoted is that the patch was not
even aware of the issue.
I can't find it on gmane.org either. Patch quoted below.
On Sat, Apr 20, 2013 at 8:05 PM, Michael Heemskerk
mheemsk...@atlassian.com wrote:
diff --git a/Documentation/technical/pack-protocol.txt
b/Documentation/technical/pack-protocol.txt
index f1a51ed..b898e97 100644
--- a/Documentation/technical/pack-protocol.txt
+++ b/Documentation/technical/pack-protocol.txt
@@ -228,8 +228,7 @@ obtained through ref discovery.
The client MUST write all obj-ids which it only has shallow copies
of (meaning that it does not have the parents of a commit) as
'shallow' lines so that the server is aware of the limitations of
-the client's history. Clients MUST NOT mention an obj-id which
-it does not know exists on the server.
+the client's history.
The client now sends the maximum commit history depth it wants for
this transaction, which is the number of commits it wants from the
diff --git a/upload-pack.c b/upload-pack.c
index bfa6279..127e59a 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -592,7 +592,7 @@ static void receive_needs(void)
die(invalid shallow line: %s, line);
object = parse_object(sha1);
if (!object)
- die(did not find object for %s, line);
+ continue;
if (object-type != OBJ_COMMIT)
die(invalid shallow object %s,
sha1_to_hex(sha1));
if (!(object-flags CLIENT_SHALLOW)) {
--
1.8.0.2
--
Duy
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to
Re: [QUERY] Why do we have git-completion.zsh?
On Sat, Apr 20, 2013 at 5:39 PM, Felipe Contreras felipe.contre...@gmail.com wrote: On Sat, Apr 20, 2013 at 1:53 PM, Jonathan Nieder jrnie...@gmail.com wrote: Jonathan Nieder wrote: Ramkumar Ramachandra wrote: However, I don't understand why we maintain it, because there's a comprehensive first-class completer in ZSH core [1] which I use all the time. Shouldn't the completion folks be contributing to this instead? Only if they want to. [...] http://thread.gmane.org/gmane.comp.version-control.git/210022/focus=210024 Sorry, wrong link. Here's a better one: http://www.zsh.org/mla/workers/2011/msg00497.html More fundamentally, your question seems to assume some kind of shared plan regarding what people work on, rather than each person choosing to work on what they consider valuable without having to justify it to others. I am very happy with Felipe's work on git's completion code and don't think it does any harm to efforts elsewhere. To complement the reason; the zsh folks (or perhaps it's only one; who works on the git stuff), absolutely prioritize correctness over speed, that means if it takes ten seconds to list all the possible files to complete, grouped nicely, that's exactly what they'll do, instead of the way the bash completion does, which lists the most likely files, which takes milliseconds. I found zsh's completion unbearably slow, which is ironic; git is the fastest DSCM on Earth, and they blow the performance away by making the completion dead slow, to the point where the completion is several orders of magnitude slower than the actual command. To me, the whole point of the completion is to make the work faster, and if the completion takes longer than me typing it, what's the point of it? And I'm not the only one, when I contributed this stuff to oh-my-zsh[1] I got a very positive response. I couldn't convince them of this obvious fact, so I choose git's bash fast completion. I have patches to improve the zsh thin wrapper to give more information, zsh style, in a way that is superior to zsh's git completion, but I'm still not happy with them, I want the user to be able to configure the output so it's not totally bloated like in zsh, and I'm still working on it. In the mean time, I want my completion to be blazingly fast, and at least as good as git's bash completion. Actually, it's mostly there now: https://github.com/felipec/git/blob/fc/zsh/ng/contrib/completion/git-completion.zsh This greatly improves 'git tab' over the plain bash version, and it's even better than the official zsh version, because you can do something like: zstyle ':completion:*:*:git:*' tag-order 'common-commands porcelain-commands' To show only the command groups you are interested on. With official zsh, you get the whole enchilada of all the commands git has. Hardly user-friendly. Cheers. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] show: obey --textconv for blobs
On Sat, Apr 20, 2013 at 03:38:53PM +0200, Michael J Gruber wrote: Wait, this does the opposite of the last patch. If we do want to do this, shouldn't the last one have been an expect_failure? The last patch just documents the status quo, which is not a bug per se. Therefore, no failure, but change in the definition of success. IMHO, the series is easier to review if you it does not go back and forth. If you have one patch that says X is the right behavior, and then another patch that flips it to say Y is the right behavior, the reviewer would read each in sequence and want to be convinced by your arguments for X and Y. But you probably cannot make a good argument for X if you are trying to end up at Y. :) So I'd much rather see the test introduced with the desired end behavior, marked as expect_failure, and the commit message contain an argument about why Y is a good thing (and squashing the tests in with the actual fix is often even better, because the fix itself would want to contain the same argument). Just my two cents as a reviewer. My reasoning is twofold: - consistency between git show commit and git show blob I'm not sure I agree with this line of reasoning. git show commit is showing a diff, not the file contents; textconv has always been about munging the contents to produce a textual diff. It may be reasonable to extend its definition to this is the preferred human view of this content, and that happens to be what you would want to produce a diff. But I do not think it is necessarily inconsistent not to apply it for the blob case. - git show is a user facing command, and as such should produce output consumable by humans; whereas git cat-file is plumbing and should produce raw data unless told otherwise (-p, --textconv). That holds if the textconv is the only (or best) human-readable version of the file. And maybe that is reasonable. But is it possible that somebody uses textconv to produce a better diff of some already human-readable format? For example, imagine I define a textconv for XML files that normalizes the formatting to make diffs less noisy. When I am not looking at a diff, what is the best human-readable version? The original, or the normalized one? I'm not sure. Note that I'm somewhat playing devil's advocate here. For the cases where I have used textconv in the real world, I think I would probably prefer seeing the converted contents, and I am happy to call it user error if I use git show HEAD:foo.jpg bar.jpg accidentally. But I also want to make sure we are not regressing somebody else unnecessarily. -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 6/6] grep: obey --textconv for the case rev:path
On Sat, Apr 20, 2013 at 04:42:49PM +0200, Michael J Gruber wrote: And this mass of almost-the-same functions is gross, too, especially given that the object_context contains a mode itself. Well, it's just providing different ways to call into the one and only function, in order to satisfy different callers' needs. It's not unheard of (or rather: unseen) in our code, is it? No, we have instances of it already. And they're ugly, too. :) I think when we hit more than 2 or 3 wrappers it is time to start thinking whether they can be consolidated. I think it is mostly the overlap in context and mode that makes me find this one particularly ugly. But it's probably not solvable without some pretty heavy refactoring. I vaguely seem to recall we had some more general framework cooking but I may be wrong (I was offline due to sickness for a while). It was about attaching some additional info to something. Yes, I said vaguely ... Yeah, I really wanted to keep the context inside the object_array, but it means either wasting a lot of space (due to over-large buffers) or having the array elements be variable-sized (with a flex-array for the pathname). And object_array entries already have a memory-leak problem from the name field, which I think we just punt on elsewhere. So I think this is probably the lesser of the possible evils. -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] Teach git to change to a given directory using -C option
On Sat, Apr 20, 2013 at 03:18:38PM -0700, Jonathan Nieder wrote: The sometimes you just want to pass a command to 'exec' use case does not convince me. I equally well might want to run git after another command, or run git if and only if a repository exists there, or do any number of other things. Sure. I don't claim that it solves every problem, just that I have wanted it in that situation before. So we're left with --git-dir does not automatically append .git when appropriate as the problem being solved, which is a real problem. Maybe that is worth fixing more directly? I'm a little hesitant, because --git-dir is _not_ pretend like I am in directory X. Even though people may use it that way for bare repositories, it explicitly does not change your working tree. I'm not sure what rule you are proposing. If it is: 1. When we get --git-dir=a/b, look in a/b/.git (assuming a/b is not a repo itself). 2. When we get --git-dir=a/b, do the usual repo search from a/b, finding the first of a/b, a/b/.git, a/.git. The second one is what makes me nervous, as it seems too much like pretend that we are in a/b. But the first one seems kind of hack-ish. I suppose it is similar to the enter_repo rule used to find remotes, though, so at least there is some precedence. It might also be convenient to be able to do something like git --git-dir=~/src/git log -- Documentation/ which this -C option makes easy. *checks* Actually it works without, but for subtle reasons. I'm not sure what subtle reason that is. It does not seem to work for me: $ (cd git git log -- Documentation | wc -l) 99152 $ git --git-dir=git log -- Documentation | wc -l fatal: Not a git repository: 'git' 0 A more interesting subtlety is this: $ git --git-dir=git/.git log -- Documentation | wc -l 99152 $ git --git-dir=git/.git log Documentation | wc -l fatal: ambiguous argument 'Documentation': unknown revision or path not in the working tree. Use '--' to separate paths from revisions, like this: 'git command [revision...] -- [file...]' 0 All that said, I don't mind -C terribly as long as it can maintain itself, which means including thorough documentation that covers the purpose and how pathname parameters and envvars interact with the new option and including tests under t/ to ensure it continues to work correctly in the future. Yeah, I pretty much feel the same way. git -C is a concept that has occurred to me several times over the years, and I always dismissed it as bah, you can do the same thing easily with one line of shell. It makes sense to me because of the precedence in other programs and I would probably use it, but I could also live without it. I do not mind it if it is not a maintenance burden. -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: [QUERY] Why do we have git-completion.zsh?
Felipe Contreras wrote: To complement the reason; the zsh folks (or perhaps it's only one; who works on the git stuff), absolutely prioritize correctness over speed, that means if it takes ten seconds to list all the possible files to complete, grouped nicely, that's exactly what they'll do, instead of the way the bash completion does, which lists the most likely files, which takes milliseconds. I see. Yes, I was looking for a reason like this. True. I've noticed that my shell just hangs when I attempt to tab-complete too early/ something wrong, and this would be nice to fix. Does it have to be a hard trade-off between correctness and speed? Is it not possible to reach a fair compromise? Now, I don't know anything about zsh's git completer versus the gitfast completer. From a glance, it looks like zsh's git completer is much larger and stuffed with features that the gitfast completer doesn't have. Although I agree that speed isn't the only parameter, can you shed some light on how these two compare on other parameters? Or you could help me figure all this out myself. How do I profile/debug shell code? I'm feeling a little lost without gdb and valgrind. And I'm not the only one, when I contributed this stuff to oh-my-zsh[1] I got a very positive response. Found it: https://github.com/robbyrussell/oh-my-zsh/commit/5a11228 If they wanted my contributions, that would be awesome, but that doesn't appear to be the case. And I'm kind of relieved, because zsh's completion is monstrous code, and the zsh development practices are not good (e.g. all my logically independent patches get squashed into one commit). I see. I've just started poking them with patches. I'll see what happens for myself. Cheers. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[BUG] Filenames with single colon being treated as remote repository
All, It was brought to my attention today that git has some weird behaviour when colons (:) are used in directory names. In my distros packaging system, for git repositories we clone a bare repo and then clone that bare repo locally as a temporary build directory (no, we can't use cp, it's a bare repository). Say we have a directory, /tmp/foo:bar/baz, that is a git repository. If I want to get a clone of that repository locally, using all of the local optimizations, then I need to run:: $ git clone /tmp/foo:bar/baz /tmp/new-baz but running this gives me this output:: Cloning into 'new-baz'... ssh: Could not resolve hostname /tmp/foo: Success fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. which it should not be doing. It is possible to use a file:// url to clone it, but then the --local option is ignored and no optimizations are made. After asking on #git, I was directed to the transport.c file, but I don't know what in that is failing. We ran some tests on the is_local function and it seems to work correctly. Any ideas on how to debug this further? Thank you, -- William Giokas | KaiSforza GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF pgpkOlM_UNxBu.pgp Description: PGP signature
Re: [PATCHv2 6/8] t9114.2: Don't use --track option against svn-remote-tracking branches
Acked-by: Eric Wong normalper...@yhbt.net -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
