Hi J.H.
On Wed, 28 Nov 2018, Houder wrote:
> On 2018-11-28 09:46, Johannes Schindelin wrote:
> >
> > On Wed, 28 Nov 2018, J.H. van de Water wrote:
> >
> > > > > me@work /cygdrive
> > > > > $ ls
> > > > > c d
> > > > >
> > > > > So `/cygdrive` *is* a valid directory in Cygwin.
> > > >
> > > >
On 2018-11-28 09:46, Johannes Schindelin wrote:
Hi J.H.,
On Wed, 28 Nov 2018, J.H. van de Water wrote:
> > me@work /cygdrive
> > $ ls
> > c d
> >
> > So `/cygdrive` *is* a valid directory in Cygwin.
>
> That supports the code that does not special case a path that begins
> with /cygdrive/
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.
>
> Signed-off-by: Ben Peart
> ---
Looks good.
My
Hi,
On Wed, 28 Nov 2018, H.Merijn Brand wrote:
> the test is explicitely checking that it should not find runnable
> scripts outside $PATH, *assuming* $PATH does not have . in it
Does this fix it for you?
-- snip --
diff --git a/t/t0061-run-command.sh b/t/t0061-run-command.sh
index
> Junio C Hamano hat am 22. November 2018 um 02:29
> geschrieben:
>
>
> Thomas Braun writes:
>
> > The -G option of log looks for the differences whose patch text
> > contains added/removed lines that match regex.
> >
> > The concept of differences only makes sense for text files, therefore
> Ævar Arnfjörð Bjarmason hat am 22. November 2018 um 10:14
> geschrieben:
>
>
>
> On Wed, Nov 21 2018, Thomas Braun wrote:
>
> > The -S option of log looks for differences that changes the
> > number of occurrences of the specified string (i.e. addition/deletion)
> > in a file.
> >
> > Add
> Junio C Hamano hat am 22. November 2018 um 02:34
> geschrieben:
>
>
> Thomas Braun writes:
>
> > The -S option of log looks for differences that changes the
> > number of occurrences of the specified string (i.e. addition/deletion)
> > in a file.
>
> s/-S /-S/ and
> s/the specified
> Ævar Arnfjörð Bjarmason hat am 22. November 2018 um 11:16
> geschrieben:
[...]
> >
> > +test_expect_success 'log -G ignores binary files' '
> > + rm -rf .git &&
> > + git init &&
> > + printf "a\0b" >data.bin &&
> > + git add data.bin &&
> > + git commit -m "message" &&
> > + git
> Junio C Hamano hat am 27. November 2018 um 01:51
> geschrieben:
>
>
> Stefan Beller writes:
>
> > On Wed, Nov 21, 2018 at 1:08 PM Thomas Braun
> > wrote:
> >>
> >> The -G option of log looks for the differences whose patch text
> >> contains added/removed lines that match regex.
> >>
>
> Jeff King hat am 22. November 2018 um 17:20 geschrieben:
>
>
> On Wed, Nov 21, 2018 at 09:52:27PM +0100, Thomas Braun wrote:
>
> > diff --git a/diffcore-pickaxe.c b/diffcore-pickaxe.c
> > index 69fc55ea1e..8c2558b07d 100644
> > --- a/diffcore-pickaxe.c
> > +++ b/diffcore-pickaxe.c
> > @@
the test is explicitely checking that it should not find runnable
scripts outside $PATH, *assuming* $PATH does not have . in it
Having '.' in $PATH can be seen as a bad idea (and it most likely is),
but the tests should either remove '.' from $PATH before testing or
ignore that fail if $PATH does
Hi Elijah,
On Wed, 21 Nov 2018, 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 bug was fixed), but it introduced
> a small regression in the
Hi J.H.,
On Wed, 28 Nov 2018, J.H. van de Water wrote:
> > > me@work /cygdrive
> > > $ ls
> > > c d
> > >
> > > So `/cygdrive` *is* a valid directory in Cygwin.
> >
> > That supports the code that does not special case a path that begins
> > with /cygdrive/ and simply treats it as a full path
Hi Ævar,
On Tue, 27 Nov 2018, Ævar Arnfjörð Bjarmason wrote:
> The advice to run 'git replace --convert-graft-file' added in
> f9f99b3f7d ("Deprecate support for .git/info/grafts", 2018-04-29)
> didn't add an exception for the 'git replace --convert-graft-file'
> codepath itself.
>
> As a
Hi Jonathan,
On Tue, 27 Nov 2018, Jonathan Nieder wrote:
> At https://bugs.debian.org/914695 is a report of a test regression in
> an outside project that is very likely to have been triggered by the
> new faster rebase code.
>From looking through that log.gz (without having a clue where the
Hi Junio,
On Wed, 28 Nov 2018, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > ...
> > In short, even a thorough study of the code (keeping in mind the few
> > tidbits of information provided by you) leaves me really wondering which
> > code you run, because it sure does not look
> Ævar Arnfjörð Bjarmason hat am 22. November 2018 um 11:16
> geschrieben:
[...]
> >
> > +test_expect_success 'log -G ignores binary files' '
> > + rm -rf .git &&
> > + git init &&
> > + printf "a\0b" >data.bin &&
> > + git add data.bin &&
> > + git commit -m "message" &&
> > + git
The -G option of log looks for the differences whose patch text
contains added/removed lines that match regex.
As the concept of patch text only makes sense for text files, we need to
ignore binary files when searching with -G as well.
The -S option of log looks for differences that changes
the
Hi!
The git-reset documentation page section which is accessible via URL
https://git-scm.com/docs/git-reset#_discussion is not looking good.
ASCII tables should look like this:
working index HEAD target working index HEAD
"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
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
> +++
Æ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
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
> ---
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
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"),
>
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
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 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
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 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 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
Æ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.
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
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
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
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
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
Æ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
Æ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
On Wed, Nov 28 2018, Johannes Schindelin wrote:
> Hi Jonathan,
>
> On Tue, 27 Nov 2018, Jonathan Nieder wrote:
>
>> At https://bugs.debian.org/914695 is a report of a test regression in
>> an outside project that is very likely to have been triggered by the
>> new faster rebase code.
>
> From
On Tue, Nov 20, 2018 at 04:11:08AM -0500, Jeff King wrote:
> On Mon, Nov 19, 2018 at 11:36:08AM -0800, Carlo Arenas wrote:
>
> > tests 3-8 seem to fail because perl is hardcoded to /urs/bin/perl in
> > t5562/invoke-with-content-length.pl, while I seem to be getting some
> > sporadic errors in 9
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 consumed, so it won't be ran again by
> 'git rebase --continue' is ran,
On Thu, Nov 22 2018, Jeff King wrote:
> On Thu, Nov 22, 2018 at 02:17:01AM -0800, Carlo Arenas wrote:
>> PS. upstreaming the PERL_PATH fix is likely to be good to do soonish
>> as I presume at least all BSD might be affected, let me know if you
>> would rather me do that instead as I suspect we
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 the goal (the implementation looked reasonable
> assuming the reader
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
--
Hello Dear ,
I came across your contact during my private search
Mrs Aisha Al-Qaddafi is my name, the only daughter of late Libyan
president, I have funds the sum
of $27.5 million USD for investment, I am interested in you for
investment project assistance in your country,
i shall compensate
On Wed, Nov 28, 2018 at 12:28 AM Johannes Schindelin
wrote:
>
> Hi Elijah,
>
> On Wed, 21 Nov 2018, 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
On Tue, Nov 27, 2018 at 8:44 PM Stefan Beller wrote:
>
> On Tue, Nov 27, 2018 at 8:53 AM Nguyễn Thái Ngọc Duy
> wrote:
> >
> > There is currently no caller that calls this function with "a" being
> > NULL. But it will be introduced shortly. It is used to construct the
> > option array from
On Wed, Nov 28, 2018 at 7:04 AM Junio C Hamano wrote:
>
> Nguyễn Thái Ngọc Duy writes:
>
> > The assumption made is here
> >
> > - "git checkout" is a horrible monster that should only be touched
> > with a two-meter pole
> >
> > - there are other commands that can achieve the same thing
>
>
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 bug was fixed), but it introduced
> a small regression in the
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
Hello!
I have very bad news for you.
03/08/2018 - on this day I hacked your OS and got full access to your account
git@vger.kernel.org
On this day your account git@vger.kernel.org has password: dirgantara
So, you can change the password, yes.. But my malware intercepts it every time.
How I
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
On Wed, 28 Nov 2018 at 12:42, Paweł Samoraj wrote:
>
> Hi!
> The git-reset documentation page section which is accessible via URL
> https://git-scm.com/docs/git-reset#_discussion is not looking good.
>
[snip]
>
> The web archive has got a snapshot from 2014-06-28 when it was ok
>
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 @@
> +#!/bin/sh
> +
> +test_description='virtual
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 consumed, so it won't be ran again by
'git rebase --continue' is ran, even if the tests weren't fixed.
This commit introduces a new
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 normally with the
stage/unstaged and diff panes. However, when I
On Wed, Nov 28 2018, Thomas Braun wrote:
Looks much better this time around.
> The -G option of log looks for the differences whose patch text
> contains added/removed lines that match regex.
>
> As the concept of patch text only makes sense for text files, we need to
> ignore binary files
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
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, 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
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 @@
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, 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|...]
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
> +--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 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 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
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
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,
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 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 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
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 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 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
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
> 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
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
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
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:
>
>
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
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
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(+)
1 - 100 of 102 matches
Mail list logo
