Johannes Schindelin writes ("Re: [PATCH] rebase: mark the C reimplementation as
an experimental opt-in feature (was Re: [ANNOUNCE] Git v2.20.0-rc1)"):
> if you could pry more information (or better information) out of that bug
> reporter, that would be nice. Apparently my email address is
From: Derrick Stolee
The '--sparse' flag in 'git pack-objects' changes the algorithm
used to enumerate objects to one that is faster for individual
users pushing new objects that change only a small cone of the
working directory. The sparse algorithm is not recommended for a
server, which likely
One of the biggest remaining pain points for users of very large
repositories is the time it takes to run 'git push'. We inspected some slow
pushes by our developers and found that the "Enumerating Objects" phase of a
push was very slow. This is unsurprising, because this is why reachability
From: Derrick Stolee
In preparation for a new algorithm that walks fewer trees when
creating a pack from a set of revisions, create a method that
takes an oidset of tree oids and marks reachable objects as
UNINTERESTING.
The current implementation uses the existing
mark_tree_uninteresting to
From: Derrick Stolee
When creating a pack-file using 'git pack-objects --revs' we provide
a list of interesting and uninteresting commits. For example, a push
operation would make the local topic branch be interesting and the
known remote refs as uninteresting. We want to discover the set of
new
On Thu, Nov 29 2018, Johannes Schindelin wrote:
> Hi Ævar,
>
> On Thu, 29 Nov 2018, Ævar Arnfjörð Bjarmason wrote:
>
>> On Thu, Nov 29 2018, Johannes Schindelin wrote:
>>
>> > On Wed, 28 Nov 2018, Ævar Arnfjörð Bjarmason wrote:
>> >
>> >> Change the semantics of the "--range-diff" option so
From: Derrick Stolee
Create a test variable GIT_TEST_PACK_SPARSE to enable the sparse
object walk algorithm by default during the test suite. Enabling
this variable ensures coverage in many interesting cases, such as
shallow clones, partial clones, and missing objects.
Signed-off-by: Derrick
From: Derrick Stolee
When enumerating objects to place in a pack-file during 'git
pack-objects --revs', we discover the "frontier" of commits
that we care about and the boundary with commit we find
uninteresting. From that point, we walk trees to discover which
trees and blobs are uninteresting.
From: Derrick Stolee
Add a '--sparse' option flag to the pack-objects builtin. This
allows the user to specify that they want to use the new logic
for walking trees. This logic currently does not differ from the
existing output, but will in a later change.
Create a new test script,
On 11/28/2018 5:11 PM, Stefan Beller wrote:
+--sparse::
+ Use the "sparse" algorithm to determine which objects to include in
+ the pack. This can have significant performance benefits when computing
+ a pack to send a small change. However, it is possible that extra
+
Hi Jonathan,
if you could pry more information (or better information) out of that bug
reporter, that would be nice. Apparently my email address is blacklisted
by his mail provider, so he is unlikely to have received my previous mail
(nor will he receive this one, I am sure).
Thanks,
Dscho
On
On 11/28/2018 8:31 AM, SZEDER Gábor wrote:
On Tue, Nov 27, 2018 at 02:50:57PM -0500, Ben Peart wrote:
diff --git a/t/t1092-virtualworkdir.sh b/t/t1092-virtualworkdir.sh
new file mode 100755
index 00..0cdfe9b362
--- /dev/null
+++ b/t/t1092-virtualworkdir.sh
@@ -0,0 +1,393 @@
On 11/28/2018 4:37 AM, Johannes Schindelin wrote:
Hi Ben,
On Tue, 27 Nov 2018, Ben Peart wrote:
From: Ben Peart
Add tracing around initializing and discarding mempools. In discard report
on the amount of memory unused in the current block to help tune setting
the initial_size.
Hi Junio,
On Thu, 29 Nov 2018, Johannes Schindelin wrote:
> On Mon, 26 Nov 2018, Junio C Hamano wrote:
>
> > Junio C Hamano writes:
> >
> > > Thomas Gummerer writes:
> > >
> > >> Thanks for your work on this! I have read through the range-diff and
> > >> the new patch of this last round,
On Thu, 29 Nov 2018 at 14:40, Randall S. Becker wrote:
> On November 29, 2018 6:56, Mateusz Loskot wrote:
> > On Thu, 29 Nov 2018 at 12:50, Stefanie Leisestreichler
> > wrote:
> > >
> > > git tag -a 0.9.0
> > > git push origin master
> > >
> > > In my local repository, when I run "git tag" it
On November 29, 2018 6:56, Mateusz Loskot wrote:
> On Thu, 29 Nov 2018 at 12:50, Stefanie Leisestreichler
> wrote:
> >
> > git tag -a 0.9.0
> > git push origin master
> >
> > In my local repository, when I run "git tag" it is showing me "0.9.0".
> >
> > Then I did (on box B)
> > git clone
Just checked gitk, it seems to work fine including children windows.
This problem seems to affect git-gui only.
On Thu, Nov 29, 2018 at 5:16 AM Eric Sunshine wrote:
>
> On Wed, Nov 28, 2018 at 2:29 PM Stefan Beller wrote:
> > On Wed, Nov 28, 2018 at 6:13 AM Kenn Sebesta wrote:
> > > v2.19.2,
We're really entering obscure territory here, I would say.
To trigger the bug, two things have to come together: the user must have
asked for a diffstat afterwards, and the commits need to have been rebased
onto a completely unrelated commit history (i.e. there must exist no merge
base between
From: Johannes Schindelin
When rebasing to a commit history that has no common commits with the
current branch, there is no merge base. In diffstat mode, this means
that we cannot compare to the merge base, but we have to compare to the
empty tree instead.
Also, if running in verbose diffstat
Hi Junio,
On Mon, 26 Nov 2018, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > Thomas Gummerer writes:
> >
> >> Thanks for your work on this! I have read through the range-diff and
> >> the new patch of this last round, and this addresses all the comments
> >> I had on v10 (and some
Hi Junio,
On Thu, 29 Nov 2018, Junio C Hamano wrote:
> "Johannes Schindelin via GitGitGadget"
> writes:
>
> > The built-in version of the `git rebase` command blindly translated that
> > shell script code, assuming that there is no need to test whether there
> > *was* a merge base, and due to
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
Hi Ævar,
On Thu, 29 Nov 2018, Ævar Arnfjörð Bjarmason wrote:
> On Thu, Nov 29 2018, Johannes Schindelin wrote:
>
> > On Wed, 28 Nov 2018, Ævar Arnfjörð Bjarmason wrote:
> >
> >> Change the semantics of the "--range-diff" option so that the regular
> >> diff options can be provided separately
On Thu, 29 Nov 2018 at 12:50, Stefanie Leisestreichler
wrote:
>
> git tag -a 0.9.0
> git push origin master
>
> In my local repository, when I run "git tag" it is showing me "0.9.0".
>
> Then I did (on box B)
> git clone ssh://user@host:/path/project.git
> cd project
> git tag
>
> Now git tag is
Hi.
I have done this (on box A):
git commit -m "Message"
git tag -a 0.9.0
git push origin master
In my local repository, when I run "git tag" it is showing me "0.9.0".
Then I did (on box B)
git clone ssh://user@host:/path/project.git
cd project
git tag
Now git tag is showing nothing.
Why is
Hi Paul,
On Thu, 29 Nov 2018, Johannes Schindelin wrote:
> I already added a test... See the reschedule-failed-exec branch on
> https://github.com/dscho/git.
And now I put up a proper Pull Request, to be submitted via GitGitGadget
right after Git v2.20.0 will be released (technically, we are in
On Thu, Nov 29 2018, Johannes Schindelin wrote:
> Hi Ævar,
>
> On Wed, 28 Nov 2018, Ævar Arnfjörð Bjarmason wrote:
>
>> Change the semantics of the "--range-diff" option so that the regular
>> diff options can be provided separately for the range-diff and the
>> patch. This allows for supplying
Dear Friend,
I am Abel Brent, a NATO soldier serving in Afghanistan. I and my
Comrades, we are seeking your assistance to help us
receive/invest our funds in your country in any lucrative
business. Please if this proposal is acceptable by you, kindly
respond back to me for more details.
On Wed, Nov 28, 2018 at 2:29 PM Stefan Beller wrote:
> On Wed, Nov 28, 2018 at 6:13 AM Kenn Sebesta wrote:
> > v2.19.2, installed from brew on macOS Mojave 14.2.1.
> >
> > `git-gui` is my much beloved go-to tool for everything git.
> > Unfortunately, on my new Macbook Air it seems to have a bug.
Hi Merijn and Junio,
On Thu, 29 Nov 2018, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > -test_expect_success 'run_command is restricted to PATH' '
> > +test_lazy_prereq DOT_IN_PATH '
> > + case ":$PATH:" in
> > + *:.:*) true;;
> > + *) false;;
> > + esac
> > +'
>
> An
Hi Ævar,
On Wed, 28 Nov 2018, Ævar Arnfjörð Bjarmason wrote:
> Change the semantics of the "--range-diff" option so that the regular
> diff options can be provided separately for the range-diff and the
> patch. This allows for supplying e.g. --range-diff-U0 and -U1 to
> "format-patch" to provide
Masaya Suzuki writes:
> In the Git pack protocol definition, an error packet may appear only in
> a certain context. However, servers can face a runtime error (e.g. I/O
> error) at an arbitrary timing. This patch changes the protocol to allow
> an error packet to be sent instead of any packet.
>
Hi Paul,
On Wed, 28 Nov 2018, Paul Morelle wrote:
> On 28/11/18 16:19, Johannes Schindelin wrote:
> >
> > On Wed, 28 Nov 2018, Paul Morelle wrote:
> >
> >> The 'exec' command can be used to run tests on a set of commits,
> >> interrupting on failing commits to let the user fix the tests.
> >>
>
Junio C Hamano writes:
>> diff --git a/connect.c b/connect.c
>> index 24281b608..458906e60 100644
>> --- a/connect.c
>> +++ b/connect.c
>> @@ -306,8 +306,6 @@ struct ref **get_remote_heads(struct packet_reader
>> *reader,
>> die_initial_contact(1);
>> case
Junio C Hamano writes:
>> +test_expect_success 'log -G ignores binary files' '
>> +git checkout --orphan orphan1 &&
>> +printf "a\0a" >data.bin &&
>> +git add data.bin &&
>> +git commit -m "message" &&
>> +git log -Ga >result &&
>> +test_must_be_empty result
>> +'
>
> As
Thomas Braun writes:
> Subject: Re: [PATCH v2] log -G: Ignore binary files
s/Ig/ig/; (will locally munge--this alone is no reason to reroll).
The code changes looked sensible.
> diff --git a/t/t4209-log-pickaxe.sh b/t/t4209-log-pickaxe.sh
> index 844df760f7..5c3e2a16b2 100755
> ---
Ævar Arnfjörð Bjarmason writes:
> -To skip tests, set the GIT_SKIP_TESTS variable. Individual tests can
> -be skipped:
> +To skip tests, set either the GIT_SKIP_TESTS or GIT_TODO_TESTS
> +variables. The difference is that with SKIP the tests won't be run at
> +all, whereas they will be run with
Nguyễn Thái Ngọc Duy writes:
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> My bad.
>
> transport-helper.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/transport-helper.c b/transport-helper.c
> index 7213fa0d32..bf225c698f 100644
> --- a/transport-helper.c
> +++
Nguyễn Thái Ngọc Duy writes:
> +static struct option *add_switch_branch_options(struct checkout_opts *opts,
> + struct option *prevopts)
> +{
> + struct option options[] = {
> OPT_STRING('b', NULL, >new_branch, N_("branch"),
>
Stefan Xenos writes:
> So - IMO - detaching should always be an explicit action. Some options
> that occur to me:
>
> git switch-branch --detach
That is the most obvious way to spell it, and it is why we have "git
checkout --detach". If we were to split one half of "checkout" into
Duy Nguyen writes:
> I see my deliberate attempt to provoke has failed :D Giving your view
> of the new commands as "training wheels", I take it we still should
> make them visible as much as possible, but we just not try to hide
> "git checkout" as much (e.g. we mention both new and old
Stefan Xenos writes:
> Although I have no problem with "switch-branch" as a command name,
> some alternative names we might consider for switch-branch might be:
>
> chbranch
> swbranch
Please never go in that direction. So far, we made a conscious
effort to keep the names of most frequently
Stefan Beller writes:
> I dislike the checkout-* names, as we already have checkout-index
> as plumbing, so it would be confusing as to which checkout-* command
> should be used when and why as it seems the co-index moves
> content *from index* to the working tree, but the co-files moves content
"Johannes Schindelin via GitGitGadget"
writes:
> The built-in version of the `git rebase` command blindly translated that
> shell script code, assuming that there is no need to test whether there
> *was* a merge base, and due to its better error checking, exited with a
> fatal error (because it
Eric Sunshine writes:
> Playing Devi's Advocate, what if Apple's clang "8" was, in reality,
> real-world clang 3? Then this condition would incorrectly enable the
> compiler option on Apple for a (real) clang version below 4. For this
> reason, it seems we shouldn't be trusting only the clang
Ævar Arnfjörð Bjarmason writes:
> I don't think something like the endgame you've described in
> https://public-inbox.org/git/xmqqzhtwuhpc@gitster-ct.c.googlers.com/
> is ever going to work. Novice git users (the vast majority) are not
> going to diligently update both .gitignore and some
Ævar Arnfjörð Bjarmason writes:
> Since I raised this 'should we hold off?' I thought I'd chime in and say
> that I'm fine with going along with what you suggest and having the
> builtin as the default in the final. IOW not merge
> jc/postpone-rebase-in-c down.
OK.
On 11/28/2018 5:18 PM, Ævar Arnfjörð Bjarmason wrote:
This is really interesting. I tested this with:
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index 124b1bafc4..5c7615f06c 100644
--- a/builtin/pack-objects.c
+++ b/builtin/pack-objects.c
@@ -3143
Ævar Arnfjörð Bjarmason writes:
> + [--range-diff]]
Let's make sure a random string thrown at this mechanism will
properly get noticed and diagnosed.
> @@ -257,6 +258,13 @@ feeding the result to `git send-email`.
> creation/deletion cost fudge factor. See
On Wed, Nov 28, 2018 at 5:19 PM Junio C Hamano wrote:
>
> > Another issue with the canned steps for "git gc" is that it means it
> > can't be used to do specific types of cleanup on a different schedule
> > from others. For example, we use "git pack-refs" directly to
> > frequently pack the refs
Johannes Sixt writes:
> Am 27.11.18 um 00:31 schrieb Junio C Hamano:
>> Johannes Sixt writes:
>>> Am 26.11.18 um 04:04 schrieb Junio C Hamano:
>>> ... this goes too far, IMO. It is the pager's task to decode control
>>> characters.
>>
>> It was tongue-in-cheek suggestion to split a CR into
Johannes Schindelin writes:
> -test_expect_success 'run_command is restricted to PATH' '
> +test_lazy_prereq DOT_IN_PATH '
> + case ":$PATH:" in
> + *:.:*) true;;
> + *) false;;
> + esac
> +'
An empty element in the colon-separated list also serves as an
instruction to pick up
Bryan Turner writes:
> For us, the biggest issue was "git gc"'s insistence on trying to run
> "git reflog expire". That triggers locking behaviors that resulted in
> very frequent GC failures--and the only reflogs Bitbucket Server (by
> default) creates are all configured to never ex[ire or be
On Fri, Oct 26, 2018 at 1:41 PM Jonathan Tan wrote:
>
> > But this default fetch is not sufficient, as a newly fetched commit in
> > the superproject could point to a commit in the submodule that is not
> > in the default refspec. This is common in workflows like Gerrit's.
> > When fetching a
The `changed_submodule_names` are only used for fetching, so let's make it
part of the struct that is passed around for fetching submodules.
Signed-off-by: Stefan Beller
---
submodule.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/submodule.c
Currently when git-fetch is asked to recurse into submodules, it dispatches
a plain "git-fetch -C " (with some submodule related options
such as prefix and recusing strategy, but) without any information of the
remote or the tip that should be fetched.
But this default fetch is not sufficient, as
This is a resend of sb/submodule-recursive-fetch-gets-the-tip,
with all feedback addressed. As it took some time, I'll send it
without range-diff, but would ask for full review.
I plan on resending after the next release as this got delayed quite a bit,
which is why I also rebased it to master.
'calculate_changed_submodule_paths' uses a local list to compute the
changed submodules, and then produces the result by copying appropriate
items into the result list.
Instead use the result list directly and prune items afterwards
using string_list_remove_empty_items.
By doing so we'll have
We can string_list_insert() to maintain sorted-ness of the
list as we find new items, or we can string_list_append() to
build an unsorted list and sort it at the end just once.
As we do not rely on the sortedness while building the
list, we pick the "append and sort at the end" as it
has better
We used to recurse into submodules, even if they were broken having
only an objects directory. The child process executed in the submodule
would fail though if the submodule was broken. This is tested via
"fetching submodule into a broken repository" in t5526.
This patch tightens the check
Keep the properties introduced in 10f5c52656 (submodule: avoid
auto-discovery in prepare_submodule_repo_env(), 2016-09-01), by fixating
the git directory of the submodule.
Signed-off-by: Stefan Beller
---
submodule.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git
When constructing a struct repository for a submodule for some revision
of the superproject where the submodule is not contained in the index,
it may not be present in the working tree currently either. In that
situation giving a 'path' argument is not useful. Upgrade the
repo_submodule_init
Helped-by: Junio C Hamano
Signed-off-by: Stefan Beller
Signed-off-by: Junio C Hamano
---
Documentation/technical/api-oid-array.txt | 5 +
sha1-array.c | 17 +
sha1-array.h | 3 +++
3 files changed, 25 insertions(+)
The submodule subsystem is really bad at staying within 80 characters.
Fix it while we are here.
Signed-off-by: Stefan Beller
Signed-off-by: Junio C Hamano
---
submodule.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/submodule.c b/submodule.c
index
More thoughts:
git switch-branch should never detach HEAD unless asked to do so
explicitly. That also means that "git switch-branch" shouldn't accept
any of the non-branch tree-ish arguments that would have caused "git
checkout" to do so.
On Wed, Nov 28, 2018 at 3:26 PM Stefan Xenos wrote:
>
>
Although I have no problem with "switch-branch" as a command name,
some alternative names we might consider for switch-branch might be:
chbranch
swbranch
switch
branch change (as a subcommand for the "branch" command)
I've personally been using "chbranch" as an alias for this
functionality for
> Since the other one is already "checkout-files", maybe this one could just be
> "checkout-branch".
I rather like switch-branch and dislike the word "checkout" since it
has been overloaded in git for so long (does it mean moving HEAD or
copying files to my working tree?)
> nobody will become
I think users have problems with detached heads for several reasons:
1. Users often enter the detached head state unexpectedly (for
example, by mistyping a "checkout" command or not understanding its
multipurpose nature, or as a side-effect of running a submodule
command). The change described
On Wed, Nov 28 2018, Derrick Stolee via GitGitGadget wrote:
> One of the biggest remaining pain points for users of very large
> repositories is the time it takes to run 'git push'. We inspected some slow
> pushes by our developers and found that the "Enumerating Objects" phase of a
> push was
> +--sparse::
> + Use the "sparse" algorithm to determine which objects to include in
> + the pack. This can have significant performance benefits when
> computing
> + a pack to send a small change. However, it is possible that extra
> + objects are added to the pack-file
On Wed, Nov 28 2018, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
>> What do you think about some patch like that which retains the plumbing
>> behavior for things like read-tree, doesn't introduce "precious" or
>> "trashable", and just makes you specify "[checkout|merge|...]
From: Derrick Stolee
When enumerating objects to place in a pack-file during 'git
pack-objects --revs', we discover the "frontier" of commits
that we care about and the boundary with commit we find
uninteresting. From that point, we walk trees to discover which
trees and blobs are uninteresting.
One of the biggest remaining pain points for users of very large
repositories is the time it takes to run 'git push'. We inspected some slow
pushes by our developers and found that the "Enumerating Objects" phase of a
push was very slow. This is unsurprising, because this is why reachability
From: Derrick Stolee
Add a '--sparse' option flag to the pack-objects builtin. This
allows the user to specify that they want to use the new logic
for walking trees. This logic currently does not differ from the
existing output, but will in a later change.
Create a new test script,
From: Derrick Stolee
The '--sparse' flag in 'git pack-objects' changes the algorithm
used to enumerate objects to one that is faster for individual
users pushing new objects that change only a small cone of the
working directory. The sparse algorithm is not recommended for a
server, which likely
From: Derrick Stolee
When creating a pack-file using 'git pack-objects --revs' we provide
a list of interesting and uninteresting commits. For example, a push
operation would make the local topic branch be interesting and the
known remote refs as uninteresting. We want to discover the set of
new
From: Derrick Stolee
In preparation for a new algorithm that walks fewer trees when
creating a pack from a set of revisions, create a method that
takes an oidset of tree oids and marks reachable objects as
UNINTERESTING.
The current implementation uses the existing
mark_tree_uninteresting to
On Wed, Nov 28, 2018 at 4:43 PM Jean-Noël Avila wrote:
> Translating the new strings introduced for v2.20 showed some typos.
Hard to spot by eyeball when looking at the diff, but both fixes make
sense. Thanks.
> Signed-off-by: Jean-Noël Avila
Translating the new strings introduced for v2.20 showed some typos.
Signed-off-by: Jean-Noël Avila
---
http.c | 2 +-
midx.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/http.c b/http.c
index 3dc8c560d6..eacc2a75ef 100644
--- a/http.c
+++ b/http.c
@@ -834,7 +834,7 @@
On Wed, 28 Nov 2018 at 20:45, Ævar Arnfjörð Bjarmason wrote:
> On Wed, Nov 28 2018, Martin Ågren wrote:
>
> > Asciidoctor removes the indentation of each line in these tables, so the
> > last lines of each table have a completely broken alignment.
>
> Earlier I was trying to get the
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 switch-branch command (or
> > whatever its name will be)?
> >
> > This is usually a confusing concept to new users
>
> And it just
On Tue, Nov 27, 2018 at 10:31 PM Junio C Hamano wrote:
>
> Will writes:
>
> > I’m far from being a guru, but I consider myself a competent Git
> > user. Yet, here’s my understanding of the output of one the most-used
> > commands, `git push`:
> >> Counting objects: 6, done.
> > No idea what an
As noted in 43dafc4172 ("format-patch: don't include --stat with
--range-diff output", 2018-11-22) the diff options provided on the
command-line currently affect both the range-diff and the patch
output, but there was no test for checking this with output where we'd
show a patch diff. Let's add
As noted in 2/2 this fixes the root cause of the bug I plastered over
in
https://public-inbox.org/git/20181122211248.24546-3-ava...@gmail.com/
(that patch is sitting in 'next').
1/2 is a test for existing behavior, to make it more easily understood
what's being changed.
Junio: I know it's late,
Change the semantics of the "--range-diff" option so that the regular
diff options can be provided separately for the range-diff and the
patch. This allows for supplying e.g. --range-diff-U0 and -U1 to
"format-patch" to provide different context for the range-diff and the
patch. This wasn't
On Wed, Nov 28, 2018 at 9:01 PM Duy Nguyen wrote:
> should we do
> something about detached HEAD in this switch-branch command (or
> whatever its name will be)?
>
> This is usually a confusing concept to new users
And it just occurred to me that perhaps we should call this "unnamed
branch" (at
On Tue, Nov 27, 2018 at 5:53 PM Nguyễn Thái Ngọc Duy wrote:
>
> v2 is just a bit better to look at than v1. This is by no means final.
> If you think the command name is bad, the default behavior should
> change, or something else, speak up. It's still very "RFC".
>
> v2 breaks down the giant
On 11/28/2018 2:45 PM, Derrick Stolee wrote:
I was preparing a new "sparse" algorithm for calculating the
interesting objects to send on push. The important steps happen
during 'git pack-objects', so I was creating test cases to see
how the behavior changes in narrow cases. Specifically, when
I was preparing a new "sparse" algorithm for calculating the
interesting objects to send on push. The important steps happen
during 'git pack-objects', so I was creating test cases to see
how the behavior changes in narrow cases. Specifically, when
copying a directory across sibling directories
On Wed, Nov 28 2018, Martin Ågren wrote:
> Asciidoctor removes the indentation of each line in these tables, so the
> last lines of each table have a completely broken alignment.
>
> Similar to 379805051d ("Documentation: render revisions correctly under
> Asciidoctor", 2018-05-06), use an
On Wed, Nov 28, 2018 at 6:13 AM Kenn Sebesta wrote:
>
> v2.19.2, installed from brew on macOS Mojave 14.2.1.
>
> `git-gui` is my much beloved go-to tool for everything git.
> Unfortunately, on my new Macbook Air it seems to have a bug. When I
> first load the program, the parent window populates
On Wed, Nov 28, 2018 at 8:08 PM Stefan Beller wrote:
>
> On Wed, Nov 28, 2018 at 7:31 AM Duy Nguyen wrote:
> >
> > On Wed, Nov 28, 2018 at 7:03 AM Junio C Hamano wrote:
> > >
> > > Nguyễn Thái Ngọc Duy writes:
> > >
> > > > The good old "git checkout" command is still here and will be until
>
On Wed, Nov 28, 2018 at 7:31 AM Duy Nguyen wrote:
>
> On Wed, Nov 28, 2018 at 7:03 AM Junio C Hamano wrote:
> >
> > Nguyễn Thái Ngọc Duy writes:
> >
> > > The good old "git checkout" command is still here and will be until
> > > all (or most of users) are sick of it.
> >
> > Two comments on
Asciidoctor removes the indentation of each line in these tables, so the
last lines of each table have a completely broken alignment.
Similar to 379805051d ("Documentation: render revisions correctly under
Asciidoctor", 2018-05-06), use an explicit literal block to indicate
that we want to keep
On Wed, 28 Nov 2018 at 13:02, Martin Ågren wrote:
>
> On Wed, 28 Nov 2018 at 12:42, Paweł Samoraj wrote:
> >
> > The git-reset documentation page section which is accessible via URL
> > https://git-scm.com/docs/git-reset#_discussion is not looking good.
>
> [...] The correct fix could be
Large parts of this document do not use `backticks` around literal
examples such as branch names (`topic/wip`), git usages, `HEAD` and
`` so they render as ordinary text. Fix that.
Signed-off-by: Martin Ågren
---
Documentation/git-reset.txt | 131 ++--
1 file
On Wed, 28 Nov 2018 at 17:50, Mateusz Loskot wrote:
>
> (using git version 2.19.2.windows.1)
> [...]
> I restored the repo and tried out
>
> git push origin 1.0
> git push origin --tags
>
> and this time both succeeded, without wiping out any refs.
And, to my surprise, this pushed all branches
Hi Johannes,
On 28/11/18 16:19, Johannes Schindelin wrote:
> Hi Paul,
>
> On Wed, 28 Nov 2018, Paul Morelle wrote:
>
>> The 'exec' command can be used to run tests on a set of commits,
>> interrupting on failing commits to let the user fix the tests.
>>
>> However, the 'exec' line has been
Hi,
(using git version 2.19.2.windows.1)
I've just encountered one of those WTH moments.
I have a bare repository
core.git (BARE:master) $ git branch
1.0
2.0
* master
core.git (BARE:master) $ git tag
1.0.1651
1.0.766
2.0.1103
2.0.1200
I published the repo using: git push --all
On Wed, Nov 28, 2018 at 8:12 AM Duy Nguyen wrote:
>
> On Thu, Nov 22, 2018 at 7:32 PM Elijah Newren wrote:
> >
> > In commit f57696802c30 ("rebase: really just passthru the `git am`
> > options", 2018-11-14), the handling of `git am` options was simplified
> > dramatically (and an option parsing
501 - 600 of 197272 matches
Mail list logo
