* Re: [RFC/PATCH 01/17] diff: move line ending check into emit_hunk_header
From: René Scharfe @ 2016-09-13 14:42 UTC (permalink / raw)
To: Stefan Beller, gitster, peff, chriscool; +Cc: git
In-Reply-To: <20160913044613.1037-2-sbeller@google.com>
Am 13.09.2016 um 06:45 schrieb Stefan Beller:
> In a later patch, I want to propose an option to detect&color
> moved lines in a diff, which cannot be done in a one-pass over
> the diff. Instead we need to go over the whole diff twice,
> because we cannot detect the first line of the two corresponding
> lines (+ and -) that got moved.
>
> So to prepare the diff machinery for two pass algorithms
> (i.e. buffer it all up and then operate on the result),
> move all emissions to places, such that the only emitting
> function is emit_line_0.
>
> This patch moves code that is conceptually part of
> emit_hunk_header, but was using output in fn_out_consume,
> back to emit_hunk_header.
>
> Signed-off-by: Stefan Beller <sbeller@google.com>
> ---
> diff.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/diff.c b/diff.c
> index cc8e812..aa50b2d 100644
> --- a/diff.c
> +++ b/diff.c
> @@ -610,6 +610,9 @@ static void emit_hunk_header(struct emit_callback *ecbdata,
> }
>
> strbuf_add(&msgbuf, line + len, org_len - len);
> + if (line[org_len - 1] != '\n')
> + strbuf_addch(&msgbuf, '\n');
> +
Using strbuf_complete_line() would be nicer.
> emit_line(ecbdata->opt, "", "", msgbuf.buf, msgbuf.len);
> strbuf_release(&msgbuf);
> }
> @@ -1247,8 +1250,6 @@ static void fn_out_consume(void *priv, char *line, unsigned long len)
> len = sane_truncate_line(ecbdata, line, len);
> find_lno(line, ecbdata);
> emit_hunk_header(ecbdata, line, len);
> - if (line[len-1] != '\n')
> - putc('\n', o->file);
> return;
> }
>
>
^ permalink raw reply
* Re: [PATCH v7 10/10] convert: add filter.<driver>.process option
From: Torsten Bögershausen @ 2016-09-13 14:44 UTC (permalink / raw)
To: Lars Schneider, Torsten Bögershausen
Cc: Git Mailing List, peff, gitster, sbeller, Johannes.Schindelin,
jnareb, mlbright, jacob.keller
In-Reply-To: <10020380-76ED-4371-A0BA-59D07AF33CE0@gmail.com>
On 12.09.16 11:49, Lars Schneider wrote:
>> How do we send pathnames the have '\n' ?
>> Not really recommended, but allowed.
>> And here I am a little bit lost, is each of the lines packed into
>> a pkt-line ?
>> command=smudge is packet as pkt-line and pathname= is packed into
>> another one ? (The we don't need the '\n' at all)
>
> Every line is a dedicated packet. That's why '\n' in a path name would
> not be a problem as the receiver is expected to read the entire packet
> when parsing the value (and the receiver knows the packet length, too).
>
> The '\n' at the end is required by the pkt-line format:
> "A non-binary line SHOULD BE terminated by an LF..."
> (see protocol-common.txt)
That is only the half part of the story:
A non-binary line SHOULD BE terminated by an LF, which if present
MUST be included in the total length. Receivers MUST treat pkt-lines
with non-binary data the same whether or not they contain the trailing
LF (stripping the LF if present, and not complaining when it is
missing).
How do we treat pathnames ?
They can have each byte value except '\0'.
What should a receiver do, which reads a string like "ABC\n\n" ?
Is it "ABC\n" or "ABC\n\n" ?
I would really consider to treat pathnames as binary, and not add a trailing '\n',
are there other opinions ?
^ permalink raw reply
* Re: [ANNOUNCE] Git User's Survey 2016
From: Kevin Daudt @ 2016-09-13 15:01 UTC (permalink / raw)
To: Jakub Narębski
Cc: git, Doug Rathbone, David Bainbridge, Stefan Beller,
Andrew Ardill, Eric Wong
In-Reply-To: <CANQwDwfj7NSHnaGhLCH33w1Eg4r_NCvs9_e8Dj2fMMUc8b78Aw@mail.gmail.com>
On Tue, Sep 13, 2016 at 03:52:28PM +0200, Jakub Narębski wrote:
> Hello Kevin,
>
> On 13 September 2016 at 15:32, Kevin Daudt <me@ikke.info> wrote:
> > On Mon, Sep 12, 2016 at 09:51:09PM +0200, Jakub Narębski wrote:
>
> >>
> >> P.P.S. Different announcements use different URLs (different channels)
> >> to better track where one got information about this survey.
> >>
> >> Thanks in advance for taking time to answer the survey,
> >
> > Can we get a channel for the freenode/#git channel? I'm trying to announce the
> > survey there too.
>
> Here you have it:
>
> https://survs.com/survey/c6wjrerw87
>
> --
> Jakub Narebski
Thanks.
^ permalink raw reply
* Re: [PATCH v7 10/10] convert: add filter.<driver>.process option
From: Junio C Hamano @ 2016-09-13 15:22 UTC (permalink / raw)
To: larsxschneider
Cc: git, peff, sbeller, Johannes.Schindelin, jnareb, mlbright, tboegi,
jacob.keller
In-Reply-To: <20160908182132.50788-11-larsxschneider@gmail.com>
larsxschneider@gmail.com writes:
> diff --git a/contrib/long-running-filter/example.pl b/contrib/long-running-filter/example.pl
> ...
> +sub packet_read {
> + my $buffer;
> + my $bytes_read = read STDIN, $buffer, 4;
> + if ( $bytes_read == 0 ) {
> +
> + # EOF - Git stopped talking to us!
> + exit();
> +...
> +packet_write( "clean=true\n" );
> +packet_write( "smudge=true\n" );
> +packet_flush();
> +
> +while (1) {
These extra SP around the contents inside () pair look unfamiliar
and somewhat strange to me, but as long as they are consistently
done (and I think you are mostly being consistent), it is OK.
> +#define CAP_CLEAN (1u<<0)
> +#define CAP_SMUDGE (1u<<1)
As these are meant to be usable together, i.e. bits in a single flag
word, they are of type "unsigned int", which makes perfect sense.
Make sure your variables and fields that store them are of the same
type. I think I saw "int' used to pass them in at least one place.
> +static int apply_filter(const char *path, const char *src, size_t len,
> + int fd, struct strbuf *dst, struct convert_driver *drv,
> + const int wanted_capability)
> +{
> + const char* cmd = NULL;
"const char *cmd = NULL;" of course.
> diff --git a/unpack-trees.c b/unpack-trees.c
> index 11c37fb..f6798f8 100644
> --- a/unpack-trees.c
> +++ b/unpack-trees.c
> @@ -10,6 +10,7 @@
> #include "attr.h"
> #include "split-index.h"
> #include "dir.h"
> +#include "convert.h"
>
> /*
> * Error messages expected by scripts out of plumbing commands such as
Why? The resulting file seems to compile without this addition.
^ permalink raw reply
* Re: git-am includes escape characters from 'From' field
From: Jeff King @ 2016-09-13 15:26 UTC (permalink / raw)
To: Swift Geek; +Cc: git
In-Reply-To: <op.yno0zli7ig5ot5@localhost.localdomain>
On Mon, Sep 12, 2016 at 10:10:23PM +0200, Swift Geek wrote:
> git-am seems to add backslash that escapes double quote character, example
> git format-patch
>
> From 63da989a5295214f9bd06cd7b409a86a65241eea Mon Sep 17 00:00:00 2001
> From: "Sebastian \"Swift Geek\" Grzywna" <swiftgeek@gmail.com>
This looks correct; the output of format-patch is an rfc2822 message,
and it requires this quoting.
The part you don't show, and that I think is wrong, is that if you then
"git am" this patch, it pulls the backslashes into the commit object.
The culprit looks like "parse_mail()" in builtin/am.c (or possibly
mailinfo() that it calls), which blindly picks up the name portion
without doing any rfc2822 de-quoting.
I don't think we have any existing de-quoting routines to plug in, so
fixing it would probably start with writing one.
-Peff
^ permalink raw reply
* Re: [PATCH v7 00/10] Git filter protocol
From: Junio C Hamano @ 2016-09-13 16:00 UTC (permalink / raw)
To: larsxschneider
Cc: git, peff, sbeller, Johannes.Schindelin, jnareb, mlbright, tboegi,
jacob.keller
In-Reply-To: <20160908182132.50788-1-larsxschneider@gmail.com>
larsxschneider@gmail.com writes:
> From: Lars Schneider <larsxschneider@gmail.com>
>
> The goal of this series is to avoid launching a new clean/smudge filter
> process for each file that is filtered.
I tentatively queued this in 'pu' because I wanted to see these
changes in context and also wanted to know if there are overlaps and
conflicts with other topics in flight. As your earlier steps
renamed packet_write() to packet_write_fmt() but didn't add a new
packet_write() that has different semantics, it was pleasantly easy
to make sure there is no new caller added in the meantime (it did
conflict with Duy's shallow-deepen topic and the resolution had to
touch outside the <<< conflicted === regions >>>, but it was
otherwise trivial).
Some details of the protocol (I think Torsten has already pointed
out that not all paths can be representable with the current
incarnation; there may be other minor nits like that) may still need
to be worked out, but I think the series at this point gets the
basic code structure right and such additional fixes would not
change things too drastically (IOW, I think we are very close to
being 'next'-ready).
Thanks.
^ permalink raw reply
* RE: [ANNOUNCE] Git User's Survey 2016
From: David Bainbridge @ 2016-09-13 16:15 UTC (permalink / raw)
To: Jakub Narębski, git@vger.kernel.org
Cc: Doug Rathbone, David Bainbridge, Stefan Beller, Andrew Ardill,
Eric Wong
In-Reply-To: <de39c03d-e84e-8e45-69cb-a2e01fd25df2@gmail.com>
Hi Jakub,
You said:
P.S. At request I can open a separate channel in survey, with a separate survey URL, so that responses from particular site or organization could be separated out.
Please can you open a channel for use by Ericsson?
Many thanks
David
DAVID BAINBRIDGE
Product Manager SW Development
Strategic Product Manager, Configuration and Compliance Management
BNEP EITTE SP&S Platforms&Infrastructure
Ericsson
8500 Decarie
Montreal, H4P 2N2, Canada
Phone +1 514 345 7900 x42014
Mobile +1 438 990 2452
Office ECN 810 42014
david.bainbridge@ericsson.com
www.ericsson.com
-----Original Message-----
From: Jakub Narębski [mailto:jnareb@gmail.com]
Sent: Monday, September 12, 2016 15:51
To: git@vger.kernel.org
Cc: Doug Rathbone <doug@dougrathbone.com>; David Bainbridge <david.bainbridge@gmail.com>; Stefan Beller <sbeller@google.com>; Andrew Ardill <andrew.ardill@gmail.com>; Eric Wong <e@80x24.org>
Subject: [ANNOUNCE] Git User's Survey 2016
Hello all,
We would like to ask you a few questions about your use of the Git version control system. This survey is mainly to understand who is using Git, how and why.
The results will be published to the Git wiki on the GitSurvey2016 page (https://git.wiki.kernel.org/index.php/GitSurvey2016) and discussed on the git mailing list.
The survey would be open from 12 September to 20 October 2016.
Please devote a few minutes of your time to fill this simple questionnaire, it will help a lot the git community to understand your needs, what you like of Git, and of course what you don't like.
The survey can be found here:
https://tinyurl.com/GitSurvey2016
https://survs.com/survey/lmo7ed3439
There is also alternate version which does not require cookies, but it doesn't allow one to go back to response and edit it.
https://tinyurl.com/GitSurvey2016-anon
https://survs.com/survey/naeec8kwd8
P.S. At request I can open a separate channel in survey, with a separate survey URL, so that responses from particular site or organization could be separated out.
Please send me a email with name of channel, and I will return with a separate survey URL to use. Note that the name of the channel would be visible to others.
P.P.S. Different announcements use different URLs (different channels) to better track where one got information about this survey.
Thanks in advance for taking time to answer the survey,
--
Jakub Narębski
on behalf of
Git Development Community
^ permalink raw reply
* Re: [PATCH v2] ls-files: adding support for submodules
From: Junio C Hamano @ 2016-09-13 16:31 UTC (permalink / raw)
To: Brandon Williams; +Cc: git
In-Reply-To: <1473726835-143289-1-git-send-email-bmwill@google.com>
Brandon Williams <bmwill@google.com> writes:
> Allow ls-files to recognize submodules in order to retrieve a list of
> files from a repository's submodules. This is done by forking off a
> process to recursively call ls-files on all submodules. Also added an
> output-path-prefix command in order to prepend paths to child processes.
>
> Signed-off-by: Brandon Williams <bmwill@google.com>
> @@ -68,6 +71,21 @@ static void write_eolinfo(const struct cache_entry *ce, const char *path)
> static void write_name(const char *name)
> {
> /*
> + * NEEDSWORK: To make this thread-safe, full_name would have to be owned
> + * by the caller.
> + *
> + * full_name get reused across output lines to minimize the allocation
> + * churn.
> + */
> + static struct strbuf full_name = STRBUF_INIT;
> + if (output_path_prefix != '\0') {
> + strbuf_reset(&full_name);
> + strbuf_addstr(&full_name, output_path_prefix);
> + strbuf_addstr(&full_name, name);
> + name = full_name.buf;
> + }
At first glance it was surprising that no test caught this lack of
dereference; the reason is because you initialize output_path_prefix
to an empty string, not NULL, causing full_name.buf always used,
which does not have an impact on the output.
I think initializing it to NULL is a more typical way to say "this
option has not been given", and if you took that route, the
condition would become
if (output_path_prefix && *output_path_prefix) {
...
In any case, the fact that only this much change was required to add
output-path-prefix shows two good things: (1) the original code was
already well structured, funneling any pathname we need to emit
through this single function so that we can do this kind of updates,
and (2) the author of the patch was competent to spot this single
point that needs to be updated.
Nice.
> + status = run_command(&cp);
> + if (status)
> + exit(status);
run_command()'s return value comes from either start_command() or
finish_command(). These signal failure by returning a non-zero
value, and in practice they are negative small integers. Feeding
negative value to exit() is not quite kosher. Perhaps exit(128)
to mimick as if we called die() is better.
If your primary interest is to support the "find in the working tree
files that are tracked, recursively in submodules" grep, I think
this "when we hit a submodule, spawn a separate ls-files in there"
is sufficient and a solid base to build on it.
On the other hand, if you are more ambitious and "grep" is merely an
example of things that can be helped by having a list of paths
across module boundaries, we may want to "libify" ls-files in such a
way that a single process can instantiate one or more instances of
"ls-files machinery", that takes which repository to work in and
other arguments that specifies which paths to report, and instead of
always showing the result to the standard output, makes repeated
calls to a callback function to report the discovered path and other
attributes associated with the path that were asked for (the object
name, values of tag_*, etc.), without spawning a separate "ls-files"
process.
The latter would be a lot bigger task and I do not necessarily think
it is needed, but that is one possible future direction to keep in
mind.
Thanks, will queue with a minimum fix.
^ permalink raw reply
* Re: [PATCH v2 09/14] i18n: notes: mark error messages for translation
From: Vasco Almeida @ 2016-09-13 16:35 UTC (permalink / raw)
To: Jean-Noël Avila
Cc: git, Jiang Xin, Ævar Arnfjörð Bjarmason,
Junio C Hamano
In-Reply-To: <83f72924-9a9d-dc1c-109f-341f0cd7ac96@free.fr>
A Seg, 12-09-2016 às 14:23 +0200, Jean-Noël Avila escreveu:
> Le 12/09/2016 à 13:29, Vasco Almeida a écrit :
> >
> > Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt>
> > ---
> > builtin/notes.c | 18 +++++++++---------
> > 1 file changed, 9 insertions(+), 9 deletions(-)
> >
> > diff --git a/builtin/notes.c b/builtin/notes.c
> > index f848b89..abacae2 100644
> > --- a/builtin/notes.c
> > +++ b/builtin/notes.c
> > @@ -340,7 +340,7 @@ static struct notes_tree
> > *init_notes_check(const char *subcommand,
> >
> > ref = (flags & NOTES_INIT_WRITABLE) ? t->update_ref : t-
> > >ref;
> > if (!starts_with(ref, "refs/notes/"))
> > - die("Refusing to %s notes in %s (outside of
> > refs/notes/)",
> > + die(_("Refusing to %s notes in %s (outside of
> > refs/notes/)"),
> > subcommand, ref);
> > return t;
> > }
>
> Not sure this one will be easy to localize. The verb is passed as a
> parameter : see line 366 "list", line 426 "add", line 517 "copy",
> line
> 658 "show", line 816 "merge", line 908 "remove" or line 595 with
> argv[0].
>
> If all the verbs are real subcommands, then the translators should be
> warned that this is some english twisting, but that they need to
> refer
> to the subcommand on the command line.
Yes, these verbs are git notes subcommands. I will add a Translators
comment to it explaining so. Or we can unfold that error messages like
if (!strcmp(subcommand, "add")
die(_("Refusing to add notes in %s (outside of refs/notes/)"),
ref);
elseif ...
else
die(_("Refusing to %s notes in %s (outside of refs/notes/)"),
subcommand, ref);
This is more verbose but translations would benefit from it being more
natural. What do we prefer: (1) concise source and a little unnatural
translations or (2) verbose code and natural translations?
Compare, imaging that English is a target translation language, the
user would read:
"Refusing to do add of notes in /path [...]" (1)
"Refusing do add notes in /path [...]" (2)
> Otherwise,
>
> Acked-by: Jean-Noël Avila <jean-noel.avila@free.fr>
>
> JN
^ permalink raw reply
* [PATCH] strbuf: use valid pointer in strbuf_remove()
From: René Scharfe @ 2016-09-13 16:40 UTC (permalink / raw)
To: Git List; +Cc: Junio C Hamano
The fourth argument of strbuf_splice() is passed to memcpy(3), which is
not supposed to handle NULL pointers. Let's be extra careful and use a
valid empty string instead. It even shortens the source code. :)
Signed-off-by: Rene Scharfe <l.s.r@web.de>
---
strbuf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/strbuf.c b/strbuf.c
index f3bd571..b839be4 100644
--- a/strbuf.c
+++ b/strbuf.c
@@ -187,7 +187,7 @@ void strbuf_insert(struct strbuf *sb, size_t pos, const void *data, size_t len)
void strbuf_remove(struct strbuf *sb, size_t pos, size_t len)
{
- strbuf_splice(sb, pos, len, NULL, 0);
+ strbuf_splice(sb, pos, len, "", 0);
}
void strbuf_add(struct strbuf *sb, const void *data, size_t len)
--
2.10.0
^ permalink raw reply related
* Re: [PATCH v7 10/10] convert: add filter.<driver>.process option
From: Junio C Hamano @ 2016-09-13 16:42 UTC (permalink / raw)
To: Torsten Bögershausen
Cc: Lars Schneider, Git Mailing List, peff, sbeller,
Johannes.Schindelin, jnareb, mlbright, jacob.keller
In-Reply-To: <96554f6d-988d-e0b8-7936-8d0f29a7564f@web.de>
Torsten Bögershausen <tboegi@web.de> writes:
> I would really consider to treat pathnames as binary, and not add a trailing '\n',
> are there other opinions ?
It would be the most consistent if the same format as
write_name_quoted() is used for this, I would think.
^ permalink raw reply
* [PATCH] pathspec: removed unnecessary function prototypes
From: Brandon Williams @ 2016-09-13 16:52 UTC (permalink / raw)
To: git; +Cc: Brandon Williams
removed function prototypes from pathspec.h which don't have a
corresponding implementation.
Signed-off-by: Brandon Williams <bmwill@google.com>
---
pathspec.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/pathspec.h b/pathspec.h
index 4a80f6f..59809e4 100644
--- a/pathspec.h
+++ b/pathspec.h
@@ -96,7 +96,5 @@ static inline int ps_strcmp(const struct pathspec_item *item,
extern char *find_pathspecs_matching_against_index(const struct pathspec *pathspec);
extern void add_pathspec_matches_against_index(const struct pathspec *pathspec, char *seen);
-extern const char *check_path_for_gitlink(const char *path);
-extern void die_if_path_beyond_symlink(const char *path, const char *prefix);
#endif /* PATHSPEC_H */
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* Re: [ANNOUNCE] Git User's Survey 2016
From: Jakub Narębski @ 2016-09-13 16:54 UTC (permalink / raw)
To: David Bainbridge
Cc: git@vger.kernel.org, Doug Rathbone, David Bainbridge,
Stefan Beller, Andrew Ardill, Eric Wong
In-Reply-To: <DB5PR07MB14487D7F217ECA53CD712D60E2FE0@DB5PR07MB1448.eurprd07.prod.outlook.com>
On 13 September 2016 at 18:15, David Bainbridge
<david.bainbridge@ericsson.com> wrote:
> Hi Jakub,
>
> You said:
> P.S. At request I can open a separate channel in survey, with
> a separate survey URL, so that responses from particular site
> or organization could be separated out.
>
> Please can you open a channel for use by Ericsson?
Sent (privately to David).
Best regards,
--
Jakub Narębski
^ permalink raw reply
* Re: [PATCH v2 07/14] i18n: merge-recursive: mark error messages for translation
From: Vasco Almeida @ 2016-09-13 16:54 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Jiang Xin, Ævar Arnfjörð Bjarmason,
Jean-Noël AVILA
In-Reply-To: <xmqqinu13y0x.fsf@gitster.mtv.corp.google.com>
A Seg, 12-09-2016 às 09:04 -0700, Junio C Hamano escreveu:
> Vasco Almeida <vascomalmeida@sapo.pt> writes:
>
> >
> > Lowercase first word of such error messages following the usual
> > style.
>
> "Change X to lowercase" is fine, but "Lowercase" is not a verb.
>
> Reword it to "Downcase the first word...", perhaps (not limited to
> this step).
Lowercase is a verb [1] meaning to print or write with a lowercase
letter or letters. Knowing that can the commit message be kept?
[1] http://www.dictionary.com/browse/lowercase
^ permalink raw reply
* [PATCH] checkout: constify parameters of checkout_stage() and checkout_merged()
From: René Scharfe @ 2016-09-13 17:11 UTC (permalink / raw)
To: Git List; +Cc: Junio C Hamano
Document the fact that checkout_stage() and checkout_merged() don't
change the objects passed to them by adding the modifier const.
Signed-off-by: Rene Scharfe <l.s.r@web.de>
---
builtin/checkout.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/builtin/checkout.c b/builtin/checkout.c
index 8672d07..afbff3e 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -154,8 +154,8 @@ static int check_stages(unsigned stages, const struct cache_entry *ce, int pos)
return 0;
}
-static int checkout_stage(int stage, struct cache_entry *ce, int pos,
- struct checkout *state)
+static int checkout_stage(int stage, const struct cache_entry *ce, int pos,
+ const struct checkout *state)
{
while (pos < active_nr &&
!strcmp(active_cache[pos]->name, ce->name)) {
@@ -169,7 +169,7 @@ static int checkout_stage(int stage, struct cache_entry *ce, int pos,
return error(_("path '%s' does not have their version"), ce->name);
}
-static int checkout_merged(int pos, struct checkout *state)
+static int checkout_merged(int pos, const struct checkout *state)
{
struct cache_entry *ce = active_cache[pos];
const char *path = ce->name;
--
2.10.0
^ permalink raw reply related
* Bug
From: Mike Hawes @ 2016-09-13 17:18 UTC (permalink / raw)
To: git; +Cc: mh351681
To whom this may concern,
I found a bug in git while trying to push my website.
I redid the process and it happened again.
I also tried it on another computer and it happened again.
I was wondering how to claim a bug?
Thank you,
Michael Hawes
^ permalink raw reply
* Re: Bug
From: Santiago Torres @ 2016-09-13 17:26 UTC (permalink / raw)
To: Mike Hawes; +Cc: git, mh351681
In-Reply-To: <B1BB8E37-C36E-4F4A-BC5F-FDA32CE162AF@gmail.com>
Hi, Michael.
It would be helpful to get more context on what triggered this bug. I'm
not a 'core' dev, so there may be a better way to send this. In general,
you want to state the following:
0) Information about your git installation, host system, etc.
1) Information about your repo (was it GitHub? local? self-hosted?)
2) What did you do? (git push origin master? git push?)
3) What happened instead of working? (the error message would be
helpful.
Hope this helps.
Cheers!
-Santiago.
On Tue, Sep 13, 2016 at 01:18:52PM -0400, Mike Hawes wrote:
> To whom this may concern,
>
> I found a bug in git while trying to push my website.
>
> I redid the process and it happened again.
>
> I also tried it on another computer and it happened again.
>
> I was wondering how to claim a bug?
>
> Thank you,
>
>
> Michael Hawes
^ permalink raw reply
* [PATCH] unpack-trees: pass checkout state explicitly to check_updates()
From: René Scharfe @ 2016-09-13 17:37 UTC (permalink / raw)
To: Git List; +Cc: Junio C Hamano
Add a parameter for the struct checkout variable to check_updates()
instead of using a static global variable. Passing it explicitly makes
object ownership and usage more easily apparent. And we get rid of a
static variable; those can be problematic in library-like code.
Signed-off-by: Rene Scharfe <l.s.r@web.de>
---
unpack-trees.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/unpack-trees.c b/unpack-trees.c
index 11c37fb..74d6dd4 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -218,8 +218,8 @@ static void unlink_entry(const struct cache_entry *ce)
schedule_dir_for_removal(ce->name, ce_namelen(ce));
}
-static struct checkout state;
-static int check_updates(struct unpack_trees_options *o)
+static int check_updates(struct unpack_trees_options *o,
+ const struct checkout *state)
{
unsigned cnt = 0, total = 0;
struct progress *progress = NULL;
@@ -264,7 +264,7 @@ static int check_updates(struct unpack_trees_options *o)
display_progress(progress, ++cnt);
ce->ce_flags &= ~CE_UPDATE;
if (o->update && !o->dry_run) {
- errs |= checkout_entry(ce, &state, NULL);
+ errs |= checkout_entry(ce, state, NULL);
}
}
}
@@ -1094,6 +1094,7 @@ int unpack_trees(unsigned len, struct tree_desc *t, struct unpack_trees_options
int i, ret;
static struct cache_entry *dfc;
struct exclude_list el;
+ struct checkout state;
if (len > MAX_UNPACK_TREES)
die("unpack_trees takes at most %d trees", MAX_UNPACK_TREES);
@@ -1239,7 +1240,7 @@ int unpack_trees(unsigned len, struct tree_desc *t, struct unpack_trees_options
}
o->src_index = NULL;
- ret = check_updates(o) ? (-2) : 0;
+ ret = check_updates(o, &state) ? (-2) : 0;
if (o->dst_index) {
if (!ret) {
if (!o->result.cache_tree)
--
2.10.0
^ permalink raw reply related
* [PATCH] sha1_file: use llist_mergesort() for sorting packs
From: René Scharfe @ 2016-09-13 17:54 UTC (permalink / raw)
To: Git List, Jeff King; +Cc: Junio C Hamano
Sort the linked list of packs directly using llist_mergesort() instead
of building an array, calling qsort(3) and fixing up the list pointers.
This is shorter and less complicated.
Signed-off-by: Rene Scharfe <l.s.r@web.de>
---
Peff: Or do you have other plans, e.g. to replace packed_git with
packed_git_mru completely?
sha1_file.c | 39 +++++++++++++++------------------------
1 file changed, 15 insertions(+), 24 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index 472ccb2..66dccaa 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -25,6 +25,7 @@
#include "dir.h"
#include "mru.h"
#include "list.h"
+#include "mergesort.h"
#ifndef O_NOATIME
#if defined(__linux__) && (defined(__i386__) || defined(__PPC__))
@@ -1380,10 +1381,20 @@ static void prepare_packed_git_one(char *objdir, int local)
strbuf_release(&path);
}
+static void *get_next_packed_git(const void *p)
+{
+ return ((const struct packed_git *)p)->next;
+}
+
+static void set_next_packed_git(void *p, void *next)
+{
+ ((struct packed_git *)p)->next = next;
+}
+
static int sort_pack(const void *a_, const void *b_)
{
- struct packed_git *a = *((struct packed_git **)a_);
- struct packed_git *b = *((struct packed_git **)b_);
+ const struct packed_git *a = a_;
+ const struct packed_git *b = b_;
int st;
/*
@@ -1410,28 +1421,8 @@ static int sort_pack(const void *a_, const void *b_)
static void rearrange_packed_git(void)
{
- struct packed_git **ary, *p;
- int i, n;
-
- for (n = 0, p = packed_git; p; p = p->next)
- n++;
- if (n < 2)
- return;
-
- /* prepare an array of packed_git for easier sorting */
- ary = xcalloc(n, sizeof(struct packed_git *));
- for (n = 0, p = packed_git; p; p = p->next)
- ary[n++] = p;
-
- qsort(ary, n, sizeof(struct packed_git *), sort_pack);
-
- /* link them back again */
- for (i = 0; i < n - 1; i++)
- ary[i]->next = ary[i + 1];
- ary[n - 1]->next = NULL;
- packed_git = ary[0];
-
- free(ary);
+ packed_git = llist_mergesort(packed_git, get_next_packed_git,
+ set_next_packed_git, sort_pack);
}
static void prepare_packed_git_mru(void)
--
2.10.0
^ permalink raw reply related
* Re: [PATCH] sha1_file: use llist_mergesort() for sorting packs
From: Jeff King @ 2016-09-13 18:13 UTC (permalink / raw)
To: René Scharfe; +Cc: Git List, Junio C Hamano
In-Reply-To: <a313343b-173e-4a07-f383-859a6f262651@web.de>
On Tue, Sep 13, 2016 at 07:54:42PM +0200, René Scharfe wrote:
> Sort the linked list of packs directly using llist_mergesort() instead
> of building an array, calling qsort(3) and fixing up the list pointers.
> This is shorter and less complicated.
Makes sense.
> Peff: Or do you have other plans, e.g. to replace packed_git with
> packed_git_mru completely?
Nope. I haven't looked into it, but I think there would be some benefit
to replacing packed_git_mru with the code in list.h. But I don't see any
benefit in replacing packed_git with that, or with the MRU itself (once
list.h is in use, one _could_ shove the MRU into packed_git itself, but
I think we would still retain the original link order for reference).
Thanks for asking.
-Peff
^ permalink raw reply
* Re: [PATCH] strbuf: use valid pointer in strbuf_remove()
From: Jeff King @ 2016-09-13 18:14 UTC (permalink / raw)
To: René Scharfe; +Cc: Git List, Junio C Hamano
In-Reply-To: <408af1a3-6867-2ff5-c97f-3eb884412ad8@web.de>
On Tue, Sep 13, 2016 at 06:40:22PM +0200, René Scharfe wrote:
> The fourth argument of strbuf_splice() is passed to memcpy(3), which is
> not supposed to handle NULL pointers. Let's be extra careful and use a
> valid empty string instead. It even shortens the source code. :)
Heh. Looks obviously correct and like a good thing to do.
-Peff
^ permalink raw reply
* Re: [PATCH] pathspec: removed unnecessary function prototypes
From: Jeff King @ 2016-09-13 18:15 UTC (permalink / raw)
To: Brandon Williams; +Cc: git
In-Reply-To: <1473785571-60439-1-git-send-email-bmwill@google.com>
On Tue, Sep 13, 2016 at 09:52:51AM -0700, Brandon Williams wrote:
> removed function prototypes from pathspec.h which don't have a
> corresponding implementation.
I'm always curious of the "why" in cases like this. Did we forget to add
them? Did they get renamed? Did they go away?
Looks like the latter; 5a76aff (add: convert to use parse_pathspec,
2013-07-14) just forgot to remove them.
-Peff
^ permalink raw reply
* Re: [PATCH] checkout: constify parameters of checkout_stage() and checkout_merged()
From: Jeff King @ 2016-09-13 18:18 UTC (permalink / raw)
To: René Scharfe; +Cc: Git List, Junio C Hamano
In-Reply-To: <a66eedc3-fc86-dd45-628c-e38018a03808@web.de>
On Tue, Sep 13, 2016 at 07:11:52PM +0200, René Scharfe wrote:
> Document the fact that checkout_stage() and checkout_merged() don't
> change the objects passed to them by adding the modifier const.
Hmm. Sometimes these big "context" objects are hard to make const,
because we end up using them to hold or pass state between functions
(e.g., see diff_options). So I'd worry slightly that we'll end up
un-consting this in the long run.
That being said, it is easy to revert, and it provides some small
benefit, so I don't mind it in the meantime.
-Peff
^ permalink raw reply
* Re: [ANNOUNCE] Git User's Survey 2016
From: Lars Schneider @ 2016-09-13 20:11 UTC (permalink / raw)
To: Jakub Narębski
Cc: David Bainbridge, git@vger.kernel.org, Doug Rathbone,
David Bainbridge, Stefan Beller, Andrew Ardill, Eric Wong
In-Reply-To: <CANQwDwcLrfkj96pqOM8b=TUWCf-Ui6s9WFo75MoWKfGGvsvZmg@mail.gmail.com>
> On 13 Sep 2016, at 17:54, Jakub Narębski <jnareb@gmail.com> wrote:
>
> On 13 September 2016 at 18:15, David Bainbridge
> <david.bainbridge@ericsson.com> wrote:
>> Hi Jakub,
>>
>> You said:
>> P.S. At request I can open a separate channel in survey, with
>> a separate survey URL, so that responses from particular site
>> or organization could be separated out.
>>
>> Please can you open a channel for use by Ericsson?
>
> Sent (privately to David).
Could you send me a channel for Autodesk, too?
Thank you,
Lars
^ permalink raw reply
* Re: [PATCH v2 09/14] i18n: notes: mark error messages for translation
From: Jean-Noël AVILA @ 2016-09-13 20:23 UTC (permalink / raw)
To: Vasco Almeida
Cc: git, Jiang Xin, Ævar Arnfjörð Bjarmason,
Junio C Hamano
In-Reply-To: <1473784505.7329.18.camel@sapo.pt>
On mardi 13 septembre 2016 16:35:05 CEST Vasco Almeida wrote:
> A Seg, 12-09-2016 às 14:23 +0200, Jean-Noël Avila escreveu:
> > Not sure this one will be easy to localize. The verb is passed as a
> > parameter : see line 366 "list", line 426 "add", line 517 "copy",
> > line
> > 658 "show", line 816 "merge", line 908 "remove" or line 595 with
> > argv[0].
> >
> > If all the verbs are real subcommands, then the translators should be
> > warned that this is some english twisting, but that they need to
> > refer
> > to the subcommand on the command line.
>
> Yes, these verbs are git notes subcommands. I will add a Translators
> comment to it explaining so. Or we can unfold that error messages like
>
> if (!strcmp(subcommand, "add")
> die(_("Refusing to add notes in %s (outside of refs/notes/)"),
> ref);
> elseif ...
>
> else
> die(_("Refusing to %s notes in %s (outside of refs/notes/)"),
> subcommand, ref);
This would be counter productive to use the inject strings as keys just to
test them just after.
>
> This is more verbose but translations would benefit from it being more
> natural. What do we prefer: (1) concise source and a little unnatural
> translations or (2) verbose code and natural translations?
>
> Compare, imaging that English is a target translation language, the
> user would read:
> "Refusing to do add of notes in /path [...]" (1)
> "Refusing do add notes in /path [...]" (2)
Having one sentence per action is cumbersome, but avoiding sentence lego is
mandatory for proper i18n. How about just adding quotes around the subcommand
and warn translators ?
^ 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