On Thu, Apr 25, 2019 at 10:50 PM Junio C Hamano wrote:
> Eric Sunshine writes:
> > test_when_finished '
> > git checkout branch1 &&
> > test_might_fail git branch -D branch2
> > ' &&
>
> Perhaps. Be careful in choosing the quotes between sq and dq,
> though.
Yep, thanks
Taylor Blau writes:
> Ah, I _can_ see the merge in my local copy (fetched from
> https://github.com/git/git) as c49927fca0 (Merge branch 'tb/unexpected'
> into next, 2019-04-25).
>
> I looked for the commits themselves with:
>
> $ git log --author=Taylor
>
> on 'next', but only found the first
On Fri, Apr 26, 2019 at 02:41:38PM +0900, Junio C Hamano wrote:
> Taylor Blau writes:
>
> > On Thu, Apr 25, 2019 at 07:15:06PM +0900, Junio C Hamano wrote:
> >> * tb/unexpected (2019-04-10) 7 commits
> >> (merged to 'next' on 2019-04-25 at c49927fca0)
> >> + rev-list: detect broken root trees
>
Taylor Blau writes:
> On Thu, Apr 25, 2019 at 07:15:06PM +0900, Junio C Hamano wrote:
>> * tb/unexpected (2019-04-10) 7 commits
>> (merged to 'next' on 2019-04-25 at c49927fca0)
>> + rev-list: detect broken root trees
>> + rev-list: let traversal die when --missing is not in use
>> + get_com
Hi Junio,
On Thu, Apr 25, 2019 at 07:15:06PM +0900, Junio C Hamano wrote:
> * tb/unexpected (2019-04-10) 7 commits
> (merged to 'next' on 2019-04-25 at c49927fca0)
> + rev-list: detect broken root trees
> + rev-list: let traversal die when --missing is not in use
> + get_commit_tree(): return
Junio C Hamano writes:
> Denton Liu writes:
>
>> -new_branch_info->name = arg;
>> +new_branch_info->name = strstr(arg, "...") ?
>> +xstrdup(oid_to_hex(rev)) :
>> +arg;
>
> Can we do better?
>
> I am not sure why we want to hardcode the knowledge of "..." syntax
>
On Wed, Apr 24, 2019 at 3:36 PM Thomas Gummerer wrote:
>
> On 04/23, Matheus Tavares Bernardino wrote:
> > On Thu, Apr 11, 2019 at 6:09 PM Thomas Gummerer
> > wrote:
> > >
> > > On 04/10, Matheus Tavares Bernardino wrote:
> > > > > > diff --git a/dir-iterator.h b/dir-iterator.h
> > > > > > index
Denton Liu writes:
> - new_branch_info->name = arg;
> + new_branch_info->name = strstr(arg, "...") ?
> + xstrdup(oid_to_hex(rev)) :
> + arg;
Can we do better?
I am not sure why we want to hardcode the knowledge of "..." syntax
like this here. "git checkout A...B
Eric Sunshine writes:
>> test_expect_success 'checkout -b to a new branch, set to HEAD' '
>> + test_when_finished test_might_fail git branch -D branch2 &&
>> + test_when_finished git checkout branch1 &&
>
> I'm aware that when-finished actions fire in reverse order but the
> inherent
Derrick Stolee writes:
> On 4/25/2019 1:08 PM, Josh Steadmon wrote:
>> Fix trace2_data_json_fl() to check for the presence of pfn_data_json_fl
>> in its targets, rather than pfn_data_fl, which is not actually called.
>
> [snip]
>
>> for_each_wanted_builtin (j, tgt_j)
>> -if (tgt_
Eric Sunshine writes:
> On Thu, Apr 25, 2019 at 11:51 AM Elijah Newren wrote:
>> This test used an author with non-ascii characters in the name, but
>> no special commit message. It then grep'ed for those non-ascii
>> characters, but those are guaranteed to exist regardless of the
>> reencoding
Ævar Arnfjörð Bjarmason writes:
> On Wed, Apr 24 2019, Derrick Stolee via GitGitGadget wrote:
>
>> NOTE: this series was rebased onto ab/commit-graph-fixes, as the conflicts
>> were significant and subtle.
>
> Sorry, hopefully it helped more than it harmed :)
>
> A few unrelated things:
Thanks a
Ævar Arnfjörð Bjarmason writes:
> It doesn't make sense to start saying "version A" here when we make it
> to version 10, however unlikely that is :)
;-)
Jonathan Nieder writes:
> I'm confused. Isn't that bog-standard Git usage, not a custom hack?
Depends on the definition of "hack".
The only native provision at the config API level that lets the
calling programs realize the "desired behaviour" you listed below
without doing anything special is
On Thu, Apr 25, 2019 at 06:34:07PM -0400, Eric Sunshine wrote:
> On Thu, Apr 25, 2019 at 5:10 PM Denton Liu wrote:
> > Before, in t2018, if do_checkout failed to create `branch2`, the next
> > test-case would run `git branch -D branch2` but then fail because it was
> > expecting `branch2` to exist
On Thu, Apr 25, 2019 at 5:10 PM Denton Liu wrote:
> Before, in t2018, if do_checkout failed to create `branch2`, the next
> test-case would run `git branch -D branch2` but then fail because it was
> expecting `branch2` to exist, even though it doesn't. As a result, an
> early failure could cause a
On 2019.04.25 19:15, Junio C Hamano wrote:
> * js/partial-clone-connectivity-check (2019-04-21) 1 commit
> (merged to 'next' on 2019-04-25 at ebd8b4bffd)
> + clone: do faster object check for partial clones
>
> During an initial "git clone --depth=..." partial clone, it is
> pointless to spen
On Wed, Apr 24 2019, Derrick Stolee via GitGitGadget wrote:
> NOTE: this series was rebased onto ab/commit-graph-fixes, as the conflicts
> were significant and subtle.
Sorry, hopefully it helped more than it harmed :)
A few unrelated things:
1)
First, before that series of mine applying this
On Wed, Apr 24 2019, Derrick Stolee via GitGitGadget wrote:
> - hash_version = *(unsigned char*)(data + 5);
> - if (hash_version != oid_version()) {
> - error(_("commit-graph hash version %X does not match version
> %X"),
> - hash_version, oid_version());
>
I noticed earlier that running
$ git checkout -b test master...
would result in the following failure message:
fatal: Not a valid object name: 'master...'.
I believe that this is a bug, so this patchset will allow this to succeed.
Denton Liu (3):
t2018: cleanup in current tes
Before, in t2018, if do_checkout failed to create `branch2`, the next
test-case would run `git branch -D branch2` but then fail because it was
expecting `branch2` to exist, even though it doesn't. As a result, an
early failure could cause a cascading failure of tests.
Make test-case responsible fo
In git-checkout.txt, it states
As a special case, you may use `"A...B"` as a shortcut for the
merge base of `A` and `B` if there is exactly one merge base. You can
leave out at most one of `A` and `B`, in which case it defaults to
`HEAD`.
However, there exists a bug where
When we ran something like
$ git checkout -b test master...
it would fail with the message
fatal: Not a valid object name: 'master...'.
This was caused by the call to `create_branch` where `start_name` is
expected to be a valid rev. However, git-checkout allows the branch to
not be a va
Am 25.04.19 um 02:55 schrieb Junio C Hamano:
> Johannes Sixt writes:
>
>> Furthermore, basing a decision on whether a file is executable won't
>> work on Windows as intended. So, it is better to aim for an existence check.
>
> That is a good point.
>
> So it may be OK for "do we have a single h
On Thu, Apr 25, 2019 at 11:51 AM Elijah Newren wrote:
> Since git supports commit messages with an encoding other than utf-8,
> allow fast-import to import such commits. This may be useful for folks
> who do not want to reencode commit messages from an external system, and
> may also be useful to
On Wed, Apr 24, 2019 at 01:56:33PM +0900, Junio C Hamano wrote:
> Denton Liu writes:
>
> > There has been a push to remove extern from function declarations.
> > Finish the job by removing all instances of "extern" for function
> > declarations in headers using sed.
> >
> > This was done by runni
On 4/25/2019 1:08 PM, Josh Steadmon wrote:
> Fix trace2_data_json_fl() to check for the presence of pfn_data_json_fl
> in its targets, rather than pfn_data_fl, which is not actually called.
[snip]
> for_each_wanted_builtin (j, tgt_j)
> - if (tgt_j->pfn_data_fl)
> + i
On Thu, Apr 25, 2019 at 02:07:58PM +0200, SZEDER Gábor wrote:
> On Mon, Apr 22, 2019 at 05:49:01PM -0400, Jeff King wrote:
> > On Wed, Apr 17, 2019 at 12:58:31AM -0700, Denton Liu wrote:
>
> > > compat/mingw.c| 2 +-
> > > compat/mingw.h| 6 +-
> > > c
On Thu, Apr 25, 2019 at 11:51 AM Elijah Newren wrote:
> This test used an author with non-ascii characters in the name, but
> no special commit message. It then grep'ed for those non-ascii
> characters, but those are guaranteed to exist regardless of the
> reencoding process since the reencoding
On 19/04/2019 06:53, Junio C Hamano wrote:
> Phillip Wood writes:
>
>> From: Phillip Wood
>>
>> commit b3a5d5a80c ("trace2:data: add subverb for rebase", 2019-02-22)
>> mistakenly marked the subverb names for translation and unnecessarily
>> NULL terminated the array.
>>
>> Signed-off-by: Philli
Assalamu Alaikum Wa Rahmatullahi Wa Barakatuh,
hello dear
I came across your contact during my private search. Mrs Aisha Al-
Qaddafi is my name, the only daughter of late Libyan president, am a
single Mother and a Widow with three Children.I have funds the sum of
$27.5 million USD for, investme
Assalamu Alaikum Wa Rahmatullahi Wa Barakatuh,
hello dear
I came across your contact during my private search. Mrs Aisha Al-
Qaddafi is my name, the only daughter of late Libyan president, am a
single Mother and a Widow with three Children.I have funds the sum of
$27.5 million USD for, investme
Assalamu Alaikum Wa Rahmatullahi Wa Barakatuh,
hello dear
I came across your contact during my private search. Mrs Aisha Al-
Qaddafi is my name, the only daughter of late Libyan president, am a
single Mother and a Widow with three Children.I have funds the sum of
$27.5 million USD for, investme
Here is today's test coverage report. You can view it in HTML [1] or in
plain-text [2].
Thanks,
-Stolee
[1] https://derrickstolee.github.io/git-test-coverage/reports/2019-04-25.htm
[2] https://derrickstolee.github.io/git-test-coverage/reports/2019-04-25.txt
---
pu 762cccf710b8bb10da04b42e3
Fix trace2_data_json_fl() to check for the presence of pfn_data_json_fl
in its targets, rather than pfn_data_fl, which is not actually called.
Signed-off-by: Josh Steadmon
---
trace2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/trace2.c b/trace2.c
index 8bbad56887..a73cf
On Thu, 2019-04-25 at 13:16 +0900, Junio C Hamano wrote:
>
> I think it is bad to silently ignore the option. With or without
> this documentation update, I think it is sensible to update the code
> so that it errors out when "--squash --commit" are both given at the
> same time, just like when
On Thu, Apr 25, 2019 at 9:55 AM Elijah Newren wrote:
>
> On Thu, Apr 25, 2019 at 9:51 AM Elijah Newren wrote:
> >
> > While stress testing `git filter-repo`, I noticed an issue with
> > encoding; further digging led to the fixes and features in this series.
> > See the individual commit messages
On Thu, Apr 25, 2019 at 9:51 AM Elijah Newren wrote:
>
> While stress testing `git filter-repo`, I noticed an issue with
> encoding; further digging led to the fixes and features in this series.
> See the individual commit messages for details.
Whoops, forgot to cc Brian; I'm curious if my unders
While stress testing `git filter-repo`, I noticed an issue with
encoding; further digging led to the fixes and features in this series.
See the individual commit messages for details.
Elijah Newren (5):
t9350: fix encoding test to actually test reencoding
fast-import: support 'encoding' commit
Automatic re-encoding of commit messages (and dropping of the encoding
header) hurts attempts to do reversible history rewrites (e.g. sha1sum
<-> sha256sum transitions, some subtree rewrites), and seems
inconsistent with the general principle followed elsewhere in
fast-export of requiring explicit
This test used an author with non-ascii characters in the name, but
no special commit message. It then grep'ed for those non-ascii
characters, but those are guaranteed to exist regardless of the
reencoding process since the reencoding only affects the commit message,
not the author or committer na
Since git supports commit messages with an encoding other than utf-8,
allow fast-import to import such commits. This may be useful for folks
who do not want to reencode commit messages from an external system, and
may also be useful to achieve reversible history rewrites (e.g. sha1sum
<-> sha256su
The find_encoding() function returned the encoding used by a commit
message, returning a default of git_commit_encoding (usually utf-8).
Although the current code does not differentiate between a commit which
explicitly requested utf-8 and one where we just assume utf-8 because no
encoding is set,
When fast-export encounters a commit with an 'encoding' header, it tries
to reencode in utf-8 and then drops the encoding header. However, if it
fails to reencode in utf-8 because e.g. one of the characters in the
commit message was invalid in the old encoding, then we need to retain
the original
On Thu, Apr 25 2019, Barret Rhoden wrote:
> Hi -
>
> On 4/25/19 10:36 AM, Jonathan Nieder wrote:
>> Hi,
>>
>> Ævar Arnfjörð Bjarmason wrote:
>>
>>> Because we don't have some general config facility for this it keeps
>>> coming up, and various existing/proposed options have their own little
>>>
On Thu, Apr 25 2019, Jonathan Nieder wrote:
> Ævar Arnfjörð Bjarmason wrote:
>
>> Because we don't have some general config facility for this it keeps
>> coming up, and various existing/proposed options have their own little
>> custom hacks for doing it, e.g. this for Barret Rhoden's proposed "b
Zdravstvuyte! Vas interesuyut kliyentskiye bazy dannykh?
On 24/04/2019 23:46, brian m. carlson wrote:
On Wed, Apr 24, 2019 at 10:51:56AM +0100, Phillip Wood wrote:
On 24/04/2019 01:49, brian m. carlson wrote:
Add support for multiple post-rewrite hooks, both for "git commit
--amend" and "git rebase".
Additionally add support for multiple prepare-com
On Mac's HFS where git sets core.precomposeUnicode to true automatically
by git init/clone, when a user creates a simple unicode refname (in NFC
format) such as españa:
$ git branch españa
different commands would display the branch name differently. For
example, git branch, git log --decorate
On Thu, Apr 25, 2019 at 7:16 AM Junio C Hamano wrote
> * en/unicode-in-refnames (2019-04-24) 1 commit
> - Honor core.precomposeUnicode in more places
>
> The names of the refs stored as filesystem entities may become
> different from what the end-user expects, just like files in the
> working
Hi -
On 4/25/19 10:36 AM, Jonathan Nieder wrote:
Hi,
Ævar Arnfjörð Bjarmason wrote:
Because we don't have some general config facility for this it keeps
coming up, and various existing/proposed options have their own little
custom hacks for doing it, e.g. this for Barret Rhoden's proposed "bl
Hi,
Ævar Arnfjörð Bjarmason wrote:
> Because we don't have some general config facility for this it keeps
> coming up, and various existing/proposed options have their own little
> custom hacks for doing it, e.g. this for Barret Rhoden's proposed "blame
> skip commits" feature
> https://public-in
Using interactive rebase has one flaw IMHO and that is the way it
handles dating its commit. Can you add an option to interactive rebase
that would make it use the date from the commit that is most recent
and not the date from the commit that is the oldest?
-
*Jeff*
Get back for more infor
On Thu, Apr 25 2019, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
>>> I agree. I am a bit bothered by the fact that
>>> `git log --oneline -Ux -G --pickaxe-raw-diff` outputs the
>>> contents/patch of a commit. My expectation is that we have the
>>> `log -p` knob for that?
>>
>> Thi
On Thu, Apr 25 2019, Eugeniu Rosca wrote:
> On Thu, Apr 25, 2019 at 01:24:56AM +0200, Ævar Arnfjörð Bjarmason wrote:
>>
>> On Thu, Apr 25 2019, Eugeniu Rosca wrote:
>>
>> > Hi Ævar,
>> >
>> > Thanks for the amazingly fast reply and for the useful feature (yay!).
>> >
>> > On Wed, Apr 24, 2019 at
On Mon, Apr 22, 2019 at 05:49:01PM -0400, Jeff King wrote:
> On Wed, Apr 17, 2019 at 12:58:31AM -0700, Denton Liu wrote:
> > compat/mingw.c| 2 +-
> > compat/mingw.h| 6 +-
> > compat/nedmalloc/malloc.c.h | 6 +-
> > compat/obstack.h
On Thu, Apr 25 2019, Duy Nguyen wrote:
> On Thu, Apr 25, 2019 at 5:08 PM Ævar Arnfjörð Bjarmason
> wrote:
>> >> Solving (1) without (2) feels like a bit of a missed opportunity to
>> >> me. Ideally, what I would like is
>> >>
>> >>i. A central registry of trustworthy Git hooks that can be
On 4/25/2019 1:29 AM, Junio C Hamano wrote:
> "Derrick Stolee via GitGitGadget" writes:
>
>> +int version = 0;
>> ...
>> +if (flags & COMMIT_GRAPH_VERSION_1)
>> +version = 1;
>> +if (!version)
>> +version = 1;
>> +if (version != 1) {
>> +error(_
On 4/25/2019 1:38 AM, Junio C Hamano wrote:
> Derrick Stolee writes:
>
>> Updates in V5:
>>
>> * Fixed the error in PATCH 7 due to a missing line that existed in PATCH 8.
>> Thanks, Josh Steadmon!
>>
>> * The 'repack' subcommand now computes the "expected size" of a pack instead
>> of
>> rely
On Thu, Apr 25, 2019 at 5:08 PM Ævar Arnfjörð Bjarmason
wrote:
> >> Solving (1) without (2) feels like a bit of a missed opportunity to
> >> me. Ideally, what I would like is
> >>
> >>i. A central registry of trustworthy Git hooks that can be upgraded
> >> using the system package manag
On 29/03/2019 10:39, Nguyễn Thái Ngọc Duy wrote:
> Unless you know what you're doing, switching to another branch to do
> something then switching back could be confusing. Worse, you may even
> forget that you're in the middle of something. By the time you realize,
> you may have done a ton of work
Hi Elijah
Sorry it's taken me so long to reply to this - I'm not sure where the
last few weeks have gone.
On 29/03/2019 15:35, Elijah Newren wrote:
> Hi Phillip,
>
> On Fri, Mar 29, 2019 at 4:04 AM Phillip Wood
> wrote:
>> On 28/03/2019 17:39, Elijah Newren wrote:
>>> On Thu, Mar 28, 2019 at 9
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.
You can find the changes described
On Thu, Apr 25, 2019 at 5:02 PM Phillip Wood wrote:
>
> On 29/03/2019 10:39, Nguyễn Thái Ngọc Duy wrote:
> > --discard-changes is a better name than --force for this option since
> > it's what really happens.
>
> I didn't realize when I suggested the name that --force overwrites
> untracked files
On Thu, Apr 25 2019, brian m. carlson wrote:
> On Tue, Apr 23, 2019 at 07:34:38PM -0700, Jonathan Nieder wrote:
>> Hi,
>>
>> brian m. carlson wrote:
>>
>> > I've talked with some people about this approach, and they've indicated
>> > they would prefer a configuration-based approach.
>>
>> I woul
Ævar Arnfjörð Bjarmason writes:
> To me this is another point in favor of bypassing this problem entirely
> and adopting the semantics GitLab (and it seems others) use. I.e. in
> order execute:
>
> .git/hooks/pre-receive .git/hooks/pre-receive.d/*
But isn't that exactly what Brian wanted to
On 29/03/2019 10:39, Nguyễn Thái Ngọc Duy wrote:
> --discard-changes is a better name than --force for this option since
> it's what really happens.
I didn't realize when I suggested the name that --force overwrites
untracked files as well as discarding changes from tracked files. I
think we shoul
In 063f2bdbf7 (mergetool: accept -g/--[no-]gui as arguments,
2018-10-24), mergetool was taught the --gui option but no tests were
added to ensure that it was working properly. Add a test to ensure that
it works.
Signed-off-by: Denton Liu
---
t/t7610-mergetool.sh | 22 ++
1 fi
In git-difftool, these options specify which tool to ultimately run. As
a result, they are logically conflicting. Explicitly disallow these
options from being used together.
Signed-off-by: Denton Liu
---
builtin/difftool.c | 3 +++
t/t7800-difftool.sh | 8
2 files changed, 11 insertion
Thanks for another review, Junio.
This should basically be the same as v3 except I've moved the IFS
assignment into a subshell so its value does not leak out.
I'd like the change in 4/6 to be reviewed carefully. t7610 and t7800
run properly with dash on My Machineة, but I couldn't find a referenc
In git-difftool, if the tool is called with --gui but `diff.guitool` is
not set, it falls back to `diff.tool`. Make git-mergetool also fallback
from `merge.guitool` to `merge.tool` if the former is undefined.
If git-difftool, when called with `--gui`, were to use
`get_configured_mergetool` in a fu
In git-mergetool, the logic for getting which merge tool to use is
duplicated in git-mergetool--lib, except for the fact that it needs to
know whether the tool was guessed or not.
Rewrite `get_merge_tool` to return whether or not the tool was guessed
through the return code and make git-mergetool
The output for commands used to be suppressed by redirecting both stdout
and stderr to /dev/null. However, this should not happen since the
output is useful for debugging and, without the "-v" flag, test scripts
don't output anyway.
Unsuppress the output by removing the redirections to /dev/null.
In git-difftool.txt, it says
'git difftool' falls back to 'git mergetool' config variables when the
difftool equivalents have not been defined.
However, when `diff.guitool` is missing, it doesn't fallback to
anything. Make git-difftool fallback to `merge.guitool` when `diff.guitoo
The third column in command-list.txt determines what group a common
command is printed in 'git help'.
"git reset" is currently in the "work on the current change (see also:
git help everyday)" group. While it's true that "git reset" can
manipulate the index and can be in this group, its unique
fun
The new command "git restore" (together with "git switch") are added
to avoid the confusion of one-command-do-all "git checkout" for new
users. They are also helpful to avoid ambiguous context.
For these reasons, promote it everywhere possible. This includes
documentation, suggestions/advice from
These two commands are basically redesigned git-checkout. We will not
have that many opportunities to redo (because we run out of verbs, and
that would also increase maintenance cost).
To play it safe, let's declare the two commands experimental in one or
two releases. If there is a serious flaw i
Signed-off-by: Nguyễn Thái Ngọc Duy
---
t/lib-patch-mode.sh | 12
t/t2070-restore.sh (new +x) | 99 +++
t/t2071-restore-patch.sh (new +x) | 110 ++
3 files changed, 221 insertions(+)
diff --git a/t/lib-patch-mode.sh b
Use a more specific option name to express its purpose. --force may come
back as an alias of --ignore-unmerged and possibly more. But since this
is a destructive operation, I don't see why we need to "force" anything
more. We already don't hold back.
When 'checkout --force' or 'restore --ignore-un
git-checkout rejects plenty of invalid option combinations. Since
git-checkout is equivalent of either
git restore --source --staged --worktree
or
git restore --worktree
that still leaves the new mode 'git restore --index' unprotected. Reject
some more invalid option combinations.
The
"git restore --staged" without --source does not make much sense since
by default we restore from the index. Instead of copying the index to
itself, set the default source to HEAD in this case, yielding behavior
that matches "git reset -- ".
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/check
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/checkout.c | 108 +
1 file changed, 59 insertions(+), 49 deletions(-)
diff --git a/builtin/checkout.c b/builtin/checkout.c
index 9c5abe170e..1753c8c5ed 100644
--- a/builtin/checkout.c
+++ b/builtin/checko
Since the operation in progress is merge, stick to the 'git merge'
variant of aborting. 'git reset --hard' does not really tell you about
aborting the merge by just looking, longer to type, and even though I
know by heart what --hard do, I still dislike it when I need to consider
whether --hard, --
'git checkout ' updates both index and
worktree. But updating the index when you want to restore worktree
files is non-intuitive. The index contains the data ready for the next
commit, and there's no indication that the user will want to commit
the restored versions.
'git restore' therefore by de
git-restore is different from git-checkout that it only restores the
worktree by default, not both worktree and index. add--interactive
needs some update to support this mode.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/checkout.c| 6 +++--
git-add--interactive.perl | 52 +++
Completion for restore is straightforward. We could still do better
though by giving the list of just tracked files instead of all present
ones. But let's leave it for later.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
contrib/completion/git-completion.bash | 15 +++
1 file changed, 15 i
This is another departure from 'git checkout' syntax, which uses -- to
separate ref and pathspec. The observation is restore (or "git
checkout -- ") is most often used to restore some files from
the index. If this is correct, we can simplify it by taking away the
ref, so that we can write
git
Overlay mode is considered confusing when the command is about
restoring files on worktree. Disable it by default. The user can still
turn it on, or use 'git checkout' which still has overlay mode on by
default.
While at it, make the check in checkout_branch() stricter. Neither
--overlay or --no-o
"git restore" without arguments does not make much sense when
it's about restoring files (what files now?). We could default to
either
git restore .
or
git restore :/
Neither is intuitive. Make the user always give pathspec, force the
user to think the scope of restore they want because
v3 changes are really small
- gitcli.txt is updated to mention the --staged/--worktree pair, in
comparison to --cached/--index which is also mention there.
- The patch 'rm --staged' is dropped. It could come back. But if it
does, it should be in a series where commands that take
--cached/--
Previously the switching branch business of 'git checkout' becomes a
new command 'switch'. This adds the restore command for the checking
out paths path.
Similar to git-switch, a new man page is added to describe what the
command will become. The implementation will be updated shortly to
match the
On Thu, Apr 25 2019, Junio C Hamano wrote:
> Johannes Sixt writes:
>
>> Furthermore, basing a decision on whether a file is executable won't
>> work on Windows as intended. So, it is better to aim for an existence check.
>
> That is a good point.
>
> So it may be OK for "do we have a single hoo
Jeff King writes:
> On Tue, Apr 09, 2019 at 05:10:43PM +0200, Ævar Arnfjörð Bjarmason wrote:
>
>> I've found a case where turning bitmaps on does horrible things for
>> bitmap "push" performance.
>> [...]
>> I can't share the repo, but I had a report where just a "git push" of a
>> topic branch t
On AIX, access(X_OK) may succeed when run as root even if the
execution isn't possible. This behavior is allowed by POSIX
which says:
... for a process with appropriate privileges, an implementation
may indicate success for X_OK even if execute permission is not
granted to any user.
It can
95 matches
Mail list logo
