* Re: [PATCH] gitweb: Silence stderr in parse_commit*() subroutines
From: Jakub Narebski @ 2012-02-13 19:04 UTC (permalink / raw)
To: rajesh boyapati; +Cc: git
In-Reply-To: <CA+EqV8xin_ubOoGouhHz2qnzoHrpMMQsjUTXnrtmsxRTLPZtZQ@mail.gmail.com>
On Mon, 13 Feb 2012, rajesh boyapati wrote:
> 2012/2/13 Jakub Narebski <jnareb@gmail.com>
>> On Mon, 13 Feb 2012, rajesh boyapati wrote:
>>> I am getting this error with this patch
>>>>>>>>>>>>>>>>>>>>>
>>> [2012-02-13 11:20:19,268] ERROR
>>> com.google.gerrit.httpd.gitweb.GitWebServlet : CGI: usage: git rev-list
>>> [OPTION] <commit-id>... [ -- paths... ]
>>> [2012-02-13 11:20:19,268] ERROR
>>> com.google.gerrit.httpd.gitweb.GitWebServlet : CGI: limiting output:
>>> [2012-02-13 11:20:19,268] ERROR
>>> com.google.gerrit.httpd.gitweb.GitWebServlet : CGI: --max-count=nr
>> [...]
>>> [2012-02-13 11:20:27,913] ERROR
>>> com.google.gerrit.httpd.gitweb.GitWebServlet : CGI: fatal: bad flag '--2'
>>> used after filename
>>> [2012-02-13 11:20:32,579] ERROR
>>> com.google.gerrit.httpd.gitweb.GitWebServlet : CGI: fatal: bad flag '--2'
>>> used after filename
>>> <<<<<<<<<<<<<<<<<<<
>>
>> Strange, I cannot reproduce this with non-Gerrit gitweb. It looks
>> like it somehow lost in between "... -- 2>/dev/null" at the end of
>> git-rev-list command, and fails at "--2" which is bad flag.
>>
> This is the patch I applied
>>>>>>>>>>>>>
> sub parse_commit {
> my ($commit_id) = @_;
> my %co;
>
> return unless defined $commit_id;
>
> local $/ = "\0";
>
> *open my $fd, "-|", quote_command(
> git_cmd(), "rev-list",*
> "--parents",
> "--header",
> "--max-count=1",
> $commit_id,
> * "--") . '2>/dev/null',*
^^^^^^^^^^^^^
It should be ' 2>/dev/null', with space before redirection, and not
'2>/dev/null'. This space is here necessary.
> With this Patch, Gerrit's gitweb is not showing anything.
> I mean, I can access gitweb from gerrit, but if I click on Tabs(like log,
> commit, etc...which worked with previous patches), I cannot see any thing.
>
> Even with previous patches also there is no improvement in Gerrit's gitweb,
> only some of the errors are gone in error_log.
> The improvement I am talking about is "If I click other tabs(log, shortlog,
> commit, tree,etc) after clicking "summary", Gerrit's gitweb is not showing
> anything".
Many views in gitweb do default to HEAD. If HEAD does not point to a valid
commit, they would fail, in better or worse way.
Except for the first one those patches are more of band-aid and workaround
than fixing underlying issue that gitweb assumes that HEAD is valid in
non-empty repository. But fixing this will require more work.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: git cherry doesn't list a merge commit
From: Junio C Hamano @ 2012-02-13 18:57 UTC (permalink / raw)
To: Tajti Ákos; +Cc: git
In-Reply-To: <4F392976.9070009@intland.com>
Tajti Ákos <akos.tajti@intland.com> writes:
> However, the manual of git cherry says:
> "*Every* commit that doesn’t exist in the <upstream> branch has its
> id (sha1) reported, prefixed by a symbol. The ones that have
> equivalent change already in the <upstream> branch are prefixed with a
> minus (-) sign"
The sole purpose of the command is to decide which commits in the existing
history to run "format-patch" on to feed the output to "am" to update the
other history, and it was clear for both readers and the author of the
documentation that a "commit" meant a "non-merge commit" in that context.
A patch to rephrase it to "every non-merge commit" for clarity may not be
useless, though.
^ permalink raw reply
* Re: Bulgarian translation of git
From: Junio C Hamano @ 2012-02-13 18:52 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Jiang Xin, Git List, Ævar Arnfjörð Bjarmason,
Alexander Shopov (Александър Шопов)
In-Reply-To: <20120213133957.GA4838@burratino>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Hopefully that would make it easier for translators to keep both
> tracks well maintained at the same time.
I somehow think it is not such a big deal if l10n messages are not
maintained for maintenance tracks at all, actually, given that our cycles
for the master track have been 8-10 weeks long, which is not a long time
to wait, compared to 5 years people survived without any ;-).
^ permalink raw reply
* Re: [BUG] git-merge-octopus creates an empty merge commit with one parent
From: Junio C Hamano @ 2012-02-13 18:48 UTC (permalink / raw)
To: Michał Kiedrowicz; +Cc: git
In-Reply-To: <1329133736-20817-1-git-send-email-michal.kiedrowicz@gmail.com>
Michał Kiedrowicz <michal.kiedrowicz@gmail.com> writes:
> This happens when git merge is run to merge multiple commits that are
> descendants of current HEAD (or are HEAD).
I am reasonably sure you meant ancestors here.
> to origin/master but accidentaly we called (while being on master):
>
> $ git merge master origin/master
I am very tempted to throw this into "don't do it then" category.
^ permalink raw reply
* Re: [PATCH] gitweb: Silence stderr in parse_commit*() subroutines
From: Junio C Hamano @ 2012-02-13 18:44 UTC (permalink / raw)
To: Jakub Narebski; +Cc: rajesh boyapati, git
In-Reply-To: <201202111402.31684.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Anyway, here is the patch that should fix those "CGI: fatal: Not a valid
> object name HEAD" errors for you.
I have to wonder if it is simpler and less error prone to check HEAD
before doing anything else immediately after which repository is being
consulted, and give the same "no history at all yet in this project" page
for most if not all operations, instead of patching things up at this deep
in the callchain.
^ permalink raw reply
* Re: [PATCH 6/8] gitweb: Highlight interesting parts of diff
From: Jakub Narebski @ 2012-02-13 18:44 UTC (permalink / raw)
To: Michal Kiedrowicz; +Cc: git
In-Reply-To: <20120213074125.3e8793ad@mkiedrowicz.ivo.pl>
On Mon, 13 Feb 2012, Michal Kiedrowicz wrote:
> Jakub Narebski <jnareb@gmail.com> wrote:
>
> > Michał Kiedrowicz <michal.kiedrowicz@gmail.com> writes:
> >
> > > Reading diff output is sometimes very hard, even if it's colored,
> > > especially if lines differ only in few characters. This is often
> > > true when a commit fixes a typo or renames some variables or
> > > functions.
> > >
> > This is certainly nice feature to have. I think most tools that
> > implement side-by-side diff implement this too.
> >
> > > This commit teaches gitweb to highlight characters that are
> > > different between old and new line. This should work in the
> > > similar manner as in Trac or GitHub.
> > >
> > Doe you have URLs with good examples of such diff refinement
> > highlighting (GNU Emacs ediff/emerge terminology) / highlighting
> > differing segments (diff-highlight terminology)?
>
> I haven't found *examples* on GitHub and Trac sites, but what about
> these ones:
>
> https://github.com/gitster/git/commit/8cad4744ee37ebec1d9491a1381ec1771a1ba795
> http://trac.edgewall.org/changeset/10973
Thanks. That is what I meant by "good examples". Perhaps they should
be put in the commit message?
BTW GitHub is closed source, but we can check what algorithm does Trac
use for diff refinement highlighting (highlighting changed portions of
diff).
> > > The code that compares lines is based on
> > > contrib/diff-highlight/diff-highlight, except that it works with
> > > multiline changes too. It also won't highlight lines that are
> > > completely different because that would only make the output
> > > unreadable.
> > >
> > So what does it look like? From the contrib/diff-highlight/README I
> > guess that it finds common prefix and common suffix, and highlights
> > the rest, which includes change.
>
> Yes.
>
> > It doesn't implement LCS / diff
> > algorithm like e.g. tkdiff does for its diff refinement highlighting,
> > isn't it?
>
> I doesn't. I share the Jeff's opinion that:
> a) Jeff's approach is "good enough"
> b) LCS on bytes could be very confusing if it marked few sets of
> characters.
I wonder if we can use --diff-words for diff refinement highlighting,
i.e. LCS on words.
Anyway Jeff's approach is a bit limited, in that it would work only for
change that does not involve adding newlines, for example splitting
overly long line when changing something.
See for example line 1786 (in pre-image) in http://trac.edgewall.org/changeset/10973
> > By completly different you mean that they do not have common prefix or
> > common suffix (at least one of them), isn't it?
BTW. is it "at least one of prefix or suffix are non-empty" or "both prefix
and suffix are non-empty"?
> Yes, but I also don't highlight lines which prefix/suffix consists only
> of whitespace (This is quite common).
O.K., that is quite sensible.
> I would also consider ignoring prefixes/suffixes with punctuation, like:
>
> - * I like you.
> + * Alice had a little lamb.
But this patch doesn't implement this feature yet, isn't it?
Well, here is another idea: do not highlight if sum of prefix and suffix
lengths are less than some threshold, e.g. 2 characters not including
whitespace, or some percentage with respect to total line length.
> > > +# Highlight characters from $prefix to $suffix and escape HTML.
> > > +# $str is a reference to the array of characters.
> > > +sub esc_html_mark_range {
> > > + my ($str, $prefix, $suffix) = @_;
> > > +
> > > + # Don't generate empty <span> element.
> > > + if ($prefix == $suffix + 1) {
> > > + return esc_html(join('', @$str), -nbsp=>1);
> > > + }
> > > +
> > > + my $before = join('', @{$str}[0..($prefix - 1)]);
> > > + my $marked = join('', @{$str}[$prefix..$suffix]);
> > > + my $after = join('', @{$str}[($suffix + 1)..$#{$str}]);
It would be nicer with 'part' from List::MoreUtils... but that module
is unfortunately not in core.
> > Eeeeeek! First you split into letters, in caller at that, then join?
> > Why not pass striung ($str suggests string not array of characters),
> > and use substr instead?
> >
> > [Please disregard this and the next paragraph at first reading]
>
> I will rename $str to something more self describing.
Please do.
BTW. don't you assume here that both common prefix and common suffix
are non-empty?
[...]
> > > +
> > > +# Format removed and added line, mark changed part and HTML-format
> > > them.
> >
> > You should probably add here that this code is taken from
> > diff-highlight in contrib area, isn't it?
>
> True.
And perhaps not the changes from diff-highlight, unless you meant to
send them upstream for inclusion.
> > > +sub format_rem_add_line {
> > > + my ($rem, $add) = @_;
> > > + my @r = split(//, $rem);
> > > + my @a = split(//, $add);
BTW the name of variable can be just @add and @rem.
> > > + my ($esc_rem, $esc_add);
> > > + my ($prefix, $suffix_rem, $suffix_add) = (1, $#r, $#a);
> >
> > It is not as much $prefix, as $prefix_len, isn't it?
>
> Yes.
>
> > Shouldn't
> > $prefix / $prefix_len start from 0, not from 1?
>
> It starts from 1 because it skips first +/-. It should become obvious
> after reading the comment from last patch :).
>
> + # In combined diff we must ignore two +/- characters.
> + $prefix = 2 if ($is_combined);
Anyway comment about that fact would be nice.
> > > + my ($prefix_is_space, $suffix_is_space) = (1, 1);
> > > +
> > > + while ($prefix < @r && $prefix < @a) {
> > > + last if ($r[$prefix] ne $a[$prefix]);
> > > +
> > > + $prefix_is_space = 0 if ($r[$prefix] !~ /\s/);
> > > + $prefix++;
> > > + }
> >
> > Ah, I see that it is easier to find common prefix by treating string
> > as array of characters.
> >
> > Though I wonder if it wouldn't be easier to use trick of XOR-ing two
> > strings (see "Bitwise String Operators" in perlop(1)):
> >
> > my $xor = "$rem" ^ "$add";
> >
> > and finding starting sequence of "\0", which denote common prefix.
> >
> >
> > Though this and the following is a nice implementation of
> > algorithm... as it would be implemented in C. Nevermind, it might be
> > good enough...
>
> The splitting and comparing by characters is taken from diff-highlight.
> I don't think it's worth changing here.
You are right.
I'll try to come with hacky algorithm using string bitwise xor and regexp,
and benchmark it comparing to your C-like solution, but it can be left for
later (simple is better than clever, usually).
> > > + while ($suffix_rem >= $prefix && $suffix_add >= $prefix) {
> > > + last if ($r[$suffix_rem] ne $a[$suffix_add]);
> > > +
> > > + $suffix_is_space = 0 if ($r[$suffix_rem] !~ /\s/);
> > > + $suffix_rem--;
> > > + $suffix_add--;
> > > + }
> >
> > BTW., perhaps using single negative $suffix_len instead of separate
> > $suffix_rem_pos and $suffix_add_pos would make code simpler and easier
> > to understand?
>
> I'll try that.
I think this should just work, and it would be one variable less to
track.
> > > # HTML-format diff context, removed and added lines.
> > > sub format_ctx_rem_add_lines {
> > > - my ($ctx, $rem, $add) = @_;
> > > + my ($ctx, $rem, $add, $is_combined) = @_;
> > > my (@new_ctx, @new_rem, @new_add);
> > > + my $num_add_lines = @$add;
> >
> > Why is this temporary variable needed? If you are not sure that ==
> > operator enforces scalar context on both arguments you can always
> > write
> >
> > scalar @$add == scalar @$rem
>
> You read my mind.
BTW. the same comment applies to patch adding support for highlighting
changed part in combined diff.
> > The original contrib/diff-highlight works only for single changed line
> > (single removed and single added). You make this code work also for
> > the case where number of aded lines is equal to the number of removed
> > lines, and assume that subsequent changed lines in preimage
> > correcponds to subsequent changed lines in postimage, [...]
[...]
> > This is not described in commit message, I think.
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH] builtin/tag.c: Fix a sparse warning
From: Ramsay Jones @ 2012-02-13 18:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: tmgrennan, GIT Mailing-list
In particular, sparse complains as follows:
SP builtin/tag.c
builtin/tag.c:411:5: warning: symbol 'parse_opt_points_at' was \
not declared. Should it be static?
In order to suppress the warning, since the parse_opt_points_at()
function does not need to be an external symbol, we simply add the
static modifier to the function definition.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
---
builtin/tag.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin/tag.c b/builtin/tag.c
index 8cfaaf8..fe7e5e5 100644
--- a/builtin/tag.c
+++ b/builtin/tag.c
@@ -408,7 +408,7 @@ static int strbuf_check_tag_ref(struct strbuf *sb, const char *name)
return check_refname_format(sb->buf, 0);
}
-int parse_opt_points_at(const struct option *opt __attribute__ ((unused)),
+static int parse_opt_points_at(const struct option *opt __attribute__((unused)),
const char *arg, int unset)
{
unsigned char sha1[20];
--
1.7.9
^ permalink raw reply related
* Re: User authentication in GIT
From: supadhyay @ 2012-02-13 18:19 UTC (permalink / raw)
To: git
In-Reply-To: <CAMK1S_g5mk44vhTsFG4-kzMw7jMVvX0VK6pXAY=PFAgOEsccgw@mail.gmail.com>
Thanks for suggesting the link, but would like to know which method is the
most secure and optimal method to use.
For testing purpose we migrate our repositories from CVS2GIT but now having
issue wiht user managment. How to manage it ? We have users for different
repositories and having different access, somewhere I read about using
Gitolite I can mange users but not find the efficent and useful method to
use it.
Thanks .
..
--
View this message in context: http://git.661346.n2.nabble.com/User-authentication-in-GIT-tp7261349p7281349.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH] gitweb: Silence stderr in parse_commit*() subroutines
From: Jakub Narebski @ 2012-02-13 18:15 UTC (permalink / raw)
To: rajesh boyapati; +Cc: git
In-Reply-To: <CA+EqV8xTsavQFWsoijrt+0UcfxSZO2voL=CawrRPvDeB=qHQfg@mail.gmail.com>
On Mon, 13 Feb 2012, rajesh boyapati wrote:
> 2012/2/11 Jakub Narebski <jnareb@gmail.com>
>> On Thu, 9 Feb 2012, Jakub Narebski wrote:
>>> On Wed, 8 Feb 2012, rajesh boyapati wrote:
>>>> 2012/2/8 Jakub Narebski <jnareb@gmail.com>
[...]
>>>> When I applied the above patch and also the patch from your previous
>>>> e-mail, I am getting this error
>>>>>>>>>>>>>>>>>
>>>> [2012-02-08 14:09:58,396] ERROR
>>>> com.google.gerrit.httpd.gitweb.GitWebServlet : CGI: fatal: bad revision
>>>> 'HEAD'
>>>> [2012-02-08 14:10:06,732] ERROR
>>>> com.google.gerrit.httpd.gitweb.GitWebServlet : CGI: fatal: bad revision
>>>> 'HEAD'
>>>> [2012-02-08 14:10:11,404] ERROR
>>>> com.google.gerrit.httpd.gitweb.GitWebServlet : CGI: fatal: bad revision
>>>> 'HEAD'
>>>> [2012-02-08 14:10:15,270] ERROR
>>>> com.google.gerrit.httpd.gitweb.GitWebServlet : CGI: fatal: Not a valid
>>>> object name HEAD
>>>> <<<<<<<<<<<<<<
>>>> With these patches, the previous errors at line numbers are gone.
[...]
>>> This final issue will be a bit harder to fix. This error message
>>>
>>> fatal: bad revision 'HEAD'
>>>
>>> comes from git (I think from "git rev-list" command), and not from gitweb.
>>> It is printed on STDERR of git command. What has to be done to fix it is
>>> to capture stderr of a process, or silence it.
[...]
>> Anyway, here is the patch that should fix those "CGI: fatal: Not a valid
>> object name HEAD" errors for you.
>>
>> I'll resend the all the patches as single patch series for inclusion in
>> git, but I am not sure if this latest patch will be accepted because of
>> drawbacks of its implementation.
>>
>> -->8 ---- ----- ----- ----->8 --
>> From: Jakub Narebski <jnareb@gmail.com>
>> Subject: [PATCH] gitweb: Silence stderr in parse_commit*() subroutines
[...]
>> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
>> index 1181aeb..081ac45 100755
>> --- a/gitweb/gitweb.perl
>> +++ b/gitweb/gitweb.perl
>> @@ -3338,12 +3338,13 @@ sub parse_commit {
>>
>> local $/ = "\0";
>>
>> - open my $fd, "-|", git_cmd(), "rev-list",
>> + open my $fd, "-|", quote_command(
>> + git_cmd(), "rev-list",
>> "--parents",
>> "--header",
>> "--max-count=1",
>> $commit_id,
>> - "--",
>> + "--") . ' 2>/dev/null',
>> or die_error(500, "Open git-rev-list failed");
>> my $commit_text = <$fd>;
>> %co = parse_commit_text($commit_text, 1)
>> @@ -3363,7 +3364,8 @@ sub parse_commits {
>>
>> local $/ = "\0";
>>
>> - open my $fd, "-|", git_cmd(), "rev-list",
>> + open my $fd, "-|", quote_command(
>> + git_cmd(), "rev-list",
>> "--header",
>> @args,
>> ("--max-count=" . $maxcount),
>> @@ -3371,7 +3373,7 @@ sub parse_commits {
>> @extra_options,
>> $commit_id,
>> "--",
>> - ($filename ? ($filename) : ())
>> + ($filename ? ($filename) : ())) . ' 2>/dev/null'
>> or die_error(500, "Open git-rev-list failed");
>> while (my $line = <$fd>) {
>> my %co = parse_commit_text($line);
>>
>
> I am getting this error with this patch
>>>>>>>>>>>>>>>>>>>
> [2012-02-13 11:20:19,268] ERROR
> com.google.gerrit.httpd.gitweb.GitWebServlet : CGI: usage: git rev-list
> [OPTION] <commit-id>... [ -- paths... ]
> [2012-02-13 11:20:19,268] ERROR
> com.google.gerrit.httpd.gitweb.GitWebServlet : CGI: limiting output:
> [2012-02-13 11:20:19,268] ERROR
> com.google.gerrit.httpd.gitweb.GitWebServlet : CGI: --max-count=nr
[...]
> [2012-02-13 11:20:27,913] ERROR
> com.google.gerrit.httpd.gitweb.GitWebServlet : CGI: fatal: bad flag '--2'
> used after filename
> [2012-02-13 11:20:32,579] ERROR
> com.google.gerrit.httpd.gitweb.GitWebServlet : CGI: fatal: bad flag '--2'
> used after filename
> <<<<<<<<<<<<<<<<<<<
Strange, I cannot reproduce this with non-Gerrit gitweb. It looks
like it somehow lost in between "... -- 2>/dev/null" at the end of
git-rev-list command, and fails at "--2" which is bad flag.
Are you sure you applied the patch correctly? Does 'object' view
(take any 'commit' or 'blob' or 'tree' view, and replace action part
by 'object') works correctly in Gerrit's gitweb?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCHv2 1/4] refs: add common refname_match_patterns()
From: Tom Grennan @ 2012-02-13 17:27 UTC (permalink / raw)
To: Michael Haggerty; +Cc: pclouds, git, gitster, jasampler
In-Reply-To: <4F3898F8.2000201@alum.mit.edu>
On Mon, Feb 13, 2012 at 06:00:40AM +0100, Michael Haggerty wrote:
>On 02/11/2012 08:17 PM, Tom Grennan wrote:
>> Yes, I didn't explicitly state that the precedence is the order written
>> and in correctly described the first case. How about?
>>
>> /**
>> * Returns in highest to lowest precedence:
>> * 1 with an empty patterns list
>> * 0 if refname fnmatch()es any ^ prefaced pattern
>> * 1 if refname fnmatch()es any other pattern
>> * 0 otherwise
>> */
>
>Much better; thanks.
>
>Please note that this choice of semantics limits its power. For
>example, if the rule were instead (like with gitattributes(5)) "if more
>than one pattern matches a refname, a later pattern overrides an earlier
>pattern", then one could do things like
>
> refs/remotes/*/* !refs/remotes/gitster/* refs/remotes/gitster/master
>
>to include specific references within a hierarchy that is otherwise
>excluded.
>
>However, since rev-list apparently uses a rule more like the one that
>you are proposing, it might be better to be consistent than to choose a
>different convention.
Hmm, I think it's important to have same respective result in each of
these case's,
$ git tag -l | grep v1.7.8.*
$ git tag -l v1.7.8*
$ git tag -l | grep -v .*-rc*
$ git tag -l ^*-rc*
$ git tag -l v1.7.8* | grep -v .*-rc*
$ git tag -l v1.7.8* ^*-rc*
$ git tag -l ^*-rc* v1.7.8*
What I propose is somewhat analogous to gitignore's double negative,
* An optional prefix ! which negates the pattern; any matching
file excluded by a previous pattern will become included again. If
a negated pattern matches, this will override lower precedence
patterns sources.
I still prefer "^" to "!" b/c A) it doesn't cause the noted regressions;
and B) doesn't need command quoting. I'd accept the counter proposals
of --exclude or --with[out][-TYPE] but frankly, that's more
code/documentation churn ("less code is always better"[TM]) and worse,
more crap to type on the command line:
$ git --with-tags v1.7.8* --without-tags '*-rc*' tag -l v1.7.8*
or
$ git tag -l --exclude '*-rc*' v1.7.8*
vs.
$ git tag -l v1.7.8* ^*-rc*
--
TomG
^ permalink raw reply
* [PATCH] completion: --no-abbrev-commit for git-log and git-show
From: Michael Schubert @ 2012-02-13 16:57 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Signed-off-by: Michael Schubert <mschub@elegosoft.com>
---
contrib/completion/git-completion.bash | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index d7367e9..22d7018 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1587,7 +1587,7 @@ _git_log ()
$__git_log_gitk_options
--root --topo-order --date-order --reverse
--follow --full-diff
- --abbrev-commit --abbrev=
+ --abbrev-commit --no-abbrev-commit --abbrev=
--relative-date --date=
--pretty= --format= --oneline
--cherry-pick
@@ -2384,7 +2384,7 @@ _git_show ()
return
;;
--*)
- __gitcomp "--pretty= --format= --abbrev-commit --oneline
+ __gitcomp "--pretty= --format= --abbrev-commit --no-abbrev-commit --online
$__git_diff_common_options
"
return
--
1.7.9.324.g3d1db
^ permalink raw reply related
* Re: git status: small difference between stating whole repository and small subdirectory
From: Piotr Krukowiecki @ 2012-02-13 16:54 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Git Mailing List
In-Reply-To: <CACsJy8C05wvQRRQJLxrxYKHjXsgh6RugFexkPUKYGxbQkqiXJA@mail.gmail.com>
On Fri, Feb 10, 2012 at 3:37 PM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> I think the cost is in $GIT_DIR, not the working directory.
Could you explain?
I got the problem again today. This time I've made a copy of the
repository so hopefully I'll able to reproduce the problems.
This time it's a different repository but the 'status' on a small
subdirectory is even more than 2x slower than on the whole repository.
Whole repo:
$ find * -type f | wc -l
33021
$ du -shc * | grep total
2.1G total
The subdir:
$ find * -type f | wc -l
17
$ du -shc * | grep total
84K total
As previously, timing was done with cold cache (echo 3 | sudo tee
/proc/sys/vm/drop_caches) and executed several times.
This time I have used recent git (1.7.9.188.g12766) compiled with -pg.
git was executed in the subdirectory. Tracked files were not
changed/deleted, there was just a couple of small untracked files.
Timings:
$ time git status
real 0m16.595s
user 0m0.680s
sys 0m0.616s
$ time git status -- .
real 0m10.030s
user 0m0.464s
sys 0m0.184s
You can find gprof output here:
http://pastebin.com/mhddDUmv - from whole repo status
http://pastebin.com/1LdVn77A - from subdir status
--
Piotr Krukowiecki
^ permalink raw reply
* Setting up a Git server (+ gitweb) with .htaccess files HOWTO
From: Matthieu Moy @ 2012-02-13 16:34 UTC (permalink / raw)
To: git
Hi,
I've set up a Git server on a machine on which I have a webspace,
permission to run CGI scripts, but no shell or root access. Good news:
it worked :-).
I've documented the process here in case anyone's interested:
http://www-verimag.imag.fr/~moy/?Host-a-Git-repository-over-HTTP-S
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCHv2 1/4] refs: add common refname_match_patterns()
From: Tom Grennan @ 2012-02-13 16:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: pclouds, git, jasampler
In-Reply-To: <7vzkcpkkbd.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 884 bytes --]
On Sat, Feb 11, 2012 at 03:43:34PM -0800, Junio C Hamano wrote:
>Tom Grennan <tmgrennan@gmail.com> writes:
>
>> Yes, I should have stated that this emphasized containment over
>> efficiency. If instead we stipulate that the caller must list exclusion
>> patterns before others, this could simply be:
>
>No.
>
>You have to pre-parse and rearrange the pattern[] list *only once* before
>matching them against dozens of refs, so instead of forcing the callers do
>anything funky, you give a function that gets a pattern[] list and returns
>something that can be efficiently used by the match_pattern() function,
>and have the caller pass that thing, not the original pattern[] list, to
>the match_pattern() function.
Hmm, I'm not communicating very well; this is exactly what I meant by,
>> Of course I'd add a with_exclusions_first() before the
>> respective ref iterator.
--
TomG
[-- Attachment #2: Type: message/rfc822, Size: 2830 bytes --]
From: Tom Grennan <tmgrennan@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: pclouds@gmail.com, git@vger.kernel.org, jasampler@gmail.com
Subject: Re: [PATCHv2 1/4] refs: add common refname_match_patterns()
Date: Sat, 11 Feb 2012 11:37:42 -0800
Message-ID: <20120211193742.GD4903@tgrennan-laptop>
On Sat, Feb 11, 2012 at 12:06:56AM -0800, Junio C Hamano wrote:
>Tom Grennan <tmgrennan@gmail.com> writes:
>
>> +int refname_match_patterns(const char **patterns, const char *refname)
>> +{
>> + int given_match_pattern = 0, had_match = 0;
>> +
>> + for (; *patterns; patterns++)
>> + if (**patterns != '!') {
>> + given_match_pattern = 1;
>> + if (!fnmatch(*patterns, refname, 0))
>> + had_match = 1;
>> + } else if (!fnmatch(*patterns+1, refname, 0))
>> + return 0;
>> + return given_match_pattern ? had_match : 1;
>> +}
>
>This, while its semantics seem sane, is highly inefficient when you have
>many patterns, and you will be calling this to filter dozens of refs. And
>it can trivially improved by first pre-parsing the pattern[] array.
>
> * If you know the patterns do not have any negative entry, you can return
> true upon seeing the first match. Because you do not pre-parse the
> pattern[] array, this loop does not know if there is any negative one,
> and has to scan it always all the way.
>
> * If you arrange the pattern[] array so that it has negative ones early,
> again, you can return false upon seeing the first hit with a negative
> one. If your input has negative ones at the end, the loop ends up
> scanning all the way, noting the positive matches, only to discard upon
> seeing the negative match at the end.
>
>That is why I said Nguyen's idea of reusing pathspec matching logic
>somewhat attractive, even though I think it has downsides (the exact
>matching logic for pathspec is more similar to that of for-each-ref
>and very different from branch/tag).
Yes, I should have stated that this emphasized containment over
efficiency. If instead we stipulate that the caller must list exclusion
patterns before others, this could simply be:
int match_pattern(const char **patterns, const char *refname)
{
if (*patterns)
return 1;
for (; *patterns && **patterns == '!'; patterns++)
if (!fnmatch(*patterns+1, refname, 0))
return 0;
for (; *patterns; patterns++)
if (!fnmatch(*patterns, refname, 0))
return 1;
return 0;
}
Of course I'd add a with_exclusions_first() before the
respective ref iterator.
--
TomG
^ permalink raw reply
* Re: Bulgarian translation of git
From: Jonathan Nieder @ 2012-02-13 15:56 UTC (permalink / raw)
To: Jiang Xin
Cc: Git List, Ævar Arnfjörð,
Alexander Shopov (Александър Шопов),
Junio C Hamano
In-Reply-To: <CANYiYbHkbUvL-d4M0iOyE5F-6rM=swk_knGEFTr9HGBK6T9UDg@mail.gmail.com>
Jiang Xin wrote:
> 2012/2/13 Jonathan Nieder <jrnieder@gmail.com>:
>> I wonder if there's a simple to ask the gettext tools to make a po
>> template including strings from both 'maint' and 'master'. (Hackish way
>> demonstrated below.)
>>
>> Hopefully that would make it easier for translators to keep both
>> tracks well maintained at the same time.
[...]
>> What do you think?
>
> Translators on a new language may not like this. Translating the obsolete
> messages in pot file is boring and waste of time.
Right, doing this for real require somehow removing stale messages,
too, so the pot file would only contain messages from actively
maintained releases (the tip of 'master' and 'maint').
Will experiment privately a little more.
^ permalink raw reply
* Re: Bulgarian translation of git
From: Jiang Xin @ 2012-02-13 15:43 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Git List, Ævar Arnfjörð,
Alexander Shopov (Александър Шопов),
Junio C Hamano
In-Reply-To: <20120213133957.GA4838@burratino>
2012/2/13 Jonathan Nieder <jrnieder@gmail.com>:
> I wonder if there's a simple to ask the gettext tools to make a po
> template including strings from both 'maint' and 'master'. (Hackish way
> demonstrated below.)
>
> Hopefully that would make it easier for translators to keep both
> tracks well maintained at the same time. If a problem in the
> translation of a string shared by 'master' and 'maint' is only noticed
> while working on 'master', there would be no need to go through the
> "switch branches; make the change; switch back; merge" dance.
>
> What do you think?
Translators on a new language may not like this. Translating the obsolete
messages in pot file is boring and waste of time.
> po/git.pot: $(LOCALIZED_C)
> - $(QUIET_XGETTEXT)$(XGETTEXT) -o$@+ $(XGETTEXT_FLAGS_C) $(LOCALIZED_C)
> + cp $@ $@+
Failed if po/git.pot does not exist. touch one first?
> + $(QUIET_XGETTEXT)$(XGETTEXT) -o$@+ --join-existing $(XGETTEXT_FLAGS_C) $(LOCALIZED_C)
> $(QUIET_XGETTEXT)$(XGETTEXT) -o$@+ --join-existing $(XGETTEXT_FLAGS_SH) \
> $(LOCALIZED_SH)
> mv $@+ $@
--
Jiang Xin
^ permalink raw reply
* git cherry doesn't list a merge commit
From: Tajti Ákos @ 2012-02-13 15:17 UTC (permalink / raw)
To: git
Dear List,
I have a question/misunderstanding about 'git cherry'. The scenario is
the following:
I have two repositories (two forks of the same parent repo): A and B. I
created a commit in A, then pulled B to A and finally made an other
commit in A. This resulted the following commits:
-----
commit f6afabb0a734843d5d122b612f0701d27b178e42
Author: akostajti <akos.tajti@intland.com>
Date: Mon Feb 13 15:59:51 2012 +0100
modified a
commit 4ec4d59f632b93456890db139125419d16a10807
Merge: a73e884 2a483e8
Author: akostajti <akos.tajti@intland.com>
Date: Mon Feb 13 15:59:34 2012 +0100
Merge branch 'master' of http://localhost:3180/git/first-60-project
commit a73e884d2dadf29898c2d6b665ed79d352422d26
Author: akostajti <akos.tajti@intland.com>
Date: Mon Feb 13 15:58:48 2012 +0100
hkl
-----
Now If I fetch B to A and run 'git cherry FETCH_HEAD master' I get only
two changeset ids:
+ a73e884d2dadf29898c2d6b665ed79d352422d26
+ f6afabb0a734843d5d122b612f0701d27b178e42
However, the manual of git cherry says:
"*Every* commit that doesn’t exist in the <upstream> branch has its id
(sha1) reported, prefixed by a symbol. The ones that have equivalent
change already in the <upstream> branch are prefixed with a minus (-) sign"
In my understanding this means that the merge commit
(4ec4d59f632b93456890db139125419d16a10807) should be also listed by
cherry, because it doesn't exist in the upstream. Am I doing something
wrong? How can I ge git cherry work as I expect?
Thanks in advance,
Ákos Tajti
^ permalink raw reply
* Re: Git documentation at kernel.org
From: Konstantin Ryabitsev @ 2012-02-13 15:15 UTC (permalink / raw)
To: Jeff King
Cc: Matthieu Moy, Junio C Hamano, Clemens Buchacher, ftpadmin,
Petr Onderka, git
In-Reply-To: <20120212222508.GA25619@sigill.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 564 bytes --]
On Sun, 2012-02-12 at 17:25 -0500, Jeff King wrote:
> As far as historical reasons, perhaps the right answer is to put the
> documentation where it makes sense to go _now_, and ask kernel.org to
> issue http redirects for http://kernel.org/pub/software/scm/git/docs.
I think that should be fine, unless John objects. The easiest would be
to preserve the same directory structure, so we do a dir-level redirect
instead of creating one-off redirects for each page.
Best,
--
Konstantin Ryabitsev
Systems Administrator, Kernel.org
Montréal, Québec
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 665 bytes --]
^ permalink raw reply
* Re: [RFC/PATCH] tag: make list exclude !<pattern>
From: Michael Haggerty @ 2012-02-13 14:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Tom Grennan, pclouds, git, krh, jasampler
In-Reply-To: <7v4nuvghfk.fsf@alter.siamese.dyndns.org>
On 02/13/2012 11:23 AM, Junio C Hamano wrote:
> Michael Haggerty <mhagger@alum.mit.edu> writes:
>
>> On 02/13/2012 07:37 AM, Junio C Hamano wrote:
>>> Michael Haggerty <mhagger@alum.mit.edu> writes:
>>>
>>>> Of *course* they operate on different namespaces. But part of the way
>>>> that revisions are selected using rev-list is by *selecting or excluding
>>>> refnames* from which it should crawl.
>>>
>>> I am appalled if that is truly the understanding of yours, after having
>>> taken more than a few patches from you to fairly core parts of Git.
>>>
>>> "rev-list A ^B" does not say "include A and exclude B from which rev-list
>>> should crawl" AT ALL. We _actively_ crawl from both A and B. It is that
>>> what are reachable from B is painted in a color different from the color
>>> in which we paint what are reachable from A.
>>
>> Please read my emails more carefully before insulting me.
>> ...
>> o---o---o---* A
>> \ \
>> \ o---o C
>> \
>> *---* B
>>
>> ... vs ...
>>
>> *---*---*---* A
>> \ \
>> \ o---o C
>> \
>> *---* B
>>
>> I argue that this is a useful selection.
>
> Then why were you so against the addition of "negation" to for-each-ref?
I'm not against it. I just think it should be spelled differently.
> If you want "I want histories reaching A and B", just say "rev-list A B",
> without adding useless "er, I do not want histories reaching C in the
> output, but I do not want commits reachable from C to be excluded from the
> output either" by mentioning C. Learn to shut your mouth and not talk
> about irrelevant "C" in such a case, and you will do just fine.
That's fine if we're talking about single references. But it does not
generalize to patterns, like my example
gitk --with-branch='refs/heads/*' \
--with-branch='remotes/gitster/*' \
--without-branch='remotes/gitster/*/**' \
--with-branch='remotes/gitster/mh/*'
If these options were supported, I could store this set of arguments as
a "view" in gitk and have it load automatically. It would continue to
work even as you add and delete branches from your repository. Listing
the branches explicitly would be fragile. Currently I would have to
write a script wrapper around gitk that invokes multiple git commands
and filters the results using grep or something. (At least I don't know
a better way.) Even if for-each-ref were taught to exclude branches, I
don't believe it is possible to use arbitrary shell commands to build a
gitk view.
> Especially, re-read your first message where you said that between
>
> git rev-list A B ^C
>
> and
>
> git rev-list $(git for-each-ref A B ^C)
>
> "consistency suggests should do the same".
I should have connected the dots better: consistency suggests they
should do the same, but they obviously cannot. Moreover, it would be
nice if the two types of exclusion could be combined in single commands,
in which case consistency is mandatory. Therefore, let's spell the
for-each-ref option another way that *can* be made consistent across
commands.
> Having said all that, if your argument against using "^" as negation for
> for-each-ref *were* with something like this from the beginning:
>
> git rev-list --all --exclude-refs=refs/tags/v\*
>
> it would have been very different. I would wholeheartedly buy the
> consistency argument that says
>
> git for-each-ref --exclude-refs=refs/tags/v\*
>
> ought to give all refs (only because for-each-ref "all" is implied) except
> for the tagged tips, and
>
> git log --all --exclude-refs=refs/tags/v\*
>
> should be the notation to produce consistently the same result as
>
> git log $(git for-each-ref --format='%(objectname)' --exclude-refs=refs/tags/v\*)
>
> but if we used "^" as negated match in for-each-ref argument, we would
> close the door to give such consistency to log family of commands later.
That *has* been exactly my argument from the beginning [1]. I
cautiously hope that we are now talking about the same thing, even if it
is not yet clear whether we agree on a conclusion.
I think this would be an interesting project, but I won't have time to
work on it in the near future. My first priority is to get the
hierarchical-refs patches rebased on top of the removal of extra refs
and do some more rationalization in that area.
Michael
[1] I don't see where anything I've written is inconsistent with your
phrasing of the argument. But fine, let's just be happy that the
miscommunication now seems to be cleared up.
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: User authentication in GIT
From: Sitaram Chamarty @ 2012-02-13 14:32 UTC (permalink / raw)
To: supadhyay; +Cc: git
In-Reply-To: <1329137674044-7280277.post@n2.nabble.com>
On Mon, Feb 13, 2012 at 6:24 PM, supadhyay <supadhyay@imany.com> wrote:
> Thanks Sitaram for your reply and guidance.
>
> From your document I can see there are three different method to install
> gitolite. May I know all methods advantage and disadvantage?
see first para after the 4 bullets in
http://sitaramc.github.com/gitolite/install.html#install_installing_and_upgrading_gitolite_
^ permalink raw reply
* Re: Bulgarian translation of git
From: Jonathan Nieder @ 2012-02-13 14:00 UTC (permalink / raw)
To: Jiang Xin
Cc: Git List, Ævar Arnfjörð Bjarmason,
Alexander Shopov (Александър Шопов),
Junio C Hamano
In-Reply-To: <7vy5s7idxb.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Jiang Xin <worldhello.net@gmail.com> writes:
>> I have a question, which version of po should be maintained? master
>> branch or maint branch.
>
> I would say for this round the git-po repository and its pot file should
> pick up whatever new translatable strings are added to 'master'.
>
> After this is merged in 1.7.10, we may want to maintain separate tracks,
> but at this moment there is no point maintaining something mergeable to
> 1.7.9.x maintenance track.
I wonder if there's a simple to ask the gettext tools to make a po
template including strings from both 'maint' and 'master'. (Hackish way
demonstrated below.)
Hopefully that would make it easier for translators to keep both
tracks well maintained at the same time. If a problem in the
translation of a string shared by 'master' and 'maint' is only noticed
while working on 'master', there would be no need to go through the
"switch branches; make the change; switch back; merge" dance.
What do you think?
Jonathan
diff --git i/Makefile w/Makefile
index 1e91b19c..5dbc6205 100644
--- i/Makefile
+++ w/Makefile
@@ -2103,7 +2103,8 @@ LOCALIZED_C := $(C_OBJ:o=c)
LOCALIZED_SH := $(SCRIPT_SH)
po/git.pot: $(LOCALIZED_C)
- $(QUIET_XGETTEXT)$(XGETTEXT) -o$@+ $(XGETTEXT_FLAGS_C) $(LOCALIZED_C)
+ cp $@ $@+
+ $(QUIET_XGETTEXT)$(XGETTEXT) -o$@+ --join-existing $(XGETTEXT_FLAGS_C) $(LOCALIZED_C)
$(QUIET_XGETTEXT)$(XGETTEXT) -o$@+ --join-existing $(XGETTEXT_FLAGS_SH) \
$(LOCALIZED_SH)
mv $@+ $@
^ permalink raw reply related
* Re: User authentication in GIT
From: supadhyay @ 2012-02-13 12:54 UTC (permalink / raw)
To: git
In-Reply-To: <CAMK1S_gOhaX4SaUZk8RrByDa_HPuMLDs=T2M2djXDhvESJu1Vg@mail.gmail.com>
Thanks Sitaram for your reply and guidance.
>From your document I can see there are three different method to install
gitolite. May I know all methods advantage and disadvantage?
Thanks,
Suchi
--
View this message in context: http://git.661346.n2.nabble.com/User-authentication-in-GIT-tp7261349p7280277.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* [BUG] git-merge-octopus creates an empty merge commit with one parent
From: Michał Kiedrowicz @ 2012-02-13 11:48 UTC (permalink / raw)
To: git; +Cc: Michał Kiedrowicz
This happens when git merge is run to merge multiple commits that are
descendants of current HEAD (or are HEAD). We've hit this while updating master
to origin/master but accidentaly we called (while being on master):
$ git merge master origin/master
Here is a minimal testcase:
$ git init a
$ cd a
$ echo a>a
$ git commit -minitial
$ echo b>a
$ git add a
$ git commit -msecond
$ git checkout master^
$ git merge master master
Fast-forwarding to: master
Already up-to-date with master
Merge made by the 'octopus' strategy.
a | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
$ git cat-file commit HEAD
tree eebfed94e75e7760540d1485c740902590a00332
parent bd679e85202280b263e20a57639a142fa14c2c64
author Michał Kiedrowicz <michal.kiedrowicz@gmail.com> 1329132996 +0100
committer Michał Kiedrowicz <michal.kiedrowicz@gmail.com> 1329132996 +0100
Merge branches 'master' and 'master' into HEAD
... and below is a patch that adds a testcase to Git's testsuite.
I would expect `git merge master master` to just 'Fast forward'.
Signed-off-by: Michał Kiedrowicz <michal.kiedrowicz@gmail.com>
---
t/t6028-merge-up-to-date.sh | 17 ++++++++++++++++-
1 files changed, 16 insertions(+), 1 deletions(-)
diff --git a/t/t6028-merge-up-to-date.sh b/t/t6028-merge-up-to-date.sh
index a91644e..824fca5 100755
--- a/t/t6028-merge-up-to-date.sh
+++ b/t/t6028-merge-up-to-date.sh
@@ -16,7 +16,12 @@ test_expect_success setup '
test_tick &&
git commit -m second &&
git tag c1 &&
- git branch test
+ git branch test &&
+ echo third >file &&
+ git add file &&
+ test_tick &&
+ git commit -m third &&
+ git tag c2
'
test_expect_success 'merge -s recursive up-to-date' '
@@ -74,4 +79,14 @@ test_expect_success 'merge -s subtree up-to-date' '
'
+test_expect_failure 'merge fast-forward octopus' '
+
+ git reset --hard c0 &&
+ test_tick &&
+ git merge c1 c2
+ expect=$(git rev-parse c2) &&
+ current=$(git rev-parse HEAD) &&
+ test "$expect" = "$current"
+'
+
test_done
--
1.7.9.rc2.155.g2e96
^ permalink raw reply related
* Re: [PATCH] Remove Git's support for smoke testing
From: Junio C Hamano @ 2012-02-13 10:32 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason; +Cc: git
In-Reply-To: <CACBZZX7pDYFqSUjqDjjEFZBaTsoN9oa9vy5Cq4CckP2nZSSRyw@mail.gmail.com>
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> On Fri, Dec 23, 2011 at 18:08, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
>> I'm no longer running the Git smoke testing service at
>> smoke.git.nix.is due to Smolder being a fragile piece of software not
>> having time to follow through on making it easy for third parties to
>> run and submit their own smoke tests.
>
> Junio, could you please apply this? The current release's t/README
> file is pointing to a service I'm not running anymore.
Will apply these three directly to maint (they all look sane, safe and do
not add any new features).
[PATCH] Makefile: Change the default compiler from "gcc" to "cc"
[PATCH] Remove Git's support for smoke testing
[PATCH] t: use sane_unset instead of unset
Thanks.
^ permalink raw reply
* Re: [RFC/PATCH] tag: make list exclude !<pattern>
From: Junio C Hamano @ 2012-02-13 10:23 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Tom Grennan, pclouds, git, krh, jasampler
In-Reply-To: <4F38D9D4.5000203@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
> On 02/13/2012 07:37 AM, Junio C Hamano wrote:
>> Michael Haggerty <mhagger@alum.mit.edu> writes:
>>
>>> Of *course* they operate on different namespaces. But part of the way
>>> that revisions are selected using rev-list is by *selecting or excluding
>>> refnames* from which it should crawl.
>>
>> I am appalled if that is truly the understanding of yours, after having
>> taken more than a few patches from you to fairly core parts of Git.
>>
>> "rev-list A ^B" does not say "include A and exclude B from which rev-list
>> should crawl" AT ALL. We _actively_ crawl from both A and B. It is that
>> what are reachable from B is painted in a color different from the color
>> in which we paint what are reachable from A.
>
> Please read my emails more carefully before insulting me.
> ...
> o---o---o---* A
> \ \
> \ o---o C
> \
> *---* B
>
> ... vs ...
>
> *---*---*---* A
> \ \
> \ o---o C
> \
> *---* B
>
> I argue that this is a useful selection.
Then why were you so against the addition of "negation" to for-each-ref?
If you want "I want histories reaching A and B", just say "rev-list A B",
without adding useless "er, I do not want histories reaching C in the
output, but I do not want commits reachable from C to be excluded from the
output either" by mentioning C. Learn to shut your mouth and not talk
about irrelevant "C" in such a case, and you will do just fine.
Especially, re-read your first message where you said that between
git rev-list A B ^C
and
git rev-list $(git for-each-ref A B ^C)
"consistency suggests should do the same". Should the consistency also
suggest that
git rev-list $(git rev-parse A B ^C)
do the same? That is a total bullshit that can only come from somebody
who does not understand the distinction between pattern matching in
refnames vs set operation over commit DAG.
Having said all that, if your argument against using "^" as negation for
for-each-ref *were* with something like this from the beginning:
git rev-list --all --exclude-refs=refs/tags/v\*
it would have been very different. I would wholeheartedly buy the
consistency argument that says
git for-each-ref --exclude-refs=refs/tags/v\*
ought to give all refs (only because for-each-ref "all" is implied) except
for the tagged tips, and
git log --all --exclude-refs=refs/tags/v\*
should be the notation to produce consistently the same result as
git log $(git for-each-ref --format='%(objectname)' --exclude-refs=refs/tags/v\*)
but if we used "^" as negated match in for-each-ref argument, we would
close the door to give such consistency to log family of commands later.
But that wasn't what you said. Why should I get accused of not guessing
what you meant to say but you clearly didn't, and in addition blamed for
insulting merely for pointing out the idiocy in what you said?
No. *YOU* go back and re-read your message more carefully.
^ 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