* Re: en/rebase-merge-on-sequencer, was Re: What's cooking in git.git (Nov 2018, #07; Fri, 30)
From: Junio C Hamano @ 2018-11-30 14:13 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <nycvar.QRO.7.76.6.1811301429220.41@tvgsbejvaqbjf.bet>
Johannes Schindelin <Johannes.Schindelin@gmx.de> 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
>>
>> "git rebase --merge" as been reimplemented by reusing the internal
>> machinery used for "git rebase -i".
>
> I *think* a new iteration has landed (which has 7 instead of 2 commits):
> https://public-inbox.org/git/20181122044841.20993-1-newren@gmail.com/
"Landed" as opposed to "be in-flight"?
You got me worried by implying that I merged them to either 'master'
or 'next' where it is harder to back out ;-).
During the freeze, especially after -rc1, I stop paying attention to
anything other than regression fixes and fixes to the addition since
the previous releases, unless I have too much time and get bored and
the new topic is trivial (which often means a single patch).
I'll mark the topic with the following, and continue ignoring it (or
any other topics) for now. Thanks.
* 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 by reusing the internal
machinery used for "git rebase -i".
Reroll exists.
cf. <20181122044841.20993-1-newren@gmail.com>
^ permalink raw reply
* en/rebase-merge-on-sequencer, was Re: What's cooking in git.git (Nov 2018, #07; Fri, 30)
From: Johannes Schindelin @ 2018-11-30 13:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <xmqqva4fj62k.fsf@gitster-ct.c.googlers.com>
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 by reusing the internal
> machinery used for "git rebase -i".
I *think* a new iteration has landed (which has 7 instead of 2 commits):
https://public-inbox.org/git/20181122044841.20993-1-newren@gmail.com/
Assuming that the -rc2 work has been interfering, I guess you wanted to
pick that up some time after -rc2 or even after -final?
Ciao,
Dscho
^ permalink raw reply
* git difftool directory diff problem copying changes back is not reliable
From: Uwe Hafner @ 2018-11-30 13:21 UTC (permalink / raw)
To: git
I have a problem with directory diff. The following command:
Git difftool -d _commit_sha_
Opens my compare tool (Beyondcompare) and I can make a folder diff. The tool
also allows browsing through all changes and looking/editing single files (a
beyondcompare feature).
So my workflow would be to open single files and make changes to the right
side of the diff.
After saving and exiting the diff tool sometimes these changes are copied
back to my working tree.
I currently assume from my tests that changes are copied to the working tree
if they are not too deeply nested in folders. So changes to files in folders
up to a depth of about 4 or so are copied back. If any deeper they are not.
My system specs:
OS: Windows 10
Git: 2.19.2.windows.1
Folder of repo. Folder name length is identical to real folder name length
in case it is a folder name length issue:
C:\Users\Developer\source\repos\Project_name_length_
Folder for comparison (temp names are really used names):
Commit sha side:
C:\Users\Developer\AppData\Local\Temp\git-difftool.a07928\left
Working tree copy side:
C:\Users\Developer\AppData\Local\Temp\git-difftool.a07928\right
Can anyone confirm this?
Thanks
^ permalink raw reply
* Re: [PATCH] format-patch: do not let its diff-options affect --range-diff (was Re: [PATCH 2/2] format-patch: allow for independent diff & range-diff options)
From: Johannes Schindelin @ 2018-11-30 12:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ævar Arnfjörð Bjarmason, git, Eric Sunshine
In-Reply-To: <xmqq36rjkkn7.fsf@gitster-ct.c.googlers.com>
Hi Junio,
On Fri, 30 Nov 2018, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> 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 top of 'master' instead? As this leaks
> > *no* information wrt how range-diff machinery should behave from the
> > format-patch side by not passing any diffopt, as long as the new
> > code I added to show_range_diff() comes up with a reasonable default
> > diffopts (for which I really would appreciate extra sets of eyes to
> > make sure), this change by definition cannot be wrong (famous last
> > words).
>
> As listed in today's "What's cooking" report, I've merged this to
> 'next' in today's pushout and planning to have it in the -rc2. I am
> not married to this exact implementation, and I'd welcome to have an
> even simpler and less disruptive solution if exists, but I am hoping
> that this is a good-enough interim measure for the upcoming release,
> until we decide what to do with the customizability of range-diff
> driven by format-patch.
>
> In addition to this, I am planning the "rebase --stat" and "reflog
> that does not say 'rebase -i' but 'rebase'" fixes merged to 'master'
> before cutting -rc2.
Thank you for integrating them. That way, we have an -rc2 with no issues
in the built-in rebase/rebase -i that we know of.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH/RFC v3 00/14] Introduce new commands switch-branch and restore-files
From: Duy Nguyen @ 2018-11-30 12:10 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: Git Mailing List, Junio C Hamano, Stefan Beller, Thomas Gummerer,
Stefan Xenos, Elijah Newren, dan
In-Reply-To: <87zhtqvm66.fsf@evledraar.gmail.com>
On Fri, Nov 30, 2018 at 12:29 PM Ævar Arnfjörð Bjarmason
<avarab@gmail.com> wrote:
>
>
> On Fri, Nov 30 2018, Duy Nguyen wrote:
>
> > On Fri, Nov 30, 2018 at 12:05 AM Ævar Arnfjörð Bjarmason
> > <avarab@gmail.com> 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 <treeish> -- <pathspec>", and we'd have:
> >>
> >> git switch <branchish>
> >> git checkout <pathspec>
> >> git checkout-tree <treeish> -- <pathspec>
> >>
> >> Or maybe that sucks, anyway what I was going to suggest is *if* others
> >> think that made sense as a "if we designed git today" endgame whether we
> >> could have an opt-in setting where you set e.g. core.uiVersion=3 (in
> >> anticipation of Git 3.0) and you'd get that behavior. There could be
> >> some other setting where core.uiVersion would use the old behavior (or
> >> with another setting, only warn) if we weren't connected to a terminal.
> >
> > 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".
>
> I don't think that's a viable way forward. First, we're not talking
> about a total change of the UI. Most the main porcelain will stay the
> same. So we'd have a "ng" that's >98% the same UI, and then if we
> discover warts in in 10 years we'd like to fix then what do wo do? Ship
> "nng" and so forth?
Yes. So think it through and try not to do it often.
> We already have this UI problem with various config variables that
> change things. I think we should just solve this general issue by a
> combination of:
>
> a) Accepting that over the long term we will have Git's UI changing,
> sometimes in breaking ways (with sensible phase-in), hopefully for
> the better. E.g. we had this with "git-init" v.s. "git init". This
> is similar, there'd be an error due to ambiguity with a "hint"
> saying use the new thing if you e.g. feed "git checkout" a branch
> name.
And I hate adding a zillion of config keys to change little things
like this. Now you use this to change bigger behavior. No.
--
Duy
^ permalink raw reply
* Re: [PATCH/RFC v3 00/14] Introduce new commands switch-branch and restore-files
From: Ævar Arnfjörð Bjarmason @ 2018-11-30 11:29 UTC (permalink / raw)
To: Duy Nguyen
Cc: Git Mailing List, Junio C Hamano, Stefan Beller, Thomas Gummerer,
Stefan Xenos, Elijah Newren, dan
In-Reply-To: <CACsJy8DCKQctO+rf=xP5gVVUy9XBq35Z1xSbfwB30nDJMMJsrA@mail.gmail.com>
On Fri, Nov 30 2018, Duy Nguyen wrote:
> On Fri, Nov 30, 2018 at 12:05 AM Ævar Arnfjörð Bjarmason
> <avarab@gmail.com> 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 <treeish> -- <pathspec>", and we'd have:
>>
>> git switch <branchish>
>> git checkout <pathspec>
>> git checkout-tree <treeish> -- <pathspec>
>>
>> Or maybe that sucks, anyway what I was going to suggest is *if* others
>> think that made sense as a "if we designed git today" endgame whether we
>> could have an opt-in setting where you set e.g. core.uiVersion=3 (in
>> anticipation of Git 3.0) and you'd get that behavior. There could be
>> some other setting where core.uiVersion would use the old behavior (or
>> with another setting, only warn) if we weren't connected to a terminal.
>
> 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".
I don't think that's a viable way forward. First, we're not talking
about a total change of the UI. Most the main porcelain will stay the
same. So we'd have a "ng" that's >98% the same UI, and then if we
discover warts in in 10 years we'd like to fix then what do wo do? Ship
"nng" and so forth?
We already have this UI problem with various config variables that
change things. I think we should just solve this general issue by a
combination of:
a) Accepting that over the long term we will have Git's UI changing,
sometimes in breaking ways (with sensible phase-in), hopefully for
the better. E.g. we had this with "git-init" v.s. "git init". This
is similar, there'd be an error due to ambiguity with a "hint"
saying use the new thing if you e.g. feed "git checkout" a branch
name.
b) For the general problem of "user has exotic config" we should learn
a "git -Q <cmd>" option similar to Emacs, which is another highly
customizable piece of software that has a "don't read user config"
escape hatch.
That's a bit more complex than for Emacs since we need to actually
read some config (e.g. remote config from .git/config), and maybe
opt to keep some stuff like user.*. But there's no reason we can't
have such a black/whitelist of config & env variables that impact us
with a switch to get "make it as if nothing was configured" for
whatever sane version of that we'd come up with.
^ permalink raw reply
* Re: [PATCH 2/2] format-patch: allow for independent diff & range-diff options
From: Eric Sunshine @ 2018-11-30 9:58 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: Johannes Schindelin, Git List, Junio C Hamano
In-Reply-To: <87tvjzyiph.fsf@evledraar.gmail.com>
On Thu, Nov 29, 2018 at 11:03 AM Ævar Arnfjörð Bjarmason
<avarab@gmail.com> 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:
>
> --range-diff-opts="--word-diff-regex='[0-9\"]'"
>
> Now admittedly that in itself isn't very painful *in this case*, but in
> terms of precedent I really dislike that option, i.e. git having some
> mode where I need to work to escape input to pass to another command.
>
> Not saying that this --range-diff-* thing is what we should go for, but
> surely we can find some way to do deal with this that doesn't involve
> the user needing to escape stuff like this.
I should mention that it was never the intention that
git-format-patch's --range-diff option would allow passing _all_
possible options to git-range-diff, but only those most likely to be
tweaked by the user (such as --creation-factor). It was understood
from the start (and stated by me either in the cover letter to that
series or in discussion) that the user always has the escape hatch of
running git-range-diff manually and copy/pasting its output into the
cover letter.
So, I'm not convinced that we need this sort of flexibility in
git-format-patch's --range-diff option, but we certainly can add
convenience options (such as I did with --creation-factor) as people
complain that their favorite option is missing. For a UI, I think we
already have sufficient precedent for
"--range-diff-opts=nopatch,creation-factor:60" as a possibility.
^ permalink raw reply
* Re: [PATCH] format-patch: do not let its diff-options affect --range-diff (was Re: [PATCH 2/2] format-patch: allow for independent diff & range-diff options)
From: Eric Sunshine @ 2018-11-30 9:31 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Ævar Arnfjörð Bjarmason,
Git List
In-Reply-To: <xmqqwoovkx5s.fsf_-_@gitster-ct.c.googlers.com>
On Thu, Nov 29, 2018 at 11:27 PM Junio C Hamano <gitster@pobox.com> wrote:
> Junio C Hamano <gitster@pobox.com> 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
> > upcoming release, and declare that the UI to pass diff options to
> > affect only the range-diff part may later be invented. IOW, I am
> > coming a bit stronger than Dscho's suggestion in that we should not
> > even pretend that we aimed to make the options used for range-diff
> > customizable when driven from format-patch in the upcoming release,
> > or aimed to make --range-diff option compatible with other diff
> > options given to the format-patch command.
I agree that this way forward makes sense. It's clear that I
overlooked how there could be unexpected interactions from passing
git-format-patch's own diff_options to show_range_diff(), so taking
time to think it through without the pressure of a looming release is
preferable to rushing out some "fixes".
> So how about doing this on top of 'master' instead? As this leaks
> *no* information wrt how range-diff machinery should behave from the
> format-patch side by not passing any diffopt, as long as the new
> code I added to show_range_diff() comes up with a reasonable default
> diffopts (for which I really would appreciate extra sets of eyes to
> make sure), this change by definition cannot be wrong (famous last
> words).
I, myself, was going to suggest this approach of leaking none of the
git-format-patch's options into range_diff(), so I think it is a good
one. Later, we can selectively pass certain _sensible_ options into
show_range_diff() once we figure out the correct UI (for instance,
--range-diff-opts=nopatch,creation-factor:60).
A couple comments on the patch itself...
> diff --git a/range-diff.c b/range-diff.c
> @@ -460,7 +460,11 @@ int show_range_diff(const char *range1, const char *range2,
> - memcpy(&opts, diffopt, sizeof(opts));
> + if (diffopt)
> + memcpy(&opts, diffopt, sizeof(opts));
> + else
> + repo_diff_setup(the_repository, &opts);
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.
Another benefit of calling show_range_diff() directly is that when
"git format-patch --stdout --range-diff=..." is sent to the terminal,
the range-diff gets colored output for free. I'm pleased to see that
that still works after this change.
> diff --git a/range-diff.h b/range-diff.h
> @@ -5,6 +5,11 @@
> +/*
> + * Compare series of commmits in RANGE1 and RANGE2, and emit to the
> + * standard output. NULL can be passed to DIFFOPT to use the built-in
> + * default.
> + */
It is more correct to say that the range-diff is emitted to
diffopt->file (which may be stdout).
Thanks for working on this.
^ permalink raw reply
* Re: [PATCH] format-patch: do not let its diff-options affect --range-diff (was Re: [PATCH 2/2] format-patch: allow for independent diff & range-diff options)
From: Ævar Arnfjörð Bjarmason @ 2018-11-30 9:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git, Eric Sunshine
In-Reply-To: <xmqq36rjkkn7.fsf@gitster-ct.c.googlers.com>
On Fri, Nov 30 2018, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> 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 top of 'master' instead? As this leaks
>> *no* information wrt how range-diff machinery should behave from the
>> format-patch side by not passing any diffopt, as long as the new
>> code I added to show_range_diff() comes up with a reasonable default
>> diffopts (for which I really would appreciate extra sets of eyes to
>> make sure), this change by definition cannot be wrong (famous last
>> words).
>
> As listed in today's "What's cooking" report, I've merged this to
> 'next' in today's pushout and planning to have it in the -rc2. I am
> not married to this exact implementation, and I'd welcome to have an
> even simpler and less disruptive solution if exists, but I am hoping
> that this is a good-enough interim measure for the upcoming release,
> until we decide what to do with the customizability of range-diff
> driven by format-patch.
>
> In addition to this, I am planning the "rebase --stat" and "reflog
> that does not say 'rebase -i' but 'rebase'" fixes merged to 'master'
> before cutting -rc2.
Thanks a lot, yeah having this wait looks good to me.
^ permalink raw reply
* What's cooking in git.git (Nov 2018, #07; Fri, 30)
From: Junio C Hamano @ 2018-11-30 8:57 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'. The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.
The road to the upcoming 2.20 turned out to be a bit rockier as we
had a couple of subcommands with larger importance (rebase and
rebase-i) reimplemented, together with some new and exciting
commands (like range-diff and its integration into format-patch),
each with a few loose ends we needed to tie until the last minute.
I've let -rc1 and -rc2 slip for a few days to make sure we get
closer to a stable point, and I am hoping that a few topics that are
at the bottom of master..pu chain with today's pushout merged to the
'master' branch, I should be able to cut a 2.20-rc2 that is in a
reasonable shape.
You can find the changes described here in the integration branches
of the repositories listed at
http://git-blame.blogspot.com/p/git-public-repositories.html
--------------------------------------------------
[New Topics]
* gh/diff-raw-has-no-ellipses (2018-11-26) 1 commit
(merged to 'next' on 2018-11-29 at 24a7536f15)
+ doc: update diff-format.txt for removed ellipses in --raw
"git diff --raw" lost ellipses to adjust the output columns for
some time now, but the documentation still showed them.
Will cook in 'next'.
* mk/http-backend-kill-children-before-exit (2018-11-26) 1 commit
(merged to 'next' on 2018-11-29 at bf2d45062f)
+ http-backend: enable cleaning up forked upload/receive-pack on exit
The http-backend CGI process did not correctly clean up the child
processes it spawns to run upload-pack etc. when it dies itself,
which has been corrected.
Will cook in 'next'.
* ab/replace-graft-with-replace-advice (2018-11-29) 1 commit
(merged to 'next' on 2018-11-30 at c5d658e075)
+ advice: don't pointlessly suggest --convert-graft-file
The advice message to tell the user to migrate an existing graft
file to the replace system when a graft file was read was shown
even when "git replace --convert-graft-file" command, which is the
way the message suggests to use, was running, which made little
sense.
Will merge to 'master'.
* ma/reset-doc-rendering-fix (2018-11-29) 2 commits
(merged to 'next' on 2018-11-30 at be718c19e2)
+ git-reset.txt: render literal examples as monospace
+ git-reset.txt: render tables correctly under Asciidoctor
Doc updates.
Will merge to 'master'.
* sg/daemon-test-signal-fix (2018-11-27) 1 commit
(merged to 'next' on 2018-11-30 at b3f7fdf727)
+ t/lib-git-daemon: fix signal checking
Test fix.
Will merge to 'master'.
* tb/log-G-binary (2018-11-29) 1 commit
- log -G: ignore binary files
"git log -G<regex>" looked for a hunk in the "git log -p" patch
output that contained a string that matches the given pattern.
Optimize this code to ignore binary files, which by default will
not show any hunk that would match any pattern (unless textconv or
the --text option is in effect, that is).
Expecting an update to the tests.
* jc/format-patch-range-diff-fix (2018-11-30) 1 commit
(merged to 'next' on 2018-11-30 at 26290b1ec1)
+ format-patch: do not let its diff-options affect --range-diff
"git format-patch --range-diff" by mistake passed the diff options
used to generate the primary output of the command to the
range-diff machinery, which caused the range-diff in the cover
letter to include fairly useless "--stat" output. This has been
corrected by forcing a non-customizable default formatting options
on the range-diff machinery when driven by format-patch.
Will merge to 'master'.
* js/rebase-reflog-action-fix (2018-11-30) 1 commit
(merged to 'next' on 2018-11-30 at 93fd2fb920)
+ rebase: fix GIT_REFLOG_ACTION regression
"git rebase" reimplemented recently in C accidentally changed the
way reflog entries are recorded (earlier "rebase -i" identified the
entries it leaves with "rebase -i", but the new version always
marks them with "rebase"). This has been corrected.
Will merge to 'master'.
* js/rebase-stat-unrelated-fix (2018-11-30) 1 commit
(merged to 'next' on 2018-11-30 at a9faaff8c1)
+ rebase --stat: fix when rebasing to an unrelated history
"git rebase --stat" to transplant a piece of history onto a totally
unrelated history were not working before and silently showed wrong
result. With the recent reimplementation in C, it started to instead
die with an error message, as the original logic was not prepared
to cope with this case. This has now been fixed.
Will merge to 'master'.
--------------------------------------------------
[Graduated to "master"]
* cc/delta-islands (2018-11-21) 3 commits
(merged to 'next' on 2018-11-21 at 3bac399f83)
+ pack-objects: fix off-by-one in delta-island tree-depth computation
+ pack-objects: zero-initialize tree_depth/layer arrays
+ pack-objects: fix tree_depth and layer invariants
A few issues in the implementation of "delta-islands" feature has
been corrected.
* cc/shared-index-permbits (2018-11-19) 1 commit
(merged to 'next' on 2018-11-19 at 79df716844)
+ read-cache: make the split index obey umask settings
The way .git/index and .git/sharedindex* files were initially
created gave these files different perm bits until they were
adjusted for shared repository settings. This was made consistent.
* jk/t5562-perl-path-fix (2018-11-24) 1 commit
(merged to 'next' on 2018-11-24 at 2d8dca3544)
+ t5562: fix perl path
Hotfix for test breakage on platforms whose Perl is not at
/usr/bin/perl
* jn/eoie-ieot (2018-11-21) 3 commits
(merged to 'next' on 2018-11-21 at 9eb98a38f0)
+ index: make index.threads=true enable ieot and eoie
+ ieot: default to not writing IEOT section
+ eoie: default to not writing EOIE section
(this branch is used by jn/unknown-index-extensions.)
As the warning message shown by existing versions of Git for
unknown index extensions is a bit too alarming, two new extensions
are held back and not written by default for the upcoming release.
* js/builtin-rebase-perf-fix-err-fix (2018-11-21) 1 commit
(merged to 'next' on 2018-11-21 at 9c351cfc4a)
+ rebase: warn about the correct tree's OID
The object name of the tree reported in a recently added error
message was wrong, which has been corrected.
* js/rebase-am-options-fix (2018-11-21) 1 commit
(merged to 'next' on 2018-11-21 at 4da85e17c2)
+ legacy-rebase: backport -C<n> and --whitespace=<option> checks
Recently, built-in "rebase" tightened the error checking for a few
options that are passed to underlying "am", but we forgot to make
the matching change to the scripted version, which has been
corrected.
* nd/clone-case-smashing-warning (2018-11-21) 1 commit
(merged to 'next' on 2018-11-21 at 68bc7959f8)
+ clone: fix colliding file detection on APFS
Recently added check for case smashing filesystems did not
correctly utilize the cached stat information, leading to false
breakage detected by our test suite, which has been corrected.
* nd/per-worktree-ref-iteration (2018-11-26) 1 commit
(merged to 'next' on 2018-11-26 at b7c39e5946)
+ files-backend.c: fix build error on Solaris
Build fix.
* tb/clone-case-smashing-warning-test (2018-11-24) 1 commit
(merged to 'next' on 2018-11-24 at 37f0d3b920)
+ t5601-99: Enable colliding file detection for MINGW
The code recently added to "git clone" to see if the platform's
filesystem is adequate to check out and use the project code
correctly (e.g. a case smashing filesystem cannot be used for a
project with two files whose paths are different only in case) was
meant to help Windows users, but the test for it was not enabled
for that platform, which has been corrected.
* tz/build-tech-midx-doc (2018-11-21) 1 commit
(merged to 'next' on 2018-11-21 at 15dd462db0)
+ Documentation: build technical/multi-pack-index
A documentation page that is referred to by other pages was not
built by mistake, which has been corrected.
--------------------------------------------------
[Stalled]
* lt/date-human (2018-07-09) 1 commit
- Add 'human' date format
A new date format "--date=human" that morphs its output depending
on how far the time is from the current time has been introduced.
"--date=auto" can be used to use this new format when the output is
goint to the pager or to the terminal and otherwise the default
format.
--------------------------------------------------
[Cooking]
* dl/merge-cleanup-scissors-fix (2018-11-21) 2 commits
(merged to 'next' on 2018-11-21 at 217be06acb)
+ merge: add scissors line on merge conflict
+ t7600: clean up 'merge --squash c3 with c7' test
The list of conflicted paths shown in the editor while concluding a
conflicted merge was shown above the scissors line when the
clean-up mode is set to "scissors", even though it was commented
out just like the list of updated paths and other information to
help the user explain the merge better.
Will cook in 'next'.
* aw/pretty-trailers (2018-11-19) 5 commits
- pretty: add support for separator option in %(trailers)
- strbuf: separate callback for strbuf_expand:ing literals
- pretty: add support for "valueonly" option in %(trailers)
- pretty: allow showing specific trailers
- pretty: single return path in %(trailers) handling
The %(trailers) formatter in "git log --format=..." now allows to
optionally pick trailers selectively by keyword, show only values,
etc.
* nd/attr-pathspec-in-tree-walk (2018-11-19) 5 commits
- tree-walk: support :(attr) matching
- dir.c: move, rename and export match_attrs()
- pathspec.h: clean up "extern" in function declarations
- tree-walk.c: make tree_entry_interesting() take an index
- tree.c: make read_tree*() take 'struct repository *'
The traversal over tree objects has learned to honor
":(attr:label)" pathspec match, which has been implemented only for
enumerating paths on the filesystem.
* ab/commit-graph-progress-fix (2018-11-20) 1 commit
- commit-graph: split up close_reachable() progress output
* sg/test-BUG (2018-11-20) 1 commit
(merged to 'next' on 2018-11-21 at bb81013952)
+ tests: send "bug in the test script" errors to the script's stderr
test framework has been updated to make a bug in the test script
(as opposed to bugs in Git that are discovered by running the
tests) stand out more prominently.
Will cook in 'next'.
* sg/test-cmp-rev (2018-11-20) 1 commit
(merged to 'next' on 2018-11-21 at 5d65cb2a76)
+ test-lib-functions: make 'test_cmp_rev' more informative on failure
Test framework update.
Will cook in 'next'.
* ss/msvc-strcasecmp (2018-11-20) 1 commit
(merged to 'next' on 2018-11-21 at 9e45649e6e)
+ msvc: directly use MS version (_stricmp) of strcasecmp
MSVC update.
Will cook in 'next'.
* jn/unknown-index-extensions (2018-11-21) 2 commits
- index: offer advice for unknown index extensions
- index: do not warn about unrecognized extensions
A bit too alarming warning given when unknown index extensions
exist is getting revamped.
Expecting a reroll.
* ab/push-example-in-doc (2018-11-14) 1 commit
(merged to 'next' on 2018-11-18 at 8fd935a19c)
+ push: change needlessly ambiguous example in error
An error message that sugggests how to give correct arguments to
"git push" has been updated.
Will cook in 'next'.
* en/fast-export-import (2018-11-17) 11 commits
(merged to 'next' on 2018-11-18 at 87bbbffc95)
+ fast-export: add a --show-original-ids option to show original names
+ fast-import: remove unmaintained duplicate documentation
+ fast-export: add --reference-excluded-parents option
+ fast-export: ensure we export requested refs
+ fast-export: when using paths, avoid corrupt stream with non-existent mark
+ fast-export: move commit rewriting logic into a function for reuse
+ fast-export: avoid dying when filtering by paths and old tags exist
+ fast-export: use value from correct enum
+ git-fast-export.txt: clarify misleading documentation about rev-list args
+ git-fast-import.txt: fix documentation for --quiet option
+ fast-export: convert sha1 to oid
Small fixes and features for fast-export and fast-import, mostly on
the fast-export side.
Will cook in 'next'.
* nd/checkout-dwim-fix (2018-11-14) 1 commit
(merged to 'next' on 2018-11-18 at 3d714e7719)
+ checkout: disambiguate dwim tracking branches and local files
"git checkout frotz" (without any double-dash) avoids ambiguity by
making sure 'frotz' cannot be interpreted as a revision and as a
path at the same time. This safety has been updated to check also
a unique remote-tracking branch 'frotz' in a remote, when dwimming
to create a local branch 'frotz' out of a remote-tracking branch
'frotz' from a remote.
Will cook in 'next'.
* nd/checkout-noisy (2018-11-20) 2 commits
- t0027: squelch checkout path run outside test_expect_* block
- checkout: print something when checking out paths
"git checkout [<tree-ish>] path..." learned to report the number of
paths that have been checked out of the index or the tree-ish,
which gives it the same degree of noisy-ness as the case in which
the command checks out a branch.
* sg/clone-initial-fetch-configuration (2018-11-16) 3 commits
(merged to 'next' on 2018-11-18 at cae0f3985b)
+ Documentation/clone: document ignored configuration variables
+ clone: respect additional configured fetch refspecs during initial fetch
+ clone: use a more appropriate variable name for the default refspec
Refspecs configured with "git -c var=val clone" did not propagate
to the resulting repository, which has been corrected.
Will cook in 'next'.
* 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 by reusing the internal
machinery used for "git rebase -i".
* fc/http-version (2018-11-09) 1 commit
(merged to 'next' on 2018-11-18 at 42f5155095)
+ http: add support selecting http version
The "http.version" configuration variable can be used with recent
enough cURL library to force the version of HTTP used to talk when
fetching and pushing.
Will cook in 'next'.
* dl/remote-save-to-push (2018-11-13) 1 commit
- remote: add --save-to-push option to git remote set-url
"git remote set-url" learned a new option that moves existing value
of the URL field to pushURL field of the remote before replacing
the URL field with a new value.
* jk/loose-object-cache (2018-11-24) 10 commits
(merged to 'next' on 2018-11-24 at 5f4f22707d)
+ odb_load_loose_cache: fix strbuf leak
(merged to 'next' on 2018-11-18 at 276691a21b)
+ fetch-pack: drop custom loose object cache
+ sha1-file: use loose object cache for quick existence check
+ object-store: provide helpers for loose_objects_cache
+ sha1-file: use an object_directory for the main object dir
+ handle alternates paths the same as the main object dir
+ sha1_file_name(): overwrite buffer instead of appending
+ rename "alternate_object_database" to "object_directory"
+ submodule--helper: prefer strip_suffix() to ends_with()
+ fsck: do not reuse child_process structs
Code clean-up with optimization for the codepath that checks
(non-)existence of loose objects.
Will cook in 'next'.
* js/protocol-advertise-multi (2018-11-17) 1 commit
- protocol: advertise multiple supported versions
The transport layer has been updated so that the protocol version
used can be negotiated between the parties, by the initiator
listing the protocol versions it is willing to talk, and the other
side choosing from one of them.
* js/smart-http-detect-remote-error (2018-11-17) 3 commits
(merged to 'next' on 2018-11-18 at 5c6edfcb85)
+ remote-curl: die on server-side errors
+ remote-curl: tighten "version 2" check for smart-http
+ remote-curl: refactor smart-http discovery
Some errors from the other side coming over smart HTTP transport
were not noticed, which has been corrected.
Will cook in 'next'.
* nb/branch-show-other-worktrees-head (2018-11-12) 2 commits
- branch: mark and colorize a branch differently if it is checked out in a linked worktree
- ref-filter: add worktree atom
"git branch --list" learned to show branches that are checked out
in other worktrees connected to the same repository prefixed with
'+', similar to the way the currently checked out branch is shown
with '*' in front.
Expecting a reroll.
* nd/the-index (2018-11-12) 22 commits
(merged to 'next' on 2018-11-18 at 73d1d8594e)
+ rebase-interactive.c: remove the_repository references
+ rerere.c: remove the_repository references
+ pack-*.c: remove the_repository references
+ pack-check.c: remove the_repository references
+ notes-cache.c: remove the_repository references
+ line-log.c: remove the_repository reference
+ diff-lib.c: remove the_repository references
+ delta-islands.c: remove the_repository references
+ cache-tree.c: remove the_repository references
+ bundle.c: remove the_repository references
+ branch.c: remove the_repository reference
+ bisect.c: remove the_repository reference
+ blame.c: remove implicit dependency the_repository
+ sequencer.c: remove implicit dependency on the_repository
+ sequencer.c: remove implicit dependency on the_index
+ transport.c: remove implicit dependency on the_index
+ notes-merge.c: remove implicit dependency the_repository
+ notes-merge.c: remove implicit dependency on the_index
+ list-objects.c: reduce the_repository references
+ list-objects-filter.c: remove implicit dependency on the_index
+ wt-status.c: remove implicit dependency the_repository
+ wt-status.c: remove implicit dependency on the_index
More codepaths become aware of working with in-core repository
instance other than the default "the_repository".
Will cook in 'next'.
* ot/ref-filter-object-info (2018-11-24) 6 commits
(merged to 'next' on 2018-11-24 at f8505762e3)
+ ref-filter: replace unportable `%lld` format with %PRIdMAX
(merged to 'next' on 2018-11-18 at ad4c086678)
+ ref-filter: add docs for new options
+ ref-filter: add tests for deltabase
+ ref-filter: add deltabase option
+ ref-filter: add tests for objectsize:disk
+ ref-filter: add objectsize:disk option
The "--format=<placeholder>" option of for-each-ref, branch and tag
learned to show a few more traits of objects that can be learned by
the object_info API.
Will cook in 'next'.
* sb/diff-color-moved-config-option-fixup (2018-11-14) 1 commit
- diff: align move detection error handling with other options
* ab/push-dwim-dst (2018-11-14) 7 commits
(merged to 'next' on 2018-11-18 at 36567023be)
+ push doc: document the DWYM behavior pushing to unqualified <dst>
+ push: test that <src> doesn't DWYM if <dst> is unqualified
+ push: add an advice on unqualified <dst> push
+ push: move unqualified refname error into a function
+ push: improve the error shown on unqualified <dst> push
+ i18n: remote.c: mark error(...) messages for translation
+ remote.c: add braces in anticipation of a follow-up change
"git push $there $src:$dst" rejects when $dst is not a fully
qualified refname and not clear what the end user meant. The
codepath has been taught to give a clearer error message, and also
guess where the push should go by taking the type of the pushed
object into account (e.g. a tag object would want to go under
refs/tags/).
Will cook in 'next'.
* md/list-lazy-objects-fix (2018-10-29) 1 commit
- list-objects.c: don't segfault for missing cmdline objects
"git rev-list --exclude-promissor-objects" had to take an object
that does not exist locally (and is lazily available) from the
command line without barfing, but the code dereferenced NULL.
That sympotom may be worth addressing, but I think the "fix" is
overly broad and is wrong. Giving a missing object should be
diagnosed as an error, not swept under the rug silently.
* nd/i18n (2018-11-12) 16 commits
(merged to 'next' on 2018-11-18 at 5215bd2f7d)
+ fsck: mark strings for translation
+ fsck: reduce word legos to help i18n
+ parse-options.c: mark more strings for translation
+ parse-options.c: turn some die() to BUG()
+ parse-options: replace opterror() with optname()
+ repack: mark more strings for translation
+ remote.c: mark messages for translation
+ remote.c: turn some error() or die() to BUG()
+ reflog: mark strings for translation
+ read-cache.c: add missing colon separators
+ read-cache.c: mark more strings for translation
+ read-cache.c: turn die("internal error") to BUG()
+ attr.c: mark more string for translation
+ archive.c: mark more strings for translation
+ alias.c: mark split_cmdline_strerror() strings for translation
+ git.c: mark more strings for translation
More _("i18n") markings.
Will cook in 'next'.
* sb/more-repo-in-api (2018-11-14) 23 commits
(merged to 'next' on 2018-11-19 at e5d2a129da)
+ t/helper/test-repository: celebrate independence from the_repository
+ path.h: make REPO_GIT_PATH_FUNC repository agnostic
+ commit: prepare free_commit_buffer and release_commit_memory for any repo
+ commit-graph: convert remaining functions to handle any repo
+ submodule: don't add submodule as odb for push
+ submodule: use submodule repos for object lookup
+ pretty: prepare format_commit_message to handle arbitrary repositories
+ commit: prepare logmsg_reencode to handle arbitrary repositories
+ commit: prepare repo_unuse_commit_buffer to handle any repo
+ commit: prepare get_commit_buffer to handle any repo
+ commit-reach: prepare in_merge_bases[_many] to handle any repo
+ commit-reach: prepare get_merge_bases to handle any repo
+ commit-reach.c: allow get_merge_bases_many_0 to handle any repo
+ commit-reach.c: allow remove_redundant to handle any repo
+ commit-reach.c: allow merge_bases_many to handle any repo
+ commit-reach.c: allow paint_down_to_common to handle any repo
+ commit: allow parse_commit* to handle any repo
+ object: parse_object to honor its repository argument
+ object-store: prepare has_{sha1, object}_file to handle any repo
+ object-store: prepare read_object_file to deal with any repo
+ object-store: allow read_object_file_extended to read from any repo
+ packfile: allow has_packed_and_bad to handle arbitrary repositories
+ sha1_file: allow read_object to read objects in arbitrary repositories
The in-core repository instances are passed through more codepaths.
Will cook in 'next'.
cf. <20181115221254.45373-1-jonathantanmy@google.com>
* en/merge-path-collision (2018-11-08) 10 commits
(merged to 'next' on 2018-11-18 at 3ec9286e0b)
+ merge-recursive: combine error handling
+ t6036, t6043: increase code coverage for file collision handling
+ merge-recursive: improve rename/rename(1to2)/add[/add] handling
+ merge-recursive: use handle_file_collision for add/add conflicts
+ merge-recursive: improve handling for rename/rename(2to1) conflicts
+ merge-recursive: fix rename/add conflict handling
+ merge-recursive: new function for better colliding conflict resolutions
+ merge-recursive: increase marker length with depth of recursion
+ t6036, t6042: testcases for rename collision of already conflicting files
+ t6042: add tests for consistency in file collision conflict handling
Updates for corner cases in merge-recursive.
Will cook in 'next'.
* sd/stash-wo-user-name (2018-11-19) 1 commit
(merged to 'next' on 2018-11-19 at 0838b091ea)
+ stash: tolerate missing user identity
A properly configured username/email is required under
user.useConfigOnly in order to create commits; now "git stash"
(even though it creates commit objects to represent stash entries)
command is excempt from the requirement.
Will cook in 'next'.
* bc/sha-256 (2018-11-14) 12 commits
- hash: add an SHA-256 implementation using OpenSSL
- sha256: add an SHA-256 implementation using libgcrypt
- Add a base implementation of SHA-256 support
- commit-graph: convert to using the_hash_algo
- t/helper: add a test helper to compute hash speed
- sha1-file: add a constant for hash block size
- t: make the sha1 test-tool helper generic
- t: add basic tests for our SHA-1 implementation
- cache: make hashcmp and hasheq work with larger hashes
- hex: introduce functions to print arbitrary hashes
- sha1-file: provide functions to look up hash algorithms
- sha1-file: rename algorithm to "sha1"
Add sha-256 hash and plug it through the code to allow building Git
with the "NewHash".
* js/vsts-ci (2018-10-16) 13 commits
. travis: fix skipping tagged releases
. README: add a build badge (status of the Azure Pipelines build)
. tests: record more stderr with --write-junit-xml in case of failure
. tests: include detailed trace logs with --write-junit-xml upon failure
. git-p4: use `test_atexit` to kill the daemon
. git-daemon: use `test_atexit` in the tests
. tests: introduce `test_atexit`
. ci: add a build definition for Azure DevOps
. ci/lib.sh: add support for Azure Pipelines
. tests: optionally write results as JUnit-style .xml
. test-date: add a subcommand to measure times in shell scripts
. ci/lib.sh: encapsulate Travis-specific things
. ci: rename the library of common functions
Prepare to run test suite on Azure DevOps.
Ejected out of 'pu', as doing so seems to help other topics get
tested at TravisCI.
https://travis-ci.org/git/git/builds/452713184 is a sample of a
build whose tests on 4 hang (with this series in). Ejecting it
gave us https://travis-ci.org/git/git/builds/452778963 which still
shows breakages from other topics not yet in 'next', but at least
the tests do not stall.
* du/branch-show-current (2018-10-26) 1 commit
- branch: introduce --show-current display option
"git branch" learned a new subcommand "--show-current".
Is the discussion on this topic over? What was the outcome?
* mk/use-size-t-in-zlib (2018-10-15) 1 commit
- zlib.c: use size_t for size
The wrapper to call into zlib followed our long tradition to use
"unsigned long" for sizes of regions in memory, which have been
updated to use "size_t".
* ag/sequencer-reduce-rewriting-todo (2018-11-12) 16 commits
. rebase--interactive: move transform_todo_file() to rebase--interactive.c
. sequencer: fix a call to error() in transform_todo_file()
. sequencer: use edit_todo_list() in complete_action()
. rebase-interactive: rewrite edit_todo_list() to handle the initial edit
. rebase-interactive: append_todo_help() changes
. rebase-interactive: use todo_list_write_to_file() in edit_todo_list()
. sequencer: refactor skip_unnecessary_picks() to work on a todo_list
. sequencer: change complete_action() to use the refactored functions
. sequencer: make sequencer_make_script() write its script to a strbuf
. sequencer: refactor rearrange_squash() to work on a todo_list
. sequencer: refactor sequencer_add_exec_commands() to work on a todo_list
. sequencer: refactor check_todo_list() to work on a todo_list
. sequencer: introduce todo_list_write_to_file()
. sequencer: refactor transform_todos() to work on a todo_list
. sequencer: make the todo_list structure public
. sequencer: changes in parse_insn_buffer()
The scripted version of "git rebase -i" wrote and rewrote the todo
list many times during a single step of its operation, and the
recent C-rewrite made a faithful conversion of the logic to C. The
implementation has been updated to carry necessary information
around in-core to avoid rewriting the same file over and over
unnecessarily.
With too many topics in-flight that touch sequencer and rebaser,
this need to wait giving precedence to other topics that fix bugs.
* sb/submodule-recursive-fetch-gets-the-tip (2018-10-31) 11 commits
- builtin/fetch: check for submodule updates in any ref update
- fetch: try fetching submodules if needed objects were not fetched
- submodule.c: fetch in submodules git directory instead of in worktree
- submodule: migrate get_next_submodule to use repository structs
- repository: repo_submodule_init to take a submodule struct
- submodule: store OIDs in changed_submodule_names
- submodule.c: tighten scope of changed_submodule_names struct
- submodule.c: sort changed_submodule_names before searching it
- submodule.c: fix indentation
- sha1-array: provide oid_array_filter
- Merge branch 'ao/submodule-wo-gitmodules-checked-out' into sb/submodule-recursive-fetch-gets-the-tip
"git fetch --recurse-submodules" may not fetch the necessary commit
that is bound to the superproject, which is getting corrected.
Is the discussion on this topic over? What was the outcome?
* js/add-i-coalesce-after-editing-hunk (2018-08-28) 1 commit
- add -p: coalesce hunks before testing applicability
Applicability check after a patch is edited in a "git add -i/p"
session has been improved.
Will hold.
cf. <e5b2900a-0558-d3bf-8ea1-d526b078bbc2@talktalk.net>
* ps/stash-in-c (2018-11-26) 22 commits
. stash: replace all `write-tree` child processes with API calls
. stash: optimize `get_untracked_files()` and `check_changes()`
. stash: convert `stash--helper.c` into `stash.c`
. stash: convert save to builtin
. stash: make push -q quiet
. stash: convert push to builtin
. stash: convert create to builtin
. stash: convert store to builtin
. stash: convert show to builtin
. stash: convert list to builtin
. stash: convert pop to builtin
. stash: convert branch to builtin
. stash: convert drop and clear to builtin
. stash: convert apply to builtin
. stash: mention options in `show` synopsis
. stash: add tests for `git stash show` config
. stash: rename test cases to be more descriptive
. t3903: modernize style
. stash: improve option parsing test coverage
. strbuf.c: add `strbuf_insertf()` and `strbuf_vinsertf()`
. strbuf.c: add `strbuf_join_argv()`
. sha1-name.c: add `get_oidf()` which acts like `get_oid()`
"git stash" rewritten in C.
Expecting a reroll, probably on top of the sd/stash-wo-user-name
topic after it stabilizes, with an escape hatch like the one in
"rebase in C".
* pw/add-p-select (2018-07-26) 4 commits
- add -p: optimize line selection for short hunks
- add -p: allow line selection to be inverted
- add -p: select modified lines correctly
- add -p: select individual hunk lines
"git add -p" interactive interface learned to let users choose
individual added/removed lines to be used in the operation, instead
of accepting or rejecting a whole hunk.
Will discard.
No further feedbacks on the topic for quite some time.
cf. <d622a95b-7302-43d4-4ec9-b2cf3388c653@talktalk.net>
I found the feature to be hard to explain, and may result in more
end-user complaints, but let's see.
--------------------------------------------------
[Discarded]
* ab/reject-alias-loop (2018-10-19) 1 commit
(merged to 'next' on 2018-10-26 at bc213f1bef)
+ alias: detect loops in mixed execution mode
Two (or more) aliases that mutually refer to each other can form an
infinite loop; we now attempt to notice and stop.
Discarded.
Reverted out of 'next'.
cf. <87sh0slvxm.fsf@evledraar.gmail.com>
* gl/bundle-unlock-before-aborting (2018-11-14) 1 commit
. bundle: rollback lock file while refusing to create an empty bundle
Superseded by jk/close-duped-fd-before-unlock-for-bundle
* js/remote-archive-v2 (2018-09-28) 4 commits
(merged to 'next' on 2018-10-12 at 5f34377f60)
+ archive: allow archive over HTTP(S) with proto v2
+ archive: implement protocol v2 archive command
+ archive: use packet_reader for communications
+ archive: follow test standards around assertions
The original implementation of "git archive --remote" more or less
bypassed the transport layer and did not work over http(s). The
version 2 of the protocol is defined to allow going over http(s) as
well as Git native transport.
Retracted; reverted out of next.
cf. <20181114195142.GI126896@google.com>
* ab/format-patch-rangediff-not-stat (2018-11-24) 1 commit
(merged to 'next' on 2018-11-26 at d9c84916b3)
+ format-patch: don't include --stat with --range-diff output
The "--rangediff" option recently added to "format-patch"
interspersed a bogus and useless "--stat" information by mistake,
which is being corrected.
Reverted out of 'next'.
* jc/postpone-rebase-in-c (2018-11-26) 1 commit
(merged to 'next' on 2018-11-26 at c6ae45110f)
+ rebase: mark the C reimplementation as an experimental opt-in feature
People seem to be still finding latent bugs in the "rebase in C"
reimplementation. For the upcoming release, use the scripted
version by default and adjust the documentation accordingly.
Reverted out of 'next'.
^ permalink raw reply
* Re: [PATCH] format-patch: do not let its diff-options affect --range-diff (was Re: [PATCH 2/2] format-patch: allow for independent diff & range-diff options)
From: Junio C Hamano @ 2018-11-30 8:57 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Ævar Arnfjörð Bjarmason, git, Eric Sunshine
In-Reply-To: <xmqqwoovkx5s.fsf_-_@gitster-ct.c.googlers.com>
Junio C Hamano <gitster@pobox.com> 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 top of 'master' instead? As this leaks
> *no* information wrt how range-diff machinery should behave from the
> format-patch side by not passing any diffopt, as long as the new
> code I added to show_range_diff() comes up with a reasonable default
> diffopts (for which I really would appreciate extra sets of eyes to
> make sure), this change by definition cannot be wrong (famous last
> words).
As listed in today's "What's cooking" report, I've merged this to
'next' in today's pushout and planning to have it in the -rc2. I am
not married to this exact implementation, and I'd welcome to have an
even simpler and less disruptive solution if exists, but I am hoping
that this is a good-enough interim measure for the upcoming release,
until we decide what to do with the customizability of range-diff
driven by format-patch.
In addition to this, I am planning the "rebase --stat" and "reflog
that does not say 'rebase -i' but 'rebase'" fixes merged to 'master'
before cutting -rc2.
^ permalink raw reply
* Re: [PATCH/RFC v3 00/14] Introduce new commands switch-branch and restore-files
From: Duy Nguyen @ 2018-11-30 6:49 UTC (permalink / raw)
To: dan
Cc: Ævar Arnfjörð Bjarmason, Git Mailing List,
Junio C Hamano, Stefan Beller, Thomas Gummerer, Stefan Xenos,
Elijah Newren
In-Reply-To: <340837B7-3004-44F7-9A30-BD3A26876D76@fabulich.com>
On Fri, Nov 30, 2018 at 1:16 AM Dan Fabulich <dan@fabulich.com> 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 fix your mistakes is fucking impossible. Git documentation has this chicken and egg problem where you can't search for how to get yourself out of a mess, unless you *already know the name of the thing you need to know about* in order to fix your problem.
>
> A significant fraction of the top-voted questions on StackOverflow are about undoing changes. https://stackoverflow.com/questions/tagged/git
>
> What if there were a 'git undo' command that could unify the answers to all of these questions?
>
> git undo stage
> git undo rm
> git undo edit (checkout files from the stage)
>
> git undo commit (prompt the user whether to revert or reset)
> git undo reset
> git undo checkout
>
> git undo merge
> git undo pull
> git undo push (prompt the user whether to force push back to the past or whether to revert pushed commits)
> git undo rebase
>
> git undo undo
>
> git undo clean
> git undo delete-branch
> git undo delete-stash
>
> Some of these would be trivial effort, but a lot of them would require fundamental changes in the way git operates. (You can't undo a clean right now because the files are just destroyed.)
We're getting there. The biggest problem I have is how this "git undo"
should work, not the changes behind to support it. For example, if I
pulled then did some rebase, what would "git undo pull" do?
--
Duy
^ permalink raw reply
* Re: [PATCH/RFC v3 00/14] Introduce new commands switch-branch and restore-files
From: Junio C Hamano @ 2018-11-30 6:47 UTC (permalink / raw)
To: Duy Nguyen
Cc: Ævar Arnfjörð Bjarmason, Git Mailing List,
Stefan Beller, Thomas Gummerer, Stefan Xenos, Elijah Newren, dan
In-Reply-To: <CACsJy8DCKQctO+rf=xP5gVVUy9XBq35Z1xSbfwB30nDJMMJsrA@mail.gmail.com>
Duy Nguyen <pclouds@gmail.com> 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".
Yup, very good point to keep in mind.
^ permalink raw reply
* Re: [PATCH/RFC v3 00/14] Introduce new commands switch-branch and restore-files
From: Junio C Hamano @ 2018-11-30 6:46 UTC (permalink / raw)
To: Duy Nguyen
Cc: Ævar Arnfjörð Bjarmason, Git Mailing List,
Stefan Beller, Thomas Gummerer, Stefan Xenos
In-Reply-To: <CACsJy8BZ7s2TbqiO+hensOF0quz+N3h5+GwKqiNTakGaGJ2yeA@mail.gmail.com>
Duy Nguyen <pclouds@gmail.com> 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 touches the "remote" concept which I think is another confusing
> thing for new people (your "master" is not the same as the server's
> "master", aka origin/master) and perhaps this dwim thing helps.
> Frankly I don't do dwim much so I don't know if it's that often used.
I actually think a user who sees a DWIM without understanding what
the user wants to do would perceive magic that sometimes works and
sometimes does not, and some other times it does a random thing that
the user does not even understand what is going on. And such a
random magic that sometimes works, even if the "sometimes" is "most
of the time", say 85% of the time, would not help user form the
right mental model.
"git checkout master~2" that DWIMs to "git checkout --deatch
master~2", but does totally different thing when "git checkout
master" is given, leaving the user confused "what is so different
between these two?". Until the user realizes 'master' can serve
both as a branch name and a name for a commit object, while master~2
can only be a name for a commit object and is not a branch name, the
behaviour of the command will stay to be mysterious and DWIMmage
would not help user form the right mental model. I earlier said
that I agree with your decision to leave the implied form out of
switch-branch for exactly that reason.
The behaviour falls into the same category as "git checkout frotz"
that DWIMS to "git checkout -b frotz -t remotes/origin/frotz", which
also is mysterious until the user understands your 'master' is unique
and is different from 'master' to everybody else, I would think.
^ permalink raw reply
* Re: [PATCH/RFC v3 00/14] Introduce new commands switch-branch and restore-files
From: Duy Nguyen @ 2018-11-30 5:41 UTC (permalink / raw)
To: Junio C Hamano
Cc: Ævar Arnfjörð Bjarmason, Git Mailing List,
Stefan Beller, Thomas Gummerer, Stefan Xenos
In-Reply-To: <xmqqefb3mhrs.fsf@gitster-ct.c.googlers.com>
On Fri, Nov 30, 2018 at 3:16 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> Nguyễn Thái Ngọc Duy <pclouds@gmail.com> 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 too subtle
> and implicit, just like the detaching head is, and require --guess
> or sticking to 'git checkout'? I think it should.
This touches the "remote" concept which I think is another confusing
thing for new people (your "master" is not the same as the server's
"master", aka origin/master) and perhaps this dwim thing helps.
Frankly I don't do dwim much so I don't know if it's that often used.
> > - -b/-B is renamed to -c/-C with long option names
>
> I did not expect that these two are the only options that would be
> out of place with the command name split, but presumably you looked
> at all options for both of the two new commands to see if they made
> sense in the new context?
Yeah (at least the description in struct option[] array)
--
Duy
^ permalink raw reply
* Re: [PATCH/RFC v3 00/14] Introduce new commands switch-branch and restore-files
From: Duy Nguyen @ 2018-11-30 5:37 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: Git Mailing List, Junio C Hamano, Stefan Beller, Thomas Gummerer,
Stefan Xenos, Elijah Newren, dan
In-Reply-To: <87pnunxz5i.fsf@evledraar.gmail.com>
On Fri, Nov 30, 2018 at 12:05 AM Ævar Arnfjörð Bjarmason
<avarab@gmail.com> 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 <treeish> -- <pathspec>", and we'd have:
>
> git switch <branchish>
> git checkout <pathspec>
> git checkout-tree <treeish> -- <pathspec>
>
> Or maybe that sucks, anyway what I was going to suggest is *if* others
> think that made sense as a "if we designed git today" endgame whether we
> could have an opt-in setting where you set e.g. core.uiVersion=3 (in
> anticipation of Git 3.0) and you'd get that behavior. There could be
> some other setting where core.uiVersion would use the old behavior (or
> with another setting, only warn) if we weren't connected to a terminal.
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
^ permalink raw reply
* [PATCH] format-patch: do not let its diff-options affect --range-diff (was Re: [PATCH 2/2] format-patch: allow for independent diff & range-diff options)
From: Junio C Hamano @ 2018-11-30 4:27 UTC (permalink / raw)
To: Johannes Schindelin, Ævar Arnfjörð Bjarmason
Cc: git, Eric Sunshine
In-Reply-To: <xmqq7egvmh54.fsf@gitster-ct.c.googlers.com>
Junio C Hamano <gitster@pobox.com> 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
> upcoming release, and declare that the UI to pass diff options to
> affect only the range-diff part may later be invented. IOW, I am
> coming a bit stronger than Dscho's suggestion in that we should not
> even pretend that we aimed to make the options used for range-diff
> customizable when driven from format-patch in the upcoming release,
> or aimed to make --range-diff option compatible with other diff
> options given to the format-patch command.
>
> 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 top of 'master' instead? As this leaks
*no* information wrt how range-diff machinery should behave from the
format-patch side by not passing any diffopt, as long as the new
code I added to show_range_diff() comes up with a reasonable default
diffopts (for which I really would appreciate extra sets of eyes to
make sure), this change by definition cannot be wrong (famous last
words).
-- >8 --
Subject: format-patch: do not let its diff-options affect --range-diff
Stop leaking how the primary output of format-patch is customized to
the range-diff machinery and instead let the latter use its own
"reasonable default", in order to correct the breakage introduced by
a5170794 ("Merge branch 'ab/range-diff-no-patch'", 2018-11-18) on
the 'master' front. "git format-patch --range-diff..." without any
weird diff option started to include the "range-diff --stat" output,
which is rather useless right now, that made the whole thing
unusable and this is probably the least disruptive way to whip the
codebase into a shippable shape.
We may want to later make the range-diff driven by format-patch more
configurable, but that would have to wait until we have a good
design.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Documentation/git-format-patch.txt | 5 +++++
builtin/log.c | 2 +-
log-tree.c | 2 +-
range-diff.c | 6 +++++-
range-diff.h | 5 +++++
5 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
index aba4c5febe..27304428a1 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -250,6 +250,11 @@ feeding the result to `git send-email`.
feature/v2`), or a revision range if the two versions of the series are
disjoint (for example `git format-patch --cover-letter
--range-diff=feature/v1~3..feature/v1 -3 feature/v2`).
++
+Note that diff options passed to the command affect how the primary
+product of `format-patch` is generated, and they are not passed to
+the underlying `range-diff` machinery used to generate the cover-letter
+material (this may change in the future).
--creation-factor=<percent>::
Used with `--range-diff`, tweak the heuristic which matches up commits
diff --git a/builtin/log.c b/builtin/log.c
index 0fe6f9ba1e..5ac18e2848 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -1096,7 +1096,7 @@ static void make_cover_letter(struct rev_info *rev, int use_stdout,
if (rev->rdiff1) {
fprintf_ln(rev->diffopt.file, "%s", rev->rdiff_title);
show_range_diff(rev->rdiff1, rev->rdiff2,
- rev->creation_factor, 1, &rev->diffopt);
+ rev->creation_factor, 1, NULL);
}
}
diff --git a/log-tree.c b/log-tree.c
index 7a83e99250..b243779a0b 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -762,7 +762,7 @@ void show_log(struct rev_info *opt)
next_commentary_block(opt, NULL);
fprintf_ln(opt->diffopt.file, "%s", opt->rdiff_title);
show_range_diff(opt->rdiff1, opt->rdiff2,
- opt->creation_factor, 1, &opt->diffopt);
+ opt->creation_factor, 1, NULL);
memcpy(&diff_queued_diff, &dq, sizeof(diff_queued_diff));
}
diff --git a/range-diff.c b/range-diff.c
index 767af8c5bb..8e52a85c19 100644
--- a/range-diff.c
+++ b/range-diff.c
@@ -460,7 +460,11 @@ int show_range_diff(const char *range1, const char *range2,
struct diff_options opts;
struct strbuf indent = STRBUF_INIT;
- memcpy(&opts, diffopt, sizeof(opts));
+ if (diffopt)
+ memcpy(&opts, diffopt, sizeof(opts));
+ else
+ repo_diff_setup(the_repository, &opts);
+
if (!opts.output_format)
opts.output_format = DIFF_FORMAT_PATCH;
opts.flags.suppress_diff_headers = 1;
diff --git a/range-diff.h b/range-diff.h
index 190593f0c7..08a50b6e98 100644
--- a/range-diff.h
+++ b/range-diff.h
@@ -5,6 +5,11 @@
#define RANGE_DIFF_CREATION_FACTOR_DEFAULT 60
+/*
+ * Compare series of commmits in RANGE1 and RANGE2, and emit to the
+ * standard output. NULL can be passed to DIFFOPT to use the built-in
+ * default.
+ */
int show_range_diff(const char *range1, const char *range2,
int creation_factor, int dual_color,
struct diff_options *diffopt);
^ permalink raw reply related
* Re: [PATCH 3/5] pack-objects: add --sparse option
From: Junio C Hamano @ 2018-11-30 2:39 UTC (permalink / raw)
To: Derrick Stolee
Cc: Stefan Beller, gitgitgadget, git, Jeff King,
Ævar Arnfjörð Bjarmason, Jonathan Nieder,
Derrick Stolee
In-Reply-To: <1e9d4d2d-561e-fcbc-48cf-374dcb9ce009@gmail.com>
Derrick Stolee <stolee@gmail.com> 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 majority of users are clients.
>
> 2. Client users are not likely to know about and tweak these settings.
>
> 3. Server users are more likely to keep an eye on the different knobs
> they can tweak.
>
> 4. Servers should use the reachability bitmaps, which don't use this
> logic anyway.
>
> 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 releases
we'll hear "enough users complain that they have to turn it on,
let's make it the default". If that does not happen, the knob
does not deserve to be turned on in the first place.
The same applies to many shiny new toys people are discussing
recently on this list (e.g. precious vs expendable and non-overlay
checkout are the ones that immediately come to my mind).
Having said that, I won't be commenting on this shiny new toy before
the final. I want to see more people help tying the loose ends and
give it final varnish to the upcoming release, as it seems to have
become rockier and larger release than we originally anticipated.
^ permalink raw reply
* Re: [PATCH 2/2] format-patch: allow for independent diff & range-diff options
From: Junio C Hamano @ 2018-11-30 2:30 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: Johannes Schindelin, git, Eric Sunshine
In-Reply-To: <87tvjzyiph.fsf@evledraar.gmail.com>
Ævar Arnfjörð Bjarmason <avarab@gmail.com> 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:
>
> --range-diff-opts="--word-diff-regex='[0-9\"]'"
>
> Now admittedly that in itself isn't very painful *in this case*, but in
> terms of precedent I really dislike that option, i.e. git having some
> mode where I need to work to escape input to pass to another command.
In addition, sq_dequote are meant to be used on quoted string we
internally produce; I do not think we want to promise that it is
safe to use on a random string that comes from end users.
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
upcoming release, and declare that the UI to pass diff options to
affect only the range-diff part may later be invented. IOW, I am
coming a bit stronger than Dscho's suggestion in that we should not
even pretend that we aimed to make the options used for range-diff
customizable when driven from format-patch in the upcoming release,
or aimed to make --range-diff option compatible with other diff
options given to the format-patch command.
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.
^ permalink raw reply
* Re: [PATCH/RFC v3 00/14] Introduce new commands switch-branch and restore-files
From: Junio C Hamano @ 2018-11-30 2:16 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy
Cc: avarab, git, sbeller, t.gummerer, sxenos
In-Reply-To: <20181129215850.7278-1-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> 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 too subtle
and implicit, just like the detaching head is, and require --guess
or sticking to 'git checkout'? I think it should.
> - -b/-B is renamed to -c/-C with long option names
I did not expect that these two are the only options that would be
out of place with the command name split, but presumably you looked
at all options for both of the two new commands to see if they made
sense in the new context?
> 'git restore-files'
>
> - takes a ref from --from argument, not as a free ref. As a result,
> '--' is no longer needed. All non-option arguments are pathspec
OK. That does make things easier to teach, as there is no need for
disambiguation.
> - pathspec is mandatory, you can't do "git restore-files" without any
> pathspec.
>
> - I just remember -p which is allowed to take no pathspec :( I'll fix
> it later.
Or leave it out of restore-files as a more advanced feature (just
like detaching with HEAD^0 is left out of switch-branch) that the
user can stick to 'git checkout' to use.
> - Two more fancy features (the "git checkout --index" being the
> default mode and the backup log for accidental overwrites) are of
> course still missing. But they are coming.
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 'both the index
and the working tree files' mode", but when "restore-files" touches
paths, it always modifies both the index and the working tree, so
the "--index" option does not capture the differences well in this
context [*1*]. As I saw this was described as "not using the usual
'overlay' semantics [*2*]", perhaps --overlay/--no-overlay option
that defaults to --no-overlay is easier to explain.
side note 1. I think the original mention of "--index" came in
the context of contrasting "git reset" with "git checkout".
"git reset (--hard|--mixed) -- <pathspec>" (that does not move
HEAD), which does not but perhaps should exist, is very much
like "git checkout -- <pathspec>", and if "reset" were written
after the "--index/--cached" convention was established, "reset
--hard" would have called "reset --index" while "reset --mixed"
would have been "reset --cached" (i.e. only work on the index
and not on the working tree). And "reset --index <directory>"
would have worked by removing paths in <directory> that are not
in the HEAD and updating paths in <directory> that are in the
HEAD, i.e. identical to the non overlay behaviour proposed for
the "git checkout" command. So calling the non overlay mode
"--index" makes sense in the context of discussing "git reset",
and not in the context of "git checkout".
side note 2. "git checkout <tree-ish> <pathspec>" grabs entries
from the <tree-ish> that patch <pathspec> and adds them to the
index and checks them out to the working tree. If the original
index has entries that match <pathspec> but do not appear in
<tree-ish>, they are left in the result. That is "overlaying
what was taken from the <tree-ish> on top of what is in the
index".
Having said all that, I will not be looking at the series until 2.20
final. And I hope more people do the same to concentrate on helping
us prevent the last minute glitch slipping in the final release.
Thanks.
^ permalink raw reply
* Re: [PATCH/RFC v2 0/7] Introduce new commands switch-branch and checkout-files
From: Junio C Hamano @ 2018-11-30 1:47 UTC (permalink / raw)
To: Duy Nguyen
Cc: Ævar Arnfjörð Bjarmason, Git Mailing List,
Stefan Beller, Thomas Gummerer
In-Reply-To: <CACsJy8Cv9ZwWEs-wsOtms3JCXo7x8fL_PBatcb0TgvrrQuMUdg@mail.gmail.com>
Duy Nguyen <pclouds@gmail.com> writes:
> On Wed, Nov 28, 2018 at 9:01 PM Duy Nguyen <pclouds@gmail.com> 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 least at high UI level) instead of detached HEAD. It is
> technically not as accurate, but much better to understand.
As I said elsewhere in nearby thread, I agree that "unnamed branch"
is a reasonable way to explain what the state the user is in. It is
not incorrect per-se that HEAD is detached from anything in refs/ in
such a state, but that is an implementation detail of how the
worktree gets on the unnamed branch (which lasts until the worktree
next gets on a named branch, at which point the unnamed branch
disappears).
^ permalink raw reply
* Re: [PATCH 1/1] rebase --stat: fix when rebasing to an unrelated history
From: Junio C Hamano @ 2018-11-30 1:40 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Johannes Schindelin via GitGitGadget, git
In-Reply-To: <nycvar.QRO.7.76.6.1811291318090.41@tvgsbejvaqbjf.bet>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> But I guess that I should not be so lazy and really use two different
> messages here:
>
> Changes from <merge-base> to <onto>
>
> and if there is no merge base,
>
> Changes in <onto>
Ah, that's excellent.
Thanks.
^ permalink raw reply
* Re: [PATCH] pack-protocol.txt: accept error packets in any context
From: Junio C Hamano @ 2018-11-30 1:39 UTC (permalink / raw)
To: Masaya Suzuki; +Cc: git
In-Reply-To: <CAJB1erVBMq84gXir1YD=3R_RXS+qXYAsPKo6ecEJBBNv-4JOFQ@mail.gmail.com>
Masaya Suzuki <masayasuzuki@google.com> 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.
^ permalink raw reply
* Re: [PATCH/RFC v3 00/14] Introduce new commands switch-branch and restore-files
From: Dan Fabulich @ 2018-11-30 0:16 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: Nguyễn Thái Ngọc Duy, git, gitster, sbeller,
t.gummerer, sxenos, Elijah Newren
In-Reply-To: <87pnunxz5i.fsf@evledraar.gmail.com>
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 fix your mistakes is fucking impossible. Git documentation has this chicken and egg problem where you can't search for how to get yourself out of a mess, unless you *already know the name of the thing you need to know about* in order to fix your problem.
A significant fraction of the top-voted questions on StackOverflow are about undoing changes. https://stackoverflow.com/questions/tagged/git
What if there were a 'git undo' command that could unify the answers to all of these questions?
git undo stage
git undo rm
git undo edit (checkout files from the stage)
git undo commit (prompt the user whether to revert or reset)
git undo reset
git undo checkout
git undo merge
git undo pull
git undo push (prompt the user whether to force push back to the past or whether to revert pushed commits)
git undo rebase
git undo undo
git undo clean
git undo delete-branch
git undo delete-stash
Some of these would be trivial effort, but a lot of them would require fundamental changes in the way git operates. (You can't undo a clean right now because the files are just destroyed.)
-Dan
> On Nov 29, 2018, at 3:05 PM, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
>
>
> On Thu, Nov 29 2018, 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'll try to summarize the differences between the new commands and
>> 'git checkout' down here, but you're welcome to just head to 07/14 and
>> read the new man pages.
>>
>> 'git switch-branch'
>>
>> - does not "do nothing", you have to either switch branch, create a
>> new branch, or detach. "git switch-branch" with no arguments is
>> rejected.
>>
>> - implicit detaching is rejected. If you need to detach, you need to
>> give --detach. Or stick to 'git checkout'.
>>
>> - -b/-B is renamed to -c/-C with long option names
>>
>> - of course does not accept pathspec
>>
>> 'git restore-files'
>>
>> - takes a ref from --from argument, not as a free ref. As a result,
>> '--' is no longer needed. All non-option arguments are pathspec
>>
>> - pathspec is mandatory, you can't do "git restore-files" without any
>> pathspec.
>>
>> - I just remember -p which is allowed to take no pathspec :( I'll fix
>> it later.
>>
>> - Two more fancy features (the "git checkout --index" being the
>> default mode and the backup log for accidental overwrites) 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 "no branch" is good enough. I dunno.
>
> I finally tracked down
> https://redfin.engineering/two-commits-that-wrecked-the-user-experience-of-git-f0075b77eab1
> which I'd remembered reading and couldn't find again in these
> discussions. Re-reading it while one may not 100% agree with the
> author's opinion, it's an interesting rabbit hole.
>
> I also didn't know about EasyGit, or that Elijah Newren had written
> it. I haven't seen him chime in on this series, and would be interested
> to see what he thinks about it.
>
> Re the naming question in
> https://public-inbox.org/git/87o9abzv46.fsf@evledraar.gmail.com/ &
> seeing that eg-switch exists, I wonder if just s/switch-branch/switch/
> makes more sense.
>
> 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 <treeish> -- <pathspec>", and we'd have:
>
> git switch <branchish>
> git checkout <pathspec>
> git checkout-tree <treeish> -- <pathspec>
>
> Or maybe that sucks, anyway what I was going to suggest is *if* others
> think that made sense as a "if we designed git today" endgame whether we
> could have an opt-in setting where you set e.g. core.uiVersion=3 (in
> anticipation of Git 3.0) and you'd get that behavior. There could be
> some other setting where core.uiVersion would use the old behavior (or
> with another setting, only warn) if we weren't connected to a terminal.
>
> I.e. I'm thinking of this as step #2 in a #3 step series. Where this is
> the fully backwards compatible UI improvement, but someone who'd
> e.g. use EasyGit or didn't have backwards compatibility concerns could
> enable step #3 and opt-in to a mode where we'd fixed a bunch of UI warts
> in a backwards-incompatible way.
>
> What would that mode look like? I'd to work on piling that on top of
> this :)
^ permalink raw reply
* Re: [PATCH/RFC v3 00/14] Introduce new commands switch-branch and restore-files
From: Dan Fabulich @ 2018-11-29 23:37 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: Nguyễn Thái Ngọc Duy, git, gitster, sbeller,
t.gummerer, sxenos, Elijah Newren
In-Reply-To: <87pnunxz5i.fsf@evledraar.gmail.com>
Assuming the great day has come to think about this, one thing I'd love to do is to unify the name of the index/stage/cache in command-line parameters and the documentation.
The index/stage/cache should have one canonical name, and the documentation should support that consistently. My taste is to call it the "stage," but references to --index, --keep-index, --no-index, etc. are all over the code, as well as legacy references to "--cached".
* You can 'git rm --cached myfile' but you can't 'git rm --staged myfile' or 'git rm --index myfile'.
* You can 'git diff --no-index' or you can 'git diff --cached' with 'git diff --staged' as a synonym, deprioritized in the documentation ("--staged is a synonym of --cached"). But you can't 'git diff --index' or 'git diff --no-stage' or 'git diff --no-cache'.
* You can 'git stage' but 'git help stage' is only one line long, declaring that it's a synonym for 'git add'. 'add' appears in the 'git help' common commands, but not 'git stage'. There's no built-in 'git unstage', and certainly no appetite for 'git index' or 'git cache'.
* Not to mention all of the plumbing commands: checkout-index, diff-index, index-pack, merge-index, show-index, and update-index.
My understanding based on historical threads is that changes like this would be unwelcome, even just to add synonyms and standardize the documentation around "stage" as the term (leaving the plumbing commands alone), but if documentation+synonym patches are welcome here, I'd be very enthusiastic.
-Dan
> On Nov 29, 2018, at 3:05 PM, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
>
>
> On Thu, Nov 29 2018, 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'll try to summarize the differences between the new commands and
>> 'git checkout' down here, but you're welcome to just head to 07/14 and
>> read the new man pages.
>>
>> 'git switch-branch'
>>
>> - does not "do nothing", you have to either switch branch, create a
>> new branch, or detach. "git switch-branch" with no arguments is
>> rejected.
>>
>> - implicit detaching is rejected. If you need to detach, you need to
>> give --detach. Or stick to 'git checkout'.
>>
>> - -b/-B is renamed to -c/-C with long option names
>>
>> - of course does not accept pathspec
>>
>> 'git restore-files'
>>
>> - takes a ref from --from argument, not as a free ref. As a result,
>> '--' is no longer needed. All non-option arguments are pathspec
>>
>> - pathspec is mandatory, you can't do "git restore-files" without any
>> pathspec.
>>
>> - I just remember -p which is allowed to take no pathspec :( I'll fix
>> it later.
>>
>> - Two more fancy features (the "git checkout --index" being the
>> default mode and the backup log for accidental overwrites) 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 "no branch" is good enough. I dunno.
>
> I finally tracked down
> https://redfin.engineering/two-commits-that-wrecked-the-user-experience-of-git-f0075b77eab1
> which I'd remembered reading and couldn't find again in these
> discussions. Re-reading it while one may not 100% agree with the
> author's opinion, it's an interesting rabbit hole.
>
> I also didn't know about EasyGit, or that Elijah Newren had written
> it. I haven't seen him chime in on this series, and would be interested
> to see what he thinks about it.
>
> Re the naming question in
> https://public-inbox.org/git/87o9abzv46.fsf@evledraar.gmail.com/ &
> seeing that eg-switch exists, I wonder if just s/switch-branch/switch/
> makes more sense.
>
> 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 <treeish> -- <pathspec>", and we'd have:
>
> git switch <branchish>
> git checkout <pathspec>
> git checkout-tree <treeish> -- <pathspec>
>
> Or maybe that sucks, anyway what I was going to suggest is *if* others
> think that made sense as a "if we designed git today" endgame whether we
> could have an opt-in setting where you set e.g. core.uiVersion=3 (in
> anticipation of Git 3.0) and you'd get that behavior. There could be
> some other setting where core.uiVersion would use the old behavior (or
> with another setting, only warn) if we weren't connected to a terminal.
>
> I.e. I'm thinking of this as step #2 in a #3 step series. Where this is
> the fully backwards compatible UI improvement, but someone who'd
> e.g. use EasyGit or didn't have backwards compatibility concerns could
> enable step #3 and opt-in to a mode where we'd fixed a bunch of UI warts
> in a backwards-incompatible way.
>
> What would that mode look like? I'd to work on piling that on top of
> this :)
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox