* Re: Getting started contributing.
From: Junio C Hamano @ 2013-02-03 19:46 UTC (permalink / raw)
To: Duy Nguyen; +Cc: adamfraser, git
In-Reply-To: <CACsJy8AYOAwLKufQ34brk1agyFAX9xjgAE9_LAcRx=RGxcEZzg@mail.gmail.com>
Duy Nguyen <pclouds@gmail.com> writes:
> On Sun, Feb 3, 2013 at 2:49 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> On the other hand, there probably still are many loose ends.
>
> A few other things
>
> - Mark more strings for translation (not as easy as it sounds, some
> strings can't be translated)
True, but not a good advice for somebody new, exactly for the reason
you stated, i.e. some strings must not be translated.
> - Color more in the output where it makes sense
Eeek.
> - Stop/Warn the user from updating HEAD (e.g. checkout another
> branch) while in the middle of a rebase (some makes sense, most is by
> mistake)
Perhaps, but again probably not for somebody new who hasn't mastered
various workflows and understood why it may make sense to allow it.
^ permalink raw reply
* Re: What's cooking in git.git (Feb 2013, #01; Fri, 1)
From: Junio C Hamano @ 2013-02-03 19:43 UTC (permalink / raw)
To: John Keeping; +Cc: David Aguilar, git
In-Reply-To: <20130203130237.GS1342@serenity.lan>
John Keeping <john@keeping.me.uk> writes:
> On Sun, Feb 03, 2013 at 04:13:22AM -0800, David Aguilar wrote:
>> It looks good to go. The additional "|| :" in the makefile is a nice
>> touchup that made it more robust too.
>
> Looks good to me as well.
Thanks, both.
^ permalink raw reply
* Re: [PATCH] git-send-email: add ~/.authinfo parsing
From: Jeff King @ 2013-02-03 19:41 UTC (permalink / raw)
To: git
In-Reply-To: <87k3qrx712.fsf@lifelogs.com>
On Sat, Feb 02, 2013 at 06:57:29AM -0500, Ted Zlatanov wrote:
> I wrote a Perl credential helper for netrc parsing which is pretty
> robust, has built-in docs with -h, and doesn't depend on external
> modules. The netrc parser regex was stolen from Net::Netrc.
>
> It will by default use ~/.authinfo.gpg, ~/.netrc.gpg, ~/.authinfo, and
> ~/.netrc (whichever is found first) and this can be overridden with -f.
Cool, thanks for working on this.
> If the file name ends with ".gpg", it will run "gpg --decrypt FILE" and
> use the output. So non-interactively, that could hang if GPG was
> waiting for input. Does Git handle that, or should I check for a TTY?
No, git does not do anything special with respect to credential helpers
and ttys (nor should it, since one use of helpers is to get credentials
when there is no tty). I think it is GPG's problem to deal with, though.
We will invoke it, and it is up to it to decide whether it can acquire
the passphrase or not (either through the tty, or possibly from
gpg-agent). So it would be wrong to do the tty check yourself.
I haven't tested GPG, but I assume it properly tries to read from
/dev/tty and not stdin. Your helper's stdio is connected to git and
speaking the credential-helper protocol, so GPG reading from stdin would
either steal your input (if run before you read it), or just get EOF (if
you have read all of the pipe content already). If GPG isn't well
behaved, it may be worth redirecting its stdin from /dev/null as a
safety measure.
> Take a look at the proposed patch and let me know if it's usable, if you
> need a formal copyright assignment, etc.
Overall looks sane to me, though my knowledge of .netrc is not
especially good. Usually we try to send patches inline in the email
(i.e., as generated by git-format-patch), and include a "Signed-off-by"
line indicating that content is released to the project; see
Documentation/SubmittingPatches.
> +use Data::Dumper;
I don't see it used here. Leftover from debugging?
> + print <<EOHIPPUS;
Cute, I haven't seen that one before.
> +$0 [-f AUTHFILE] [-d] get
> +
> +Version $VERSION by tzz\@lifelogs.com. License: any use is OK.
I don't know if we have a particular policy for items in contrib/, but
this license may be too vague. In particular, it does not explicitly
allow redistribution, which would make Junio shipping a release with it
a copyright violation.
Any objection to just putting it under some well-known simple license
(GPL, BSD, or whatever)?
> +if ($file =~ m/\.gpg$/)
> +{
> + $file = "gpg --decrypt $file|";
> +}
Does this need to quote $file, since the result will get passed to the
shell? It might be easier to just use the list form of open(), like:
my @data = $file =~ /\.gpg$/ ?
load('-|', qw(gpg --decrypt), $file) :
load('<', $file);
(and then obviously update load to just dump all of @_ to open()).
> +die "Sorry, we could not load data from [$file]"
> + unless (scalar @data);
Probably not that interesting a corner case, but this means we die on an
empty .netrc, whereas it might be more sensible for it to behave as "no
match".
For the same reason, it might be worth silently exiting when we don't
find a .netrc (or any of its variants). That lets people who share their
dot-files across machines configure git globally, even if they don't
necessarily have a netrc on every machine.
> +# the query
> +my %q;
> +
> +foreach my $v (values %{$options{tmap}})
> +{
> + undef $q{$v};
> +}
Just my personal style, but I find the intent more obvious with "map" (I
know some people find it unreadable, though):
my %q = map { $_ => undef } values(%{$options{tmap}});
> +while (<STDIN>)
> +{
> + next unless m/([a-z]+)=(.+)/;
We don't currently have any exotic tokens that this would not match, nor
do I plan to add them, but the credential documentation defines a valid
line as /^([^=]+)=(.+)/.
It's also possible for the value to be empty, but I do not think
off-hand that current git will ever send such an empty value.
> [...]
The rest of it looks fine to me. I don't think any of my comments are
show-stoppers. Tests would be nice, but integrating contrib/ stuff with
the test harness is kind of a pain.
-Peff
^ permalink raw reply
* Re: [PATCH 1/3] fix clang -Wtautological-compare with unsigned enum
From: Jonathan Nieder @ 2013-02-03 19:38 UTC (permalink / raw)
To: John Keeping; +Cc: git, Antoine Pelisse
In-Reply-To: <a9fe675ed9b34d3c15f4678ee13e90cddaa36055.1359901732.git.john@keeping.me.uk>
John Keeping wrote:
> From: Antoine Pelisse <apelisse@gmail.com>
>
> Create a GREP_HEADER_FIELD_MIN so we can check that the field value is
> sane and silent the clang warning.
Thanks. Looks good to me.
[...]
> --- a/grep.c
> +++ b/grep.c
> @@ -625,7 +625,8 @@ static struct grep_expr *prep_header_patterns(struct grep_opt *opt)
> for (p = opt->header_list; p; p = p->next) {
> if (p->token != GREP_PATTERN_HEAD)
> die("bug: a non-header pattern in grep header list.");
> - if (p->field < 0 || GREP_HEADER_FIELD_MAX <= p->field)
> + if (p->field < GREP_HEADER_FIELD_MIN ||
> + GREP_HEADER_FIELD_MAX <= p->field)
> die("bug: unknown header field %d", p->field);
I also think it would be fine to drop this test or replace it with an
assert((unsigned) p->field < ARRAY_SIZE(header_field));
because we know the test never trips.
^ permalink raw reply
* Re: [PATCH 2/3] combine-diff: suppress a clang warning
From: John Keeping @ 2013-02-03 19:06 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: Git Mailing List, Antoine Pelisse
In-Reply-To: <CALUzUxowrh53g50ZxkXSjLfOrSgX-YiZEB2MJXbLwxmwNB187A@mail.gmail.com>
On Mon, Feb 04, 2013 at 02:20:06AM +0800, Tay Ray Chuan wrote:
> On Sun, Feb 3, 2013 at 10:37 PM, John Keeping <john@keeping.me.uk> wrote:
> > When compiling combine-diff.c, clang 3.2 says:
> >
> > combine-diff.c:1006:19: warning: adding 'int' to a string does not
> > append to the string [-Wstring-plus-int]
> > prefix = COLONS + offset;
> > ~~~~~~~^~~~~~~~
> > combine-diff.c:1006:19: note: use array indexing to silence this warning
> > prefix = COLONS + offset;
> > ^
> > & [ ]
> >
> > Suppress this by making the suggested change.
> >
> > Signed-off-by: John Keeping <john@keeping.me.uk>
> > ---
> > combine-diff.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/combine-diff.c b/combine-diff.c
> > index bb1cc96..dba4748 100644
> > --- a/combine-diff.c
> > +++ b/combine-diff.c
> > @@ -1003,7 +1003,7 @@ static void show_raw_diff(struct combine_diff_path *p, int num_parent, struct re
> > offset = strlen(COLONS) - num_parent;
> > if (offset < 0)
> > offset = 0;
> > - prefix = COLONS + offset;
> > + prefix = &COLONS[offset];
> >
> > /* Show the modes */
> > for (i = 0; i < num_parent; i++) {
>
> Hmm, does
>
> prefix = (const char *) COLONS + offset;
>
> suppress the warning?
It does, but it turns out that the following also suppresses the
warning:
-- >8 --
diff --git a/combine-diff.c b/combine-diff.c
index bb1cc96..a07d329 100644
--- a/combine-diff.c
+++ b/combine-diff.c
@@ -982,7 +982,7 @@ static void show_patch_diff(struct combine_diff_path *elem, int num_parent,
free(sline);
}
-#define COLONS "::::::::::::::::::::::::::::::::"
+static const char COLONS[] = "::::::::::::::::::::::::::::::::";
static void show_raw_diff(struct combine_diff_path *p, int num_parent, struct rev_info *rev)
{
I think that's a nicer change than the original suggestion.
John
^ permalink raw reply related
* Re: [PATCH] gitk: Display the date of a tag in a human friendly way.
From: Anand Kumria @ 2013-02-03 18:37 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Junio C Hamano, git
In-Reply-To: <7v1udzqv1v.fsf@alter.siamese.dyndns.org>
Hi Pau,
I've not been able to find the canonical location of your gitk repository.
I've tried kernel.org, samba.org and ozlabs.org; none of them to have
it - nor does any amount of google searching I do reveal the location.
I realise you've probably had a busy month with linux.conf.au but it
would be nice to have some feedback.
Could you let me know where gitk is hosted and I'll re-roll this patch
against that (and update the docs so others don't need to go hunting).
Thanks,
Anand
On 5 January 2013 19:38, Junio C Hamano <gitster@pobox.com> wrote:
> Anand Kumria <wildfire@progsoc.org> writes:
>
>> Sorry, I didn't know that gitk had been split back out (and
>> Documentation/gitk.txt still mentions it is part of the git suite).
>
> It is not "split back" at all, and it won't be. From "git" user's
> point of view it is part of the suite.
>
> Gitk however is still a viable freestanding project, so it would be
> selfish for me to take a patch to gitk-git/gitk directly to my tree,
> as the patch will not be able to flow back to the standalone gitk
> project. Hence we always let patches go through Paul's tree and then
> I pull from him.
>
>
^ permalink raw reply
* Re: [PATCH 2/3] combine-diff: suppress a clang warning
From: Tay Ray Chuan @ 2013-02-03 18:20 UTC (permalink / raw)
To: John Keeping; +Cc: Git Mailing List, Antoine Pelisse
In-Reply-To: <6995fd5e4d9cb3320ab80c983f1b25ae8a399284.1359901732.git.john@keeping.me.uk>
On Sun, Feb 3, 2013 at 10:37 PM, John Keeping <john@keeping.me.uk> wrote:
> When compiling combine-diff.c, clang 3.2 says:
>
> combine-diff.c:1006:19: warning: adding 'int' to a string does not
> append to the string [-Wstring-plus-int]
> prefix = COLONS + offset;
> ~~~~~~~^~~~~~~~
> combine-diff.c:1006:19: note: use array indexing to silence this warning
> prefix = COLONS + offset;
> ^
> & [ ]
>
> Suppress this by making the suggested change.
>
> Signed-off-by: John Keeping <john@keeping.me.uk>
> ---
> combine-diff.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/combine-diff.c b/combine-diff.c
> index bb1cc96..dba4748 100644
> --- a/combine-diff.c
> +++ b/combine-diff.c
> @@ -1003,7 +1003,7 @@ static void show_raw_diff(struct combine_diff_path *p, int num_parent, struct re
> offset = strlen(COLONS) - num_parent;
> if (offset < 0)
> offset = 0;
> - prefix = COLONS + offset;
> + prefix = &COLONS[offset];
>
> /* Show the modes */
> for (i = 0; i < num_parent; i++) {
> --
Hmm, does
prefix = (const char *) COLONS + offset;
suppress the warning?
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: Feature request: Allow extracting revisions into directories
From: Robert Clausecker @ 2013-02-03 18:11 UTC (permalink / raw)
To: git
In-Reply-To: <510E8F82.9050306@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 757 bytes --]
Am Sonntag, den 03.02.2013, 21:55 +0530 schrieb Sitaram Chamarty:
> Could you help me understand why piping it to tar (actually 'tar -C
> /dest/dir -x') is not sufficient to achieve what you want?
Piping the output of git archive into tar is of course a possible
solution; I just don't like the fact that you need to pipe the output
into a separate program to do something that should be possible with a
simple switch and not an extra command. It feels unintuitive and like a
workaround to make an archive just to unpack it on-the-fly. Also, adding
such a command (or at least documenting the way to do this using a pipe
to tar somewhere in the man pages) is a small and simple change that
improves usability.
Yours, Robert Clausecker
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH] send-email: ignore files ending with ~
From: Antoine Pelisse @ 2013-02-03 17:16 UTC (permalink / raw)
To: Alexandre Courbot; +Cc: Junio C Hamano, git
In-Reply-To: <1359903340-14508-1-git-send-email-gnurou@gmail.com>
On Sun, Feb 3, 2013 at 3:55 PM, Alexandre Courbot <gnurou@gmail.com> wrote:
> It certainly happened to a lot of people already: you carefully prepare
> your set of patches, export them using format-patch --cover-letter,
> write your cover letter, and send the set like this:
>
> $ git send-email --to=somerenowneddeveloper --to=myfutureemployer
> --cc=thismailinglistiwanttoimpress 00*
Why don't you use 00*.patch ? That seems dubious to me to ignore files
specified on the command line.
^ permalink raw reply
* Re: [PATCH 0/3] Make Git compile warning-free with Clang
From: Antoine Pelisse @ 2013-02-03 17:13 UTC (permalink / raw)
To: John Keeping; +Cc: git
In-Reply-To: <cover.1359901732.git.john@keeping.me.uk>
Thanks John,
I couldn't find any time to send that "sum-up" series.
On Sun, Feb 3, 2013 at 3:37 PM, John Keeping <john@keeping.me.uk> wrote:
> The first two patches here were sent to the list before but seem to have
> got lost in the noise [1][2]. The final one is new but was prompted by
> discussion in the same thread.
^ permalink raw reply
* Re: Feature request: Allow extracting revisions into directories
From: Sitaram Chamarty @ 2013-02-03 16:25 UTC (permalink / raw)
To: Robert Clausecker; +Cc: git
In-Reply-To: <1359901085.24730.11.camel@t520>
On 02/03/2013 07:48 PM, Robert Clausecker wrote:
> Hello!
>
> git currently has the archive command that allows to save an arbitrary
> revision into a tar or zip file. Sometimes it is useful to not save this
> revision into an archive but to directly put all files into an arbitrary
> directory. Currently this seems to be not possible to archive directly;
> the only way I found to do it is to run git archive and then directly
> unpack the archive into a directory.
>
> git --git-dir REPO archive REVISION | tar x
>
> It would be nice to have a command or simply a switch to git archive
> that allows the user to put the files of REVISION into a directory
> instead of making an archive.
Could you help me understand why piping it to tar (actually 'tar -C
/dest/dir -x') is not sufficient to achieve what you want?
^ permalink raw reply
* Re: [RFC/PATCH v2] CodingGuidelines: add Python coding guidelines
From: Pete Wyckoff @ 2013-02-03 15:12 UTC (permalink / raw)
To: John Keeping; +Cc: Michael Haggerty, git
In-Reply-To: <20130201111634.GA2476@farnsworth.metanate.com>
john@keeping.me.uk wrote on Fri, 01 Feb 2013 11:16 +0000:
> On Fri, Feb 01, 2013 at 09:39:39AM +0100, Michael Haggerty wrote:
> > On 01/30/2013 09:31 PM, John Keeping wrote:
> > > On Wed, Jan 30, 2013 at 11:05:10AM +0100, Michael Haggerty wrote:
> > >> [...] maybe we should establish a small Python library of
> > >> compatibility utilities (like a small "six"). [...]
> > >> But I haven't had time to think of where to put such a library, how to
> > >> install it, etc.
> > >
> > > If we want to go that route, I think restructuring the
> > > "git_remote_helpers" directory and re-using its infrastructure for
> > > installing the "Git Python modules" would be the way to go. The
> > > directory structure would become something like this:
> > >
> > > git/
> > > `-- python/
> > > |-- Makefile # existing file pulled out of git_remote_helpers
> > > |-- < some new utility library >
> > > |-- git_remote_helpers
> > > | |-- __init__.py
> > > | |-- git
> > > | | |-- __init__.py
> > > | | |-- exporter.py
> > > | | |-- git.py
> > > | | |-- importer.py
> > > | | |-- non_local.py
> > > | | `-- repo.py
> > > | `-- util.py
> > > |-- setup.cfg # existing file pulled out of git_remote_helpers
> > > `-- setup.py # existing file pulled out of git_remote_helpers
> > >
> > >
> > > It looks like the GitPython project[1] as already taken the "git" module
> > > name, so perhaps we should use "git_core" if we do introduce a new
> > > module.
> > >
> > > [1] http://pypi.python.org/pypi/GitPython
> >
> > This sounds reasonable. But not all Python code will go under the
> > "python" subdirectory, right? For example, I am working on a Python
> > script that fits thematically under contrib/hooks.
>
> I was thinking of it as analagous with the "perl" directory that
> currently exists. So the "python" directory will contain library code
> but scripts can live wherever is most appropriate.
>
> One way of looking at it is: could the user want to have this installed
> for all available versions of Python? For a script, the answer is "no"
> because they will call it and it will just run. For libraries, you want
> them to be available with whatever Python interpreter you happen to be
> running (assuming that it is a version supported by the library).
>
> > OTOH (I'm thinking aloud here) it is probably a bad idea for a hook
> > script to depend on a Python module that is part of git itself. Doing
> > so would make the hook script depend on a particular version of git (or
> > at least a version with a compatible Python module). But users might be
> > reluctant to upgrade git just to install a hook script.
>
> I don't think such a dependency is a bad idea in the longer term. If a
> "Git Python library" is developed, then at some point most people who
> have Git installed will have some version of that library - it becomes a
> case of perhaps wanting to limit yourself to some subset of the library
> rather than just not using it.
>
> In fact, git_remote_helpers has been available since Git 1.7.0 and
> contains a lot of functionality that is more generic than its name
> suggests.
This library idea would be a great help; there are 100-odd calls
to git in git-p4, and we've had to deal with getting the arguments
and parsing correct. I'd happily switch to using git_core.
Probably some elements of GitPython can be used too. I'm not so
interested in the raw database manipulation, but the command
wrappers look reasonable.
-- Pete
^ permalink raw reply
* [PATCH] send-email: ignore files ending with ~
From: Alexandre Courbot @ 2013-02-03 14:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Alexandre Courbot
It certainly happened to a lot of people already: you carefully prepare
your set of patches, export them using format-patch --cover-letter,
write your cover letter, and send the set like this:
$ git send-email --to=somerenowneddeveloper --to=myfutureemployer
--cc=thismailinglistiwanttoimpress 00*
And of course since you think you know what you are doing, you just
answer 'a' at the first prompt to send all emails at once.
The next day, all these people are laughing at you because the editor
you used to write your cover letter saved a backup of the previous
version and they received two versions of it, including one containing
the familiar *** BLURB HERE *** (or potentially more humiliating stuff
if you used the buffer as a temporary scratch).
Let's save people's reputations by ignoring files ending with '~' in
send-email. There should be no reason to send such a file anyways.
Signed-off-by: Alexandre Courbot <gnurou@gmail.com>
---
git-send-email.perl | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index be809e5..4cc5855 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -548,7 +548,10 @@ while (defined(my $f = shift @ARGV)) {
sort readdir $dh;
closedir $dh;
} elsif ((-f $f or -p $f) and !check_file_rev_conflict($f)) {
- push @files, $f;
+ # Ignore backup files
+ if ($f !~ "~\$") {
+ push @files, $f;
+ }
} else {
push @rev_list_opts, $f;
}
--
1.8.1.1
^ permalink raw reply related
* [PATCH 3/3] builtin/apply: tighten (dis)similarity index parsing
From: John Keeping @ 2013-02-03 14:37 UTC (permalink / raw)
To: git; +Cc: Antoine Pelisse, John Keeping
In-Reply-To: <cover.1359901732.git.john@keeping.me.uk>
This was prompted by an incorrect warning issued by clang [1], and a
suggestion by Linus to restrict the range to check for values greater
than INT_MAX since these will give bogus output after casting to int.
In fact the (dis)similarity index is a percentage, so reject values
greater than 100.
[1] http://article.gmane.org/gmane.comp.version-control.git/213857
Signed-off-by: John Keeping <john@keeping.me.uk>
---
builtin/apply.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/builtin/apply.c b/builtin/apply.c
index 6c11e8b..4745e75 100644
--- a/builtin/apply.c
+++ b/builtin/apply.c
@@ -1041,15 +1041,17 @@ static int gitdiff_renamedst(const char *line, struct patch *patch)
static int gitdiff_similarity(const char *line, struct patch *patch)
{
- if ((patch->score = strtoul(line, NULL, 10)) == ULONG_MAX)
- patch->score = 0;
+ unsigned long val = strtoul(line, NULL, 10);
+ if (val <= 100)
+ patch->score = val;
return 0;
}
static int gitdiff_dissimilarity(const char *line, struct patch *patch)
{
- if ((patch->score = strtoul(line, NULL, 10)) == ULONG_MAX)
- patch->score = 0;
+ unsigned long val = strtoul(line, NULL, 10);
+ if (val <= 100)
+ patch->score = val;
return 0;
}
--
1.8.1.2
^ permalink raw reply related
* [PATCH 1/3] fix clang -Wtautological-compare with unsigned enum
From: John Keeping @ 2013-02-03 14:37 UTC (permalink / raw)
To: git; +Cc: Antoine Pelisse, John Keeping
In-Reply-To: <cover.1359901732.git.john@keeping.me.uk>
From: Antoine Pelisse <apelisse@gmail.com>
Create a GREP_HEADER_FIELD_MIN so we can check that the field value is
sane and silent the clang warning.
Clang warning happens because the enum is unsigned (this is
implementation-defined, and there is no negative fields) and the check
is then tautological.
Signed-off-by: Antoine Pelisse <apelisse@gmail.com>
---
grep.c | 3 ++-
grep.h | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/grep.c b/grep.c
index 4bd1b8b..bb548ca 100644
--- a/grep.c
+++ b/grep.c
@@ -625,7 +625,8 @@ static struct grep_expr *prep_header_patterns(struct grep_opt *opt)
for (p = opt->header_list; p; p = p->next) {
if (p->token != GREP_PATTERN_HEAD)
die("bug: a non-header pattern in grep header list.");
- if (p->field < 0 || GREP_HEADER_FIELD_MAX <= p->field)
+ if (p->field < GREP_HEADER_FIELD_MIN ||
+ GREP_HEADER_FIELD_MAX <= p->field)
die("bug: unknown header field %d", p->field);
compile_regexp(p, opt);
}
diff --git a/grep.h b/grep.h
index 8fc854f..e4a1df5 100644
--- a/grep.h
+++ b/grep.h
@@ -28,7 +28,8 @@ enum grep_context {
};
enum grep_header_field {
- GREP_HEADER_AUTHOR = 0,
+ GREP_HEADER_FIELD_MIN = 0,
+ GREP_HEADER_AUTHOR = GREP_HEADER_FIELD_MIN,
GREP_HEADER_COMMITTER,
GREP_HEADER_REFLOG,
--
1.8.1.2
^ permalink raw reply related
* [PATCH 2/3] combine-diff: suppress a clang warning
From: John Keeping @ 2013-02-03 14:37 UTC (permalink / raw)
To: git; +Cc: Antoine Pelisse, John Keeping
In-Reply-To: <cover.1359901732.git.john@keeping.me.uk>
When compiling combine-diff.c, clang 3.2 says:
combine-diff.c:1006:19: warning: adding 'int' to a string does not
append to the string [-Wstring-plus-int]
prefix = COLONS + offset;
~~~~~~~^~~~~~~~
combine-diff.c:1006:19: note: use array indexing to silence this warning
prefix = COLONS + offset;
^
& [ ]
Suppress this by making the suggested change.
Signed-off-by: John Keeping <john@keeping.me.uk>
---
combine-diff.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/combine-diff.c b/combine-diff.c
index bb1cc96..dba4748 100644
--- a/combine-diff.c
+++ b/combine-diff.c
@@ -1003,7 +1003,7 @@ static void show_raw_diff(struct combine_diff_path *p, int num_parent, struct re
offset = strlen(COLONS) - num_parent;
if (offset < 0)
offset = 0;
- prefix = COLONS + offset;
+ prefix = &COLONS[offset];
/* Show the modes */
for (i = 0; i < num_parent; i++) {
--
1.8.1.2
^ permalink raw reply related
* [PATCH 0/3] Make Git compile warning-free with Clang
From: John Keeping @ 2013-02-03 14:37 UTC (permalink / raw)
To: git; +Cc: Antoine Pelisse, John Keeping
The first two patches here were sent to the list before but seem to have
got lost in the noise [1][2]. The final one is new but was prompted by
discussion in the same thread.
After applying all of these patches, I don't see any warnings compiling
Git with Clang 3.2.
[1] http://article.gmane.org/gmane.comp.version-control.git/213817
[2] http://article.gmane.org/gmane.comp.version-control.git/213849
Antoine Pelisse (1):
fix clang -Wtautological-compare with unsigned enum
John Keeping (2):
combine-diff: suppress a clang warning
builtin/apply: tighten (dis)similarity index parsing
builtin/apply.c | 10 ++++++----
combine-diff.c | 2 +-
grep.c | 3 ++-
grep.h | 3 ++-
4 files changed, 11 insertions(+), 7 deletions(-)
--
1.8.1.2
^ permalink raw reply
* Feature request: Allow extracting revisions into directories
From: Robert Clausecker @ 2013-02-03 14:18 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 700 bytes --]
Hello!
git currently has the archive command that allows to save an arbitrary
revision into a tar or zip file. Sometimes it is useful to not save this
revision into an archive but to directly put all files into an arbitrary
directory. Currently this seems to be not possible to archive directly;
the only way I found to do it is to run git archive and then directly
unpack the archive into a directory.
git --git-dir REPO archive REVISION | tar x
It would be nice to have a command or simply a switch to git archive
that allows the user to put the files of REVISION into a directory
instead of making an archive.
Thank you very much for your help. Yours,
Robert Clausecker
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: Getting started contributing.
From: Philip Oakley @ 2013-02-03 13:34 UTC (permalink / raw)
To: adamfraser; +Cc: git, Junio C Hamano
In-Reply-To: <7vd2whalax.fsf@alter.siamese.dyndns.org>
From: "Junio C Hamano" <gitster@pobox.com>
Sent: Sunday, February 03, 2013 7:49 AM
> adamfraser <adamfraser0@gmail.com> writes:
>
>> I've done a little searching and
>> haven't been able to find an official bug tracker for git is there
>> somewhere
>> I can find some bugs to help fix?
>
> You came to the right place. A new bug or regression is reported to
> this list, and it often is fixed (or often diagnosed as pebcak)
> fairly quickly by list regulars. Nobody maintains a bugzilla that
> is not maintained and is full of stale/invalid bug reports.
>
> The best contribution a new person can make is to use the software
> regularly and find issues. It is very hard to find real bugs that
> can easily be fixed by somebody totally new to the codebase in Git
> these days.
>
> On the other hand, there probably still are many loose ends. When a
> command is supposed to take only two arguments because taking more
> than three does not make any sense, for example, it has not been
> unusual for us to document the two-argument form of the command,
> reject if the user gives only one argument with an error message,
> but we simply ignore the third argument if the user mistakenly runs
> the command with three arguments, instead of erroring out (i.e. the
> code does not bother to help insane or too inexperienced users).
> That kind of things are hard to find by users experienced with Git
> exactly because they know running such a command with three or more
> arguments is nonsense, and they do not even try to make such a
> mistake. Still, it would be very nice to find and fix such issues.
>
A review of the git-user list
https://groups.google.com/forum/?fromgroups#!forum/git-users is one
place to discover some of the user issues and thinking about how to
address them. Or resurrect issues from this Git list. E.g. There are a
number of sub-module improvements available there.
If you have any Windows experience the MSysGit team
https://github.com/msysgit/msysgit is always looking for help on some of
the compatibility issues, e.g. where the Linux optimisations conflict
with the Windows approaches.
Another area is picking out documentation issues you have seen and
submitting patches for them, whether in the command man pages or in the
guides. On my 'todo' list is to make the `help` command actually list
the "Help me" (i.e. guides and articles) pages, not just the command man
pages.
I also had -
* Bulk move detection (when folk change/move upper level directory
names).
* add a .gitnevermerge option to stop private files you don't want in
'master' (or any other branch) to be merged
Philip
^ permalink raw reply
* Re: What's cooking in git.git (Feb 2013, #01; Fri, 1)
From: John Keeping @ 2013-02-03 13:02 UTC (permalink / raw)
To: David Aguilar; +Cc: Junio C Hamano, git
In-Reply-To: <CAJDDKr6bPjKwe3NitvGCec2LyesY3yL=UtN85Bsox-bGWN=qeA@mail.gmail.com>
On Sun, Feb 03, 2013 at 04:13:22AM -0800, David Aguilar wrote:
> On Sat, Feb 2, 2013 at 9:44 PM, Junio C Hamano <gitster@pobox.com> wrote:
> > Junio C Hamano <gitster@pobox.com> writes:
> >
> > Regarding these two topics....
> >
> >> * da/mergetool-docs (2013-01-30) 7 commits
> >> - doc: generate a list of valid merge tools
> >> - mergetool--lib: list user configured tools in '--tool-help'
> >> - fixup! doc: generate a list of valid merge tools
> >> - fixup! mergetool--lib: add functions for finding available tools
> >> - mergetool--lib: add functions for finding available tools
> >> - mergetool--lib: improve the help text in guess_merge_tool()
> >> - mergetool--lib: simplify command expressions
> >> (this branch uses jk/mergetool.)
> >>
> >> Build on top of the clean-up done by jk/mergetool and automatically
> >> generate the list of mergetool and difftool backends the build
> >> supports to be included in the documentation.
> >>
> >> Will merge to 'next', after squashing the fixup! commits from John
> >> Keeping.
> >>
> >>
> >> * jk/mergetool (2013-01-28) 8 commits
> >> - mergetools: simplify how we handle "vim" and "defaults"
> >> - mergetool--lib: don't call "exit" in setup_tool
> >> - mergetool--lib: improve show_tool_help() output
> >> - mergetools/vim: remove redundant diff command
> >> - git-difftool: use git-mergetool--lib for "--tool-help"
> >> - git-mergetool: don't hardcode 'mergetool' in show_tool_help
> >> - git-mergetool: remove redundant assignment
> >> - git-mergetool: move show_tool_help to mergetool--lib
> >> (this branch is used by da/mergetool-docs.)
> >>
> >> Cleans up mergetool/difftool combo.
> >>
> >> This is looking ready for 'next'.
> >
> > Do the tips of these two topics look reasonable to both of you, or
> > are there anything you sent but I missed?
>
> It looks good to go. The additional "|| :" in the makefile is a nice
> touchup that made it more robust too.
Looks good to me as well.
John
^ permalink raw reply
* Re: What's cooking in git.git (Feb 2013, #01; Fri, 1)
From: David Aguilar @ 2013-02-03 12:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: John Keeping, git
In-Reply-To: <7vlib69cjh.fsf@alter.siamese.dyndns.org>
On Sat, Feb 2, 2013 at 9:44 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
> Regarding these two topics....
>
>> * da/mergetool-docs (2013-01-30) 7 commits
>> - doc: generate a list of valid merge tools
>> - mergetool--lib: list user configured tools in '--tool-help'
>> - fixup! doc: generate a list of valid merge tools
>> - fixup! mergetool--lib: add functions for finding available tools
>> - mergetool--lib: add functions for finding available tools
>> - mergetool--lib: improve the help text in guess_merge_tool()
>> - mergetool--lib: simplify command expressions
>> (this branch uses jk/mergetool.)
>>
>> Build on top of the clean-up done by jk/mergetool and automatically
>> generate the list of mergetool and difftool backends the build
>> supports to be included in the documentation.
>>
>> Will merge to 'next', after squashing the fixup! commits from John
>> Keeping.
>>
>>
>> * jk/mergetool (2013-01-28) 8 commits
>> - mergetools: simplify how we handle "vim" and "defaults"
>> - mergetool--lib: don't call "exit" in setup_tool
>> - mergetool--lib: improve show_tool_help() output
>> - mergetools/vim: remove redundant diff command
>> - git-difftool: use git-mergetool--lib for "--tool-help"
>> - git-mergetool: don't hardcode 'mergetool' in show_tool_help
>> - git-mergetool: remove redundant assignment
>> - git-mergetool: move show_tool_help to mergetool--lib
>> (this branch is used by da/mergetool-docs.)
>>
>> Cleans up mergetool/difftool combo.
>>
>> This is looking ready for 'next'.
>
> Do the tips of these two topics look reasonable to both of you, or
> are there anything you sent but I missed?
It looks good to go. The additional "|| :" in the makefile is a nice
touchup that made it more robust too.
--
David
^ permalink raw reply
* Re: Getting started contributing.
From: Duy Nguyen @ 2013-02-03 9:54 UTC (permalink / raw)
To: adamfraser; +Cc: Junio C Hamano, git
In-Reply-To: <7vd2whalax.fsf@alter.siamese.dyndns.org>
On Sun, Feb 3, 2013 at 2:49 PM, Junio C Hamano <gitster@pobox.com> wrote:
> On the other hand, there probably still are many loose ends.
A few other things
- Mark more strings for translation (not as easy as it sounds, some
strings can't be translated)
- Color more in the output where it makes sense
- Stop/Warn the user from updating HEAD (e.g. checkout another
branch) while in the middle of a rebase (some makes sense, most is by
mistake)
PS. You are welcome to improve my two patches Junio mentioned. I don't
think it overlaps much with "git rebase --status" though. Printing the
remaining steps, or what patch being applied is not going to be done
by "git status".
--
Duy
^ permalink raw reply
* Re: Getting started contributing.
From: Junio C Hamano @ 2013-02-03 7:49 UTC (permalink / raw)
To: adamfraser; +Cc: git
In-Reply-To: <1359872508519-7576834.post@n2.nabble.com>
adamfraser <adamfraser0@gmail.com> writes:
> I've done a little searching and
> haven't been able to find an official bug tracker for git is there somewhere
> I can find some bugs to help fix?
You came to the right place. A new bug or regression is reported to
this list, and it often is fixed (or often diagnosed as pebcak)
fairly quickly by list regulars. Nobody maintains a bugzilla that
is not maintained and is full of stale/invalid bug reports.
The best contribution a new person can make is to use the software
regularly and find issues. It is very hard to find real bugs that
can easily be fixed by somebody totally new to the codebase in Git
these days.
On the other hand, there probably still are many loose ends. When a
command is supposed to take only two arguments because taking more
than three does not make any sense, for example, it has not been
unusual for us to document the two-argument form of the command,
reject if the user gives only one argument with an error message,
but we simply ignore the third argument if the user mistakenly runs
the command with three arguments, instead of erroring out (i.e. the
code does not bother to help insane or too inexperienced users).
That kind of things are hard to find by users experienced with Git
exactly because they know running such a command with three or more
arguments is nonsense, and they do not even try to make such a
mistake. Still, it would be very nice to find and fix such issues.
Thanks.
^ permalink raw reply
* Re: Getting started contributing.
From: Junio C Hamano @ 2013-02-03 7:40 UTC (permalink / raw)
To: adamfraser; +Cc: git
In-Reply-To: <1359872508519-7576834.post@n2.nabble.com>
adamfraser <adamfraser0@gmail.com> writes:
> I would like to start contributing to git and am looking for a small project
> idea to get started with. On the Small Project Ideas wiki
> <https://git.wiki.kernel.org/index.php/SmallProjectsIdeas> site there is a
> suggestion for adding a 'git rebase --status' command that sounds like it
> would be good for someone who has little knowledge of the code base.
I think the two patches Duy just posted tonight overlap with that
topic, and I suspect it would give the end users a better experience
to put the information in "git status" output rather than a separate
"git rebase" subcommand. Perhaps you can work with him to see what
other things his patch may have missed can be improved?
^ permalink raw reply
* Getting started contributing.
From: adamfraser @ 2013-02-03 6:21 UTC (permalink / raw)
To: git
Hi,
I would like to start contributing to git and am looking for a small project
idea to get started with. On the Small Project Ideas wiki
<https://git.wiki.kernel.org/index.php/SmallProjectsIdeas> site there is a
suggestion for adding a 'git rebase --status' command that sounds like it
would be good for someone who has little knowledge of the code base. Is this
project still wanted? Aside from that, I've done a little searching and
haven't been able to find an official bug tracker for git is there somewhere
I can find some bugs to help fix?
Apologies if this isn't the correct place to be posting.
Thanks
Adam Fraser
--
View this message in context: http://git.661346.n2.nabble.com/Getting-started-contributing-tp7576834.html
Sent from the git mailing list archive at Nabble.com.
^ 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