Re: [QUERY] Why do we have git-completion.zsh?
Felipe Contreras wrote: > First of all, 'gitfast' is just the name I gave to the oh-my-zsh > plugin that uses git.git's completion stuff. The zsh support in git's > bash completion has been working for years, I just copied the stuff to > oh-my-zsh so those guys can use it easily. Yeah, I know. I just used the name. > Secondly, I don't see what "features" zsh's git completer might have > that we don't. Yes, some specific argument behaviors are nice, like > adding a '=' after --git-dir, and then complete only directories, and > completion descriptions, along with tag groupings, but all those > things are cosmetic, and they could be added relatively easy to my > thin wrapper (which wouldn't be so thin after all). It's mostly grunt > work, not something that requires a great mind. > > Functionally I don't see any value. > Are these minor features worth all this slowness and complicated code? > I don't think so. Moved to using git.git's completer, and I see that you're absolutely right about the "minor features" missing part. I just assumed that zsh's completer must be more complete because it's so much larger than git.git's bash/zsh completer. Working backwards from zsh's completer would've been a nightmare. > The reason why I prefer git.git's bash completion is that it has taken > years to develop, and using good development practices, borrowed from > the mainline git process. Many more people use them, have debugged > them through the years, and optimized them. It's relatively small > (compared to zsh's version), much more readable, and it even has tests > (which I helped to start), and it's much less buggy. It's basically > rock solid. Great! I'll stop working on zsh's completer immediately, and try to redirect my attention on improving git.git's completer instead. Thanks for the information. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5] git-log.txt: rewrite note on why "--" may be required
Ramkumar Ramachandra writes: > 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 > --- > 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. I think "branch names" was an attempt to make it more newbie friendly by sacrificing technical accuracy. With the suggested update (see the review for the previous one), it would be easier to read if this part said "options or the revision range". Two other things I noticed with the current text are: * As the synopsis section shows, on the command line, --options come first, then revision range and then pathspec. The order of the description should follow that as well. The current text shows .. at the very beginning, which is wrong. * The part with the new "-L" option seems to be throwing the overall formatting off. Its second paragraph " and can take..." is not indented to the same level as its first paragraph "Trace the evolution of...", and the following items, like "--full-line-diff" and "[--] ..." are indented one level too deeply. -- To unsubscribe from this list: send the line "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 ..
Ramkumar Ramachandra writes: > First, and are ways to specify "revisions", not > "commits", as gitrevisions.txt would indicate. Second, > '..' 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 '..' under OPTIONS. > > Signed-off-by: Ramkumar Ramachandra > --- > 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 > --- > > ..:: > - Show only commits between the named two commits. When > + Show only commits between the named two revisions. When > either or is omitted, it defaults to > `HEAD`, i.e. the tip of the current branch. > - For a more complete list of ways to spell > - and , see linkgit:gitrevisions[7]. > + For a more complete list of ways to spell .., > + see linkgit:gitrevisions[7]. A bigger issue is if it is a good idea to single out A..B like this in the enumeration of options and parameters. We are listing this among the optoins and pathspec, so this is where we _ought_ to be saying that you can specify a revision range on the command line. We use A..B only because it is the most commonly used form, asking e.g. "show me the commit since v1.7.12 up to v1.8.0", but this existing headline makes it as if it is the _only_ form, which is somewhat misleading. It might be better _not_ to say .. here and on the synopsis part, replace it with , and update the text to mention .. as a more concrete "v1.0..v2.0" example. Perhaps like :: Show only commits in the specified revision range. When no is specified, defaults to "HEAD" (i.e. the whole history leading to the current commit). v1.0..v2.0 asks for commits since the commit tagged as version 1.0 up to the commit tagged as version 2.0. For a more complete list of ways to spell this parameter, see "Specifying Ranges" section of linkgit:gitrevisions[7]. or something. Documentation/gitrevisions.txt lists .., but does not mention that missing (or ) defaults to HEAD, which is worth adding there with or without the above suggested update. -- To unsubscribe from this list: send the line "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
Johannes Sixt wrote: > Am 21.04.2013 02:05, schrieb Jonathan Nieder: >> 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=///. > > That would be totally unexpected. There is an exception to the path mangling for //unc/paths, if that's what you mean. >From [1]: if (path[0] == '/' && path[1] == '/') { int tidx = 2; while (spath[tidx] && spath[tidx] == '/') tidx++; if (strchr (&spath[tidx], '/')) { retpathcpy (spath); } else { retpathcpy (&spath[1]); } return ScrubRetpath (retpath); } I haven't tested, since I don't have easy access to a Windows test setup. Regards, Jonathan [1] http://mingw.cvs.sourceforge.net/viewvc/mingw/msys/rt/src/winsup/cygwin/path.cc?content-type=text%2Fplain -- To unsubscribe from this list: send the line "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
Am 21.04.2013 02:05, schrieb Jonathan Nieder: > 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=///. That would be totally unexpected. -- Hannes -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [QUERY] Why do we have git-completion.zsh?
On Sat, Apr 20, 2013 at 11:36 PM, Ramkumar Ramachandra wrote: > 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? It doesn't matter, the zsh folks don't want *any* compromise: http://article.gmane.org/gmane.comp.shells.zsh.devel/22475 > 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? First of all, 'gitfast' is just the name I gave to the oh-my-zsh plugin that uses git.git's completion stuff. The zsh support in git's bash completion has been working for years, I just copied the stuff to oh-my-zsh so those guys can use it easily. I also added my thin zsh wrapper, because of issues with zsh's bash completion emulation, but that's not specific to oh-my-zsh in any way. Secondly, I don't see what "features" zsh's git completer might have that we don't. Yes, some specific argument behaviors are nice, like adding a '=' after --git-dir, and then complete only directories, and completion descriptions, along with tag groupings, but all those things are cosmetic, and they could be added relatively easy to my thin wrapper (which wouldn't be so thin after all). It's mostly grunt work, not something that requires a great mind. Functionally I don't see any value. For example, a difference is that when you do 'git show v', git.git bash's completion will show refs, and only if there aren't any that could match, show files, any files. zsh's version will show both files and refs at the same time, and if you have grouping enabled they would show that way, in the git.git repo I see them grouped in commit tag, tag, 'cached file' (although showing tags twice is probably a bug), and only the files present in the repository. Another one is that when you do 'git add ', you see the results grouped for example in 'modified file', 'untracked file', whereas in bash they can't be grouped. Are these minor features worth all this slowness and complicated code? I don't think so. Also, the grouping requires a configuration like: zstyle ':completion:*:descriptions' format '%B%d%b' zstyle ':completion:*' group-name '' And I bet most people don't have such configuration. So all this complicated code achieves nothing for the majority of users. The reason why I prefer git.git's bash completion is that it has taken years to develop, and using good development practices, borrowed from the mainline git process. Many more people use them, have debugged them through the years, and optimized them. It's relatively small (compared to zsh's version), much more readable, and it even has tests (which I helped to start), and it's much less buggy. It's basically rock solid. Just now I was reading about a bug in zsh-workers when you do 'git show v3' in the Linux kernel git tree, and you can count the seconds before it completes. This is the sort of thing that just doesn't happen with git's bash completion. > 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. For git.git's bash completion I just run a script that exercises the function I'm interested in with perf. Fortunately nothing there is really slow, so I don't have to track offenders (usually). Unfortunately zsh's completion stuff can't be scripted, or at least I haven't managed to find a way to either profile or write tests for any of that code. >> 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. Yeah, I did contribute patches myself too. As long as they are superficial, like adding a missing argument or so, they are fine. But don't try messing with their precious "completeness". Cheers. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a mes
Re: [BUG] Filenames with single colon being treated as remote repository
Hi, William Giokas wrote: > $ 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. Here's a toy patch. I haven't thought carefully about whether it's a good idea, but maybe it can be useful for thinking about that. Still needs documentation and tests. My main worry is that the proposed rule for when an argument is treated as a local path is hard to explain. There's some precedent in handling of bundles, though. What do you think? Thanks, Jonathan diff --git i/transport.c w/transport.c index e6f9346c..61eba842 100644 --- i/transport.c +++ w/transport.c @@ -903,6 +903,7 @@ struct transport *transport_get(struct remote *remote, const char *url) { const char *helper; struct transport *ret = xcalloc(1, sizeof(*ret)); + struct stat st; ret->progress = isatty(2); @@ -942,6 +943,7 @@ struct transport *transport_get(struct remote *remote, const char *url) ret->disconnect = close_bundle; ret->smart_options = NULL; } else if (!is_url(url) + || (is_local(url) && !stat(url, &st)) || !prefixcmp(url, "file://") || !prefixcmp(url, "git://") || !prefixcmp(url, "ssh://") -- To unsubscribe from this list: send the line "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 6/8] t9114.2: Don't use --track option against "svn-remote"-tracking branches
Acked-by: Eric Wong -- To unsubscribe from this list: send the line "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: [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
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 [...] -- [...]' 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: [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 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: [QUERY] Why do we have git-completion.zsh?
On Sat, Apr 20, 2013 at 5:39 PM, Felipe Contreras wrote: > On Sat, Apr 20, 2013 at 1:53 PM, Jonathan Nieder 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 ' 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
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 wrote: > > On Sun, Apr 21, 2013 at 6:51 AM, Junio C Hamano wrote: > > Duy Nguyen 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 > 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 th
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
Re: [PATCH/RFC] upload-pack: ignore 'shallow' lines with unknown obj-ids
On Sun, Apr 21, 2013 at 6:51 AM, Junio C Hamano wrote: > Duy Nguyen 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 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: Is there a way to speed up remote-hg?
On Sat, Apr 20, 2013 at 6:07 AM, John Szakmeister 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: [PATCHv2 1/8] t2024: Add tests verifying current DWIM behavior of 'git checkout '
On Sat, Apr 20, 2013 at 10:44 PM, Jonathan Nieder 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, 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: [QUERY] Why do we have git-completion.zsh?
On Sat, Apr 20, 2013 at 1:53 PM, Jonathan Nieder 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: [PATCH 3/5] git-log.txt: fix description of ..
Ramkumar Ramachandra wrote: > First, and 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: [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= -- :/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
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/RFC] upload-pack: ignore 'shallow' lines with unknown obj-ids
Duy Nguyen writes: > On Sat, Apr 20, 2013 at 8:05 PM, Michael Heemskerk > 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 ". 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
Re: [PATCHv2 1/8] t2024: Add tests verifying current DWIM behavior of 'git checkout '
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: > +# > +# Verify that we have checked out , and that it is at the same > +# commit as , and that has appropriate tracking config > +# setup against > +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 &&
Re: [PATCH v2 1/8] Add new git-cc-cmd helper to contrib
Johannes Sixt 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: [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: [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
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: Some observations on log -L
Ramkumar Ramachandra 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
[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 --- 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 --- 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 <> that is used to follow changes from - another <>. 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 <> in a Pull: - <>. + A <> that is used to follow changes from another + <>. 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 <>. A remote-tracking + branch should not contain direct modifications or have local + commits made to it. [[def_repository]]repository:: A collection of <> 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
[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 --- 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 ' ' +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 Signed-off-by: Johan Herland --- 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 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 --- 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 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 --- 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 --- 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_
[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..remote and branch..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 ' 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 '
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 --- 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 + +Ensures that checkout on an unborn branch does what the user expects' + +. ./test-lib.sh + +# Arguments: +# +# Verify that we have checked out , and that it is at the same +# commit as , and that has appropriate tracking config +# setup against +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
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 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
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 " obeys the textconc setting while "git show " >> 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 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 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] 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: 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 --- 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[] -U:: -- 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: 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 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
[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 --- 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
[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 --- 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] [--] [... ]"), - "", - N_("[rev-opts] are documented in git-rev-list(1)"), + N_("git shortlog [] [..] [[--] [...]]"), 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 --- 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[[,[, ... +git log --pretty=short | 'git shortlog' [] +'git shortlog' [] [..] [[\--] ...] DESCRIPTION --- @@ -26,6 +26,13 @@ reference to the current repository. OPTIONS --- +..:: + Consider only commits between the named two revisions. When + either or is omitted, it defaults to `HEAD`, + i.e. the tip of the current branch. For a more complete list + of ways to spell .., 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. +[\--] ...:: + 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 3/5] git-log.txt: fix description of ..
First, and are ways to specify "revisions", not "commits", as gitrevisions.txt would indicate. Second, '..' 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 '..' under OPTIONS. Signed-off-by: Ramkumar Ramachandra --- 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 --- ..:: - Show only commits between the named two commits. When + Show only commits between the named two revisions. When either or is omitted, it defaults to `HEAD`, i.e. the tip of the current branch. - For a more complete list of ways to spell - and , see linkgit:gitrevisions[7]. + For a more complete list of ways to spell .., + 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 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 --- 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 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 .. 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
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
Re: is git-p4 compatible with p4/linux?
On Thu, Apr 18, 2013 at 5:09 PM, Pete Wyckoff 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
Re: [PATCH] gitk: workaround Tcl/Tk Cmd-TAB behavior on OSX
On Apr 20, 2013, at 9:19 AM, Paul Mackerras 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: [PATCH/RFC] upload-pack: ignore 'shallow' lines with unknown obj-ids
On Sat, Apr 20, 2013 at 8:05 PM, Michael Heemskerk 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 ". 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 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 -- 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[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
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
[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
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 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, 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