* Re: Re: [PATCH] Docs: git checkout --orphan: `root commit' and `branch head'
From: Eric Raible @ 2011-09-27 20:34 UTC (permalink / raw)
To: Junio C Hamano
Cc: Michael Witten, Michael J Gruber, Carlos Martín Nieto,
vra5107, git
In-Reply-To: <7v39fhyk21.fsf@alter.siamese.dyndns.org>
On 11:59 AM, Junio C Hamano wrote:
> Michael Witten <mfwitten@gmail.com> writes:
>
>> It seems like a more logical approach would be instead for "git
>> commit" to take a "--root" option that would create a new root commit
>> based on the current index and then point the current branch head to
>> the new root commit. Thus:
>>
>> $ git checkout -b new_branch old_branch
>> $ # Manipulate or not
>> $ git commit --root
>>
>> That's how people think.
Not this person.
I like the idea but I'd rather see:
git commit --no-parent
"parent" at least appears in gitk and therefore newcomers will prob
have a better chance of understanding the intent w/out needing to
otherwise unnecessary terminology.
^ permalink raw reply
* Re: [PATCH v2] Docs: git checkout --orphan: `root commit' and `branch head'
From: Philip Oakley @ 2011-09-27 20:59 UTC (permalink / raw)
To: Matthieu Moy, Michael Witten
Cc: Junio C Hamano, Carlos Martín Nieto, vra5107, git
In-Reply-To: <vpqsjni6kkk.fsf@bauges.imag.fr>
From: "Matthieu Moy" <Matthieu.Moy@grenoble-inp.fr>
> Michael Witten <mfwitten@gmail.com> writes:
>
>> -This can be useful when you want to publish the tree from a commit
>> -without exposing its full history. You might want to do this to publish
>> -an open source branch of a project whose current tree is "clean", but
>> -whose full history contains proprietary or otherwise encumbered bits of
>> -code.
>
> This part used to be just this in v1:
>
> -This can be useful when you want to publish the tree from a commit
> -without exposing its full history. You might want to do this to publish
> +This can be useful when you want to publish a tree without exposing its
> +full history; for instance, you might want to do this to publish
> an open source branch of a project whose current tree is "clean", but
> whose full history contains proprietary or otherwise encumbered bits of
> code.
>
> is it intentionnal that you discarded completely the paragraph? If so,
> then I disagree, the paragraph was one of the main motivation for
> someone to use --orphan, without it, someone may understand _what_ it
> does, but not _why_ it is useful.
>
> --
I agree - it would be wrong to discard the explanation of why it is used. As
a relatively new git user, the man pages do need to properly inform the
usage.
I have some orphan [i.e. independant] branches that are for documentation
and for old matlab code that are both part of the project, but are separate
from the various code branches. The original term `--orphan` was meaningful,
though I do agree about it being a root commit.
It can be very easy for those that already know to presume knowledge of the
reader that the reader doesn't have, leaving both sides frustrated. Reading
the full manual could be a life times work to get all the nuances.
^ permalink raw reply
* Re: [PATCH] add --progress to git-gc and git-repack
From: Jeff King @ 2011-09-27 21:29 UTC (permalink / raw)
To: Oleg Andreev; +Cc: git, gitster
In-Reply-To: <9F9C752E-6B3C-401B-9E01-8B1F5544A82F@gmail.com>
On Tue, Sep 27, 2011 at 10:32:45PM +0200, Oleg Andreev wrote:
> From 1f261e13e72770deabd77087e354f304be850efc Mon Sep 17 00:00:00 2001
> From: Oleg Andreev <oleganza@gmail.com>
> Date: Tue, 27 Sep 2011 08:24:25 +0200
> Subject: [PATCH 1/2] git-repack: pass --progress down to git-pack-objects
Please follow Documentation/SubmittingPatches. This should be part of
the actual email headers. And there should be one patch per email.
My first thought was "doesn't git-repack already show progress?".
There's no motivation in the commit message, so I have to guess why you
want this. I assume you want to override the isatty(2) decision that
pack-objects uses?
> diff --git a/git-repack.sh b/git-repack.sh
> index 624feec..b86d60e 100755
> --- a/git-repack.sh
> +++ b/git-repack.sh
> [...]
> @@ -35,6 +36,7 @@ do
> unpack_unreachable=--unpack-unreachable ;;
> -d) remove_redundant=t ;;
> -q) GIT_QUIET=t ;;
> + --progress) progress=--progress ;;
> -f) no_reuse=--no-reuse-delta ;;
> -F) no_reuse=--no-reuse-object ;;
> -l) local=--local ;;
Should this also handle --no-progress? Maybe it is not a big deal, as
"-q" will also suppress progress, but it would be consistent with other
git commands that take --progress.
> diff --git a/Documentation/git-gc.txt b/Documentation/git-gc.txt
> index 815afcb..b65fa3e 100644
> --- a/Documentation/git-gc.txt
> +++ b/Documentation/git-gc.txt
> [...]
> --quiet::
> - Suppress all progress reports.
> + Suppress all progress reports. Progress is not reported to
> + the standard error stream.
This just seems redundant to me.
> +--progress::
> + Progress status is reported on the standard error stream
> + by default when it is attached to a terminal, unless -q
> + is specified. This flag forces progress status even if the
> + standard error stream is not directed to a terminal.
Though this is a nice description.
> --- a/builtin/gc.c
> +++ b/builtin/gc.c
> struct option builtin_gc_options[] = {
> OPT__QUIET(&quiet, "suppress progress reporting"),
> + OPT_BOOLEAN(0, "progress", &progress, "force progress reporting"),
This will handle --no-progress for us automatically, which is good.
> diff --git a/contrib/examples/git-gc.sh b/contrib/examples/git-gc.sh
> index 1597e9f..52ea808 100755
> --- a/contrib/examples/git-gc.sh
> +++ b/contrib/examples/git-gc.sh
> [...]
> while test $# != 0
> do
> case "$1" in
> --prune)
> no_prune=
> ;;
> + --progress)
> + progress=--progress
> + ;;
This won't, but I think this whole hunk is unnecessary. The files in
contrib/examples are kept around for people to see how git commands can
be composed of plumbing building blocks. But they don't need to gain new
features as their C counterparts do. I think we can just leave them
frozen in time as of when each script was rewritten in C.
-Peff
^ permalink raw reply
* Re: Re: [PATCH] Docs: git checkout --orphan: `root commit' and `branch head'
From: Philip Oakley @ 2011-09-27 21:31 UTC (permalink / raw)
To: Eric Raible, Junio C Hamano
Cc: Michael Witten, Michael J Gruber, Carlos Martín Nieto,
vra5107, git
In-Reply-To: <4E823359.7080602@nextest.com>
From: "Eric Raible" <raible@nextest.com>
> On 11:59 AM, Junio C Hamano wrote:
>> Michael Witten <mfwitten@gmail.com> writes:
>>
>>> It seems like a more logical approach would be instead for "git
>>> commit" to take a "--root" option that would create a new root commit
>>> based on the current index and then point the current branch head to
>>> the new root commit. Thus:
>>>
>>> $ git checkout -b new_branch old_branch
>>> $ # Manipulate or not
>>> $ git commit --root
>>>
>>> That's how people think.
>
> Not this person.
>
> I like the idea but I'd rather see:
>
> git commit --no-parent
>
> "parent" at least appears in gitk and therefore newcomers will prob
> have a better chance of understanding the intent w/out needing to
> otherwise unnecessary terminology.
> --
I think this feels and sounds sensible. And better located within the
'commit' command, rather than 'checkout --orphan' which was more obscure
(and difficult to find).
Philip
^ permalink raw reply
* Re: Do we have a convenient way to refer to a specific commit in an already filtered rev-list?
From: Jeff King @ 2011-09-27 21:35 UTC (permalink / raw)
To: Tzu-Jung Lee; +Cc: git
In-Reply-To: <CAEvN+1jPD53-e8a31g+iz6vMB0-e2LECjouBELkBOXBV5=oGBg@mail.gmail.com>
On Sun, Sep 25, 2011 at 12:46:20AM +0800, Tzu-Jung Lee wrote:
> Do we have a convenient/symbolic way to refer to a specific commit of
> an already filtered rev-list? For example, I'm interested in the
> commits with some constraints:
>
> git log somepath --author=someone
>
> Without gui/tui tools, I have to frequently CUT & PASTE the commit-ID
> for further manipulation (show, cherry-pick, ...), and possibly repeat
> the parsing couple of times if I didn't save the output. I wonder if
> we have a convenient way to refer to the discrete commits? like
> HEAD~4, HEAD@{3} or something magic.
Use the shell:
git rev-list --author=someone HEAD >saved-query
git log --no-walk --stdin <saved-query
git cherry-pick `cat saved-query`
or even:
q=`git rev-list --author=someone HEAD`
git log --no-walk $q
git cherry-pick $q
-Peff
^ permalink raw reply
* [PATCH v2] send-email: auth plain/login fix
From: Zbigniew Jędrzejewski-Szmek @ 2011-09-27 21:36 UTC (permalink / raw)
To: gitster, joe, git; +Cc: Zbigniew Jędrzejewski-Szmek
In-Reply-To: <m3fwjjp69m.fsf@localhost.localdomain>
git send-email was not authenticating properly when communicating over
TLS with a server supporting only AUTH PLAIN and AUTH LOGIN. This is
e.g. the standard server setup under debian with exim4 and probably
everywhere where system accounts are used.
The solution comes from this forum thread:
http://www.perlmonks.org/?node_id=904354
This patch is tested by sending it :)
Before:
Net::SMTP>>> Net::SMTP(2.31)
Net::SMTP>>> Net::Cmd(2.29)
Net::SMTP>>> Exporter(5.64_01)
Net::SMTP>>> IO::Socket::INET(1.31)
Net::SMTP>>> IO::Socket(1.31)
Net::SMTP>>> IO::Handle(1.28)
...
Net::SMTP=GLOB(0x238f668)>>> STARTTLS
Net::SMTP=GLOB(0x238f668)<<< 220 2.0.0 Ready to start TLS
Net::SMTP::SSL=GLOB(0x238f668)>>> EHLO localhost.localdomain
Net::SMTP::SSL=GLOB(0x238f668)<<< 250-yyy.yyy.yyy Hello xxx.xxx [xxx.xxx.xxx.xxx], pleased to meet you
Net::SMTP::SSL=GLOB(0x238f668)<<< 250-ENHANCEDSTATUSCODES
Net::SMTP::SSL=GLOB(0x238f668)<<< 250-PIPELINING
Net::SMTP::SSL=GLOB(0x238f668)<<< 250-8BITMIME
Net::SMTP::SSL=GLOB(0x238f668)<<< 250-SIZE 80000000
Net::SMTP::SSL=GLOB(0x238f668)<<< 250-DSN
Net::SMTP::SSL=GLOB(0x238f668)<<< 250-AUTH=LOGIN PLAIN
Net::SMTP::SSL=GLOB(0x238f668)<<< 250-AUTH LOGIN PLAIN
Net::SMTP::SSL=GLOB(0x238f668)<<< 250-DELIVERBY
Net::SMTP::SSL=GLOB(0x238f668)<<< 250 HELP
Password:
Net::SMTP::SSL=GLOB(0x238f668)>>> AUTH
Net::SMTP::SSL=GLOB(0x238f668)<<< 501 5.5.2 AUTH mechanism must be specified
5.5.2 AUTH mechanism must be specified
After:
Net::SMTP=GLOB(0x1ac4a60)>>> STARTTLS
Net::SMTP=GLOB(0x1ac4a60)<<< 220 2.0.0 Ready to start TLS
Net::SMTP::SSL=GLOB(0x1ac4a60)>>> EHLO localhost.localdomain
Net::SMTP::SSL=GLOB(0x1ac4a60)<<< 250-yyy.yyy.yyy Hello xxx.xxx [xxx.xxx.xxx.xxx], pleased to meet you
Net::SMTP::SSL=GLOB(0x1ac4a60)<<< 250-ENHANCEDSTATUSCODES
Net::SMTP::SSL=GLOB(0x1ac4a60)<<< 250-PIPELINING
Net::SMTP::SSL=GLOB(0x1ac4a60)<<< 250-8BITMIME
Net::SMTP::SSL=GLOB(0x1ac4a60)<<< 250-SIZE 80000000
Net::SMTP::SSL=GLOB(0x1ac4a60)<<< 250-DSN
Net::SMTP::SSL=GLOB(0x1ac4a60)<<< 250-AUTH=LOGIN PLAIN
Net::SMTP::SSL=GLOB(0x1ac4a60)<<< 250-AUTH LOGIN PLAIN
Net::SMTP::SSL=GLOB(0x1ac4a60)<<< 250-DELIVERBY
Net::SMTP::SSL=GLOB(0x1ac4a60)<<< 250 HELP
Password:
Net::SMTP::SSL=GLOB(0x1ac4a60)>>> AUTH LOGIN
Net::SMTP::SSL=GLOB(0x1ac4a60)<<< 334 VXNlcm5hbWU6
Net::SMTP::SSL=GLOB(0x1ac4a60)>>> emJ5c3plaw==
Net::SMTP::SSL=GLOB(0x1ac4a60)<<< 334 UGFzc3dvcmQ6
Net::SMTP::SSL=GLOB(0x1ac4a60)>>> dGVzdA==
Net::SMTP::SSL=GLOB(0x1ac4a60)<<< 535 5.7.0 authentication failed
5.7.0 authentication failed
The password is incorrect in this snippet, but the protocol works correctly.
Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
---
v2: - added sign-off as requested, although the patch is as trivial
as it gets
- the import is performed only if it will be used
git-send-email.perl | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 37dfbe7..5a22d18 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -1098,6 +1098,8 @@ X-Mailer: git-send-email $gitversion
}
if (defined $smtp_authuser) {
+ require Authen::SASL;
+ Authen::SASL->import(qw(Perl));
if (!defined $smtp_authpass) {
--
1.7.6
^ permalink raw reply related
* Re: Re: [PATCH] Docs: git checkout --orphan: `root commit' and `branch head'
From: Jeff King @ 2011-09-27 21:42 UTC (permalink / raw)
To: Philip Oakley
Cc: Eric Raible, Junio C Hamano, Michael Witten, Michael J Gruber,
Carlos Martín Nieto, vra5107, git
In-Reply-To: <DBCBE20265964ECCA5B9724DAC74D83B@PhilipOakley>
On Tue, Sep 27, 2011 at 10:31:17PM +0100, Philip Oakley wrote:
> >Not this person.
> >
> >I like the idea but I'd rather see:
> >
> >git commit --no-parent
> >
> >"parent" at least appears in gitk and therefore newcomers will prob
> >have a better chance of understanding the intent w/out needing to
> >otherwise unnecessary terminology.
> >--
> I think this feels and sounds sensible. And better located within
> the 'commit' command, rather than 'checkout --orphan' which was more
> obscure (and difficult to find).
Keep in mind that making it part of commit is potentially much more
dangerous. With "checkout --orphan", you are making a _new_ branch that
has no parents. Committing on it will make a disconnected history, but
your original branch is still there.
With "git commit --no-parent", you are disconnecting history on the
_current_ branch. Which means you are throwing away the old history
completely. I.e., it is about as dangerous as "git branch -d", which we
usually protect with a "force" flag[1].
So at the very least, the documentation for the new option would need to
make the consequences very clear, and that one should run it on a newly
created branch if they don't want to throw away the old history.
-Peff
[1] Actually, it's similarly dangerous to "git reset", which doesn't
have a force flag. But then, "git reset" is frequently brought up as
the most dangerous and confusing command by new git users.
^ permalink raw reply
* Re: [PATCH v2] send-email: auth plain/login fix
From: Jeff King @ 2011-09-27 21:48 UTC (permalink / raw)
To: Zbigniew Jędrzejewski-Szmek; +Cc: gitster, joe, git
In-Reply-To: <1317159419-23166-1-git-send-email-zbyszek@in.waw.pl>
On Tue, Sep 27, 2011 at 11:36:59PM +0200, Zbigniew Jędrzejewski-Szmek wrote:
> v2: - added sign-off as requested, although the patch is as trivial
> as it gets
> - the import is performed only if it will be used
Nice, it's much better not to make the dependency required by people who
are not using smtp auth, but...
> diff --git a/git-send-email.perl b/git-send-email.perl
> index 37dfbe7..5a22d18 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -1098,6 +1098,8 @@ X-Mailer: git-send-email $gitversion
> }
>
> if (defined $smtp_authuser) {
> + require Authen::SASL;
> + Authen::SASL->import(qw(Perl));
What about people who are using smtp auth, but don't need or have
Authen::SASL? I.e., shouldn't this be:
eval {
require Authen::SASL;
Authen::SASL->import(qw(Perl));
}
and if we hit an error, just ignore it and continue without Authen::SASL
loaded?
-Peff
^ permalink raw reply
* Re: [PATCH 0/6] A handful of "branch description" patches
From: Jeff King @ 2011-09-27 21:58 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Junio C Hamano, git
In-Reply-To: <4E7DEC4A.3050900@drmicha.warpmail.net>
On Sat, Sep 24, 2011 at 04:42:18PM +0200, Michael J Gruber wrote:
> > This seems like a clever solution to making git-notes store a ref as a
> > key instead of an arbitrary sha1. But I wonder if the end result is
> > really waht the user wants. The resulting notes tree is good for doing
> > lookups, but the entries are completely obfuscated. So I can't easily do
> > something like "list all of the refs which have descriptions". I can
> > only list the _hashes_ of the refs which have descriptions. And if I am
> > lucky, I can hash the refs I have and correlate them. But unknown ones
> > will simply be a mystery.
>
> [mjg@localhost git]$ git rev-parse ref:mjg/vob/virtual-objects
> 3f8aa9bb80fe241306aafd3d76af50739ba88268
> [mjg@localhost git]$ git show 3f8aa9bb80fe241306aafd3d76af50739ba88268
> refs/heads/mjg/vob/virtual-objects
Sure, but what about:
git notes list
which is just filled with meaningless nonsense.
> > Wouldn't it be much more friendly to have a separate tree of refnames
> > that stores:
> >
> > refs/heads/foo -> (some blob with the "foo" description)
> > refs/heads/bar -> (some blob with the "bar" description)
>
> Given the above, I don't think it's more friendly.
>
> In fact, in my first attempt, I wrote out the blobs, and referenced them
> just like above from a different subtree within the notes tree, in order
> to keep them from being pruned. So the virtual approach is pretty
> equivalent, though leaner.
Hmm. So your mapping of $ref to $desc is:
sha1($ref) -> sha1(blob($desc))
>From what you wrote there, I think maybe you think I meant to store:
sha1(blob($ref)) -> sha1(blob($desc))
But what I meant was actually:
$ref -> sha1(blob($desc))
I.e., not to use "notes" at all, but rather a tree that mirrors the
refs/ hierarchy in its names.
> > Yeah, you have to build another git-notes-like interface around it. But
> > the data structure is pleasant and flexible. You could even "git
> > checkout" the whole tree and edit the notes with your editor, without
> > having to deal with some obfuscated name.
>
> Well, "git branch --edit-description" and such should be the way to edit
> them, shouldn't it?
It's one way. I assume that if we store things in a reasonable,
readable state, then people like that because they can hack on the data
structure using more flexible tools.
> I really think the only issue is remote refnames. As Junio points out,
> they are local by nature. OTOH, you typically use a non-renaming refspec
> which puts them under refs/remotes/foo/bar with "bar" being the same
> name as the local one on the remote, foo something you have chosen. So,
> teaching the code that the note for
If they are local by nature, is it worth putting them into a notes tree
at all? That provides versioning and backup. But I wonder if it is worth
the hassle, when one could just put them in the config.
-Peff
^ permalink raw reply
* Re* [PATCH 2/2] grep --no-index: don't use git standard exclusions
From: Junio C Hamano @ 2011-09-27 22:21 UTC (permalink / raw)
To: git; +Cc: Bert Wesarg
In-Reply-To: <CAKPyHN2ewwLf6am3VQr_z4c3_Q5=saeLcZtuY-fEtUGr-41rKQ@mail.gmail.com>
Bert Wesarg <bert.wesarg@googlemail.com> writes:
> Would '--untracked-too' only be a synonym for '--no-index
> --exclude-standard', i.e. the current behavior?
That basically would be the idea. Perhaps something like this on top of
a9e6436 (grep --no-index: don't use git standard exclusions, 2011-09-15).
-- >8 --
Subject: [PATCH 1/2] grep: teach --untracked and --exclude options
In a working tree of a git managed repository, "grep --untracked" would
find the specified patterns from files in untracked files in addition to
its usual behaviour of finding them in the tracked files.
By default, when working with "--no-index" option, "grep" does not pay
attention to .gitignore mechanism. "grep --no-index --exclude" can be
used to tell the command to use .gitignore and stop reporting hits from
files that would be ignored. Also, when working without "--no-index",
"grep" honors .gitignore mechanism, and "grep --no-exclude" can be used
to tell the command to include hits from files that are ignored.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Documentation/git-grep.txt | 15 ++++++++++++++-
builtin-grep.c | 25 ++++++++++++++++++-------
2 files changed, 32 insertions(+), 8 deletions(-)
diff --git a/Documentation/git-grep.txt b/Documentation/git-grep.txt
index e019e76..2ccfb90 100644
--- a/Documentation/git-grep.txt
+++ b/Documentation/git-grep.txt
@@ -9,7 +9,7 @@ git-grep - Print lines matching a pattern
SYNOPSIS
--------
[verse]
-'git grep' [--cached]
+'git grep' [--cached] [--untracked] [--excludes]
[-a | --text] [-I] [-i | --ignore-case] [-w | --word-regexp]
[-v | --invert-match] [-h|-H] [--full-name]
[-E | --extended-regexp] [-G | --basic-regexp]
@@ -36,6 +36,19 @@ OPTIONS
Instead of searching in the working tree files, check
the blobs registered in the index file.
+--untracked::
+ In addition to searching in the tracked files in the working
+ tree, search also in untracked files.
+
+--no-excludes::
+ Also search in ignored files by not honoring the `.gitignore`
+ mechanism. Only useful with `--untracked`.
+
+--excludes::
+ Do not pay attention to ignored files specified via the `.gitignore`
+ mechanism. Only useful when searching files in the current directory
+ with `--no-index`.
+
-a::
--text::
Process binary files as if they were text.
diff --git a/builtin-grep.c b/builtin-grep.c
index a10946d..c6cfdf8 100644
--- a/builtin-grep.c
+++ b/builtin-grep.c
@@ -646,12 +646,14 @@ static int grep_object(struct grep_opt *opt, const char **paths,
die("unable to grep from object of type %s", typename(obj->type));
}
-static int grep_directory(struct grep_opt *opt, const char **paths)
+static int grep_directory(struct grep_opt *opt, const char **paths, int exc_std)
{
struct dir_struct dir;
int i, hit = 0;
memset(&dir, 0, sizeof(dir));
+ if (exc_std)
+ setup_standard_excludes(&dir);
fill_directory(&dir, paths);
for (i = 0; i < dir.nr; i++) {
@@ -749,7 +751,7 @@ static int help_callback(const struct option *opt, const char *arg, int unset)
int cmd_grep(int argc, const char **argv, const char *prefix)
{
int hit = 0;
- int cached = 0;
+ int cached = 0, untracked = 0, opt_exclude = -1;
int seen_dashdash = 0;
int external_grep_allowed__ignored;
struct grep_opt opt;
@@ -764,6 +766,10 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
{ OPTION_BOOLEAN, 0, "index", &use_index, NULL,
"finds in contents not managed by git",
PARSE_OPT_NOARG | PARSE_OPT_NEGHELP },
+ OPT_BOOLEAN(0, "untracked", &untracked,
+ "search in both tracked and untracked files"),
+ OPT_SET_INT(0, "exclude", &opt_exclude,
+ "search also in ignored files", 1),
OPT_GROUP(""),
OPT_BOOLEAN('v', "invert-match", &opt.invert,
"show non-matching lines"),
@@ -950,18 +956,23 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
paths[1] = NULL;
}
- if (!use_index) {
+ if (!use_index && (untracked || cached))
+ die("--cached or --untracked cannot be used with --no-index.");
+
+ if (!use_index || untracked) {
int hit;
- if (cached)
- die("--cached cannot be used with --no-index.");
+ int use_exclude = (opt_exclude < 0) ? use_index : !!opt_exclude;
if (list.nr)
- die("--no-index cannot be used with revs.");
- hit = grep_directory(&opt, paths);
+ die("--no-index or --untracked cannot be used with revs.");
+ hit = grep_directory(&opt, paths, use_exclude);
if (use_threads)
hit |= wait_all();
return !hit;
}
+ if (0 <= opt_exclude)
+ die("--exclude or --no-exclude cannot be used for tracked contents.");
+
if (!list.nr) {
int hit;
if (!cached)
--
1.7.7.rc3.4.g8d714
^ permalink raw reply related
* [PATCH 2/2] grep: --untracked and --exclude tests
From: Junio C Hamano @ 2011-09-27 22:22 UTC (permalink / raw)
To: git; +Cc: Bert Wesarg
In-Reply-To: <7vty7xwrsf.fsf_-_@alter.siamese.dyndns.org>
Test various combinations of these options and --no-index.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
t/t7002-grep.sh | 34 +++++++++++++++++++++++++++++++++-
1 files changed, 33 insertions(+), 1 deletions(-)
diff --git a/t/t7002-grep.sh b/t/t7002-grep.sh
index 918d33f..2cbbdcc 100755
--- a/t/t7002-grep.sh
+++ b/t/t7002-grep.sh
@@ -455,6 +455,23 @@ test_expect_success 'outside of git repository' '
test_must_fail git grep o &&
git grep --no-index o >../../actual.sub &&
test_cmp ../../expect.sub ../../actual.sub
+ ) &&
+
+ echo ".*o*" >non/git/.gitignore &&
+ (
+ GIT_CEILING_DIRECTORIES="$(pwd)/non/git" &&
+ export GIT_CEILING_DIRECTORIES &&
+ cd non/git &&
+ test_must_fail git grep o &&
+ git grep --no-index --exclude o >../actual.full &&
+ test_cmp ../expect.full ../actual.full &&
+
+ {
+ echo ".gitignore:.*o*"
+ cat ../expect.full
+ } >../expect.with.ignored &&
+ git grep --no-index --no-exclude o >../actual.full &&
+ test_cmp ../expect.with.ignored ../actual.full
)
'
@@ -465,9 +482,12 @@ test_expect_success 'inside git repository but with --no-index' '
echo world >is/git/sub/file2 &&
echo ".*o*" >is/git/.gitignore &&
{
- echo ".gitignore:.*o*" &&
echo file1:hello &&
echo sub/file2:world
+ } >is/expect.unignored &&
+ {
+ echo ".gitignore:.*o*" &&
+ cat is/expect.unignored
} >is/expect.full &&
: >is/expect.empty &&
echo file2:world >is/expect.sub
@@ -476,12 +496,24 @@ test_expect_success 'inside git repository but with --no-index' '
git init &&
test_must_fail git grep o >../actual.full &&
test_cmp ../expect.empty ../actual.full &&
+
+ git grep --untracked o >../actual.unignored &&
+ test_cmp ../expect.unignored ../actual.unignored &&
+
git grep --no-index o >../actual.full &&
test_cmp ../expect.full ../actual.full &&
+
+ git grep --no-index --exclude o >../actual.unignored &&
+ test_cmp ../expect.unignored ../actual.unignored &&
+
cd sub &&
test_must_fail git grep o >../../actual.sub &&
test_cmp ../../expect.empty ../../actual.sub &&
+
git grep --no-index o >../../actual.sub &&
+ test_cmp ../../expect.sub ../../actual.sub &&
+
+ git grep --untracked o >../../actual.sub &&
test_cmp ../../expect.sub ../../actual.sub
)
'
--
1.7.7.rc3.4.g8d714
^ permalink raw reply related
* Re: [PATCH/RFC 0/2] Teach receive-pack not to run update hook for corrupt/non existent ref
From: Pang Yan Han @ 2011-09-27 22:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Shawn O. Pearce, Jeff King, Johannes Schindelin
In-Reply-To: <7vhb3xyld7.fsf@alter.siamese.dyndns.org>
On Tue, Sep 27, 2011 at 09:56:52AM -0700, Junio C Hamano wrote:
> [offtopic: where does that annoying M-F-T header come from? It even seems
> to be pointless in this case as it lists the same people as are already on
> To/Cc/From of the message.]
Sorry, it's due to my lack of familiarity with mutt.
>
> Pang Yan Han <pangyanhan@gmail.com> writes:
>
> > Should I reroll this patch with this behaviour:
> >
> > - Everything as usual for valid ref updates and deletes
> > - For deleting corrupt (dangling?) ref, post-receive and post-update hooks
> > also receive the same args as per valid update / delete
>
> Suonds sensible.
>
> > - For deleting non-existent refs:
> > - post-receive shall have empty stdin for those refs
> > - post-update shall have an empty arg for those refs
>
> I do not think these hooks should see names of refs that ended up being a
> no-op. If the push is only about attempting to delete a ref that did not
> exist, these hooks should not even get called. If there were other refs
> that got updated, these hooks have to be called, but they should not be
> told about the no-op. IOW
>
> $ git push $there :no-such-ref master:refs/remotes/origin/master
>
> should:
>
> (1) not call the post-* hooks if the refs/remotes/origin/master was
> already pointing at the same commit; or
>
> (2) invoke the post-* hooks if refs/remotes/origin/master is updated, but
> should tell hooks only about the update of refs/remotes/origin/master.
>
> That is pretty much in line with how a normal attempt to push the same
> commit to an already up-to-date ref works. For example, if you:
>
> $ git push $there master next
>
> when 'master' is lagging and 'next' is already up-to-date, post-update and
> post-receive hooks run and told only about 'master' and not 'next'.
Thanks, I will reroll this later.
^ permalink raw reply
* Re: Re: [PATCH] Docs: git checkout --orphan: `root commit' and `branch head'
From: Michael Witten @ 2011-09-27 23:28 UTC (permalink / raw)
To: Jeff King
Cc: Philip Oakley, Eric Raible, Junio C Hamano, Michael J Gruber,
Carlos Martín Nieto, vra5107, git
In-Reply-To: <20110927214213.GC5176@sigill.intra.peff.net>
On Tue, Sep 27, 2011 at 21:42, Jeff King <peff@peff.net> wrote:
> Keep in mind that making it part of commit is potentially much more
> dangerous. With "checkout --orphan", you are making a _new_ branch that
> has no parents. Committing on it will make a disconnected history, but
> your original branch is still there.
>
> With "git commit --no-parent", you are disconnecting history on the
> _current_ branch. Which means you are throwing away the old history
> completely. I.e., it is about as dangerous as "git branch -d", which we
> usually protect with a "force" flag[1].
If I might be a bit more pedantic:
With "checkout --orphan", you are setting up a new branch head
to point to an as-yet-to-exist commit that will have no parents.
Your original branch head is not changed.
With "git commit --no-parent", you would be altering the current
branch head, which means you are potentially leaving as a dangling
commit the commit to which that branch head originally pointed.
I.e., it is about as dangerous as "git reset --hard <new_root_commit>",
something for which we do NOT provide any protection.
For instance, what if I want the current branch head to point to that
new root commit? The existing solution requires juggling branch names;
why can't git just do what I tell it to do (as with "git reset")?
After all, "git commit --no-parent" is pretty name explicit.
^ permalink raw reply
* Re: Re: [PATCH] Docs: git checkout --orphan: `root commit' and `branch head'
From: Jeff King @ 2011-09-27 23:35 UTC (permalink / raw)
To: Michael Witten
Cc: Philip Oakley, Eric Raible, Junio C Hamano, Michael J Gruber,
Carlos Martín Nieto, vra5107, git
In-Reply-To: <CAMOZ1BvzWDPQ_e3Y5H8CX4wQwL5xf3xVvZvRL3gQPcB_kCGBbw@mail.gmail.com>
On Tue, Sep 27, 2011 at 11:28:14PM +0000, Michael Witten wrote:
> With "git commit --no-parent", you would be altering the current
> branch head, which means you are potentially leaving as a dangling
> commit the commit to which that branch head originally pointed.
> I.e., it is about as dangerous as "git reset --hard <new_root_commit>",
> something for which we do NOT provide any protection.
Didn't I already mention that example? And then say that I think the
lack of protection there has been the source of a lot of confusion and
hardship?
Repeating the problems of "git reset" does not seem like a good idea to
me. Especially not with a command like "commit", which is usually very
safe.
That being said, I did say in my last email that one option would be for
the documentation to be very clear about leaving the old history
dangling. That at least keeps clueless people from stumbling into using
the option accidentally.
So I'm not saying "we can't do this". I'm saying "this is dangerous, so
let's think for a minute about what safety mechanisms we can have".
> For instance, what if I want the current branch head to point to that
> new root commit? The existing solution requires juggling branch names;
> why can't git just do what I tell it to do (as with "git reset")?
> After all, "git commit --no-parent" is pretty name explicit.
It's explicit if you understand how git works, or what "parent" means.
I'm not sure every git user does, these days.
-Peff
^ permalink raw reply
* Re: Re: [PATCH] Docs: git checkout --orphan: `root commit' and `branch head'
From: Michael Witten @ 2011-09-27 23:44 UTC (permalink / raw)
To: Jeff King
Cc: Philip Oakley, Eric Raible, Junio C Hamano, Michael J Gruber,
Carlos Martín Nieto, vra5107, git
In-Reply-To: <20110927233549.GA10434@sigill.intra.peff.net>
On Tue, Sep 27, 2011 at 23:35, Jeff King <peff@peff.net> wrote:
> On Tue, Sep 27, 2011 at 11:28:14PM +0000, Michael Witten wrote:
>
>> With "git commit --no-parent", you would be altering the current
>> branch head, which means you are potentially leaving as a dangling
>> commit the commit to which that branch head originally pointed.
>> I.e., it is about as dangerous as "git reset --hard <new_root_commit>",
>> something for which we do NOT provide any protection.
>
> Didn't I already mention that example? And then say that I think the
> lack of protection there has been the source of a lot of confusion and
> hardship?
Sorry, I suppose you did already mention that, but:
* I missed it because of the footnote.
* There is more pedantry to my text than just that.
> Repeating the problems of "git reset" does not seem like a good idea to
> me. Especially not with a command like "commit", which is usually very
> safe.
I think that "git reset" is confusing and dangerous for more
fundamental reasons: It's another one of git's bizarre, poorly
chosen abstractions on top of the working tree and index.
^ permalink raw reply
* Lack of detached signatures
From: Joseph Parmelee @ 2011-09-27 23:48 UTC (permalink / raw)
To: git
Hello all:
Under the present circumstances, and particularly considering the
sensitivity of the git code itself, I would suggest that you implement
signed detached digital signatures on all release tarballs. Just a crypto
hash by itself, however strong, does not protect against man-in-the-middle
attacks.
Joseph
^ permalink raw reply
* [PATCH] parse-options: deprecate OPT_BOOLEAN
From: Junio C Hamano @ 2011-09-27 23:56 UTC (permalink / raw)
To: git; +Cc: Pierre Habouzit
It is natural to expect that an option defined with OPT_BOOLEAN() could be
used in this way:
int option = -1; /* unspecified */
struct option options[] = {
OPT_BOOLEAN(0, "option", &option, "set option"),
OPT_END()
};
parse_options(ac, av, prefix, options, usage, 0);
if (option < 0)
... do the default thing ...
else if (!option)
... --no-option was given ...
else
... --option was given ...
to easily tell three cases apart:
- There is no mention of the `--option` on the command line;
- The variable is positively set with `--option`; or
- The variable is explicitly negated with `--no-option`.
Unfortunately, this is not the case. OPT_BOOLEAN() increments the variable
every time `--option` is given, and resets it to zero when `--no-option`
is given.
As a first step to remedy this, introduce a true boolean OPT_BOOL(), and
rename OPT_BOOLEAN() to OPT_COUNTUP(). To help transitioning, OPT_BOOLEAN
and OPTION_BOOLEAN are defined as deprecated synonyms to OPT_COUNTUP and
OPTION_COUNTUP respectively.
This is what db7244b (parse-options new features., 2007-11-07) from four
years ago started by marking OPTION_BOOLEAN as "INCR would have been a
better name".
Some existing users do depend on the count-up semantics; for example,
users of OPT__VERBOSE() could use it to raise the verbosity level with
repeated use of `-v` on the command line, but they probably should be
rewritten to use OPT__VERBOSITY() instead these days. I suspect that some
users of OPT__FORCE() may also use it to implement different level of
forcibleness but I didn't check.
On top of this patch, here are the remaining clean-up tasks that other
people can help:
- Look at each hit in "git grep -e OPT_BOOLEAN"; trace all uses of the
value that is set to the underlying variable, and if it can proven that
the variable is only used as a boolean, replace it with OPT_BOOL(). If
the caller does depend on the count-up semantics, replace it with
OPT_COUNTUP() instead.
- Same for OPTION_BOOLEAN; replace it with OPTION_SET_INT and arrange to
set 1 to the variable for a true boolean, and otherwise replace it with
OPTION_COUNTUP.
- Look at each hit in "git grep -e OPT__VERBOSE -e OPT__QUIET" and see if
they can be replaced with OPT__VERBOSITY().
I'll follow this message up with a separate patch as an example.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Documentation/technical/api-parse-options.txt | 16 +++++++++++-----
parse-options.c | 4 ++--
parse-options.h | 10 ++++++++--
3 files changed, 21 insertions(+), 9 deletions(-)
diff --git a/Documentation/technical/api-parse-options.txt b/Documentation/technical/api-parse-options.txt
index f6a4a36..acf1760 100644
--- a/Documentation/technical/api-parse-options.txt
+++ b/Documentation/technical/api-parse-options.txt
@@ -135,9 +135,14 @@ There are some macros to easily define options:
describes the group or an empty string.
Start the description with an upper-case letter.
-`OPT_BOOLEAN(short, long, &int_var, description)`::
- Introduce a boolean option.
- `int_var` is incremented on each use.
+`OPT_BOOL(short, long, &int_var, description)`::
+ Introduce a boolean option. `int_var` is set to one with
+ `--option` and set to zero with `--no-option`.
+
+`OPT_COUNTUP(short, long, &int_var, description)`::
+ Introduce a count-up option.
+ `int_var` is incremented on each use of `--option`, and
+ reset to zero with `--no-option`.
`OPT_BIT(short, long, &int_var, description, mask)`::
Introduce a boolean option.
@@ -148,8 +153,9 @@ There are some macros to easily define options:
If used, `int_var` is bitwise-anded with the inverted `mask`.
`OPT_SET_INT(short, long, &int_var, description, integer)`::
- Introduce a boolean option.
- If used, set `int_var` to `integer`.
+ Introduce an integer option.
+ `int_var` is set to `integer` with `--option`, and
+ reset to zero with `--no-option`.
`OPT_SET_PTR(short, long, &ptr_var, description, ptr)`::
Introduce a boolean option.
diff --git a/parse-options.c b/parse-options.c
index 503ab5d..f0098eb 100644
--- a/parse-options.c
+++ b/parse-options.c
@@ -83,7 +83,7 @@ static int get_value(struct parse_opt_ctx_t *p,
*(int *)opt->value &= ~opt->defval;
return 0;
- case OPTION_BOOLEAN:
+ case OPTION_COUNTUP:
*(int *)opt->value = unset ? 0 : *(int *)opt->value + 1;
return 0;
@@ -319,7 +319,7 @@ static void parse_options_check(const struct option *opts)
err |= optbug(opts, "uses feature "
"not supported for dashless options");
switch (opts->type) {
- case OPTION_BOOLEAN:
+ case OPTION_COUNTUP:
case OPTION_BIT:
case OPTION_NEGBIT:
case OPTION_SET_INT:
diff --git a/parse-options.h b/parse-options.h
index 59e0b52..22c0273 100644
--- a/parse-options.h
+++ b/parse-options.h
@@ -10,7 +10,7 @@ enum parse_opt_type {
/* options with no arguments */
OPTION_BIT,
OPTION_NEGBIT,
- OPTION_BOOLEAN, /* _INCR would have been a better name */
+ OPTION_COUNTUP,
OPTION_SET_INT,
OPTION_SET_PTR,
/* options with arguments (usually) */
@@ -21,6 +21,9 @@ enum parse_opt_type {
OPTION_FILENAME
};
+/* Deprecated synonym */
+#define OPTION_BOOLEAN OPTION_COUNTUP
+
enum parse_opt_flags {
PARSE_OPT_KEEP_DASHDASH = 1,
PARSE_OPT_STOP_AT_NON_OPTION = 2,
@@ -122,10 +125,11 @@ struct option {
PARSE_OPT_NOARG, NULL, (b) }
#define OPT_NEGBIT(s, l, v, h, b) { OPTION_NEGBIT, (s), (l), (v), NULL, \
(h), PARSE_OPT_NOARG, NULL, (b) }
-#define OPT_BOOLEAN(s, l, v, h) { OPTION_BOOLEAN, (s), (l), (v), NULL, \
+#define OPT_COUNTUP(s, l, v, h) { OPTION_COUNTUP, (s), (l), (v), NULL, \
(h), PARSE_OPT_NOARG }
#define OPT_SET_INT(s, l, v, h, i) { OPTION_SET_INT, (s), (l), (v), NULL, \
(h), PARSE_OPT_NOARG, NULL, (i) }
+#define OPT_BOOL(s, l, v, h) OPT_SET_INT(s, l, v, h, 1)
#define OPT_SET_PTR(s, l, v, h, p) { OPTION_SET_PTR, (s), (l), (v), NULL, \
(h), PARSE_OPT_NOARG, NULL, (p) }
#define OPT_INTEGER(s, l, v, h) { OPTION_INTEGER, (s), (l), (v), "n", (h) }
@@ -149,6 +153,8 @@ struct option {
{ OPTION_CALLBACK, (s), (l), (v), "when", (h), PARSE_OPT_OPTARG, \
parse_opt_color_flag_cb, (intptr_t)"always" }
+/* Deprecated synonym */
+#define OPT_BOOLEAN OPT_COUNTUP
/* parse_options() will filter out the processed options and leave the
* non-option arguments in argv[].
^ permalink raw reply related
* [PATCH] archive.c: use OPT_BOOL()
From: Junio C Hamano @ 2011-09-27 23:59 UTC (permalink / raw)
To: git
In-Reply-To: <7v39fhv8se.fsf@alter.siamese.dyndns.org>
The list variable (which is OPT_BOOLEAN) is initialized to 0 and only
checked against 0 in the code, so it is safe to use OPT_BOOL().
The worktree_attributes variable (which is OPT_BOOLEAN) is initialized to
0 and later assigned to a field with the same name in struct archive_args,
which is a bitfield of width 1. It is safe and even more correct to use
OPT_BOOL() here; the new test in 5001 demonstrates why using OPT_COUNTUP
is wrong.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* This is an example of "the remaining clean-up tasks" I mentioned.
archive.c | 4 ++--
t/t5001-archive-attr.sh | 9 +++++++++
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/archive.c b/archive.c
index 3fd7f47..2ae740a 100644
--- a/archive.c
+++ b/archive.c
@@ -318,7 +318,7 @@ static int parse_archive_args(int argc, const char **argv,
"prepend prefix to each pathname in the archive"),
OPT_STRING('o', "output", &output, "file",
"write the archive to this file"),
- OPT_BOOLEAN(0, "worktree-attributes", &worktree_attributes,
+ OPT_BOOL(0, "worktree-attributes", &worktree_attributes,
"read .gitattributes in working directory"),
OPT__VERBOSE(&verbose, "report archived files on stderr"),
OPT__COMPR('0', &compression_level, "store only", 0),
@@ -332,7 +332,7 @@ static int parse_archive_args(int argc, const char **argv,
OPT__COMPR_HIDDEN('8', &compression_level, 8),
OPT__COMPR('9', &compression_level, "compress better", 9),
OPT_GROUP(""),
- OPT_BOOLEAN('l', "list", &list,
+ OPT_BOOL('l', "list", &list,
"list supported archive formats"),
OPT_GROUP(""),
OPT_STRING(0, "remote", &remote, "repo",
diff --git a/t/t5001-archive-attr.sh b/t/t5001-archive-attr.sh
index 02d4d22..f47d871 100755
--- a/t/t5001-archive-attr.sh
+++ b/t/t5001-archive-attr.sh
@@ -57,6 +57,15 @@ test_expect_missing worktree/ignored
test_expect_exists worktree/ignored-by-tree
test_expect_missing worktree/ignored-by-worktree
+test_expect_success 'git archive --worktree-attributes option' '
+ git archive --worktree-attributes --worktree-attributes HEAD >worktree.tar &&
+ (mkdir worktree2 && cd worktree2 && "$TAR" xf -) <worktree.tar
+'
+
+test_expect_missing worktree2/ignored
+test_expect_exists worktree2/ignored-by-tree
+test_expect_missing worktree2/ignored-by-worktree
+
test_expect_success 'git archive vs. bare' '
(cd bare && git archive HEAD) >bare-archive.tar &&
test_cmp archive.tar bare-archive.tar
^ permalink raw reply related
* Re: Lack of detached signatures
From: Junio C Hamano @ 2011-09-28 0:03 UTC (permalink / raw)
To: Joseph Parmelee; +Cc: git
In-Reply-To: <alpine.LNX.2.00.1109271742460.24832@bruno>
Joseph Parmelee <jparmele@wildbear.com> writes:
> Under the present circumstances, and particularly considering the
> sensitivity of the git code itself, I would suggest that you implement
> signed detached digital signatures on all release tarballs.
Well, signed tags are essentially detached signatures. People can verify
tarballs against them if they wanted to, although it is a bit cumbersome.
^ permalink raw reply
* Re: Lack of detached signatures
From: Michael Witten @ 2011-09-28 0:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Joseph Parmelee, git
In-Reply-To: <7vty7xttxh.fsf@alter.siamese.dyndns.org>
On Wed, Sep 28, 2011 at 00:03, Junio C Hamano <gitster@pobox.com> wrote:
> Joseph Parmelee <jparmele@wildbear.com> writes:
>
>> Under the present circumstances, and particularly considering the
>> sensitivity of the git code itself, I would suggest that you implement
>> signed detached digital signatures on all release tarballs.
>
> Well, signed tags are essentially detached signatures. People can verify
> tarballs against them if they wanted to, although it is a bit cumbersome.
Aren't tarballs used to get git on machines that don't yet have git?
^ permalink raw reply
* Re: [PATCH] Docs: git checkout --orphan: `root commit' and `branch head'
From: Junio C Hamano @ 2011-09-28 0:32 UTC (permalink / raw)
To: Jeff King
Cc: Michael Witten, Philip Oakley, Eric Raible, Michael J Gruber,
Carlos Martín Nieto, vra5107, git
In-Reply-To: <20110927233549.GA10434@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Tue, Sep 27, 2011 at 11:28:14PM +0000, Michael Witten wrote:
>
>> With "git commit --no-parent", you would be altering the current
>> branch head, which means you are potentially leaving as a dangling
>> commit the commit to which that branch head originally pointed.
>> I.e., it is about as dangerous as "git reset --hard <new_root_commit>",
>> something for which we do NOT provide any protection.
>
> Didn't I already mention that example? And then say that I think the
> lack of protection there has been the source of a lot of confusion and
> hardship?
>
> Repeating the problems of "git reset" does not seem like a good idea to
> me. Especially not with a command like "commit", which is usually very
> safe.
>
> That being said, I did say in my last email that one option would be for
> the documentation to be very clear about leaving the old history
> dangling. That at least keeps clueless people from stumbling into using
> the option accidentally.
Both of you are right and I agree "commit --root" is a bad idea (I can
change my mind ;-). Especially it is rare (and I would even say it should
be discouraged) to create a new root commit in a repository that already
has history, we should try to make it _very_ hard to lose history by
mistake, even though that means creating a new root commit has to be done
as a multi-step process (e.g. "checkout --orphan" to dissociate the new
state from the current history and then "commit").
Thanks for a bit of sanity.
^ permalink raw reply
* Re: [PATCH] git-completion: offer remotes for 'git remote update'
From: Junio C Hamano @ 2011-09-28 0:47 UTC (permalink / raw)
To: Auke Schrijnen; +Cc: git
In-Reply-To: <347b845858abcc62551d83df324e5c10@schrijnen.nl>
Auke Schrijnen <auke@schrijnen.nl> writes:
> Completion for 'git remote update' only offers configured remote
> groups.
I have this suspicion that it might even be a feature. I am a bad person
to make the judgement, as I do not use the "grouping" feature at all.
If you throw in individual remotes that are not grouped in the mix, the
users of "git remote update" auto-completion, who have been happily
relying on seeing only the configured groups, suddenly will start seeing
many individual repositories offered, cluttering the available choices.
Besides, if you want to fetch from a single source, why not use "git
fetch" directly?
Back when "git fetch" didn't allow fetching from multiple repositories in
one go, "remote update" was written as a wrapper for the explicit purpose
of fetching from more than one remote by defining remote groups. Since
late 2009, "git fetch" can update from multiple remotes itself, and I
suspect "git remote update" outlived its usefulness in some sense, but
that is a tangent.
^ permalink raw reply
* Re: [PATCH] gitweb: Fix links to lines in blobs when javascript-actions are enabled
From: Peter Stuge @ 2011-09-28 1:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7h4tykf3.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Nicely done.
Thanks.
> You forgot to mention another bug you fixed
Well.. I'm not sure that it is worth mentioning, since it may never
actually have been triggered by the way fixLinks() works.
> I'll amend in a few sentences to describe it as well.
Go for it.
//Peter
^ permalink raw reply
* Re: [PATCH] notes_merge_commit(): do not pass temporary buffer to other function
From: Michael Haggerty @ 2011-09-28 2:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johan Herland
In-Reply-To: <7vd3elyl8t.fsf@alter.siamese.dyndns.org>
On 09/27/2011 06:59 PM, Junio C Hamano wrote:
> Michael Haggerty <mhagger@alum.mit.edu> writes:
>
>> I discovered this problem when an innocent modification to unrelated
>> code triggered test failures.
>>
>> notes-merge.c | 3 ++-
>> 1 files changed, 2 insertions(+), 1 deletions(-)
>>
>> diff --git notes-merge.c notes-merge.c
>> index e1aaf43..baaf31f 100644
>> --- notes-merge.c
>> +++ notes-merge.c
>
> It is Ok to play with -p0 yourself but please don't do that in the public.
Sorry; I had set diff.noprefix=true, not realizing that it would affect
things like "git format-patch". It also confused emacs' magit mode, and
probably some other tools. It's now set permanently back to false.
The reason I was experimenting with this option is that it is a quick
double-click to select a filename like "foo/bar" in the diff output,
whereas selecting the filename out of "a/foo/bar" requires a slower
click and drag. Once I considered whether git could be taught to
explicitly ignore the "[ab]/" prefix when parsing filenames, but that is
too evil even for me :-)
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: [PATCH] notes_merge_commit(): do not pass temporary buffer to other function
From: Junio C Hamano @ 2011-09-28 3:10 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Junio C Hamano, git, Johan Herland
In-Reply-To: <4E828B6C.1010707@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
>>> diff --git notes-merge.c notes-merge.c
>>> index e1aaf43..baaf31f 100644
>>> --- notes-merge.c
>>> +++ notes-merge.c
>>
>> It is Ok to play with -p0 yourself but please don't do that in the public.
>
> Sorry; I had set diff.noprefix=true, not realizing that it would affect
> things like "git format-patch". It also confused emacs' magit mode, and
> probably some other tools. It's now set permanently back to false.
Thanks.
It is nothing catastrophic (I applied it with "am -p0 -s3c" just fine),
but everybody here sends -p1 format, so...
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox