Hi Ralf,
On Fri, 30 Nov 2018, Ralf Thielow wrote:
> Signed-off-by: Ralf Thielow
ACK.
The commit message could state that the scripted rebase does not have
those whitespace issues, and that this aligns the built-in rebase with it,
but I won't insist.
Ciao,
Johannes
> ---
> builtin/rebase.c
sequencer_add_exec_commands() to work on a todo_list to
avoid redundant reads and writes to the disk.
Instead of just inserting the `exec' command between the other commands,
and re-parsing the buffer at the end the exec command is appended to the
buffer once, and a new list of items is created. Items from
On 11/29/2018 9:39 PM, Junio C Hamano wrote:
Derrick Stolee writes:
While _eventually_ we should make this opt-out, we shouldn't do that
until it has cooked a while.
I actually do not agree. If the knob gives enough benefit, the
users will learn about it viva voce, and in a few more
On Fri, Nov 30, 2018 at 6:16 AM Junio C Hamano wrote:
>
> Johannes Schindelin writes:
>
> > Hi Junio,
> >
> > On Fri, 30 Nov 2018, Junio C Hamano wrote:
> >
> >> * en/rebase-merge-on-sequencer (2018-11-08) 2 commits
> >> - rebase: implement --merge via git-rebase--interactive
> >> -
Hi Junio,
On Fri, 30 Nov 2018, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > On Fri, 30 Nov 2018, Junio C Hamano wrote:
> >
> >> * en/rebase-merge-on-sequencer (2018-11-08) 2 commits
> >> - rebase: implement --merge via git-rebase--interactive
> >> - git-rebase, sequencer: extend
Johannes Schindelin writes:
> Hi Junio,
>
> On Fri, 30 Nov 2018, Junio C Hamano wrote:
>
>> * en/rebase-merge-on-sequencer (2018-11-08) 2 commits
>> - rebase: implement --merge via git-rebase--interactive
>> - git-rebase, sequencer: extend --quiet option for the interactive machinery
>>
>>
Hi Junio,
On Fri, 30 Nov 2018, Junio C Hamano wrote:
> * en/rebase-merge-on-sequencer (2018-11-08) 2 commits
> - rebase: implement --merge via git-rebase--interactive
> - git-rebase, sequencer: extend --quiet option for the interactive machinery
>
> "git rebase --merge" as been reimplemented
Hi Junio,
On Fri, 30 Nov 2018, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> >> I had to delay -rc2 to see these last minute tweaks come to some
> >> reasonable place to stop at, and I do not think we want to delay the
> >> final any longer or destablizing it further by piling last minute
On Fri, Nov 30, 2018 at 12:29 PM Ævar Arnfjörð Bjarmason
wrote:
>
>
> On Fri, Nov 30 2018, Duy Nguyen wrote:
>
> > On Fri, Nov 30, 2018 at 12:05 AM Ævar Arnfjörð Bjarmason
> > wrote:
> >> Assuming greenfield development (which we definitely don't have), I
> >> don't like the "restore-files"
On Fri, Nov 30 2018, Duy Nguyen wrote:
> On Fri, Nov 30, 2018 at 12:05 AM Ævar Arnfjörð Bjarmason
> wrote:
>> Assuming greenfield development (which we definitely don't have), I
>> don't like the "restore-files" name, but the alternative that makes
>> sense is "checkout". Then this "--from"
On Thu, Nov 29, 2018 at 11:03 AM Ævar Arnfjörð Bjarmason
wrote:
> I mean not just nasty in terms of implementation, yeah we could do it,
> but also a nasty UX for things like --word-diff-regex. I.e. instead of:
>
> --range-diff-word-diff-regex='[0-9"]'
>
> You need:
>
>
epo_diff_setup(the_repository, );
The first attempt at adding --range-diff to git-format-patch invoked
the git-range-diff command, so no diff_options were passed at all.
After Dscho libified the range-diff machinery in one of his major
re-rolls, I took advantage of that to avoid the subprocess invocation.
A
On Fri, Nov 30 2018, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>>> I had to delay -rc2 to see these last minute tweaks come to some
>>> reasonable place to stop at, and I do not think we want to delay the
>>> final any longer or destablizing it further by piling last minute
>>>
Junio C Hamano writes:
>> I had to delay -rc2 to see these last minute tweaks come to some
>> reasonable place to stop at, and I do not think we want to delay the
>> final any longer or destablizing it further by piling last minute
>> undercooked changes on top.
>
> So how about doing this on
On Fri, Nov 30, 2018 at 1:16 AM Dan Fabulich wrote:
>
> Other thoughts on a global UI rethink:
>
> One of the most common complaints I hear about git is the conceptual
> difficulty required in undoing changes. https://ohshitgit.com/
>
> > Git is hard: screwing up is easy, and figuring out how to
Duy Nguyen writes:
> core.uiVersion is a big no no to me. I don't want to go to someone's
> terminal, type something and have a total surprise because they set
> different ui version. If you want a total UI redesign, go with a new
> prefix, like "ng" (for new git) or something instead of "git".
Duy Nguyen writes:
>>
>> OK. Is "auto-vivify the named branch based on a remote-tracking"
>> also rejected, as it is a confusing behaviour that is a too subtle
>> and implicit, just like the detaching head is, and require --guess
>> or sticking to 'git checkout'? I think it should.
>
> This
On Fri, Nov 30, 2018 at 3:16 AM Junio C Hamano wrote:
>
> Nguyễn Thái Ngọc Duy writes:
>
> > 'git switch-branch'
> >
> > - implicit detaching is rejected. If you need to detach, you need to
> > give --detach. Or stick to 'git checkout'.
>
> OK. Is "auto-vivify the named branch based on a
On Fri, Nov 30, 2018 at 12:05 AM Ævar Arnfjörð Bjarmason
wrote:
> Assuming greenfield development (which we definitely don't have), I
> don't like the "restore-files" name, but the alternative that makes
> sense is "checkout". Then this "--from" argument could become "git
> checkout-tree -- ",
Junio C Hamano writes:
> In any case, I tend to agree with the conclusion in the downthread
> by Dscho that we should just clearly mark that invocations of the
> "format-patch --range-diff" command with additional diff options is
> an experimental feature that may not do anything sensible in the
Derrick Stolee writes:
> You're right that having this hidden as an opt-in config variable
> makes it hard to discover as a typical user.
>
> I would argue that we should actually make the config setting true by
> default, and recommend that servers opt-out. Here are my reasons:
>
> 1. The vast
Ævar Arnfjörð Bjarmason writes:
>> What prevents you from using `sq_dequote_to_argv()`?
>
> I mean not just nasty in terms of implementation, yeah we could do it,
> but also a nasty UX for things like --word-diff-regex. I.e. instead of:
>
> --range-diff-word-diff-regex='[0-9"]'
>
> You need:
Nguyễn Thái Ngọc Duy writes:
> 'git switch-branch'
>
> - implicit detaching is rejected. If you need to detach, you need to
> give --detach. Or stick to 'git checkout'.
OK. Is "auto-vivify the named branch based on a remote-tracking"
also rejected, as it is a confusing behaviour that is a
Duy Nguyen writes:
> 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
Johannes Schindelin writes:
> But I guess that I should not be so lazy and really use two different
> messages here:
>
> Changes from to
>
> and if there is no merge base,
>
> Changes in
Ah, that's excellent.
Thanks.
Masaya Suzuki writes:
> Yes, I did. And it also didn't end up in a build error. Do I have a
> different build option...?
Passig DEVELOPER=Yes to make turns a bit more warnings on (in this
case, I think it was "unused-variable") and also uses -Werror to
turn warnings into errors.
ites) are of
>> course still missing. But they are coming.
>>
>> I did not go replace "detached HEAD" with "unnamed branch" (or "no
>> branch") everywhere because I think a unique term is still good to
>> refer to this concept. Or maybe &q
t;> I did not go replace "detached HEAD" with "unnamed branch" (or "no
>> branch") everywhere because I think a unique term is still good to
>> refer to this concept. Or maybe "no branch" is good enough. I dunno.
>
> I finally tracked d
>> branch") everywhere because I think a unique term is still good to
>> refer to this concept. Or maybe "no branch" is good enough. I dunno.
>
> I finally tracked down
> https://redfin.engineering/two-commits-that-wrecked-the-user-experience-of-git-f0075b77eab1
t go replace "detached HEAD" with "unnamed branch" (or "no
> branch") everywhere because I think a unique term is still good to
> refer to this concept. Or maybe "no branch" is good enough. I dunno.
I finally tracked down
https://redfin.engineering/two
>
> Which brings us back to your "git checkout-files " use case
> above. It should be treat the same way in my opinion, so we either do
>
> git checkout-files --from=tree-ish :/
>
> or
>
> git checkout-files --from=tree-ish .
>
> But "git checkout-files --from=tree-ish" alone is rejected.
Hi Ævar,
On Thu, 29 Nov 2018, Ævar Arnfjörð Bjarmason wrote:
> On Thu, Nov 29 2018, Johannes Schindelin wrote:
>
> > On Thu, 29 Nov 2018, Ævar Arnfjörð Bjarmason wrote:
> >
> >> On Thu, Nov 29 2018, Johannes Schindelin wrote:
> >>
> >> > On Thu, 29 Nov 2018, Ævar Arnfjörð Bjarmason wrote:
> >>
On Thu, Nov 29, 2018 at 7:14 PM Stefan Beller wrote:
>
> > > Idea:
> > > If git checkout-files modifies the submodules file, it could also
> > > auto-update the submodules. (For example, with something like "git
> > > submodule update --init --recursive --progress").
> >
> > This one is tricky
> > Idea:
> > If git checkout-files modifies the submodules file, it could also
> > auto-update the submodules. (For example, with something like "git
> > submodule update --init --recursive --progress").
>
> This one is tricky because we should deal with submodule autoupdate
> consistently across
Johannes Schindelin writes ("Re: [PATCH] rebase: mark the C reimplementation as
an experimental opt-in feature (was Re: [ANNOUNCE] Git v2.20.0-rc1)"):
> I'll have to take a (lengthy) dinner break now, but this is what I have so
> far: a regression test that verifies the breakage
Hi Ian,
On Thu, 29 Nov 2018, Ian Jackson wrote:
> Johannes Schindelin writes ("Re: [PATCH] rebase: mark the C reimplementation
> as an experimental opt-in feature (was Re: [ANNOUNCE] Git v2.20.0-rc1)"):
> > > In a successful run with older git I get a reflog like this
On Thu, Nov 29, 2018 at 3:42 AM Junio C Hamano wrote:
>
> 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
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 Thu, 29 Nov 2018, Ævar Arnfjörð Bjarmason wrote:
>> >
>> >> On Thu, Nov 29 2018, Johannes Schindelin wrote:
>> >>
>>
Johannes Schindelin writes ("Re: [PATCH] rebase: mark the C reimplementation as
an experimental opt-in feature (was Re: [ANNOUNCE] Git v2.20.0-rc1)"):
> > In a successful run with older git I get a reflog like this:
> >
> >4833d74 HEAD@{0}: rebase finished:
On Thu, Nov 29, 2018 at 12:22 AM Stefan Xenos wrote:
> Some behaviors I'd expect to see from these commands (I haven't yet
> checked to see if you've already done this):
>
> git checkout-files
> should reset all the files in the repository regardless of the current
> directory - it should
Hi Ævar,
On Thu, 29 Nov 2018, Ævar Arnfjörð Bjarmason wrote:
> On Thu, Nov 29 2018, Johannes Schindelin wrote:
>
> > 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:
> >>
Hi Ian,
On Thu, 29 Nov 2018, Ian Jackson wrote:
> 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
On Thu, Nov 29 2018, Mateusz Loskot wrote:
> On Thu, 29 Nov 2018 at 16:03, Ævar Arnfjörð Bjarmason
> wrote:
>> On Wed, Nov 28 2018, Mateusz Loskot wrote:
>> >
>> > (using git version 2.19.2.windows.1)
>> >
>> > I've just encountered one of those WTH moments.
>> >
>> > I have a bare repository
Hi Ben,
On Thu, 29 Nov 2018, Ben Peart wrote:
> 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
On Thu, Nov 29, 2018 at 6:59 AM Junio C Hamano wrote:
>
> 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.
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 switch-branch command (or
> > > whatever its name will be)?
> > >
On Thu, 29 Nov 2018 at 16:03, Ævar Arnfjörð Bjarmason wrote:
> On Wed, Nov 28 2018, Mateusz Loskot wrote:
> >
> > (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
> >
On Thu, Nov 29 2018, Stefanie Leisestreichler wrote:
> 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
On Wed, Nov 28 2018, Mateusz Loskot wrote:
> 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
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
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
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,
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
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 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
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.
>
exec', except
> >> that it is automatically rescheduled in the todo list if it fails.
> >>
> >> Signed-off-by: Paul Morelle
> > Would it not make more sense to add a command-line option (and a config
> > setting) to re-schedule failed `exec` commands? Like
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.
it for submission (and then forgot to re-run that test).
Specifically, these null checks are important:
diff --git a/list-objects.c b/list-objects.c
index 9bb93d1640..7e864b4db8 100644
--- a/list-objects.c
+++ b/list-objects.c
@@ -232,6 +232,10 @@ static void add_edge_parents(struct commit *commit
Æ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
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|...]
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
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
301 - 400 of 100366 matches
Mail list logo
