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: [QUERY] Why do we have git-completion.zsh?
On Sat, Apr 20, 2013 at 11:36 PM, Ramkumar Ramachandra artag...@gmail.com 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 vtab', 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 tab', 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 v3tab' 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 message to
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: [PATCH 3/5] git-log.txt: fix description of since..until
Ramkumar Ramachandra artag...@gmail.com writes: First, since and until are ways to specify revisions, not commits, as gitrevisions.txt would indicate. Second, 'since..until' is simply indicative of how users would normally want to specify the rev spec: it need not conform to this form, and can take any form that gitrevisions.txt lists. A 'git log :/quuxery' is perfectly valid, for instance. Make these two corrections to the description of 'since..until' under OPTIONS. Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- Documentation/git-log.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt index 69db578..f03ae74 100644 --- a/Documentation/git-log.txt +++ b/Documentation/git-log.txt @@ -25,11 +25,11 @@ OPTIONS --- since..until:: - Show only commits between the named two commits. When + Show only commits between the named two revisions. When either since or until is omitted, it defaults to `HEAD`, i.e. the tip of the current branch. - For a more complete list of ways to spell since - and until, see linkgit:gitrevisions[7]. + For a more complete list of ways to spell since..until, + see linkgit:gitrevisions[7]. 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 since..until here and on the synopsis part, replace it with revision range, and update the text to mention since..until as a more concrete v1.0..v2.0 example. Perhaps like revision range:: Show only commits in the specified revision range. When no revision range 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 rev1..rev2, but does not mention that missing rev1 (or rev2) 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: [PATCH 4/5] git-log.txt: rewrite note on why -- may be required
Ramkumar Ramachandra artag...@gmail.com 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 artag...@gmail.com --- Documentation/git-log.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt index f03ae74..1a9c3ca 100644 --- a/Documentation/git-log.txt +++ b/Documentation/git-log.txt @@ -75,8 +75,8 @@ produced by --stat etc. Simplification below for details and other simplification modes. + -To prevent confusion with options and branch names, paths may need to -be prefixed with \-- to separate them from options or refnames. +Paths may need to be prefixed with \-- to separate them from +options or revisions, when confusion arises. 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 since..until 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 start and end 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 [--] pathspec... 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: [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 5/5] git-shortlog.txt: make SYNOPSIS match log, update OPTIONS
Ramkumar Ramachandra artag...@gmail.com writes: +since..until:: + Consider only commits between the named two revisions. When + either since or until is omitted, it defaults to `HEAD`, + i.e. the tip of the current branch. For a more complete list + of ways to spell since..until, see + linkgit:gitrevisions[7]. + The same revision range comment, and also that this should be after all options and before -- pathspec, apply to this. @@ -56,6 +63,16 @@ OPTIONS If width is `0` (zero) then indent the lines of the output without wrapping them. +[\--] path...:: + Consider only commits that are enough to explain how the files + that match the specified paths came to be. See History + Simplification below for details and other simplification + modes. ++ +Paths may need to be prefixed with \-- to separate them from +options or revisions, when confusion arises. + +include::rev-list-options.txt[] While it is true that this page is missing many options, including rev-list-options.txt as-is is more harmful than helpful and the patch needs more work (hint: with ifdef::git-shortlog[] sprinkled in rev-list-options.txt). Some of the earlier one in rev-list-options are fine, but some others are inappropriate in the context of shortlog. For example, --grep=pattern, while it would internally work as it is told to do, is unlikely to be clear how well/correctly worked when viewing the end result. So are many others, such as --all-match, --walk-reflogs, --sparse, etc. Some e.g. --topo-order, do not make sense at all. I am not sure what the command would do if you give --stdin; the command wants to read from the standard input to operate as a filter for git log output, but the --stdin from rev-list family wants to read revision range specifiers from the standard input. I do not think it is something any sane user would want to do. -- To unsubscribe from this list: send the line 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
Jonathan Nieder jrnie...@gmail.com writes: 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? that refers to...? Do you mean: $ value=/; mycmd key=$value breaks msys, but you can say $ value=//; mycmd key=$value instead to pass a value that is a single slash. then that is not a valid workaround; it would work differently between Windows (passes one slash?) and everybody else (passes two slashes). I do not mean to say the '' (empty string) and what you want to say and '' (empty string) concatenated together I suggested in the previous message is a workable (let alone the best) proposition, but if $ value=/; mycmd key=''$value'' worked as a way to temporarily turn off the path mangling, it at least would be a usable workaround that would work the same way between Windows and everybody else. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] git-log.txt: fix description of since..until
Jonathan Nieder wrote: What's the difference between a revision and a commit? The definition in gitglossary(7) only confuses me. What's so confusing about it? commit:: As a noun: A single point in the Git history; the entire history of a project is represented as a set of interrelated commits. The word commit is often used by Git in the same places other revision control systems use the words revision or version. Also used as a short hand for commit object. revision:: A particular state of files and directories which was stored in the object database. It is referenced by a commit object. -- 8 -- There a reference to revision in the commit description which might be misleading. Otherwise, these are quite accurate. master~3:README is a valid revision, but not a commit, for instance. Another problem with the word commit is that it doesn't encapsulate ranges like 'master~3..HEAD'. It would probably help to add the terms commitish and treeish to the glossary to refer to rev specs (those in revisions.txt) that resolve to commits or trees. I'll give you two simple examples: 1. In 'git show master:README', master is a treeish and master:README is a blob. If we were to say 'git blame master: -- README', it would error out because master: is not a commitish, but a treeish. 2. In 'git log master~3.. -- README', master~3.. is a commitish. In general, log can take only rev specs that resolve to a commits. Although 'git log master:' doesn't error out, it doesn't make any sense either. Perhaps we should tighten it? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] git-log.txt: fix description of since..until
Jonathan Nieder jrnie...@gmail.com writes: Ramkumar Ramachandra wrote: First, since and until are ways to specify revisions, not commits, as gitrevisions.txt would indicate. What's the difference between a revision and a commit? The definition in gitglossary(7) only confuses me. They are the same, but I think it is irrelevant. We do not want revision or commit there, anyway. We want a revision range there. This is git log not git show. -- To unsubscribe from this list: send the line 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?
Simon Ruderich si...@ruderich.org writes:
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[]
It probably is a better change to drop Use `-c`... and refer to
the Diff formatting section.
And then add '-p' and the fact that by default it will not show
pairwise diff for merge commits to the Diff Formatting section.
That is where -c/--cc/-m are already described.
--
To unsubscribe from this list: send the line 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
Junio C Hamano wrote: 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. Why does it have to be a range? It might well be a list of revisions, so I'm tempted to stick with the word revisions. As I wrote in the previous email, I think revision can be referenced by any one of the syntaxes specified in revisions.txt (this includes a committish range). -- To unsubscribe from this list: send the line 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 artag...@gmail.com writes: Junio C Hamano wrote: 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. Why does it have to be a range? It might well be a list of revisions, Study Specifying Ranges section of gitrevisions and come back, perhaps? A list of revisions is merely a way to specify revision range that are reachable from any of these revisions listed. log A B won't stop by just showing A and B (that would be show A B), but will list those that are reachable from A B, so in the context of discussing the arguments given to git log command, A B is still revision range. -- To unsubscribe from this list: send the line 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
Junio C Hamano wrote: A list of revisions is merely a way to specify revision range that are reachable from any of these revisions listed. log A B won't stop by just showing A and B (that would be show A B), but will list those that are reachable from A B, so in the context of discussing the arguments given to git log command, A B is still revision range. ... and what about 'git log HEAD^!'? Is that a range? What about 'git log HEAD:README' (hint: it doesn't error out)? I would argue that A B is not inherently a revision range, but rather two revisions. It's upto different commands to interpret it differently. Then again, in the context of log, we just want ranges (also considering we had since..until for this long, and I didn't even object to it). So I'll go with your revision range, but I won't claim that it's technically accurate. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
jc/add-2.0-delete-default (Re: What's cooking in git.git (Apr 2013, #05; Mon, 15))
On Fri, Apr 19, 2013 at 10:25:46AM -0700, Junio C Hamano wrote:
Junio C Hamano wrote:
You ran 'git add' with neither '-A (--all)' or '--no-all', whose
behaviour will change in Git 2.0 with respect to paths you
removed from your working tree.
* 'git add --no-all pathspec', which is the current default,
ignores paths you removed from your working tree.
* 'git add --all pathspec' will let you also record the
removals.
The removed paths (e.g. '%s') are ignored with this version of Git.
Run 'git status' to remind yourself what paths you have removed
from your working tree.
or something?
[...]
Somebody good at phrasing needs
to trim it down without losing the essense.
By the way, it was mentioned on IRC that the above is a bit odd for
a different reason: the option --no-all that maintains the old behavior
is not intuitively named.
How about something like this?
warning: git add run on path with files removed (e.g., '%s')
hint: use git add --ignore-removals pathspec to ignore removals
hint: or git add --no-ignore-removals pathspec to notice them
hint: --ignore-removals is the default but this will change soon
hint: see git-add(1) for details
Then the --ignore-removals option could be added using a patch like
the following.
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
Documentation/git-add.txt | 24 +++-
builtin/add.c | 28 +---
2 files changed, 40 insertions(+), 12 deletions(-)
diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index b0944e57..8607cf37 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -9,7 +9,8 @@ SYNOPSIS
[verse]
'git add' [-n] [-v] [--force | -f] [--interactive | -i] [--patch | -p]
- [--edit | -e] [--all | [--update | -u]] [--intent-to-add | -N]
+ [--edit | -e] [--update | -u] [--no-ignore-removals | -A]
+ [--intent-to-add | -N]
[--refresh] [--ignore-errors] [--ignore-missing] [--]
[pathspec...]
@@ -109,17 +110,22 @@ If no pathspec is given, the current version of Git
defaults to
and its subdirectories. This default will change in a future version
of Git, hence the form without pathspec should not be used.
+--ignore-removals::
+--no-ignore-removals::
-A::
--all::
- Update the index not only where the working tree has a file
- matching pathspec but also where the index already has an
- entry. This adds, modifies, and removes index entries to
- match the working tree.
+ Update the index only where the working tree has a file
+ matching pathspec. This adds and modifies index entries
+ to match the working tree but ignores removed files.
+
-If no pathspec is given, the current version of Git defaults to
-.; in other words, update all files in the current directory
-and its subdirectories. This default will change in a future version
-of Git, hence the form without pathspec should not be used.
+This is currently the default. Git 2.0 will change the default
+to --no-ignore-removals.
++
+With --no-ignore-removals (and its historical synonyms `-A` and
+`--all`), if no pathspec is given, the current version of Git
+defaults to .; in other words, update all files in the current
+directory and its subdirectories. This default will change in a future
+version of Git, hence the form without pathspec should not be used.
-N::
--intent-to-add::
diff --git a/builtin/add.c b/builtin/add.c
index ab1c9e8f..4a4e71ad 100644
--- a/builtin/add.c
+++ b/builtin/add.c
@@ -28,6 +28,14 @@ struct update_callback_data {
int add_errors;
};
+static int parse_opt_neg_tertiary(const struct option *opt, const char *arg,
+ int unset)
+{
+ int *target = opt-value;
+ *target = unset ? 1 : 2;
+ return 0;
+}
+
static int fix_unmerged_status(struct diff_filepair *p,
struct update_callback_data *data)
{
@@ -271,7 +279,8 @@ static const char ignore_error[] =
N_(The following paths are ignored by one of your .gitignore files:\n);
static int verbose = 0, show_only = 0, ignored_too = 0, refresh_only = 0;
-static int ignore_add_errors, addremove, intent_to_add, ignore_missing = 0;
+static int ignore_add_errors, intent_to_add, ignore_missing = 0;
+static int ignore_removals, addremove;
static struct option builtin_add_options[] = {
OPT__DRY_RUN(show_only, N_(dry run)),
@@ -283,10 +292,12 @@ static struct option builtin_add_options[] = {
OPT__FORCE(ignored_too, N_(allow adding otherwise ignored files)),
OPT_BOOLEAN('u', update, take_worktree_changes, N_(update tracked
files)),
OPT_BOOLEAN('N', intent-to-add, intent_to_add, N_(record only the
fact that the path will be added later)),
- OPT_BOOLEAN('A', all, addremove, N_(add changes from all
Re: [PATCH 4/5] git-log.txt: rewrite note on why -- may be required
Junio C Hamano gits...@pobox.com writes: Ramkumar Ramachandra artag...@gmail.com writes: Junio C Hamano wrote: 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. Why does it have to be a range? It might well be a list of revisions, Study Specifying Ranges section of gitrevisions and come back, perhaps? A bit more specifically, there is a reason why we list Specifying Revisions and Specifying Ranges separately in that manual page. I think you are trying explain git log --short A B ^C as if it takes --short (which is an option), A, B, and ^C (all of which are revisions). And I am saying that is wrong. It is --short (which is an option) and A B ^C (which is a revision range). git log --short A is taking --short (an option) and A. This A is still a revision range and not a single revision. It is a single commit that is used to name a revision range which is the entire history behind the commit A. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] git-log.txt: fix description of since..until
Ramkumar Ramachandra wrote: What's so confusing about it? [...] revision:: A particular state of files and directories which was stored in the object database. It is referenced by a commit object. So a revision is a tree? (one of the things pointed to by a commit object, representing a particular state of files and directories) -- To unsubscribe from this list: send the line 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 artag...@gmail.com writes: ... and what about 'git log HEAD^!'? Is that a range? Of course it _is_ a range; didn't you read it in the specifying ranges section? It is a short-hand for include HEAD, exclude its parents, and you can further combine it with other starting points. What about 'git log HEAD:README' (hint: it doesn't error out)? Sounds like a bug, if it doesn't. Patches welcome---I suspect that it can be solved the same way as the recent cherry-pick patch by Miklos. I would argue that A B is not inherently a revision range, but rather two revisions. It's upto different commands to interpret it differently. That is why I said this is git log, not git show. -- To unsubscribe from this list: send the line 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
Junio C Hamano wrote: I think you are trying explain git log --short A B ^C as if it takes --short (which is an option), A, B, and ^C (all of which are revisions). And I am saying that is wrong. It is --short (which is an option) and A B ^C (which is a revision range). Got it. Your explanation makes more sense. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5] git-log.txt: rewrite note on why -- may be required
Junio C Hamano wrote: Sounds like a bug, if it doesn't. Patches welcome---I suspect that it can be solved the same way as the recent cherry-pick patch by Miklos. It's not as pressing as the glaring Documentation inaccuracies, so I'll queue the task. To exclude this case, I would say the most technically accurate description of what 'git log' takes is a committish range (basically a revision range that resolves to commits). -- To unsubscribe from this list: send the line 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 wrote: I would say the most technically accurate description of what 'git log' takes is a committish range (basically a revision range that resolves to commits). What is a revision range that doesn't resolve to commits? Am I wrong in thinking revision is nothing more than a synonym for commit? When gitrevisions(7) says A revision parameter rev typically, but not necessarily, names a commit object, I suspect it is residue from 3a45f625 trying to apologize for the extended SHA1 syntax parser being called git rev-parse instead of git object-name-parse. -- To unsubscribe from this list: send the line 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] prompt: fix tracked files for zsh
When this option is enabled, the prompt gets totally screwed in zsh
because all the codes start with % in zsh (like they are \ in bas). So
we need to escape the % character.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/completion/git-prompt.sh | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index 756a951..4bedbcc 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -340,7 +340,11 @@ __git_ps1 ()
[ $(git config --bool bash.showUntrackedFiles) !=
false ]
[ -n $(git ls-files --others --exclude-standard) ]
then
- u=%
+ if [ -n ${ZSH_VERSION-} ]; then
+ u=%%
+ else
+ u=%
+ fi
fi
if [ -n ${GIT_PS1_SHOWUPSTREAM-} ]; then
--
1.8.2.1.790.g4588561
--
To unsubscribe from this list: send the line 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
Junio C Hamano wrote: A revision range is a slice of history, so you don't need any further adjective. Please don't introduce new words that do not add any accuracies nor value. I was just saying: I don't want to introduce new terms either. I think revisions.txt needs to be fixed. Under the Specifying Ranges section: 'rev':: Include commits that are reachable from (i.e. ancestors of) rev. This doesn't make sense because rev might as well refer to a blob*. So this should say s/rev/rev that names a commit object/. * The first line in the Specifying Revisions section: A revision parameter 'rev' typically, but not necessarily, names a commit object. -- To unsubscribe from this list: send the line 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
Jonathan Nieder wrote:
Am I wrong
in thinking revision is nothing more than a synonym for commit?
Yes. If master@{3}~2:README isn't a revision, what is it? And it
fits into the Specifying Revisions section quite snugly: I see no
reason to mangle the meaning of revision.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC] glossary: a revision is just a commit
The current definition of 'revision' sounds like it is saying that a revision is a tree object. In reality it is just a commit. This should be especially useful for people used to other revision control systems trying to see how familiar concepts translate into git terms. Reported-by: Ramkumar Ramachandra artag...@gmail.com Signed-off-by: Jonathan Nieder jrnie...@gmail.com --- Junio C Hamano wrote: On Apr 21, 2013 12:41 AM, Jonathan Nieder jrnie...@gmail.com wrote: revision:: A particular state of files and directories which was stored in the object database. It is referenced by a commit object. So a revision is a tree? [...] That's a historical misnomer. Some places in the documentation use revision as if the word were interchangeable with object name, and HEAD:path listed in specifying revision section is a prime example of it. What the section lists is historically called extended SHA-1 expression, essentially what get_sha1() can grok down to a single object name (as opposed to a slice of history, which is a revision range). Thanks. Documentation/glossary-content.txt | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/Documentation/glossary-content.txt b/Documentation/glossary-content.txt index eb7ba84f..521fceeb 100644 --- a/Documentation/glossary-content.txt +++ b/Documentation/glossary-content.txt @@ -430,9 +430,7 @@ should not be combined with other pathspec. def_merge,merge left behind. [[def_revision]]revision:: - A particular state of files and directories which was stored in the - def_object_database,object database. It is referenced by a - def_commit_object,commit object. + Synonym for def_commit,commit (the noun). [[def_rewind]]rewind:: To throw away part of the development, i.e. to assign the -- 1.8.2.1 -- To unsubscribe from this list: send the line 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 wrote:
Yes. If master@{3}~2:README isn't a revision, what is it?
An extended SHA1 expression referring to a blob.
--
To unsubscribe from this list: send the line 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] prompt: fix tracked files for zsh
Felipe Contreras felipe.contre...@gmail.com writes:
+ if [ -n ${ZSH_VERSION-} ]; then
+ u=%%
+ else
+ u=%
+ fi
aka u=%${ZSH_VERSION:+%}
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
And now for something completely different.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5] git-log.txt: rewrite note on why -- may be required
Ramkumar Ramachandra wrote: 'rev':: Include commits that are reachable from (i.e. ancestors of) rev. This doesn't make sense because rev might as well refer to a blob*. So this should say s/rev/rev that names a commit object/. In other words, my fix is to change the meaning of revision range to not literally mean range of revisions, but rather range of (revisions that are commits). I think it is more sensible than Jonathan's fix which breaks too many existing things; most significantly, the names rev-parse/rev-list. -- To unsubscribe from this list: send the line 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
Jonathan Nieder jrnie...@gmail.com writes: Ramkumar Ramachandra wrote: I would say the most technically accurate description of what 'git log' takes is a committish range (basically a revision range that resolves to commits). What is a revision range that doesn't resolve to commits? Am I wrong in thinking revision is nothing more than a synonym for commit? When gitrevisions(7) says A revision parameter rev typically, but not necessarily, names a commit object, I suspect it is residue from 3a45f625 trying to apologize for the extended SHA1 syntax parser being called git rev-parse instead of git object-name-parse. - A revision range is a slice of history. There is no need for committish revision range as there is no other kinds of ranges. - A revision should be a synonym to a committish, as glossary defines. We historically used revision more or less interchangeably with object name, especially an extended SHA-1 expression that is used as an object name, to mean whatever get_sha1() can grok down to a single object name. This must be rectified to avoid causing confusion to new readers of our documentation. - Documentation/revisions.txt needs to be cleaned up. It lists specifying revisions and specifying ranges, which is a good start primarily because some notations used in ranges are not revisions (e.g. ^C), but it should have three (not two) sections. They are: specifying revisions, specifying object names, and specifying ranges. Move non committish specification such as revision:path from the current specifying revisions section and make the new object names section. The ranges section is already written in terms of revisions, and does not need any update, once we clarify the definition of a revision as committish. -- To unsubscribe from this list: send the line 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] prompt: fix tracked files for zsh
On Sun, Apr 21, 2013 at 4:11 AM, Felipe Contreras felipe.contre...@gmail.com wrote: When this option is enabled, the prompt gets totally screwed in zsh because all the codes start with % in zsh (like they are \ in bas). So s/bas/bash/ we need to escape the % character. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] prompt: fix tracked files for zsh
Felipe Contreras felipe.contre...@gmail.com writes:
When this option is enabled, the prompt gets totally screwed in zsh
because all the codes start with % in zsh (like they are \ in bas). So
we need to escape the % character.
It is not that I do not believe that $u needs to duplicate %% in
ZSH, but I hate it when I do not understand the explanation. Could
you help me clarify what you meant by codes and like they are \ in bas?
Are you referring to things like \u (user) \h (host) as code and
bas was a simple typo of bash? In other words, is my reading
below:
... because '%' is used as an introducer of prompt
customization in zsh (just like bash prompt uses '\' to
introduce \u, \h, etc.), we need to give '%%' to get a
literal per-cent character.
match what you meant to say?
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/completion/git-prompt.sh | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/contrib/completion/git-prompt.sh
b/contrib/completion/git-prompt.sh
index 756a951..4bedbcc 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -340,7 +340,11 @@ __git_ps1 ()
[ $(git config --bool bash.showUntrackedFiles) !=
false ]
[ -n $(git ls-files --others --exclude-standard) ]
then
- u=%
+ if [ -n ${ZSH_VERSION-} ]; then
+ u=%%
+ else
+ u=%
+ fi
fi
if [ -n ${GIT_PS1_SHOWUPSTREAM-} ]; then
--
To unsubscribe from this list: send the line 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] prompt: fix tracked files for zsh
Felipe Contreras felipe.contre...@gmail.com writes:
When this option is enabled, the prompt gets totally screwed in zsh
because all the codes start with % in zsh (like they are \ in bas). So
we need to escape the % character.
It is not that I do not believe that $u needs to duplicate %% in
ZSH, but I hate it when I do not understand the explanation. Could
you help me clarify what you meant by codes and like they are \ in bas?
Are you referring to things like \u (user) \h (host) as code and
bas was a simple typo of bash? In other words, does my reading
below:
... because '%' is used as an introducer of prompt
customization in zsh (just like bash prompt uses '\' to
introduce \u, \h, etc.), we need to give '%%' to get a
literal per-cent character.
match what you meant to say?
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/completion/git-prompt.sh | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/contrib/completion/git-prompt.sh
b/contrib/completion/git-prompt.sh
index 756a951..4bedbcc 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -340,7 +340,11 @@ __git_ps1 ()
[ $(git config --bool bash.showUntrackedFiles) !=
false ]
[ -n $(git ls-files --others --exclude-standard) ]
then
- u=%
+ if [ -n ${ZSH_VERSION-} ]; then
+ u=%%
+ else
+ u=%
+ fi
fi
if [ -n ${GIT_PS1_SHOWUPSTREAM-} ]; then
--
To unsubscribe from this list: send the line 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] prompt: fix tracked files for zsh
Andreas Schwab sch...@linux-m68k.org writes:
Felipe Contreras felipe.contre...@gmail.com writes:
+if [ -n ${ZSH_VERSION-} ]; then
+u=%%
+else
+u=%
+fi
aka u=%${ZSH_VERSION:+%}
Do you need/want a colon there? Even if it is empty, as long as it
is defined we would want this, no?
Andreas.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/7] Documentation/shortlog improvements
In this round, I've incorporated suggestions made by Junio: [3/7] is entirely new. [4/7] and [5/7] together re-order and replace 'since..until' with 'revision range', in contrast to a single patch which attempted to fix 'since..until' in-place in the previous version. [6/7] uses the revision range instad of revisions. [7/7] copies the latest text from git-log.txt, and doesn't attempt to add rev-list-options.txt. There's a parallel discussion going on about fixing the meaning of revision, but this series is entirely unrelated to that. Ramkumar Ramachandra (7): git-shortlog.txt: remove (-h|--help) from OPTIONS builtin/shortlog.c: make usage string consistent with log revisions.txt: clarify the .. and ... syntax git-log.txt: order OPTIONS properly; move since..until git-log.txt: generalize since..until git-log.txt: rewrite note on why -- may be required git-shortlog.txt: make SYNOPSIS match log, update OPTIONS Documentation/git-log.txt | 22 -- Documentation/git-shortlog.txt | 25 +++-- Documentation/revisions.txt| 6 -- builtin/shortlog.c | 4 +--- 4 files changed, 36 insertions(+), 21 deletions(-) -- 1.8.2.1.501.gd2949c7 -- To unsubscribe from this list: send the line 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/7] git-shortlog.txt: remove (-h|--help) from OPTIONS
To be consistent with the documentation of all the other commands, remove (-h|--help) from the OPTIONS section. Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- Documentation/git-shortlog.txt | 4 1 file changed, 4 deletions(-) diff --git a/Documentation/git-shortlog.txt b/Documentation/git-shortlog.txt index c308e91..c7f7f51 100644 --- a/Documentation/git-shortlog.txt +++ b/Documentation/git-shortlog.txt @@ -26,10 +26,6 @@ reference to the current repository. OPTIONS --- --h:: ---help:: - Print a short usage message and exit. - -n:: --numbered:: Sort output according to the number of commits per author instead -- 1.8.2.1.501.gd2949c7 -- To unsubscribe from this list: send the line 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/7] git-log.txt: generalize since..until
'since..until' is misleading, as there are many other forms that 'git log' can accept as an argument. Replace it with revision range, referring to the section Specifying Ranges in revisions.txt, and rewrite the section appropriately. Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- Documentation/git-log.txt | 16 +--- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt index 64cc337..c238475 100644 --- a/Documentation/git-log.txt +++ b/Documentation/git-log.txt @@ -9,7 +9,7 @@ git-log - Show commit logs SYNOPSIS [verse] -'git log' [options] [since..until] [[\--] path...] +'git log' [options] [revision range] [[\--] path...] DESCRIPTION --- @@ -62,12 +62,14 @@ produced by --stat etc. Note that only message is considered, if also a diff is shown its size is not included. -since..until:: - Show only commits between the named two commits. When - either since or until is omitted, it defaults to - `HEAD`, i.e. the tip of the current branch. - For a more complete list of ways to spell since - and until, see linkgit:gitrevisions[7]. +revision range:: + Show only commits in the specified revision range. When no + revision range is specified, it defaults to 'HEAD' (ie. the + whole history leading to the current commit). master..HEAD + specifies all the commits reachable from 'HEAD', but not from + 'master'. For a complete list of ways to spell + revision range, see the Specifying Ranges section of + linkgit:gitrevisions[7]. [\--] path...:: Show only commits that are enough to explain how the files -- 1.8.2.1.501.gd2949c7 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/7] 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 revision range need not be a set of branch names or ref names. Rewrite it to use the word revision range, to be consistent with the SYNOPSIS. Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- Documentation/git-log.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt index c238475..7ae21ff 100644 --- a/Documentation/git-log.txt +++ b/Documentation/git-log.txt @@ -77,8 +77,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 the revision range, when confusion arises. include::rev-list-options.txt[] -- 1.8.2.1.501.gd2949c7 -- To unsubscribe from this list: send the line 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/7] revisions.txt: clarify the .. and ... syntax
In rev1..rev2 and rev1...rev2, if either rev1 or rev2 is
omitted, it defaults to 'HEAD'. Add this detail to the document.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
Documentation/revisions.txt | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt
index 8855b1a..0a23129 100644
--- a/Documentation/revisions.txt
+++ b/Documentation/revisions.txt
@@ -244,11 +244,13 @@ To summarize:
'rev1..rev2'::
Include commits that are reachable from rev2 but exclude
- those that are reachable from rev1.
+ those that are reachable from rev1. When either rev1 or
+ rev2 is omitted, it defaults to 'HEAD'.
'rev1\...rev2'::
Include commits that are reachable from either rev1 or
- rev2 but exclude those that are reachable from both.
+ rev2 but exclude those that are reachable from both. When
+ either rev1 or rev2 is omitted, it defaults to 'HEAD'.
'rev{caret}@', e.g. 'HEAD{caret}@'::
A suffix '{caret}' followed by an at sign is the same as listing
--
1.8.2.1.501.gd2949c7
--
To unsubscribe from this list: send the line 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 7/7] 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. Save adding the options from rev-list-options.txt for a later patch, as it requires some work to pick out the options that are relevant to shortlog. Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- Documentation/git-shortlog.txt | 21 +++-- 1 file changed, 19 insertions(+), 2 deletions(-) diff --git a/Documentation/git-shortlog.txt b/Documentation/git-shortlog.txt index c7f7f51..2a66518 100644 --- a/Documentation/git-shortlog.txt +++ b/Documentation/git-shortlog.txt @@ -8,8 +8,8 @@ git-shortlog - Summarize 'git log' output SYNOPSIS [verse] -git log --pretty=short | 'git shortlog' [-h] [-n] [-s] [-e] [-w] -'git shortlog' [-n|--numbered] [-s|--summary] [-e|--email] [-w[width[,indent1[,indent2 commit... +git log --pretty=short | 'git shortlog' [options] +'git shortlog' [options] [revision range] [[\--] path...] DESCRIPTION --- @@ -56,6 +56,23 @@ OPTIONS If width is `0` (zero) then indent the lines of the output without wrapping them. +revision range:: + Consider only commits in the specified revision range. When no + revision range is specified, it defaults to 'HEAD' (ie. the + whole history leading to the current commit). master..next + specifies all the commits reachable from 'next, but not from + 'master'. For a complete list of ways to spell + revision range, see the Specifying Ranges section of + linkgit:gitrevisions[7]. + +[\--] path...:: + Consider only commits that are enough to explain how the files + that match the specified paths came to be. See History + Simplification below for details and other simplification + modes. ++ +Paths may need to be prefixed with \-- to separate them from +options or the revision range, when confusion arises. MAPPING AUTHORS --- -- 1.8.2.1.501.gd2949c7 -- To unsubscribe from this list: send the line 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 21 April 2013 08:26, Junio C Hamano gits...@pobox.com wrote:
Simon Ruderich si...@ruderich.org writes:
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[]
It probably is a better change to drop Use `-c`... and refer to
the Diff formatting section.
And then add '-p' and the fact that by default it will not show
pairwise diff for merge commits to the Diff Formatting section.
That is where -c/--cc/-m are already described.
Why not have it in both places? This is really important.
I'm concerned that noone is taking this security risk seriously. Just
because it doesn't show up in certain workflows doesn't make the risk
go away.
What about all the people who use git internally? They aren't using
github and almost certainly aren't using a mail based system.
It's bad that we can't even set the right behaviour as a default.
John
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5] git-log.txt: rewrite note on why -- may be required
Junio C Hamano wrote:
- A revision range is a slice of history. There is no need for
committish revision range as there is no other kinds of ranges.
For the record, 'git rev-parse master:README..HEAD@{3}~2' works just
fine. I don't know whether you want to consider it sensible or not,
but the current revisions.txt is consistent with this.
- A revision should be a synonym to a committish, as glossary
defines. We historically used revision more or less
interchangeably with object name, especially an extended SHA-1
expression that is used as an object name, to mean whatever
get_sha1() can grok down to a single object name. This must be
rectified to avoid causing confusion to new readers of our
documentation.
The question is: who is the authority on this? The combination of
rev-parse, rev-list, and revisions.txt, or gitglossary.txt.
They are: specifying revisions, specifying object names, and
specifying ranges.
Personally, I don't like giving commit objects a special status, and
like things just the way they currently are. Why do you want to
separate revisions (which are really just extended SHA-1
expressions that incidentally resolve to commit objects) and
extended SHA-1 expressions that resolve to objects other than
commits? Is the current hand-wavy unclear gitglossary.txt the only
basis for your argument?
--
To unsubscribe from this list: send the line 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 wrote:
For the record, 'git rev-parse master:README..HEAD@{3}~2' works just
fine. I don't know whether you want to consider it sensible or not,
but the current revisions.txt is consistent with this.
rev-list errors out though:
error: Object 15bfea is a blob, not a commit
fatal: Invalid revision range master:README..HEAD@{3}~2
Hence my suggestion to change the meaning of what a valid revision
range is (using rev-list as the guideline) , and be done with it.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git log -p unexpected behaviour - security risk?
John Tapsell wrote: I'm concerned that noone is taking this security risk seriously. If anyone relies on git log -p or git log -p --cc output to make sure that the untrusted code they use doesn't introduce unwanted behavior, they are making a serious mistake. A merge can completely undo important changes made in a side branch and -c and --cc will not show it. The lack of -c cannot be a security issue here, because in normal life adding -c isn't a secure deployment strategy. That's why if you want to review the code you are pulling in as a whole, it is worthwhile to do git diff HEAD...FETCH_HEAD That is how you ask What code changes does FETCH_HEAD introduce? before putting your stamp of approval on them by merging and pushing out the result. Unfortunately that doesn't protect you from maliciously written commits that will be encountered when bisecting. At some point you have to be able to trust people. 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
[PATCH v3 0/1] git-multimail: a replacement for post-receive-email
This is the third iteration of submitting git-multimail to Git. The first pass [1] was a modest trial balloon, proposing to add a new script to live alongside post-receive-email. Following feedback [2] from the mailing list, I decided to make the script a full replacement for post-receive-email (and renamed it from post-receive-multimail.py to git-multimail). The second pass [3] was an RFC that generated a lot of useful feedback, some requests for better support of old features (mostly implemented), and some contributions by other members of the community (especially Matthieu Moy). The overall reaction to git-multimail as a replacement for post-receive-email has been quite positive. Now I believe that git-multimail is ripe for inclusion in contrib. Its features are documented in the README file and its advantages over post-receive-email are documented in the file README.migrate-from-post-receive-email. This series consists of a single patch that adds a directory contrib/hooks/git-multimail/ containing five files, described in the patch's commit message. It does *not* deprecate post-receive-email, let alone remove it, though I hope that both of those steps will be warranted in time. If there is consensus that git-multimail should be integrated into the Git project, there are some logistical issues that need to be discussed: * Code drop versus merge? * The first 170 commits to git-multimerge took place in a private repository, commingled with other material. All of these commits were by me. I don't have time to sanitize these commits into a publishable history, so I'm afraid that part of the history will never become public. * The subsequent 200 commits of the history have been published to GitHub [4]. (The version that I am submitting corresponds to the git-multimail subtree of revision c06a1af5d3a9dfbac7eb704dc8e15a2aee60a334 of that repository.) These commits are reasonably clean, though definitely not up to the usual Git project standards. The first of these commits consists of a code drop from the private repository just mentioned. The recent part of this history includes commits by other authors. Would it be preferable to merge the last 200 commits of the git-multimail history into the Git project (presumably via subtree merge), or just to incorporate it as a single, squashed patch? * What to include? The GitHub repo contains some infrastructure outside of the git-multimail directory, which is not included in this patch series: .gitignore, COPYING -- redundant with the Git project's top-level files. MANIFEST.in, setup.py -- infrastructure for Python's setuptools (to allow git-multimail to be packaged as a Python module, probably irrelevant in the context of the Git project. README -- a symlink to git-multimail/README. t/ -- some crude scripts and data that I have been using for testing. The tests are largely manual, so it is not clear whether they would be helpful within the Git project. notes.txt -- TODO list etc. * How to organize future development? Directly in the Git repo, using the git mailing list, etc? As a fork of the Git project that occasionally issues patches and/or pull requests to the main project? Or as a separate project that does not include the whole Git tree, which is occasionally merged back to the Git project using subtree merge? [1] http://article.gmane.org/gmane.comp.version-control.git/201433 [2] http://article.gmane.org/gmane.comp.version-control.git/201471 [3] http://article.gmane.org/gmane.comp.version-control.git/214686 [4] https://github.com/mhagger/git-multimail Michael Haggerty (1): git-multimail: a replacement for post-receive-email contrib/hooks/git-multimail/README | 410 .../README.migrate-from-post-receive-email | 146 ++ contrib/hooks/git-multimail/git_multimail.py | 2126 .../hooks/git-multimail/migrate-mailhook-config| 270 +++ contrib/hooks/git-multimail/post-receive | 66 + 5 files changed, 3018 insertions(+) create mode 100644 contrib/hooks/git-multimail/README create mode 100644 contrib/hooks/git-multimail/README.migrate-from-post-receive-email create mode 100755 contrib/hooks/git-multimail/git_multimail.py create mode 100755 contrib/hooks/git-multimail/migrate-mailhook-config create mode 100755 contrib/hooks/git-multimail/post-receive -- 1.8.2.1 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/1] git-multimail: a replacement for post-receive-email
Hi, Michael Haggerty wrote: This series consists of a single patch that adds a directory contrib/hooks/git-multimail/ containing five files, described in the patch's commit message. Yay! I look forward to seeing it. [...] The first of these commits consists of a code drop from the private repository just mentioned. The recent part of this history includes commits by other authors. That could be a reason to do a subtree merge if you want. A code drop with a commit message that acknowledges the contributors would also presumably be fine. [...] * How to organize future development? Directly in the Git repo, using the git mailing list, etc? As a fork of the Git project that occasionally issues patches and/or pull requests to the main project? Or as a separate project that does not include the whole Git tree, which is occasionally merged back to the Git project using subtree merge? My personal preference is that patches come on the git list, are reviewed here, and then go to your fork of the Git project that Junio can periodically pull from at your request (like git-svn). But of course this is up to you, too. Thanks, Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/1] git-multimail: a replacement for post-receive-email
Michael Haggerty wrote: Add git-multimail, a tool for generating notification emails for pushes to a Git repository. It is largely plug-in compatible with post-receive-email, and is proposed to eventually replace that script. The advantages of git-multimail relative to post-receive-email are described in README.migrate-from-post-receive-email. Very nice. For what it's worth, I'd be happy to see this in contrib/. It is good to see an actively maintained analog to post-receive-email, and the one-mail-per-commit functionality looks fun and useful. Jonathan [1] http://thread.gmane.org/gmane.comp.version-control.git/137426 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] Filenames with single colon being treated as remote repository
On Sat, Apr 20, 2013 at 11:05:39PM -0700, Jonathan Nieder wrote: 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? I think the rule could be something like: 1. If it looks like a URL (^scheme://), it is. 2. Otherwise, if it is a path in the filesystem, it is. 3. Otherwise, if it has a colon, it's host:path 4. Otherwise, barf. where the interesting bit is the ordering of 2 and 3. It seems like git clone follows the order above with get_repo_path. But we do not seem to follow it in git_connect, where we prefer 3 over 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://) I don't think that is enough. Something like /path/to/foo:bar would trigger !is_url already, but then git_connect fails. Try: $ git init --bare foo:bar $ git clone foo:bar ssh: Could not resolve hostname /home/peff/foo: Name or service not known fatal: Could not read from remote repository. ... Clone recognizes it as a path and turns it into an absolute path. It then feeds it to the transport code, which triggers !is_url and knows to use the git transport. But then git_connect prefers ssh over the filesystem. If you do a straight fetch, though, the transport code might see the relative path (if you use one): $ git init $ git init --bare sub:repo $ git fetch sub:repo ssh: Could not resolve hostname sub: Name or service not known but that still triggers the is_url above (which demands the ://). I am not sure whether your patch covers any cases I am missing, but I think you would need an analogous change to git_connect for these common cases. -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: Is there a way to speed up remote-hg?
On Sat, Apr 20, 2013 at 7:07 PM, Felipe Contreras felipe.contre...@gmail.com wrote: On Sat, Apr 20, 2013 at 6:07 AM, John Szakmeister j...@szakmeister.net wrote: I really like the idea of remote-hg, but it appears to be awfully slow on the clone step: The short answer is no. I do have a couple of patches that improve performance, but not by a huge factor. I have profiled the code, and there are two significant places where performance is wasted: 1) Fetching the file contents Extracting, decompressing, transferring, and then compressing and storing the file contents is mostly unavoidable, unless we already have the contents of such file, which in Git, it would be easy to check by analyzing the checksum (SHA-1). Unfortunately Mercurial doesn't have that information. The SHA-1 that is stored is not of the contents, but the contents and the parent checksum, which means that if you revert a modification you made to a file, or move a file, any operation that ends up in the same contents, but from a different path, the SHA-1 is different. This means the only way to know if the contents are the same, is by extracting, and calculating the SHA-1 yourself, which defeats the purpose of what you want the calculation for. I've tried, calculating the SHA-1 and use a previous reference to avoid the transfer, or do the transfer, and let Git check for existing objects doesn't make a difference. This is by Mercurial's stupid design, and there's nothing we, or anybody could do about it until they change it. That's a bummer. :-( 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. Eek! 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). [snip] That's unfortunate, but thank you for taking the time to explain! -John -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/5] Minor additions to git-completion.bash
Hi, I just looked at the config section, and started writing patches, and kept going until I got bored. So they're pretty random. Sorry about the triviality of the patches: I was just looking to kill some time on a lazy Sunday afternoon. Thanks. Ramkumar Ramachandra (5): git-completion.bash: lexical sorting for diff.statGraphWidth git-completion.bash: add diff.submodule to config list git-completion.bash: complete branch.*.rebase as boolean git-completion.bash: add branch.*.pushremote to config list git-completion.bash: add remote.pushdefault to config list contrib/completion/git-completion.bash | 20 +--- 1 file changed, 17 insertions(+), 3 deletions(-) -- 1.8.2.1.501.gd2949c7 -- To unsubscribe from this list: send the line 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] git-completion.bash: add diff.submodule to config list
c47ef57 (diff: introduce diff.submodule configuration variable, 2012-11-13) introduced the diff.submodule configuration variable, but forgot to teach git-completion.bash about it. Fix this. Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- contrib/completion/git-completion.bash | 5 + 1 file changed, 5 insertions(+) diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash index 6bfb9ad..f799dc8 100644 --- a/contrib/completion/git-completion.bash +++ b/contrib/completion/git-completion.bash @@ -1864,6 +1864,10 @@ _git_config () return ;; + diff.submodule) + __gitcomp log short + return + ;; help.format) __gitcomp man info web html return @@ -2065,6 +2069,7 @@ _git_config () diff.renameLimit diff.renames diff.statGraphWidth + diff.submodule diff.suppressBlankEmpty diff.tool diff.wordRegex -- 1.8.2.1.501.gd2949c7 -- To unsubscribe from this list: send the line 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-completion.bash: complete branch.*.rebase as boolean
6fac1b83 (completion: add missing config variables, 2009-06-29) added
rebase to the list of completions for branch.*.*, but forgot to
specify completions for the values that this configuration variable
can take (namely false and true). Fix this.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
contrib/completion/git-completion.bash | 4
1 file changed, 4 insertions(+)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index f799dc8..843273c 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1825,6 +1825,10 @@ _git_config ()
__gitcomp_nl $(__git_refs)
return
;;
+ branch.*.rebase)
+ __gitcomp false true
+ return
+ ;;
remote.*.fetch)
local remote=${prev#remote.}
remote=${remote%.fetch}
--
1.8.2.1.501.gd2949c7
--
To unsubscribe from this list: send the line 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-completion.bash: add remote.pushdefault to config list
224c2171 (remote.c: introduce remote.pushdefault, 2013-04-02)
introduced the remote.pushdefault configuration variable, but forgot
to teach git-completion.bash about it. Fix this.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
contrib/completion/git-completion.bash | 5 +
1 file changed, 5 insertions(+)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index fa0d604..d0cb4f1 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1829,6 +1829,10 @@ _git_config ()
__gitcomp false true
return
;;
+ remote.pushdefault)
+ __gitcomp_nl $(__git_remotes)
+ return
+ ;;
remote.*.fetch)
local remote=${prev#remote.}
remote=${remote%.fetch}
@@ -2208,6 +2212,7 @@ _git_config ()
receive.fsckObjects
receive.unpackLimit
receive.updateserverinfo
+ remote.pushdefault
remotes.
repack.usedeltabaseoffset
rerere.autoupdate
--
1.8.2.1.501.gd2949c7
--
To unsubscribe from this list: send the line 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 21 April 2013 11:21, Jonathan Nieder jrnie...@gmail.com wrote: John Tapsell wrote: I'm concerned that noone is taking this security risk seriously. If anyone relies on git log -p or git log -p --cc output to make sure that the untrusted code they use doesn't introduce unwanted behavior, they are making a serious mistake. Which is exactly my problem. Go and ask the average person using git this very question, and I bet you the vast majority will not know about -cc etc. You can't just push all the blame on the user for bad defaults. Hiding code changes is a bad default. A merge can completely undo important changes made in a side branch and -c and --cc will not show it. Wait, what? This is getting even worse then! Can you expand on this please? And then how do I show all of these important changes with a git log -p ? Or is it impossible to get a sane output? The lack of -c cannot be a security issue here, because in normal life adding -c isn't a secure deployment strategy. So, is it impossible to make git log -p a secure deployment strategy ? That's why if you want to review the code you are pulling in as a whole, it is worthwhile to do git diff HEAD...FETCH_HEAD Which basically means that you're asking the review the same code twice. Once that way, and once using git log -p (to check for the exact reason that you said). Unfortunately that doesn't protect you from maliciously written commits that will be encountered when bisecting. At some point you have to be able to trust people. Seriously? Your reasoning for awful defaults is that you should just trust people? This is getting worse and worse! John -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Teach git to change to a given directory using -C option
This is similar in spirit to to make -C dir ... and tar -C dir
Currently finding out the status of a git repository that is located
away from the current working directory without going to that directory
can be done in the following ways:
1. (cd ~/foo git status)
2. git --git-dir=~/foo/.git --work-dir=~/foo status
3. GIT_DIR=~/foo/.git GIT_WORK_TREE=~/foo git status
While doable the methods shown above are arguably more suitable for
scripting than quick command line invocations.
With this new option, the above can be done a bit more tersely:
$ git -C ~/foo status
A new test script is added to verify the behavior of this option with
other path-related options like --git-dir and --work-tree.
Signed-off-by: Nazri Ramliy ayieh...@gmail.com
---
Jeff: Thanks for pointing out the mistakes.
But I did not address your concern:
I know you are copying this from the other options in the same function,
but I wonder if they should all be calling error() (and dropping the
terminating .) to better match our usual error messages.
because I'd rather have that fix be done in a separate topic.
The other points raised are all valid and fixed in this new patch.
Documentation/git.txt | 13 +
git.c | 15 --
t/t0056-git-C.sh | 76 +++
3 files changed, 102 insertions(+), 2 deletions(-)
create mode 100755 t/t0056-git-C.sh
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 6a875f2..6064b3d 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -379,6 +379,19 @@ displayed. See linkgit:git-help[1] for more information,
because `git --help ...` is converted internally into `git
help ...`.
+-C directory::
+ Run as if git were started in directory instead of the current
+ working directory. If multiple -C options are given, subsequent
+ directory arguments are interpreted relative to the previous one: -C
+ /usr -C src is equivalent to -C /usr/src. This option affects options
+ that expect path name like --git-dir and --work-tree in that their
+ interpretations of the path names would be made relative to the
+ effective working directory caused by the -C option. For example the
+ following invocations are equivalent:
+
+ git --git-dir=a.git --work-tree=b -C c status
+ git --git-dir=c/a.git --work-tree=c/b status
+
-c name=value::
Pass a configuration parameter to the command. The value
given will override values from configuration files.
diff --git a/git.c b/git.c
index 1ada169..a8731e9 100644
--- a/git.c
+++ b/git.c
@@ -6,7 +6,7 @@
#include run-command.h
const char git_usage_string[] =
- git [--version] [--help] [-c name=value]\n
+ git [--version] [--help] [-C directory] [-c name=value]\n
[--exec-path[=path]] [--html-path] [--man-path]
[--info-path]\n
[-p|--paginate|--no-pager] [--no-replace-objects]
[--bare]\n
[--git-dir=path] [--work-tree=path]
[--namespace=name]\n
@@ -53,7 +53,18 @@ static int handle_options(const char ***argv, int *argc, int
*envchanged)
/*
* Check remaining flags.
*/
- if (!prefixcmp(cmd, --exec-path)) {
+ if (!strcmp(cmd, -C)) {
+ if (*argc 2) {
+ fprintf(stderr, No directory given for -C.\n
);
+ usage(git_usage_string);
+ }
+ if (chdir((*argv)[1]))
+ die_errno(Cannot change to '%s', (*argv)[1]);
+ if (envchanged)
+ *envchanged = 1;
+ (*argv)++;
+ (*argc)--;
+ } else if (!prefixcmp(cmd, --exec-path)) {
cmd += 11;
if (*cmd == '=')
git_set_argv_exec_path(cmd + 1);
diff --git a/t/t0056-git-C.sh b/t/t0056-git-C.sh
new file mode 100755
index 000..370eae6
--- /dev/null
+++ b/t/t0056-git-C.sh
@@ -0,0 +1,76 @@
+#!/bin/sh
+
+test_description='-C directory option and it effects on other path-related
options'
+
+. ./test-lib.sh
+
+test_expect_success 'git -C dir runs git from the directory dir' '
+ test_create_repo dir1
+ echo 1 dir1/a.txt
+ (cd dir1 git add a.txt git commit -m initial in dir1)
+ expected=initial in dir1
+ actual=$(git -C dir1 log --format=%s)
+ test $expected = $actual
+'
+
+test_expect_success 'Multiple -C options: -C dir1 -C dir2 is equivalent to
-C dir1/dir2' '
+ test_create_repo dir1/dir2
+ echo 1 dir1/dir2/a.txt
+ git -C dir1/dir2 add a.txt
+ expected=initial in dir1/dir2
+ git -C dir1/dir2 commit -m $expected
+ actual=$(git -C dir1 -C dir2 log --format=%s)
+ test $expected =
Re: [BUG] Filenames with single colon being treated as remote repository
Jeff King wrote:
I don't think that is enough. Something like /path/to/foo:bar would
trigger !is_url already, but then git_connect fails.
Doh. Here's another try, still untested.
diff --git i/connect.c w/connect.c
index 49e56ba3..fe13942f 100644
--- i/connect.c
+++ w/connect.c
@@ -504,6 +504,7 @@ struct child_process *git_connect(int fd[2], const char
*url_orig,
int c;
struct child_process *conn = no_fork;
enum protocol protocol = PROTO_LOCAL;
+ struct stat st;
int free_path = 0;
char *port = NULL;
const char **arg;
@@ -548,7 +549,8 @@ struct child_process *git_connect(int fd[2], const char
*url_orig,
end = host;
path = strchr(end, c);
- if (path !has_dos_drive_prefix(end)) {
+ if (path !has_dos_drive_prefix(end)
+ (c != ':' || stat(path, st))) {
if (c == ':') {
protocol = PROTO_SSH;
*path++ = '\0';
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] Filenames with single colon being treated as remote repository
Jeff King p...@peff.net writes: On Sat, Apr 20, 2013 at 11:05:39PM -0700, Jonathan Nieder wrote: 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? I think the rule could be something like: 1. If it looks like a URL (^scheme://), it is. 2. Otherwise, if it is a path in the filesystem, it is. 3. Otherwise, if it has a colon, it's host:path 4. Otherwise, barf. where the interesting bit is the ordering of 2 and 3. It seems like git clone follows the order above with get_repo_path. But we do not seem to follow it in git_connect, where we prefer 3 over 2. At least for a string whose host part does not have any slash, switching the rules 2 and 3 in git_connect() would be a regression, no? frotz:/srv/git/git.git has been the way to talk to host frotz for a long time, and if you want to talk to a local directory that is a subdirectory of frotz:/ directory you have in your $cwd, you can disambiguate by saying ./frotz:/srv/git/git.git or something. -- To unsubscribe from this list: send the line 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?
Jonathan Nieder jrnie...@gmail.com writes: That's why if you want to review the code you are pulling in as a whole, it is worthwhile to do git diff HEAD...FETCH_HEAD That is how you ask What code changes does FETCH_HEAD introduce? before putting your stamp of approval on them by merging and pushing out the result. And the only way to retroactively review that a merge C did not do anything funly is to check git diff C^1 C, assuming that you already trust C^1, the state before you performed the merge. Incidentally, this works for non-merge commits just as well. git log -m -p is not the default because most of the time people are not interested in seeing what it shows over --cc or -c. It is a repetition of what you would get from individual patches on the side branch merged that you will later see in the traversal of that command. --cc/-c gives a representation for tricky merge cases where people could likely have made a mistake, or had correctly resolved semantic conflicts (e.g. one side renames a function, the other side adds a callsite, the merge result renames the function new caller calls). For the purpose of a merge audit John seems to want, the only way is to wade through log -m -p output. -- To unsubscribe from this list: send the line 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?
Jonathan Nieder jrnie...@gmail.com writes: The thing is, I'm not convinced this is a bad default. Shows no diff at all for merges is easy for a person to understand. It is much easier to understand its limitations than -c and --cc. Making log -p -m a default before -c/--cc was introduced would have been the stupidest thing to do, as it would make the command mostly useless. Nobody would want to see repetitious output from a merge that he would eventually get when the traversal drills down to individual commits on the merged side branch. When I added -c/--cc, I contemplated making -p imply --cc, but decided against it primarily because it is a change in traditional behaviour, and it is easy for users to say --cc instead of -p from the command line. On the other hand, show was a newer command and it was easy to turn its default to --cc without having to worry too much about existing users. For that reason, it is a much *better* default for security than --cc or -c (even though I believe one of the latter would be a better default for convenience). Yes. I do not fundamentally oppose to the idea of log -p to imply log --cc when -m is not given (log -p -m is specifically declining the combined diff simplification). It may be a usability improvement. But --cc/-c does not have anything to do with Tapsell's security worries. The only real audit he can do is with log -m -p, possibly with --first-parent (only if he trusts his first-parent history). The recreate mechanical merge and compare recorded merge against it mode may highlight a malicious merger, but it will not show a cleanly merged hunk of malicious code in the merge, so it cannot be used with --first-parent when used as a security audit tool. Tapsell still needs to drill down to the merged side branch that introduced the malicious change that merged cleanly with -p. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/1] git-multimail: a replacement for post-receive-email
Jonathan Nieder jrnie...@gmail.com writes: My personal preference is that patches come on the git list, are reviewed here, and then go to your fork of the Git project that Junio can periodically pull from at your request (like git-svn). But of course this is up to you, too. And also me ;-) Yes, I very much prefer the way how git-svn is managed. -- To unsubscribe from this list: send the line 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 5/7] git-log.txt: generalize since..until
Ramkumar Ramachandra artag...@gmail.com writes:
'since..until' is misleading, as there are many other forms that
'git log' can accept as an argument. Replace it with revision range,
referring to the section Specifying Ranges in revisions.txt, and
rewrite the section appropriately.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
Documentation/git-log.txt | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt
index 64cc337..c238475 100644
--- a/Documentation/git-log.txt
+++ b/Documentation/git-log.txt
@@ -9,7 +9,7 @@ git-log - Show commit logs
SYNOPSIS
[verse]
-'git log' [options] [since..until] [[\--] path...]
+'git log' [options] [revision range] [[\--] path...]
DESCRIPTION
---
@@ -62,12 +62,14 @@ produced by --stat etc.
Note that only message is considered, if also a diff is shown
its size is not included.
-since..until::
- Show only commits between the named two commits. When
- either since or until is omitted, it defaults to
- `HEAD`, i.e. the tip of the current branch.
- For a more complete list of ways to spell since
- and until, see linkgit:gitrevisions[7].
+revision range::
+ Show only commits in the specified revision range. When no
+ revision range is specified, it defaults to 'HEAD' (ie. the
s/ie/i.e./; or s/ie/meaning /;
+ whole history leading to the current commit). master..HEAD
+ specifies all the commits reachable from 'HEAD', but not from
+ 'master'. For a complete list of ways to spell
+ revision range, see the Specifying Ranges section of
+ linkgit:gitrevisions[7].
If you want to have a single example (other than 'HEAD' which has to
be there anyway to describe the default), I think it would be more
helpful to use one that would be common for not-so-advanced users,
e.g. origin..HEAD, without many other prerequisites (e.g. @{u}..
may be common among more advanced users but is not appropriate here,
because the reader may not have learned @{upstream} or omission of a
side of a range defaulting to HEAD).
... `origin..HEAD` specifies all the commits reachable from
the current commit (i.e. `HEAD`) but not from `origin`.
I could squash these in locally without a reroll, but I haven't read
the remainder of the series yet, so we'll see.
[\--] path...::
Show only commits that are enough to explain how the files
--
To unsubscribe from this list: send the line 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] prompt: fix tracked files for zsh
Junio C Hamano gits...@pobox.com writes:
Andreas Schwab sch...@linux-m68k.org writes:
Felipe Contreras felipe.contre...@gmail.com writes:
+ if [ -n ${ZSH_VERSION-} ]; then
+ u=%%
+ else
+ u=%
+ fi
aka u=%${ZSH_VERSION:+%}
Do you need/want a colon there? Even if it is empty, as long as it
is defined we would want this, no?
The original wouldn't.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
And now for something completely different.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 7/7] git-shortlog.txt: make SYNOPSIS match log, update OPTIONS
Ramkumar Ramachandra artag...@gmail.com writes: diff --git a/Documentation/git-shortlog.txt b/Documentation/git-shortlog.txt index c7f7f51..2a66518 100644 --- a/Documentation/git-shortlog.txt +++ b/Documentation/git-shortlog.txt @@ -8,8 +8,8 @@ git-shortlog - Summarize 'git log' output SYNOPSIS [verse] -git log --pretty=short | 'git shortlog' [-h] [-n] [-s] [-e] [-w] -'git shortlog' [-n|--numbered] [-s|--summary] [-e|--email] [-w[width[,indent1[,indent2 commit... +git log --pretty=short | 'git shortlog' [options] +'git shortlog' [options] [revision range] [[\--] path...] You will need to update what you added in [PATCH 2/7] to builtin/shortlog.c to match this in this patch. DESCRIPTION --- @@ -56,6 +56,23 @@ OPTIONS If width is `0` (zero) then indent the lines of the output without wrapping them. +revision range:: + Consider only commits in the specified revision range. When no + revision range is specified, it defaults to 'HEAD' (ie. the + whole history leading to the current commit). master..next + specifies all the commits reachable from 'next, but not from + 'master'. For a complete list of ways to spell + revision range, see the Specifying Ranges section of + linkgit:gitrevisions[7]. Match the text you modified in 'log.txt' in [PATCH 5/7], perhaps? +[\--] path...:: + Consider only commits that are enough to explain how the files + that match the specified paths came to be. See History + Simplification below for details and other simplification + modes. Have you read the resulting git shortlog --help? Do we even have below? ++ +Paths may need to be prefixed with \-- to separate them from +options or the revision range, when confusion arises. MAPPING AUTHORS --- -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/1] git-multimail: a replacement for post-receive-email
On 04/21/2013 08:44 PM, Junio C Hamano wrote: Jonathan Nieder jrnie...@gmail.com writes: My personal preference is that patches come on the git list, are reviewed here, and then go to your fork of the Git project that Junio can periodically pull from at your request (like git-svn). But of course this is up to you, too. And also me ;-) Yes, I very much prefer the way how git-svn is managed. Let me see if I understand what that means: * I maintain my own Git clone * Patches to git-multimail would go to the Git mailing list like patches to other patches to the Git project, but I would be the one to git-am them, monitor discussion, help with review, etc. I would presumably apply the patches near your master (or near maint when necessary). * When I think a batch of patches is ready, I merge them to my master and publish my master somewhere. (Or is it better I publish the feature branch and leave it to you to merge directly to your master?) Then I send a merge request to you and the Git mailing list with the URL and SHA-1 of the branch that I would like you to merge. That seems very workable. What is your preference regarding the history to date? Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] prompt: fix tracked files for zsh
On Sun, Apr 21, 2013 at 2:02 PM, Andreas Schwab sch...@linux-m68k.org wrote:
Junio C Hamano gits...@pobox.com writes:
Andreas Schwab sch...@linux-m68k.org writes:
Felipe Contreras felipe.contre...@gmail.com writes:
+ if [ -n ${ZSH_VERSION-} ]; then
+ u=%%
+ else
+ u=%
+ fi
aka u=%${ZSH_VERSION:+%}
Do you need/want a colon there? Even if it is empty, as long as it
is defined we would want this, no?
The original wouldn't.
I thought you were trying to improve the original ;)
--
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
[PATCHv3 0/8] Improving the search for remote-tracking branches
Hi, This is third iteration of this series. The only difference from v2 is improved test code (in patches #1 and #2) thanks to Jonathan Nieder, and Eric Wong's ACK to patch #6. Have fun! :) ...Johan Johan Herland (8): t2024: Add tests verifying current DWIM behavior of 'git checkout branch' t2024: Show failure to use refspec when DWIMming remote branch names checkout: Use remote refspecs when DWIMming tracking branches t3200.39: tracking setup should fail if there is no matching refspec. t7201.24: Add refspec to keep --track working t9114.2: Don't use --track option against svn-remote-tracking branches branch.c: Validate tracking branches with refspecs instead of refs/remotes/* glossary: Update and rephrase the definition of a remote-tracking branch Documentation/git-checkout.txt | 6 +- Documentation/glossary-content.txt | 13 +-- branch.c | 17 +++- builtin/checkout.c | 42 +- t/t2024-checkout-dwim.sh | 167 + t/t3200-branch.sh | 8 +- t/t7201-co.sh | 1 + t/t9114-git-svn-dcommit-merge.sh | 2 +- 8 files changed, 221 insertions(+), 35 deletions(-) create mode 100755 t/t2024-checkout-dwim.sh -- 1.8.1.3.704.g33f7d4f From fcab754f6702ea2724258dacd40803943db1e172 Mon Sep 17 00:00:00 2001 From: Johan Herland jo...@herland.net Date: Sat, 20 Apr 2013 14:28:51 +0200 Subject: [PATCHv2 0/8] Improving the search for remote-tracking branches Hi, This is second iteration of this series. The initial three patches are unchanged, although the commit message of #3 has been rephrased based on Junio's comments. Patches #4-#6 fixes existing tests in preparation for patch #7, which changes the validation of the remote-tracking branch passed to --track: We now require the --track argument to refer to a ref that matches a configured refspec - otherwise, we can not reliably deduce the upstream information to store into branch.name.remote and branch.name.merge. Finally, patch #8 updates the paragraph on remote-tracking branches in the glossary to be somewhat closer to the current state of things. Have fun! :) ...Johan Johan Herland (8): t2024: Add tests verifying current DWIM behavior of 'git checkout branch' t2024: Show failure to use refspec when DWIMming remote branch names checkout: Use remote refspecs when DWIMming tracking branches t3200.39: tracking setup should fail if there is no matching refspec. t7201.24: Add refspec to keep --track working t9114.2: Don't use --track option against svn-remote-tracking branches branch.c: Validate tracking branches with refspecs instead of refs/remotes/* glossary: Update and rephrase the definition of a remote-tracking branch Documentation/git-checkout.txt | 6 +- Documentation/glossary-content.txt | 13 +++-- branch.c | 17 +- builtin/checkout.c | 42 +++--- t/t2024-checkout-dwim.sh | 116 + t/t3200-branch.sh | 8 +-- t/t7201-co.sh | 1 + t/t9114-git-svn-dcommit-merge.sh | 2 +- 8 files changed, 170 insertions(+), 35 deletions(-) create mode 100755 t/t2024-checkout-dwim.sh -- 1.8.1.3.704.g33f7d4f -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 1/8] t2024: Add tests verifying current DWIM behavior of 'git checkout branch'
The DWIM mode of checkout allows you to run git checkout foo when there is
no existing local ref or path called foo, and there is exactly one remote
with a remote-tracking branch called foo. Git will then automatically
create a new local branch called foo using the remote-tracking foo as
its starting point and configured upstream.
Improved-by: Jonathan Nieder jrnie...@gmail.com
Signed-off-by: Johan Herland jo...@herland.net
---
t/t2024-checkout-dwim.sh | 99
1 file changed, 99 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..1452bea
--- /dev/null
+++ b/t/t2024-checkout-dwim.sh
@@ -0,0 +1,99 @@
+#!/bin/sh
+
+test_description='checkout branch
+
+Ensures that checkout on an unborn branch does what the user expects'
+
+. ./test-lib.sh
+
+# 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_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' '
+ 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' '
+ 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 -B master
+ test_might_fail git branch -D bar
+
+ git checkout bar
+ test_branch bar
+ test_cmp_rev remotes/repo_a/bar HEAD
+ test_branch_upstream bar repo_a bar
+'
+
+test_expect_success 'checkout of branch from a single remote succeeds #2' '
+ git checkout -B master
+ test_might_fail git branch -D baz
+
+ git checkout baz
+ test_branch baz
+ test_cmp_rev remotes/other_b/baz HEAD
+ test_branch_upstream baz repo_b baz
+'
+
+test_expect_success '--no-guess suppresses branch auto-vivification' '
+ git checkout -B master
+ test_might_fail git branch -D bar
+
+ test_must_fail git checkout --no-guess bar
+ test_must_fail git rev-parse --verify refs/heads/bar
+ test_branch master
+'
+
+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
[PATCHv3 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.
Improved-by: Jonathan Nieder jrnie...@gmail.com
Signed-off-by: Johan Herland jo...@herland.net
---
t/t2024-checkout-dwim.sh | 70 +++-
1 file changed, 69 insertions(+), 1 deletion(-)
diff --git a/t/t2024-checkout-dwim.sh b/t/t2024-checkout-dwim.sh
index 1452bea..b1e3444 100755
--- a/t/t2024-checkout-dwim.sh
+++ b/t/t2024-checkout-dwim.sh
@@ -24,6 +24,7 @@ test_branch_upstream () {
}
test_expect_success 'setup' '
+ test_commit my_master
git init repo_a
(
cd repo_a
@@ -58,7 +59,7 @@ test_expect_success 'checkout of non-existing branch fails' '
test_branch master
'
-test_expect_success 'checkout of branch from multiple remotes fails' '
+test_expect_success 'checkout of branch from multiple remotes fails #1' '
git checkout -B master
test_might_fail git branch -D foo
@@ -96,4 +97,71 @@ test_expect_success '--no-guess suppresses branch
auto-vivification' '
test_branch master
'
+test_expect_success 'setup more remotes with unconventional refspecs' '
+ git checkout -B 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 remote add repo_d repo_d
+ git config remote.repo_d.fetch \
+ +refs/heads/*:refs/repo_d/*
+ git fetch --all
+'
+
+test_expect_failure 'checkout of branch from multiple remotes fails #2' '
+ git checkout -B master
+ test_might_fail git branch -D bar
+
+ test_must_fail git checkout bar
+ test_must_fail git rev-parse --verify refs/heads/bar
+ test_branch master
+'
+
+test_expect_failure 'checkout of branch from multiple remotes fails #3' '
+ git checkout -B master
+ test_might_fail git branch -D baz
+
+ test_must_fail git checkout baz
+ test_must_fail git rev-parse --verify refs/heads/baz
+ test_branch master
+'
+
+test_expect_failure 'checkout of branch from a single remote succeeds #3' '
+ git checkout -B master
+ test_might_fail git branch -D spam
+
+ git checkout spam
+ test_branch spam
+ test_cmp_rev refs/remotes/extra_dir/repo_c/extra_dir/spam HEAD
+ test_branch_upstream spam repo_c spam
+'
+
+test_expect_failure 'checkout of branch from a single remote succeeds #4' '
+ git checkout -B master
+ test_might_fail git branch -D eggs
+
+ git checkout eggs
+ test_branch eggs
+ test_cmp_rev refs/repo_d/eggs HEAD
+ test_branch_upstream eggs 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
[PATCHv3 3/8] checkout: Use remote refspecs when DWIMming tracking branches
The DWIM mode of checkout allows you to run git checkout foo when there
is no existing local ref or path called foo, and there is exactly _one_
remote with a remote-tracking branch called foo. Git will automatically
create a new local branch called foo using the remote-tracking foo as
its starting point and configured upstream.
For example, consider the following unconventional (but perfectly valid)
remote setup:
[remote origin]
fetch = refs/heads/*:refs/remotes/origin/*
[remote frotz]
fetch = refs/heads/*:refs/remotes/frotz/nitfol/*
Case 1: Assume both origin and frotz have remote-tracking branches called
foo, at refs/remotes/origin/foo and refs/remotes/frotz/nitfol/foo
respectively. In this case git checkout foo should fail, because there is
more than one remote with a foo branch.
Case 2: Assume only frotz have a remote-tracking branch called foo. In
this case git checkout foo should succeed, and create a local branch foo
from refs/remotes/frotz/nitfol/foo, using remote branch foo from frotz
as its upstream.
The current code hardcodes the assumption that all remote-tracking branches
must match the refs/remotes/$remote/* pattern (which is true for remotes
with conventional refspecs, but not true for the frotz remote above).
When running git checkout foo, the current code looks for exactly one ref
matching refs/remotes/*/foo, hence in the above example, it fails to find
refs/remotes/frotz/nitfol/foo, which causes it to fail both case #1 and #2.
The better way to handle the above example is to actually study the fetch
refspecs to deduce the candidate remote-tracking branches for foo; i.e.
assume foo is a remote branch being fetched, and then map refs/heads/foo
through the refspecs in order to get the corresponding remote-tracking
branches refs/remotes/origin/foo and refs/remotes/frotz/nitfol/foo.
Finally we check which of these happens to exist in the local repo, and
if there is exactly one, we have an unambiguous match for git checkout foo,
and may proceed.
This fixes most of the failing tests introduced in the previous patch.
Signed-off-by: Johan Herland jo...@herland.net
---
Documentation/git-checkout.txt | 6 +++---
builtin/checkout.c | 42 ++
t/t2024-checkout-dwim.sh | 6 +++---
3 files changed, 28 insertions(+), 26 deletions(-)
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index 8edcdca..bf0c99c 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -131,9 +131,9 @@ entries; instead, unmerged entries are ignored.
--track in linkgit:git-branch[1] for details.
+
If no '-b' option is given, the name of the new branch will be
-derived from the remote-tracking branch. If remotes/ or refs/remotes/
-is prefixed it is stripped away, and then the part up to the
-next slash (which would be the nickname of the remote) is removed.
+derived from the remote-tracking branch, by looking at the local part of
+the refspec configured for the corresponding remote, and then stripping
+the initial part up to the *.
This would tell us to use hack as the local branch when branching
off of origin/hack (or remotes/origin/hack, or even
refs/remotes/origin/hack). If the given name has no slash, or the above
diff --git a/builtin/checkout.c b/builtin/checkout.c
index eb51872..bcb18c8 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -822,38 +822,40 @@ static int git_checkout_config(const char *var, const
char *value, void *cb)
}
struct tracking_name_data {
- const char *name;
- char *remote;
+ /* const */ char *src_ref;
+ char *dst_ref;
+ unsigned char *dst_sha1;
int unique;
};
-static int check_tracking_name(const char *refname, const unsigned char *sha1,
- int flags, void *cb_data)
+static int check_tracking_name(struct remote *remote, void *cb_data)
{
struct tracking_name_data *cb = cb_data;
- const char *slash;
-
- if (prefixcmp(refname, refs/remotes/))
- return 0;
- slash = strchr(refname + 13, '/');
- if (!slash || strcmp(slash + 1, cb-name))
+ struct refspec query;
+ memset(query, 0, sizeof(struct refspec));
+ query.src = cb-src_ref;
+ if (remote_find_tracking(remote, query) ||
+ get_sha1(query.dst, cb-dst_sha1))
return 0;
- if (cb-remote) {
+ if (cb-dst_ref) {
cb-unique = 0;
return 0;
}
- cb-remote = xstrdup(refname);
+ cb-dst_ref = xstrdup(query.dst);
return 0;
}
-static const char *unique_tracking_name(const char *name)
+static const char *unique_tracking_name(const char *name, unsigned char *sha1)
{
- struct tracking_name_data cb_data = { NULL, NULL, 1 };
- cb_data.name = name;
- for_each_ref(check_tracking_name, cb_data);
+ struct tracking_name_data
[PATCHv3 4/8] t3200.39: tracking setup should fail if there is no matching refspec.
We are formalizing a requirement that any remote-tracking branch to be used as an upstream (i.e. as an argument to --track), _must_ belong to a configured remote by being matched by the dst side of a fetch refspec. This patch encodes the new expected behavior of this test, and marks the test with test_expect_failure in anticipation of a following patch to introduce the new behavior. Signed-off-by: Johan Herland jo...@herland.net --- t/t3200-branch.sh | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh index d969f0e..1bfdadc 100755 --- a/t/t3200-branch.sh +++ b/t/t3200-branch.sh @@ -317,13 +317,13 @@ test_expect_success 'test tracking setup (non-wildcard, matching)' ' test $(git config branch.my4.merge) = refs/heads/master ' -test_expect_success 'test tracking setup (non-wildcard, not matching)' ' +test_expect_failure 'tracking setup fails on non-matching refspec' ' git config remote.local.url . git config remote.local.fetch refs/heads/s:refs/remotes/local/s (git show-ref -q refs/remotes/local/master || git fetch local) - git branch --track my5 local/master - ! test $(git config branch.my5.remote) = local - ! test $(git config branch.my5.merge) = refs/heads/master + test_must_fail git branch --track my5 local/master + test_must_fail git config branch.my5.remote + test_must_fail git config branch.my5.merge ' test_expect_success 'test tracking setup via config' ' -- 1.8.1.3.704.g33f7d4f -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 5/8] t7201.24: Add refspec to keep --track working
We are formalizing a requirement that any remote-tracking branch to be used as an upstream (i.e. as an argument to --track), _must_ belong to a configured remote by being matched by the dst side of a fetch refspec. Without this patch, this test would start failing when the new behavior is introduced. Signed-off-by: Johan Herland jo...@herland.net --- t/t7201-co.sh | 1 + 1 file changed, 1 insertion(+) diff --git a/t/t7201-co.sh b/t/t7201-co.sh index be9672e..0c9ec0a 100755 --- a/t/t7201-co.sh +++ b/t/t7201-co.sh @@ -431,6 +431,7 @@ test_expect_success 'detach a symbolic link HEAD' ' test_expect_success \ 'checkout with --track fakes a sensible -b name' ' +git config remote.origin.fetch +refs/heads/*:refs/remotes/origin/* git update-ref refs/remotes/origin/koala/bear renamer git checkout --track origin/koala/bear -- 1.8.1.3.704.g33f7d4f -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 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. Acked-by: Eric Wong normalper...@yhbt.net Signed-off-by: Johan Herland jo...@herland.net --- t/t9114-git-svn-dcommit-merge.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/t/t9114-git-svn-dcommit-merge.sh b/t/t9114-git-svn-dcommit-merge.sh index 3077851..f524d2f 100755 --- a/t/t9114-git-svn-dcommit-merge.sh +++ b/t/t9114-git-svn-dcommit-merge.sh @@ -48,7 +48,7 @@ test_expect_success 'setup svn repository' ' test_expect_success 'setup git mirror and merge' ' git svn init $svnrepo -t tags -T trunk -b branches git svn fetch - git checkout --track -b svn remotes/trunk + git checkout -b svn remotes/trunk git checkout -b merge echo new file new_file git add new_file -- 1.8.1.3.704.g33f7d4f -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 7/8] branch.c: Validate tracking branches with refspecs instead of refs/remotes/*
The current code for validating tracking branches (e.g. the argument to
the -t/--track option) hardcodes refs/heads/* and refs/remotes/* as the
potential locations for tracking branches. This works with the refspecs
created by git clone or git remote add, but is suboptimal in other
cases:
- If refs/remotes/foo/bar exists without any association to a remote
(i.e. there is no remote named foo, or no remote with a refspec
that matches refs/remotes/foo/bar), then it is impossible to set up
a valid upstream config that tracks it. Currently, the code defaults
to using refs/remotes/foo/bar from repo . as the upstream, which
works, but is probably not what the user had in mind when running
git branch baz --track foo/bar.
- If the user has tweaked the fetch refspec for a remote to put its
remote-tracking branches outside of refs/remotes/*, e.g. by running
git config remote.foo.fetch +refs/heads/*:refs/foo_stuff/*
then the current code will refuse to use its remote-tracking branches
as --track arguments, since they do not match refs/remotes/*.
This patch removes the refs/remotes/* requirement for upstream branches,
and replaces it with explicit checking of the refspecs for each remote to
determine whether a given --track argument is a valid remote-tracking
branch. This solves both of the above problems, since the matching refspec
guarantees that there is a both a remote name and a remote branch name
that can be used for the upstream config.
However, this means that refs located within refs/remotes/* without a
corresponding remote/refspec will no longer be usable as upstreams.
The few existing tests which depended on this behavioral quirk has
already been fixed in the preceding patches.
This patch fixes the last remaining test failure in t2024-checkout-dwim.
Signed-off-by: Johan Herland jo...@herland.net
---
branch.c | 17 -
t/t2024-checkout-dwim.sh | 2 +-
t/t3200-branch.sh| 2 +-
3 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/branch.c b/branch.c
index 6ae6a4c..beaf11d 100644
--- a/branch.c
+++ b/branch.c
@@ -197,6 +197,21 @@ int validate_new_branchname(const char *name, struct
strbuf *ref,
return 1;
}
+static int check_tracking_branch(struct remote *remote, void *cb_data)
+{
+ char *tracking_branch = cb_data;
+ struct refspec query;
+ memset(query, 0, sizeof(struct refspec));
+ query.dst = tracking_branch;
+ return !(remote_find_tracking(remote, query) ||
+prefixcmp(query.src, refs/heads/));
+}
+
+static int validate_remote_tracking_branch(char *ref)
+{
+ return !for_each_remote(check_tracking_branch, ref);
+}
+
static const char upstream_not_branch[] =
N_(Cannot setup tracking information; starting point '%s' is not a branch.);
static const char upstream_missing[] =
@@ -259,7 +274,7 @@ void create_branch(const char *head,
case 1:
/* Unique completion -- good, only if it is a real branch */
if (prefixcmp(real_ref, refs/heads/)
- prefixcmp(real_ref, refs/remotes/)) {
+ validate_remote_tracking_branch(real_ref)) {
if (explicit_tracking)
die(_(upstream_not_branch), start_name);
else
diff --git a/t/t2024-checkout-dwim.sh b/t/t2024-checkout-dwim.sh
index 31e3d47..dee55e4 100755
--- a/t/t2024-checkout-dwim.sh
+++ b/t/t2024-checkout-dwim.sh
@@ -154,7 +154,7 @@ test_expect_success 'checkout of branch from a single
remote succeeds #3' '
test_branch_upstream spam repo_c 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 -B master
test_might_fail git branch -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
[PATCHv3 8/8] glossary: Update and rephrase the definition of a remote-tracking branch
The definition of a remote-tracking branch in the glossary have been out-of-date for a while (by e.g. referring to Pull: from old-style $GIT_DIR/remotes files). Also, the preceding patches have formalized that a remote-tracking branch must match a configured refspec in order to be usable as an upstream. This patch rewrites the paragraph on remote-tracking branches accordingly. Signed-off-by: Johan Herland jo...@herland.net --- Documentation/glossary-content.txt | 13 +++-- 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/Documentation/glossary-content.txt b/Documentation/glossary-content.txt index 2478a39..7a79f26 100644 --- a/Documentation/glossary-content.txt +++ b/Documentation/glossary-content.txt @@ -423,12 +423,13 @@ should not be combined with other pathspec. linkgit:git-push[1]. [[def_remote_tracking_branch]]remote-tracking branch:: - A regular Git def_branch,branch that is used to follow changes from - another def_repository,repository. A remote-tracking - branch should not contain direct modifications or have local commits - made to it. A remote-tracking branch can usually be - identified as the right-hand-side def_ref,ref in a Pull: - def_refspec,refspec. + A def_ref,ref that is used to follow changes from another + def_repository,repository. It typically looks like + 'refs/remotes/foo/bar' (indicating that it tracks a branch named + 'bar' in a remote named 'foo'), and matches the right-hand-side of + a configured fetch def_refspec,refspec. A remote-tracking + branch should not contain direct modifications or have local + commits made to it. [[def_repository]]repository:: A collection of def_ref,refs together with an -- 1.8.1.3.704.g33f7d4f -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] prompt: fix tracked files for zsh
Felipe Contreras felipe.contre...@gmail.com writes:
On Sun, Apr 21, 2013 at 2:02 PM, Andreas Schwab sch...@linux-m68k.org wrote:
Junio C Hamano gits...@pobox.com writes:
Andreas Schwab sch...@linux-m68k.org writes:
Felipe Contreras felipe.contre...@gmail.com writes:
+ if [ -n ${ZSH_VERSION-} ]; then
+ u=%%
+ else
+ u=%
+ fi
aka u=%${ZSH_VERSION:+%}
Do you need/want a colon there? Even if it is empty, as long as it
is defined we would want this, no?
The original wouldn't.
I thought you were trying to improve the original ;)
OK, so I _think_ everybody is in agreement that the patch should
look like this. OK?
-- 8 --
From: Felipe Contreras felipe.contre...@gmail.com
Subject: [PATCH] prompt: fix untracked files for zsh
With bash.showUntrackedFiles option, presense of untracked files
is signalled by adding a per-cent sign '%' to the prompt. But
because '%' is used as an escape character to introduce prompt
customization in zsh (just like bash prompt uses '\' to escape \u,
\h, etc.), we need to say '%%' to get a literal per-cent.
Helped-by: Andreas Schwab sch...@linux-m68k.org
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/completion/git-prompt.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index 756a951..054c52e 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -340,7 +340,7 @@ __git_ps1 ()
[ $(git config --bool bash.showUntrackedFiles) !=
false ]
[ -n $(git ls-files --others --exclude-standard) ]
then
- u=%
+ u=%${ZSH_VERSION+%}
fi
if [ -n ${GIT_PS1_SHOWUPSTREAM-} ]; then
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/1] git-multimail: a replacement for post-receive-email
Michael Haggerty mhag...@alum.mit.edu writes: That seems very workable. That is pretty much it. What is your preference regarding the history to date? The only thing I deeply care about is that initial and subsequent git pull I'll do from you [*1*] will pull in commits that touch only the multimail part in the contrib/ area and not mixed with unrelated changes to other areas. If the history you have so far would later help others learn the motivation, design, constraints etc. while developing it, which cannot be easily read from the resulting code, i.e. help maintaining it in general, it's a good idea to keep it. In such a case, however, people may want to review that history as well. If it is the oops, it didn't work, let's try another kind of record as we build type of history that may not help the future maintainace that much, you may instead want to start with a single code-dump here is the first public version (which is reviewed in this thread, I think) without the history behind it. Your choice, in other words ;-) [Footnote] *1* This does not even have to be a stable URL I would place in remote.multimail.url configuration; it does not even have to be a non-rewinding tree. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/1] git-multimail: a replacement for post-receive-email
Michael Haggerty mhag...@alum.mit.edu writes: * When I think a batch of patches is ready, I merge them to my master and publish my master somewhere. (Or is it better I publish the feature branch and leave it to you to merge directly to your master?) I think I missed this part, but in the case of git-svn, what we do is the former. The branch Eric makes me pull may be called 'master' in his repository, but it does not contain anything unrelated to git-svn, so from _my_ viewpoint, it is a single topic to improve git-svn. But from Eric's point of view, it is an aggregation of different topics from many people on top of my tree, and each topic may tackle its own theme. I think most of the pulls from him so far were single strand of pearls without merges, but if two or more long topics were cooking in his tree, it would have been perfectly reasonable for him to resolve such inter-topic conflicts before telling me to pull the result. After all, that is what the sub-maintainer of an area is. One who knows the area the best coordinates possibly conflicting changes brought in different topics to the area. Ths same can go for multimail, or any contrib/ material for that matter. -- To unsubscribe from this list: send the line 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] prompt: fix tracked files for zsh
On Sun, Apr 21, 2013 at 5:00 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
On Sun, Apr 21, 2013 at 2:02 PM, Andreas Schwab sch...@linux-m68k.org
wrote:
Junio C Hamano gits...@pobox.com writes:
Andreas Schwab sch...@linux-m68k.org writes:
Felipe Contreras felipe.contre...@gmail.com writes:
+ if [ -n ${ZSH_VERSION-} ]; then
+ u=%%
+ else
+ u=%
+ fi
aka u=%${ZSH_VERSION:+%}
Do you need/want a colon there? Even if it is empty, as long as it
is defined we would want this, no?
The original wouldn't.
I thought you were trying to improve the original ;)
OK, so I _think_ everybody is in agreement that the patch should
look like this. OK?
-- 8 --
From: Felipe Contreras felipe.contre...@gmail.com
Subject: [PATCH] prompt: fix untracked files for zsh
With bash.showUntrackedFiles option,
Not exactly correct, it can also be GIT_PS1_SHOWUNTRACKEDFILES.
presense of untracked files
is signalled by adding a per-cent sign '%' to the prompt. But
because '%' is used as an escape character to introduce prompt
customization in zsh (just like bash prompt uses '\' to escape \u,
\h, etc.), we need to say '%%' to get a literal per-cent.
Otherwise it's fine.
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: jc/add-2.0-delete-default (Re: What's cooking in git.git (Apr 2013, #05; Mon, 15))
Jonathan Nieder jrnie...@gmail.com writes: How about something like this? warning: git add run on path with files removed (e.g., '%s') hint: use git add --ignore-removals pathspec to ignore removals hint: or git add --no-ignore-removals pathspec to notice them hint: --ignore-removals is the default but this will change soon hint: see git-add(1) for details Then the --ignore-removals option could be added using a patch like the following. adding ignore-removals as a synonym (and keeping it) would be a good idea. We would still need to carry --all and --no-all that have been with us ever since we added -A option, though. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5] git-log.txt: rewrite note on why -- may be required
Junio C Hamano gits...@pobox.com writes: Two other things I noticed with the current text are: ... * The part with the new -L option seems to be throwing the overall formatting off. Its second paragraph start and end 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 [--] pathspec... are indented one level too deeply. This is a minimalistic patch to fix the formatting. I removed the extra sentence after the enumeration and moved it to the end of the main text, but somebody may have a better idea to persuade AsciiDoc to format it in a more reasonable way while keeping the sentence there. -- 8 -- Subject: line-log: fix documentation formatting The second paragraph of the added description for the -L option start and end can take one of these forms:, and the list of forms that follow the headline, were indented one level too short, due to the missing + to signal that the next paragraph continues the previous one. Also You can specify this option more than once is about the -L option, not about its various forms of starting and ending points. Move it to the end of the main text. Signed-off-by: Junio C Hamano gits...@pobox.com --- Documentation/git-log.txt | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt index 4850226..0959f9d 100644 --- a/Documentation/git-log.txt +++ b/Documentation/git-log.txt @@ -76,12 +76,11 @@ produced by --stat etc. not give any pathspec limiters. This is currently limited to a walk starting from a single revision, i.e., you may only give zero or one positive revision arguments. - + You can specify this option more than once. ++ start and end can take one of these forms: include::line-range-format.txt[] -You can specify this option more than once. - --full-line-diff:: Always print the interesting range even if the current commit -- To unsubscribe from this list: send the line 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: jc/add-2.0-delete-default (Re: What's cooking in git.git (Apr 2013, #05; Mon, 15))
Junio C Hamano gits...@pobox.com writes:
Then the --ignore-removals option could be added using a patch like
the following.
adding ignore-removals as a synonym (and keeping it) would be a good
idea.
We would still need to carry --all and --no-all that have been with
us ever since we added -A option, though.
The final step to turn -A the default will be held back until Git 2.0 release,
but I've inserted the following patch before that step.
I am thinking that it would be a good idea to merge up to this step
to 'master' tomorrow, and have you guys tweak it further on 'master'
with a patch like the one I am responding to, before the 1.8.3
final. We will have to tweak the 2.0 endgame version as we go but
that is outside 'next' for now, so it should be manageable.
-- 8 --
Subject: [PATCH] git add: rephrase the removal will cease to be ignored
warning
Now the logic to decide when to warn has been tightened, we know the
user is in a situation where the current and future behaviours will
be different. Spell out what happens with these two versions and
how to explicitly ask for the behaviour, and suggest git status as
a way to inspect the current status.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
builtin/add.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/builtin/add.c b/builtin/add.c
index 4242bce..20f459a 100644
--- a/builtin/add.c
+++ b/builtin/add.c
@@ -52,15 +52,22 @@ static int fix_unmerged_status(struct diff_filepair *p,
return DIFF_STATUS_MODIFIED;
}
+static const char *add_would_remove_warning = N_(
+ You ran 'git add' with neither '-A (--all)' or '--no-all', whose\n
+behaviour will change in Git 2.0 with respect to paths you removed from\n
+your working tree. Paths like '%s' that are\n
+removed are ignored with this version of Git.\n
+\n
+* 'git add --no-all pathspec', which is the current default, ignores\n
+ paths you removed from your working tree.\n
+\n
+* 'git add --all pathspec' will let you also record the removals.\n
+\n
+Run 'git status' to check the paths you removed from your working tree.\n);
+
static void warn_add_would_remove(const char *path)
{
- warning(_(In Git 2.0, 'git add pathspec...' will also update the\n
- index for paths removed from the working tree that match\n
- the given pathspec. If you want to 'add' only changed\n
- or newly created paths, say 'git add --no-all pathspec...'
- instead.\n\n
- '%s' would be removed from the index without --no-all.),
- path);
+ warning(_(add_would_remove_warning), path);
}
static void update_callback(struct diff_queue_struct *q,
--
1.8.2.1-650-g3c8b519
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/7] Documentation/shortlog improvements
Hi, The re-roll was necessary due to minor/silly mistakes in v2, as pointed out by Junio. The builtin/shortlog.c patch has moved to the end until we change 'since..until' to 'revision range' everywhere else. We use 'revision range' here too. [4/7] has been replaced with the version Junio fixed up and put in `pu`. [6/7] has been updated to copy sections from log.txt properly, and omit the see below for History Simplification part. Thanks. Ramkumar Ramachandra (7): git-shortlog.txt: remove (-h|--help) from OPTIONS revisions.txt: clarify the .. and ... syntax git-log.txt: order OPTIONS properly; move since..until git-log.txt: generalize since..until git-log.txt: rewrite note on why -- may be required git-shortlog.txt: make SYNOPSIS match log, update OPTIONS builtin/shortlog.c: make usage string consistent with log Documentation/git-log.txt | 22 -- Documentation/git-shortlog.txt | 23 +-- Documentation/revisions.txt| 6 -- builtin/shortlog.c | 4 +--- 4 files changed, 34 insertions(+), 21 deletions(-) -- 1.8.2.1.501.gd2949c7 -- To unsubscribe from this list: send the line 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/7] git-shortlog.txt: remove (-h|--help) from OPTIONS
To be consistent with the documentation of all the other commands, remove (-h|--help) from the OPTIONS section. Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- Documentation/git-shortlog.txt | 4 1 file changed, 4 deletions(-) diff --git a/Documentation/git-shortlog.txt b/Documentation/git-shortlog.txt index c308e91..c7f7f51 100644 --- a/Documentation/git-shortlog.txt +++ b/Documentation/git-shortlog.txt @@ -26,10 +26,6 @@ reference to the current repository. OPTIONS --- --h:: ---help:: - Print a short usage message and exit. - -n:: --numbered:: Sort output according to the number of commits per author instead -- 1.8.2.1.501.gd2949c7 -- To unsubscribe from this list: send the line 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/7] revisions.txt: clarify the .. and ... syntax
In rev1..rev2 and rev1...rev2, if either rev1 or rev2 is
omitted, it defaults to 'HEAD'. Add this detail to the document.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
Documentation/revisions.txt | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt
index 8855b1a..0a23129 100644
--- a/Documentation/revisions.txt
+++ b/Documentation/revisions.txt
@@ -244,11 +244,13 @@ To summarize:
'rev1..rev2'::
Include commits that are reachable from rev2 but exclude
- those that are reachable from rev1.
+ those that are reachable from rev1. When either rev1 or
+ rev2 is omitted, it defaults to 'HEAD'.
'rev1\...rev2'::
Include commits that are reachable from either rev1 or
- rev2 but exclude those that are reachable from both.
+ rev2 but exclude those that are reachable from both. When
+ either rev1 or rev2 is omitted, it defaults to 'HEAD'.
'rev{caret}@', e.g. 'HEAD{caret}@'::
A suffix '{caret}' followed by an at sign is the same as listing
--
1.8.2.1.501.gd2949c7
--
To unsubscribe from this list: send the line 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/7] git-log.txt: order OPTIONS properly; move since..until
The OPTIONS section lists since..until as the first item, but this is inconsistent with the ordering in SYNOPSIS. Move it down until it appears just before [[--] path...]. Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- Documentation/git-log.txt | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt index 69db578..64cc337 100644 --- a/Documentation/git-log.txt +++ b/Documentation/git-log.txt @@ -24,13 +24,6 @@ each commit introduces are shown. OPTIONS --- -since..until:: - Show only commits between the named two commits. When - either since or until is omitted, it defaults to - `HEAD`, i.e. the tip of the current branch. - For a more complete list of ways to spell since - and until, see linkgit:gitrevisions[7]. - --follow:: Continue listing the history of a file beyond renames (works only for a single file). @@ -69,6 +62,13 @@ produced by --stat etc. Note that only message is considered, if also a diff is shown its size is not included. +since..until:: + Show only commits between the named two commits. When + either since or until is omitted, it defaults to + `HEAD`, i.e. the tip of the current branch. + For a more complete list of ways to spell since + and until, see linkgit:gitrevisions[7]. + [\--] path...:: Show only commits that are enough to explain how the files that match the specified paths came to be. See History -- 1.8.2.1.501.gd2949c7 -- To unsubscribe from this list: send the line 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/7] git-log.txt: generalize since..until
'since..until' is misleading, as there are many other forms that 'git log' can accept as an argument. Replace it with revision range, referring to the section Specifying Ranges in revisions.txt, and rewrite the section appropriately. Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- Documentation/git-log.txt | 16 +--- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt index 64cc337..9576695 100644 --- a/Documentation/git-log.txt +++ b/Documentation/git-log.txt @@ -9,7 +9,7 @@ git-log - Show commit logs SYNOPSIS [verse] -'git log' [options] [since..until] [[\--] path...] +'git log' [options] [revision range] [[\--] path...] DESCRIPTION --- @@ -62,12 +62,14 @@ produced by --stat etc. Note that only message is considered, if also a diff is shown its size is not included. -since..until:: - Show only commits between the named two commits. When - either since or until is omitted, it defaults to - `HEAD`, i.e. the tip of the current branch. - For a more complete list of ways to spell since - and until, see linkgit:gitrevisions[7]. +revision range:: + Show only commits in the specified revision range. When no + revision range is specified, it defaults to `HEAD` (i.e. the + whole history leading to the current commit). `origin..HEAD` + specifies all the commits reachable from the current commit + (i.e. `HEAD`), but not from `origin`. For a complete list of + ways to spell revision range, see the Specifying Ranges + section of linkgit:gitrevisions[7]. [\--] path...:: Show only commits that are enough to explain how the files -- 1.8.2.1.501.gd2949c7 -- To unsubscribe from this list: send the line 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/7] 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 revision range need not be a set of branch names or ref names. Rewrite it to use the word revision range, to be consistent with the SYNOPSIS. Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- Documentation/git-log.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt index 9576695..a976534 100644 --- a/Documentation/git-log.txt +++ b/Documentation/git-log.txt @@ -77,8 +77,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 the revision range, when confusion arises. include::rev-list-options.txt[] -- 1.8.2.1.501.gd2949c7 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/7] 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. Save adding the options from rev-list-options.txt for a later patch, as it requires some work to pick out the options that are relevant to shortlog. Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- Documentation/git-shortlog.txt | 19 +-- 1 file changed, 17 insertions(+), 2 deletions(-) diff --git a/Documentation/git-shortlog.txt b/Documentation/git-shortlog.txt index c7f7f51..31af7f2 100644 --- a/Documentation/git-shortlog.txt +++ b/Documentation/git-shortlog.txt @@ -8,8 +8,8 @@ git-shortlog - Summarize 'git log' output SYNOPSIS [verse] -git log --pretty=short | 'git shortlog' [-h] [-n] [-s] [-e] [-w] -'git shortlog' [-n|--numbered] [-s|--summary] [-e|--email] [-w[width[,indent1[,indent2 commit... +git log --pretty=short | 'git shortlog' [options] +'git shortlog' [options] [revision range] [[\--] path...] DESCRIPTION --- @@ -56,6 +56,21 @@ OPTIONS If width is `0` (zero) then indent the lines of the output without wrapping them. +revision range:: + Show only commits in the specified revision range. When no + revision range is specified, it defaults to `HEAD` (i.e. the + whole history leading to the current commit). `origin..HEAD` + specifies all the commits reachable from the current commit + (i.e. `HEAD`), but not from `origin`. For a complete list of + ways to spell revision range, see the Specifying Ranges + section of linkgit:gitrevisions[7]. + +[\--] path...:: + Consider only commits that are enough to explain how the files + that match the specified paths came to be. ++ +Paths may need to be prefixed with \-- to separate them from +options or the revision range, when confusion arises. MAPPING AUTHORS --- -- 1.8.2.1.501.gd2949c7 -- To unsubscribe from this list: send the line 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 7/7] builtin/shortlog.c: make usage string consistent with log
-- is used to separate pathspecs from the rev specs, and not rev
specs from the options, as the shortlog_usage string currently
indicates. In correcting this usage string, make it consistent with
the log_usage string.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
builtin/shortlog.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/builtin/shortlog.c b/builtin/shortlog.c
index 240bff3..1fd6f8a 100644
--- a/builtin/shortlog.c
+++ b/builtin/shortlog.c
@@ -10,9 +10,7 @@
#include parse-options.h
static char const * const shortlog_usage[] = {
- N_(git shortlog [-n] [-s] [-e] [-w] [rev-opts] [--] [commit-id...
]),
- ,
- N_([rev-opts] are documented in git-rev-list(1)),
+ N_(git shortlog [options] [revision range] [[--] [path...]]),
NULL
};
--
1.8.2.1.501.gd2949c7
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
