Signed-off-by: Ralf Thielow
---
v2 updates the translation up to the latest update of git.pot.
range-diff:
1: f0a6c76bf ! 1: f8313495e l10n: update German translation
@@ -205,13 +205,13 @@
-msgstr ""
+msgstr "Falsche Reihenfolge bei multi-pack-index Pack-Namen: '%s' vor
'%s'"
On Mon, Nov 26, 2018 at 09:03:37PM +0100, SZEDER Gábor wrote:
> Test scripts checking 'git daemon' stop the daemon with a TERM signal,
> and the 'stop_git_daemon' helper checks the daemon's exit status to
> make sure that it indeed died because of that signal.
>
> This check is bogus since
I had to read this sentence a few times to understand it. Let's try to
clarify it.
Signed-off-by: Martin Ågren
---
Documentation/RelNotes/2.20.0.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/RelNotes/2.20.0.txt
b/Documentation/RelNotes/2.20.0.txt
index
We have three double-quote characters, which is one too many or too few.
Dropping the last one seems to match the original intention best.
Signed-off-by: Martin Ågren
---
Documentation/RelNotes/2.20.0.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Some items that should be in "Performance, Internal Implementation,
Development Support etc." have ended up in "UI, Workflows & Features".
Move them, and do s/uses/use/ while at it.
Signed-off-by: Martin Ågren
---
Documentation/RelNotes/2.20.0.txt | 10 +-
1 file changed, 5
On Tue, 4 Dec 2018 at 03:23, Junio C Hamano wrote:
>
> Martin Ågren writes:
>
> > Some items that should be in "Performance, Internal Implementation,
> > Development Support etc." have ended up in "UI, Workflows & Features"
> > and "Fixes since v2.19". Move them, and do s/uses/use/ while at it.
On Mon, 3 Dec 2018 at 22:21, Eric Sunshine wrote:
> [es: retain diff coloring when going to stdout]
>
> Signed-off-by: Martin Ågren
> Signed-off-by: Eric Sunshine
> ---
>
> This is a re-roll of Martin's v2[1]. The only difference from v2 is that
> it retains coloring when emitting to the
On Dec 3, 2018, at 8:50 PM, Jeff King wrote:
>
> I don't suppose this is leaving those incoming-* directories sitting
> around so we can inspect their permissions (it's suppose to clean them
> up, so I doubt it). If you're up for it, it might be interesting to
> patch Git to inspect the umask
On Mon, Dec 03, 2018 at 08:19:12PM -0800, Jamie Zawinski wrote:
> On Dec 3, 2018, at 8:09 PM, Jeff King wrote:
> >
> > but it works fine. Might there be some effective-uid trickiness with the
> > way the server side of git is invoked? Or is this a network mount where
> > the filesystem uid
On Dec 3, 2018, at 8:19 PM, Jamie Zawinski wrote:
>
> (Oh, I didn't check what umask was, but it should have been 022...)
Typo, I mean to say 002.
--
Jamie Zawinski https://www.jwz.org/ https://www.dnalounge.com/
On Dec 3, 2018, at 8:09 PM, Jeff King wrote:
>
> but it works fine. Might there be some effective-uid trickiness with the
> way the server side of git is invoked? Or is this a network mount where
> the filesystem uid might not match the process uid?
Huh. They're on the same ext4 fs (it's an AWS
On Mon, Dec 03, 2018 at 07:27:13PM -0800, Jamie Zawinski wrote:
> I think sharedrepository=group stopped working some time between
> 2.10.5 (works) and 2.12.4 (does not). 2.19.2 also does not.
Hmm. Given the time-frame and the fact that your strace shows problems
writing into the
I think sharedrepository=group stopped working some time between 2.10.5 (works)
and 2.12.4 (does not). 2.19.2 also does not.
I have a user trying to push to a shared repo; the user is not the owner of the
files but it is in the same group. All the repo files are g+rw and all the repo
Elijah Newren writes:
>> +Updates files in the working tree to match the version in the index
>> +or the specified tree.
>> +
>> +'git restore-files' [--from=] ...::
>
> and ? I understand and ,
> or but have no clue why it'd be okay to specify
> and together. What does that even mean?
I
Jonathan Nieder writes:
> Stefan Beller wrote:
>> On Mon, Dec 3, 2018 at 3:23 PM Jonathan Nieder wrote:
>
>>> I was curious about what versions of Gerrit this is designed to
>>> support (or in other words whether it's a bug fix or a feature).
Well, bf1a11f0 ("sideband: highlight keywords in
Johannes Sixt writes:
> Am 03.12.18 um 21:42 schrieb Martin Ågren:
>> On Mon, 3 Dec 2018 at 18:35, Johannes Sixt wrote:
>>> I actually did not test the result, because I don't have the
>>> infrastructure.
>>
>> I've tested with asciidoc and Asciidoctor, html and man-page. Looks
>> good.
>
>
Junio C Hamano writes:
> If "git clean" takes a pathspec, perhaps you can give a negative
> pathspec to exclude whatever you do not want to get cleaned,
> something like
>
> git clean '*.o' ':!precious.o'
>
> to say "presious.o is ignored (hence normally expendable), but I do
> not want to
Martin Ågren writes:
> We have three double-quote characters, which is one too many or too few.
> Dropping the last one seems to match the original intention best.
Thanks for spotting. The actual original intention was that the
user says two things:
first saying "add only what does
Martin Ågren writes:
> I had to read this sentence a few times to understand it. Let's try to
> clarify it.
Great. Thanks.
>
> Signed-off-by: Martin Ågren
> ---
> Documentation/RelNotes/2.20.0.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
Martin Ågren writes:
> Some items that should be in "Performance, Internal Implementation,
> Development Support etc." have ended up in "UI, Workflows & Features"
> and "Fixes since v2.19". Move them, and do s/uses/use/ while at it.
>
> Signed-off-by: Martin Ågren
> ---
I agree with the early
Jeff King writes:
> That said, our C99 designated initializer weather-balloons haven't
> gotten any complaints yet. So I think you could actually do:
>
> struct setup_revision_opt s_r_opt = {
> .allow_exclude_promisor_objects = 1,
> };
> ...
> setup_revisions(...);
>
> which is
On Mon, Dec 03, 2018 at 03:37:35PM -0800, Jonathan Tan wrote:
> Signed-off-by: Jonathan Tan
> ---
> Documentation/technical/packfile-uri.txt | 83
> Documentation/technical/protocol-v2.txt | 6 +-
> 2 files changed, 88 insertions(+), 1 deletion(-)
> create mode 100644
Eric Sunshine writes:
> This is a re-roll of Martin's v2[1]. The only difference from v2 is that
> it retains coloring when emitting to the terminal (plus an in-code
> comment was simplified).
>
> The regression introduced by d8981c3f88, in which the range-diff only
> ever gets emitted to the
On Thu, Nov 29, 2018 at 2:01 PM Nguyễn Thái Ngọc Duy wrote:
>
> v3 sees switch-branch go back to switch-branch (in v2 it was
> checkout-branch). checkout-files is also renamed restore-files (v1 was
> restore-paths). Hopefully we won't see another rename.
I started reading through the patches. I
On Thu, Nov 29, 2018 at 2:03 PM Nguyễn Thái Ngọc Duy wrote:
>
> "git checkout" doing too many things is a source of confusion for many
> users (and it even bites old timers sometimes). To rememdy that, the
> command is now split in two: switch-branch and checkout-files. The
"checkout-files"
On Mon, Dec 3, 2018 at 3:37 PM Jonathan Tan wrote:
>
> Subsequent patches will change how the output of pack-objects is
> processed, so extract that processing into its own function.
>
> Currently, at most 1 character can be buffered (in the "buffered" local
> variable). One of those patches will
Thanks for bringing this design to the list!
> diff --git a/Documentation/technical/protocol-v2.txt
> b/Documentation/technical/protocol-v2.txt
> index 345c00e08c..2cb1c41742 100644
> --- a/Documentation/technical/protocol-v2.txt
> +++ b/Documentation/technical/protocol-v2.txt
> @@ -313,7 +313,8
On Mon, Dec 3, 2018 at 3:37 PM Jonathan Tan wrote:
>
> There is a potential issue: a server which produces both the URIs and
> the packfile at roughly the same time (like the implementation in this
> patch set) will not have sideband access until it has concluded sending
> the URIs. Among other
> diff --git a/pkt-line.c b/pkt-line.c
> index 04d10bbd0..ce9e42d10 100644
> --- a/pkt-line.c
> +++ b/pkt-line.c
> @@ -346,6 +346,10 @@ enum packet_read_status packet_read_with_status(int fd,
> char **src_buffer,
> return PACKET_READ_EOF;
> }
>
> + if
Stefan Beller wrote:
> On Mon, Dec 3, 2018 at 3:23 PM Jonathan Nieder wrote:
>> I was curious about what versions of Gerrit this is designed to
>> support (or in other words whether it's a bug fix or a feature).
>> Looking at examples like [1], it seems that Gerrit historically always
>> used
Some of us have been working on a design to improve the scalability of
Git servers by allowing them to offload part of the packfile response to
CDNs in this way: returning HTTP(S) URIs in fetch responses in addition
to packfiles.
This can reduce the load on individual Git servers and improves
The git command line expects Git servers to follow a specific order of
sections when transmitting protocol v2 responses, but this is not
explicit in the documentation. Make the order explicit.
Signed-off-by: Jonathan Tan
---
Documentation/technical/protocol-v2.txt | 18 --
1
This is a partial implementation of upload-pack sending part of its
packfile response as URIs.
The client is not fully implemented - it knows to ignore the
"packfile-uris" section, but because it does not actually fetch those
URIs, the returned packfile is incomplete. A test is included to show
A subsequent patch allows pack-objects to output additional information
(in addition to the packfile that it currently outputs). This means that
we must hold off on writing the "packfile" section header to the client
before we process the output of pack-objects, so move the writing of
the
Signed-off-by: Jonathan Tan
---
Documentation/technical/packfile-uri.txt | 83
Documentation/technical/protocol-v2.txt | 6 +-
2 files changed, 88 insertions(+), 1 deletion(-)
create mode 100644 Documentation/technical/packfile-uri.txt
diff --git
Subsequent patches will change how the output of pack-objects is
processed, so extract that processing into its own function.
Currently, at most 1 character can be buffered (in the "buffered" local
variable). One of those patches will require a larger buffer, so replace
that "buffered" local
On Mon, Dec 3, 2018 at 3:23 PM Jonathan Nieder wrote:
> I was curious about what versions of Gerrit this is designed to
> support (or in other words whether it's a bug fix or a feature).
> Looking at examples like [1], it seems that Gerrit historically always
> used "ERROR:" so the 59a255aef0
Jonathan Nieder wrote:
> Stefan Beller wrote:
>> /*
>> * Match case insensitively, so we colorize output from existing
>> @@ -95,7 +95,8 @@ static void maybe_colorize_sideband(struct strbuf *dest,
>> const char *src, int n)
>> * messages. We only
Hi,
Stefan Beller wrote:
> When bf1a11f0a1 (sideband: highlight keywords in remote sideband output,
> 2018-08-07) was introduced, it was carefully considered which strings
> would be highlighted. However 59a255aef0 (sideband: do not read beyond
> the end of input, 2018-08-18) brought in a
On Mon, Dec 03, 2018 at 02:30:44PM -0800, Matthew DeVore wrote:
> Here is a one-liner to do it. It is Perl line noise, so it's not very cute,
> thought that is subjective. The output shown below is for the Git project
> (not Linux) repository as I've currently synced it:
>
> $ git rev-list
When bf1a11f0a1 (sideband: highlight keywords in remote sideband output,
2018-08-07) was introduced, it was carefully considered which strings
would be highlighted. However 59a255aef0 (sideband: do not read beyond
the end of input, 2018-08-18) brought in a regression that the original
did not test
On 12/02/2018 05:23 AM, Ævar Arnfjörð Bjarmason wrote:
On Sun, Dec 02 2018, Robert P. J. Day wrote:
as part of an upcoming git class i'm delivering, i thought it would
be amusing to demonstrate the maximum length of colliding SHA-1
prefixes in a repository (in my case, i use the linux
On Mon, Dec 03, 2018 at 02:10:19PM -0800, Matthew DeVore wrote:
> Put the allow_exclude_promisor_objects flag in setup_revision_opt. When
> it was in rev_info, it was unclear when it was used, since rev_info is
> passed to functions that don't use the flag. This resulted in
> unnecessary setting
On Sun, Dec 02, 2018 at 09:07:47PM +1100, Robert White wrote:
> `git log --pretty short` gives the error message "ambiguous argument
> 'short'". To get the expected result, you need to use `git log
> --pretty=short`. However, `git log --since yesterday` and `git log
> --since=yesterday` both work
Put the allow_exclude_promisor_objects flag in setup_revision_opt. When
it was in rev_info, it was unclear when it was used, since rev_info is
passed to functions that don't use the flag. This resulted in
unnecessary setting of the flag in prune.c, so fix that as well.
Signed-off-by: Matthew
On 12/03/2018 01:24 PM, Jeff King wrote:
@@ -297,7 +296,8 @@ struct setup_revision_opt {
const char *def;
void (*tweak)(struct rev_info *, struct setup_revision_opt *);
const char *submodule; /* TODO: drop this and use rev_info->repo */
- int assume_dashdash;
+
On Sun, Dec 02, 2018 at 11:52:50AM +0100, René Scharfe wrote:
> > And for mu.git, a ~20k object repo:
> >
> > Test origin/master
> > peff/jk/loose-cache avar/check-collisions-config
> >
> >
On 12/03/2018 01:15 PM, Jeff King wrote:
That said, our C99 designated initializer weather-balloons haven't
gotten any complaints yet. So I think you could actually do:
struct setup_revision_opt s_r_opt = {
.allow_exclude_promisor_objects = 1,
};
I like this way best, so I'll
On Thu, Nov 29, 2018 at 7:33 AM Duy Nguyen wrote:
>
> On Wed, Nov 28, 2018 at 9:30 PM Stefan Beller wrote:
> >
> > On Wed, Nov 28, 2018 at 12:09 PM Duy Nguyen wrote:
> > >
> > > On Wed, Nov 28, 2018 at 9:01 PM Duy Nguyen wrote:
> > > > should we do
> > > > something about detached HEAD in this
On Mon, Dec 03, 2018 at 06:53:22PM +0100, Duy Nguyen wrote:
> On Sat, Dec 01, 2018 at 03:02:09PM -0500, Jeff King wrote:
> > I sometimes add "x false" to the top of the todo list to stop and create
> > new commits before the first one.
>
> And here I've been doing the same by "edit" the first
On Mon, Dec 03, 2018 at 08:01:44PM +0100, Johannes Schindelin wrote:
> > In this sort of situation, I often whish to be able to do nested rebases.
> > Even more because it happen relatively often that I forget that I'm
> > working in a rebase and not on the head, and then it's quite natural
> >
On Mon, Dec 03, 2018 at 02:31:37PM +, Phillip Wood wrote:
> > How would I move past the test that fails to continue? I guess "git
> > rebase --edit-todo" and then manually remove it (and any other remaining
> > test lines)?
>
> Perhaps we could teach git rebase --skip to skip a rescheduled
On Mon, Dec 03, 2018 at 11:23:56AM -0800, Matthew DeVore wrote:
> Put the allow_exclude_promisor_objects flag in setup_revision_opt. When
> it was in rev_info, it was unclear when it was used, since rev_info is
> passed to functions that don't use the flag. This resulted in
> unnecessary setting
From: Martin Ågren
Commit d8981c3f88 ("format-patch: do not let its diff-options affect
--range-diff", 2018-11-30) taught `show_range_diff()` to accept a
NULL-pointer as an indication that it should use its own "reasonable
default". That fixed a regression from a5170794 ("Merge branch
On Mon, Dec 03, 2018 at 11:10:49AM -0800, Matthew DeVore wrote:
> > > + memset(_r_opt, 0, sizeof(s_r_opt));
> > > + s_r_opt.allow_exclude_promisor_objects = 1;
> > > + setup_revisions(ac, av, , _r_opt);
> >
> > I wonder if a static initializer for setup_revision_opt is worth it. It
> > would
Hi Hannes,
On Mon, 3 Dec 2018, Johannes Sixt wrote:
> The text body of section Behavioral Differences is typeset as code,
> but should be regular text. Remove the indentation to achieve that.
>
> While here, prettify the language:
>
> - use "the x backend" instead of "x-based rebase";
> - use
Am 03.12.18 um 21:42 schrieb Martin Ågren:
On Mon, 3 Dec 2018 at 18:35, Johannes Sixt wrote:
I actually did not test the result, because I don't have the
infrastructure.
I've tested with asciidoc and Asciidoctor, html and man-page. Looks
good.
Thank you so much!
-- Hannes
Team,
Git for Windows v2.20.0-rc2 is available here:
https://github.com/git-for-windows/git/releases/tag/v2.20.0-rc2.windows.1
There is already one known issue: the size of the installer increased (see
https://github.com/git-for-windows/git/issues/1963). This is in the
process of being
On Mon, 3 Dec 2018 at 18:35, Johannes Sixt wrote:
> I actually did not test the result, because I don't have the
> infrastructure.
I've tested with asciidoc and Asciidoctor, html and man-page. Looks
good.
Martin
Some items that should be in "Performance, Internal Implementation,
Development Support etc." have ended up in "UI, Workflows & Features"
and "Fixes since v2.19". Move them, and do s/uses/use/ while at it.
Signed-off-by: Martin Ågren
---
Documentation/RelNotes/2.20.0.txt | 26
I had to read this sentence a few times to understand it. Let's try to
clarify it.
Signed-off-by: Martin Ågren
---
Documentation/RelNotes/2.20.0.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/RelNotes/2.20.0.txt
b/Documentation/RelNotes/2.20.0.txt
index
Hi Junio,
> A release candidate Git v2.20.0-rc2 is now available for testing
> at the usual places. It is comprised of 934 non-merge commits
> since v2.19.0, contributed by 76 people, 25 of which are new faces.
Here are a few suggested tweaks after reading the draft release notes.
Nothing
We have three double-quote characters, which is one too many or too few.
Dropping the last one seems to match the original intention best.
Signed-off-by: Martin Ågren
---
Documentation/RelNotes/2.20.0.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Commit d8981c3f88 ("format-patch: do not let its diff-options affect
--range-diff", 2018-11-30) taught `show_range_diff()` to accept a
NULL-pointer as an indication that it should use its own "reasonable
default". That fixed a regression from a5170794 ("Merge branch
'ab/range-diff-no-patch'",
On Mon, Dec 03, 2018 at 08:01:44PM +0100, Johannes Schindelin wrote:
> Hi Luc,
>
> On Mon, 3 Dec 2018, Luc Van Oostenryck wrote:
>
> > On Sat, Dec 01, 2018 at 03:02:09PM -0500, Jeff King wrote:
> > > I sometimes add "x false" to the top of the todo list to stop and create
> > > new commits
Put the allow_exclude_promisor_objects flag in setup_revision_opt. When
it was in rev_info, it was unclear when it was used, since rev_info is
passed to functions that don't use the flag. This resulted in
unnecessary setting of the flag in prune.c, so fix that as well.
Signed-off-by: Matthew
On 12/01/2018 11:44 AM, Jeff King wrote:
repo_init_revisions(the_repository, , NULL);
save_commit_buffer = 0;
- revs.allow_exclude_promisor_objects_opt = 1;
- setup_revisions(ac, av, , NULL);
+
+ memset(_r_opt, 0, sizeof(s_r_opt));
+
Hi Duy,
On Mon, 3 Dec 2018, Duy Nguyen wrote:
> On Sat, Dec 01, 2018 at 03:02:09PM -0500, Jeff King wrote:
> > I sometimes add "x false" to the top of the todo list to stop and create
> > new commits before the first one.
>
> And here I've been doing the same by "edit" the first commit, add a
>
Hi Luc,
On Mon, 3 Dec 2018, Luc Van Oostenryck wrote:
> On Sat, Dec 01, 2018 at 03:02:09PM -0500, Jeff King wrote:
> > On Thu, Nov 29, 2018 at 09:32:48AM +0100, Johannes Schindelin wrote:
> >
> > > > > Would it not make more sense to add a command-line option (and a
> > > > > config
> > > > >
On Sat, Dec 01, 2018 at 03:02:09PM -0500, Jeff King wrote:
> I sometimes add "x false" to the top of the todo list to stop and create
> new commits before the first one.
And here I've been doing the same by "edit" the first commit, add a
new commit then reorder them in the second interactive
The text body of section Behavioral Differences is typeset as code,
but should be regular text. Remove the indentation to achieve that.
While here, prettify the language:
- use "the x backend" instead of "x-based rebase";
- use present tense instead of future tense;
and use subsections instead
On Sat, Dec 01, 2018 at 03:02:09PM -0500, Jeff King wrote:
> On Thu, Nov 29, 2018 at 09:32:48AM +0100, Johannes Schindelin wrote:
>
> > > > Would it not make more sense to add a command-line option (and a config
> > > > setting) to re-schedule failed `exec` commands? Like so:
> > >
> > > Your
On 01/12/2018 20:02, Jeff King wrote:
On Thu, Nov 29, 2018 at 09:32:48AM +0100, Johannes Schindelin wrote:
Would it not make more sense to add a command-line option (and a config
setting) to re-schedule failed `exec` commands? Like so:
Your proposition would do in most cases, however it is
On Fri, 30 Nov 2018 at 10:32, Eric Sunshine wrote:
>
> On Thu, Nov 29, 2018 at 11:27 PM Junio C Hamano wrote:
> > Junio C Hamano writes:
> > So how about doing this on top of 'master' instead? As this leaks
> > *no* information wrt how range-diff machinery should behave from the
> >
Beloved,
I am writing this mail to you with heavy tears in my eyes and great
sorrow in my heart. As I informed you earlier, I am (Mrs.)Marianne
Jeanne,
suffering from long time Cancer. From all indications
my condition is really deteriorating and it's quite obvious
that I won't live more than
75 matches
Mail list logo
