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
> > Would something like git clean --exclude=file-pattern work as a
> > compromise notion? Files matching the pattern would not be cleaned
> > regardless of .gitignore or their potential preciousness status
> > long-term. Multiple repetitions of the --exclude option might be
> > supportable. I
Hi,friend,
This is Daniel Murray and i am from Sinara Group Co.Ltd in Russia.
We are glad to know about your company from the web and we are interested in
your products.
Could you kindly send us your Latest catalog and price list for our trial order.
Best Regards,
Daniel Murray
Purchasing
Carlo Marcelo Arenas Belón writes:
> ea2d20d4c2 ("t5004: avoid using tar for checking emptiness of archive",
> 2013-05-09), introduced a fake empty tar archive to allow for portable
> tests of emptiness without having to invoke tar
>
> 4318094047 ("archive: don't add empty directories to
Frank Schäfer writes:
> Hi Junio,
>
> Am 29.11.18 um 03:11 schrieb Junio C Hamano:
> [...]
>> This was misspoken a bit. Let's revise it to
>>
>> When producing a colored output (not limited to whitespace
>> error coloring of diff output) for contents that are not
>> marked as
"H.Merijn Brand" writes:
> When $PATH contains the current directory as .:PATH, PATH:., PATH:.:PATH,
> or (maybe worse) as :PATH, PATH:, or PATH::PATH - as an empty entry is
> identical to having dot in $PATH - this test used to fail
It is totally unclear what "this test" refers to. Let's
Jeff King writes:
> Since the test is ultimately checking "can we run should-not-run from
> the current directory", might it be simpler to actually try that as the
> precondition? I.e., something like:
> ...
A nice egg of columbus. It also would save us from mischievous
users who have
Am 02.12.18 um 20:31 schrieb Frank Schäfer:
Am 29.11.18 um 03:11 schrieb Junio C Hamano:
[...]
This was misspoken a bit. Let's revise it to
When producing a colored output (not limited to whitespace
error coloring of diff output) for contents that are not
marked as
Greetings
My name is Miss Alizata Aron. It give me a great pleasure to write you, it
attracts me to write to you so that we can be friends if you will have the
desire as me. i will be very happy to be in communication with you so that we
can get to know each other better and see what
Hi Peff,
On Sat, 1 Dec 2018, 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
Thomas Gummerer writes:
> Agreed, I think --{no-,}overlay is a much better name for the option,
> I'll use that for my patch series (I hope to send that soon after 2.20
> is released).
OK.
> I must admit that I was not aware that the mode is called overlay
> mode, before you explained it to
Jiang Xin writes:
> Git v2.20.0-rc2 has been released, and there are 5 new messages need to
> be translated. So let's start new round of l10n for Git 2.20.0.
A huge thanks, as always, to the translation team. Jiang, sorry to
see that -rc2 slipped just after you sent out the round 2 message
and
We are licensed loan company, rendering our customers with amount they need is
our main priority. We offer all kinds of loans. reply us now for more details.
"Randall S. Becker" writes:
> Would something like git clean --exclude=file-pattern work as a
> compromise notion? Files matching the pattern would not be cleaned
> regardless of .gitignore or their potential preciousness status
> long-term. Multiple repetitions of the --exclude option might be
Hi Junio,
Am 29.11.18 um 03:11 schrieb Junio C Hamano:
[...]
> This was misspoken a bit. Let's revise it to
>
> When producing a colored output (not limited to whitespace
> error coloring of diff output) for contents that are not
> marked as eol=crlf (and other historical
On 11/30, Junio C Hamano wrote:
>
> I am unsure about the wisdom of calling it "--index", though.
>
> The "--index" option is "the command can work only on the index, or
> only on the working tree files, or on both the index and the working
> tree files, and this option tells it to work in the
--
Hello?
I apologize for invading your privacy, especially by contacting you with
this tool. I have a commercial offer (7,800,000.00 dollar left by my last
client who worked and lived here in my country, I appeal to you because you
share the same last name with the deceased, please reply
On December 2, 2018 8:26, Ævar Arnfjörð Bjarmason wrote:
>
> On Sat, Dec 01 2018, Cameron Boehmer wrote:
>
> > 1) add a new flag
> > -l, --local
> > Do not consult git config --global core.excludesFile in
> > determining what files git ignores. This is useful in conjunction with
> > -x/-X to
On Sun, 2 Dec 2018, Duy Nguyen wrote:
> On Sun, Dec 2, 2018 at 6:05 PM Robert P. J. Day wrote:
> > > Patch update>> 2
> > > staged unstaged path
> > > * 1:unchanged+1/-0 README.md
> > > * 2:unchanged+1/-0 contrib/README
> > > 3:unchanged
On Sun, Dec 2, 2018 at 6:05 PM Robert P. J. Day wrote:
> > Patch update>> 2
> > staged unstaged path
> > * 1:unchanged+1/-0 README.md
> > * 2:unchanged+1/-0 contrib/README
> > 3:unchanged+1/-0 t/README
> > Patch update>>
> >
> >
On Sun, 2 Dec 2018, SZEDER Gábor wrote:
> On Sun, Dec 02, 2018 at 11:30:19AM -0500, Robert P. J. Day wrote:
> >
> > testing adding by patch for the very first time (i've just never
> > needed this), and reading the "progit" book and reading the man page,
> > and the impression i'm getting is
On Sun, 2 Dec 2018, SZEDER Gábor wrote:
> On Sun, Dec 02, 2018 at 11:30:19AM -0500, Robert P. J. Day wrote:
> >
> > testing adding by patch for the very first time (i've just never
> > needed this), and reading the "progit" book and reading the man page,
> > and the impression i'm getting is
On Sun, 2 Dec 2018, Kevin Daudt wrote:
> On Sun, Dec 02, 2018 at 11:30:19AM -0500, Robert P. J. Day wrote:
> >
> > testing adding by patch for the very first time (i've just never
> > needed this), and reading the "progit" book and reading the man page,
> > and the impression i'm getting is
On Sun, Dec 02, 2018 at 11:30:19AM -0500, Robert P. J. Day wrote:
>
> testing adding by patch for the very first time (i've just never
> needed this), and reading the "progit" book and reading the man page,
> and the impression i'm getting is that running "git add -p" (going
> straight to patch
On Sun, Dec 02, 2018 at 11:30:19AM -0500, Robert P. J. Day wrote:
>
> testing adding by patch for the very first time (i've just never
> needed this), and reading the "progit" book and reading the man page,
> and the impression i'm getting is that running "git add -p" (going
> straight to patch
testing adding by patch for the very first time (i've just never
needed this), and reading the "progit" book and reading the man page,
and the impression i'm getting is that running "git add -p" (going
straight to patch mode) is supposed to be equivalent to running "git
add -i", then typing
On Sun, 2 Dec 2018, Æ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
On Fri, Feb 09 2018, Nguyễn Thái Ngọc Duy wrote:
> +static int show_gitcomp(struct parse_opt_ctx_t *ctx,
> + const struct option *opts)
> +{
Says it returns 'static int'...
> [...]
> + exit(0);
Then just exits...
> + /* lone --git-completion-helper is
On Sat, Dec 01 2018, Cameron Boehmer wrote:
> 1) add a new flag
> -l, --local
> Do not consult git config --global core.excludesFile in
> determining what files git ignores. This is useful in conjunction with
> -x/-X to preserve user files while removing build artifacts.
Or perhaps a
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 kernel git repo
> for most of my examples).
>
> is
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 kernel git repo
for most of my examples).
is there a way to display the objects in the object database
Am 13.11.2018 um 11:02 schrieb Ævar Arnfjörð Bjarmason:
>
> On Mon, Nov 12 2018, Ævar Arnfjörð Bjarmason wrote:
>
>> On Mon, Nov 12 2018, Ævar Arnfjörð Bjarmason wrote:
>>
>>> I get:
>>>
>>> Test origin/master
>>> peff/jk/loose-cache
On Sun, Dec 2, 2018 at 11:13 AM 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 as
`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 as expected.
When is an = needed? What is the reason for these
Junio C Hamano writes:
> Cameron Boehmer writes:
>
>> 1) add a new flag
>> -l, --local
>> Do not consult git config --global core.excludesFile in
>> determining what files git ignores. This is useful in conjunction with
>> -x/-X to preserve user files while removing build artifacts.
> ...
>
On Sat, Dec 01, 2018 at 09:28:47PM -0500, Eric Sunshine wrote:
> On Sat, Dec 1, 2018 at 3:02 PM Jeff King wrote:
> > On Thu, Nov 29, 2018 at 09:32:48AM +0100, Johannes Schindelin wrote:
> > > In reality, I think that it would even make sense to change the default to
> > > reschedule failed
Hi,
Git v2.20.0-rc2 has been released, and there are 5 new messages need to
be translated. So let's start new round of l10n for Git 2.20.0. See commit:
l10n: git.pot: v2.20.0 round 3 (5 new, 3 removed)
Generate po/git.pot from v2.20.0-rc2 for git v2.20.0 l10n round 3.
FWIW this patch doesn't have any other siblings and subject should had
been just [PATCH]; apologize for the confusion and the spam (including
that other duplicated email, and most likely this one)
Carlo
this "fixes" test 23 (proper error on directory "files") from t1308
MirBSD likely also affected but this was only tested with OpenBSD and
therefore this specific change only affects that platform
the optional 'configure' sets this automatically (tested with 6.1 to 6.4)
but considering this is a
ea2d20d4c2 ("t5004: avoid using tar for checking emptiness of archive",
2013-05-09), introduced a fake empty tar archive to allow for portable
tests of emptiness without having to invoke tar
4318094047 ("archive: don't add empty directories to archives", 2017-09-13)
changed the expected result
ea2d20d4c2 ("t5004: avoid using tar for checking emptiness of archive",
2013-05-09), introduced a fake empty tar archive to allow for portable
tests of emptiness without having to invoke tar
4318094047 ("archive: don't add empty directories to archives", 2017-09-13)
changed the expected result
On Sat, Dec 1, 2018 at 3:02 PM Jeff King wrote:
> On Thu, Nov 29, 2018 at 09:32:48AM +0100, Johannes Schindelin wrote:
> > In reality, I think that it would even make sense to change the default to
> > reschedule failed `exec` commands. Which is why I suggested to also add a
> > config option.
>
Good day,
My Name is Johann Reimann and i have something important to discuss with you
but only with your permission i will proceed.
Regards
J. Reimann
301 - 400 of 197272 matches
Mail list logo
