On 10/18/19 4:52 AM, Willy Tarreau wrote:
> On Thu, Oct 17, 2019 at 09:54:47PM -0400, Konstantin Ryabitsev wrote:
>> On Thu, Oct 17, 2019 at 06:30:29PM -0700, Greg KH wrote:
It could only possibly work if nobody ever adds their own
"Signed-Off-By" or
any other bylines. I expect this
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.
A preview release 2.24-rc0 has bee
An early preview release Git v2.24.0-rc0 is now available for
testing at the usual places. It is comprised of 493 non-merge
commits since v2.23.0, contributed by 63 people, 15 of which are
new faces.
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/testing/
The followi
Vegard Nossum wrote:
> Disadvantages:
>
> - requires patching git
The bigger disadvantage is this won't work with a historical
patch series (and some folks stay on ancient git). But maybe
that window for that is only a few years...
The toughest part right now for public-inbox is trying to ma
On Thu, Oct 17, 2019 at 10:20:38PM +, brian m. carlson wrote:
> > > Documentation/git-commit-tree.txt | 6 ++
> > > 1 file changed, 6 insertions(+)
> >
> > ...I was surprised to see it here, where I think most users wouldn't
> > find it. Would it make sense in git-commit(1), or in the de
When parsing a tag, we may end up with a NULL "tagged" field when
there's a type mismatch (e.g., the tag claims to point to object X as a
commit, but we previously saw X as a blob in the same process), but we
do not otherwise indicate a parse failure to the caller.
This is similar to the case disc
If parsing a commit yields a valid tree oid, but we've seen that same
oid as a non-tree in the same process, the resulting commit struct will
end up with a NULL tree pointer, but not otherwise report a parsing
failure.
That's perhaps convenient for callers which want to operate on even
partially c
While parsing the parents of a commit, if we are able to parse an actual
oid but lookup_commit() fails on it (because we previously saw it in
this process as a different object type), we silently omit the parent
and do not report any error to the caller.
The caller has no way of knowing this happe
The thread starting at:
https://public-inbox.org/git/xmqqo8zxnz0m@gitster-ct.c.googlers.com/
discusses some issues with our handling of corrupt objects, as well as
some weirdness in fsck. This series is my attempt to clean it up. The
number of patches is a little daunting, but the early one
We don't actually look at the tree struct in fsck_tree() beyond its oid
and type (which is obviously OBJ_TREE). Just taking an oid gives our
callers more flexibility to avoid creating a struct, and makes it clear
that we are fscking just what is in the buffer, not any pre-parsed bits
from the struc
We don't actually look at the tag struct in fsck_tag() beyond its oid
and type (which is obviously OBJ_TAG). Just taking an oid gives our
callers more flexibility to avoid creating or parsing a struct, and
makes it clear that we are fscking just what is in the buffer, not any
pre-parsed bits from t
We don't actually look at the commit struct in fsck_commit() beyond its
oid and type (which is obviously OBJ_COMMIT). Just taking an oid gives
our callers more flexibility to avoid creating or parsing a struct, and
makes it clear that we are fscking just what is in the buffer, not any
pre-parsed bi
In fsck_commit() and fsck_tag(), we have local "oid" variables used for
parsing parent and tagged-object oids. Let's give these more specific
names in preparation for the functions taking an "oid" parameter for the
object we're checking.
Signed-off-by: Jeff King
---
fsck.c | 8
1 file c
We only need the oid and type to pass on to report(). Let's accept the
broken-out parameters to give our callers more flexibility.
Signed-off-by: Jeff King
---
fsck.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/fsck.c b/fsck.c
index e1d06fb210..50c93200ed 100
We don't actually need any information from the object struct except its
oid (and the type, of course, but that's implicitly OBJ_BLOB). This
gives our callers more flexibility to drop the object structs, too.
Signed-off-by: Jeff King
---
fsck.c | 26 +-
1 file changed, 13
The report() function really only cares about the oid and type of the
object, not the full object struct. Let's convert it to take those two
items separately, which gives our callers more flexibility.
This makes some already-long lines even longer. I've mostly left them,
as our eventual goal is to
Since fsck_blob() no longer requires us to have a "struct blob", we
don't need to create one. Which also means we don't need to worry about
handling the case that lookup_blob() returns NULL (we'll still catch
wrongly-identified blobs when we read the actual object contents and
type from disk).
Sig
The only thing we do with the struct is pass its oid and type to
report(). We can just take those explicitly, which gives our callers
more flexibility.
Signed-off-by: Jeff King
---
fsck.c | 30 --
1 file changed, 16 insertions(+), 14 deletions(-)
diff --git a/fsck.c
The skiplist is inherently an oidset, so we don't need a full object
struct. Let's take just the oid to give our callers more flexibility.
Signed-off-by: Jeff King
---
fsck.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/fsck.c b/fsck.c
index c036ba09ab..2309c40a11
None of the callbacks actually care about having a "struct object";
they're happy with just the oid and type information. So let's give
ourselves more flexibility to avoid having a "struct object" by just
passing the broken-down fields.
Note that the callback already takes a "type" field for the f
Our printable_type() and describe_object() functions take whole object
structs, but they really only care about the oid and type. Let's take
those individually in order to give our callers more flexibility.
Signed-off-by: Jeff King
---
builtin/fsck.c | 69 +++-
Way back in 92d4c85d24 (fsck-cache: fix SIGSEGV on bad tag object,
2005-05-03), we added an fsck check that the "tagged" field of a tag
struct isn't NULL. But that was mainly protecting the printing code for
"--tags", and that code wasn't moved along with the check as part of
ba002f3b28 (builtin-fs
On Thu, Oct 17, 2019 at 09:54:47PM -0400, Konstantin Ryabitsev wrote:
> On Thu, Oct 17, 2019 at 06:30:29PM -0700, Greg KH wrote:
> > > It could only possibly work if nobody ever adds their own
> > > "Signed-Off-By" or
> > > any other bylines. I expect this is a deal-breaker for most maintainers.
>
We don't actually care about having object structs; we only need to look
up decorations by oid. Let's accept this more limited form, which will
give our callers more flexibility.
Note that the decoration API we rely on uses object structs itself (even
though it only looks at their oids). We can so
This isolates the implementation detail of using the decoration code to
our put/get functions.
Signed-off-by: Jeff King
---
Arguably this could be squashed into the previous commit. By not doing
so, it made describe_object() more of a pure code movement.
fsck.c | 5 +
1 file changed, 1 inse
Commit 90cf590f53 (fsck: optionally show more helpful info for broken
links, 2016-07-17) added a system for decorating objects with names. The
code is split across builtin/fsck.c (which gives the initial names) and
fsck.c (which adds to the names as it traverses the object graph). This
leads to som
In 4516338243 (builtin-fsck: reports missing parent commits,
2008-02-25), we added code to check that fsck found the same number of
parents from parsing the commit itself as we see in the commit struct we
got from parse_commit_buffer(). Back then the rationale was that the
normal commit parser migh
We check in fsck_commit_buffer() that commit->tree isn't NULL, which in
turn generally comes from a previous parse by parse_commit(). But this
isn't really accomplishing anything. The two things we might care about
are:
- was there a syntactically valid "tree " line in the object? But
we've
The fsck_object() function takes in a buffer, but also a "struct
object". The rules for using these vary between types:
- for a commit, we'll use the provided buffer; if it's NULL, we'll
fall back to get_commit_buffer(), which loads from either an
in-memory cache or from disk. If the lat
If we can't parse a commit, then parse_commit() will return an error
code. But it _also_ sets the "parsed" flag, which tells us not to bother
trying to re-parse the object. That means that subsequent parses have no
idea that the information in the struct may be bogus. I.e., doing this:
parse_co
On Thu, Oct 17, 2019 at 06:30:29PM -0700, Greg KH wrote:
It could only possibly work if nobody ever adds their own
"Signed-Off-By" or
any other bylines. I expect this is a deal-breaker for most maintainers.
Yeah it is :(
But, if we could just have the signature on the code change, not the
cha
"Carlo Marcelo Arenas Belón via GitGitGadget"
writes:
> builtin/grep.c | 1 +
> grep.c | 34 +-
> grep.h | 1 +
> 3 files changed, 35 insertions(+), 1 deletion(-)
>
> +#if defined(USE_LIBPCRE2)
> + if (!pcre2_global_context)
> +
Philip Oakley writes:
> branch..merge::
> Defines, together with branch..remote, the upstream branch
> - for the given branch. It tells 'git fetch'/'git pull'/'git rebase' which
> + for the given branch. It defines the branch name _on the remote_,
> + which may be different fro
On Thu, Oct 17, 2019 at 04:45:32PM -0400, Konstantin Ryabitsev wrote:
> On Thu, Oct 17, 2019 at 01:43:43PM -0700, Greg KH wrote:
> > > I wonder if it'd be also possible to then embed gpg signatures over
> > > send-mail payloads so as they can be transparently transferred to the
> > > commit.
> >
>
"Johannes Schindelin via GitGitGadget"
writes:
> From: Johannes Schindelin
>
> Ever since worktrees were introduced, the `git_path()` function _really_
> needed to be called e.g. to get at the path to `logs/HEAD` (`HEAD` is
> specific to the worktree). However, the wrong path is returned for
> `
Understood (and agree).
We do use git for source code (where we use SSH
and key authentication for CI/CD), but also for
configuration control of other files like
financial reports, engineering drawings, etc.
where access is via HTTPS. In that 2nd group the
challenge is to make it as "not cod
Hello everyone,
My name is Heba and I’m one of the Outreachy applicants. I’ve selected
the ‘moving the doc to comments’ microproject, and I’ll be submitting
several patches addressing this area during the next week or two. The
first one is already out there waiting for feedback (yey)
https://publi
Derrick Stolee writes:
> I hit this very situation recently when I was experimenting with
> 'git fast-import' and accidentally created many parallel, independent
> histories. Running "git log --graph --all --simplify-by-decoration"
> made it look like all the refs were in a line, but they were no
Doan Tran Cong Danh writes:
> Documentation/git-notes.txt | 6 +++---
> builtin/notes.c | 2 +-
> t/t3301-notes.sh| 40 +++--
> 3 files changed, 42 insertions(+), 6 deletions(-)
Thanks, makes sense.
Doan Tran Cong Danh writes:
> If we accidentally lifted the check inside our code base, the test may
> still failed because the provided parameter is not a valid ref.
Makes sense. Another option would be to use a valid ref to make
sure there are no other possible reason for the command to fail,
On 2019-10-17 at 08:56:34, Manoj Sterex wrote:
> Hi all,
>
> Currently, AFAIK, there is no way to know if a commit was done with or
> without using the '--no-verify' option. That is, git does not track if
> hooks were skipped when the commit happened.
>
> Is there some way to track this in the lo
On Thu, Oct 17, 2019 at 7:35 PM Denton Liu wrote:
> Although `test -f` has the same functionality as test_path_is_file(), in
> the case where test_path_is_file() fails, we get much better debugging
> information.
>
> Replace `test -f` with test_path_is_file() so that future developers
> will have
This commit is copying and summarizing the documentation from
documentation/technical/api-config.txt to comments in config.h
Signed-off-by: Heba Waly heba.w...@gmail.com [heba.w...@gmail.com]
Thanks for taking the time to contribute to Git! Please be advised that the
Git community does not use gi
From: Heba Waly
This commit is copying and summarizing the documentation from
documentation/technical/api-config.txt to comments in config.h
Signed-off-by: Heba Waly
---
config.h | 327 +++
1 file changed, 327 insertions(+)
diff --git a/conf
On 10/15/19 6:55 AM, Derrick Stolee via GitGitGadget wrote:
V4 UPDATE: Rebased on latest master to include ew/hashmap and
ds/include-exclude in the base.
I did a partial review of the v4 patches out of curiosity and I notice
in sparse-checkout.c there are a couple of unchecked `fopen` call site
On Thu, Oct 17, 2019 at 7:17 PM Denton Liu wrote:
> In case an invocation of a Git command fails within the subshell, the
> failure will be masked. Replace the subshell with a file-redirection and
> a call to test_cmp.
>
> Signed-off-by: Denton Liu
> ---
> diff --git a/t/t5520-pull.sh b/t/t5520-p
On Thu, Oct 17, 2019 at 7:17 PM Denton Liu wrote:
> In case an invocation of `git rev-list` fails within the subshell, the
> failure will be masked. Remove the subshell and use test_cmp_rev() so
> that failures can be discovered.
>
> Signed-off-by: Denton Liu
> ---
> diff --git a/t/t5520-pull.sh
Although `test -f` has the same functionality as test_path_is_file(), in
the case where test_path_is_file() fails, we get much better debugging
information.
Replace `test -f` with test_path_is_file() so that future developers
will have a better experience debugging these test cases. Also, in the
c
On Thu, Oct 17, 2019 at 7:17 PM Denton Liu wrote:
> Instead of using `test -n` or `test -z`, replace them respectively with
> invocations of test_file_not_empty() and test_must_be_empty().
>
> Signed-off-by: Denton Liu
> ---
> diff --git a/t/t5520-pull.sh b/t/t5520-pull.sh
> @@ -206,15 +206,18 @@
On Thu, Oct 17, 2019 at 7:17 PM Denton Liu wrote:
> Although `test -f` has the same functionality as test_path_is_file(), in
> the case where test_path_is_file() fails, we get much better debugging
> information. Replace `test -f` with test_path_is_file so that future
> developers will have a bett
Like earlier patchsets, I want to implement a feature that involves
modifications to the test suite. Since that feature will probably take a
while to polish up, however, let's clean up the test suite in a separate
patchset first so it's not blocked by the feature work.
Denton Liu (12):
t5520: im
Improve the test style by removing leading and trailing empty lines
within test cases. Also, reformat multi-line subshells to conform to the
existing style.
Signed-off-by: Denton Liu
---
t/t5520-pull.sh | 88 +
1 file changed, 45 insertions(+), 43
The style for tests in Git is to have the redirect operator attached to
the filename with no spaces. Fix test cases where this is not the case.
Signed-off-by: Denton Liu
---
t/t5520-pull.sh | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/t/t5520-pull.sh b/t/t5520-p
We were using a redirection operator to feed input into sed. However,
since sed is capable of opening its own files, make sed open its own
files instead of redirecting input into it.
Signed-off-by: Denton Liu
---
t/t5520-pull.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a
Although `test -f` has the same functionality as test_path_is_file(), in
the case where test_path_is_file() fails, we get much better debugging
information. Replace `test -f` with test_path_is_file so that future
developers will have a better experience debugging these test cases.
Signed-off-by: D
We currently have many instances of `test = $(cat )` and
`test $(cat ) = `. In the case where this fails, it will be
difficult for a developer to debug since the output will be masked.
Replace these instances with invocations of test_cmp().
This change was done with the following GNU sed express
Before, if the invocation of git failed, it would be masked by the pipe
since only the return code of the last element of a pipe is used.
Rewrite the test to put the Git command on its own line so its return
code is not masked.
Signed-off-by: Denton Liu
---
t/t5520-pull.sh | 3 ++-
1 file change
The usual convention is for test case names to be written between
single-quotes. Change all double-quoted test case names to single-quotes
except for two test case names that use variables within.
Signed-off-by: Denton Liu
---
t/t5520-pull.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletion
Currently, if a Git command fails in an unexpected way, such as a
segfault, it will be masked and ignored. Replace the ! with
test_must_fail so that only expected failures pass.
Signed-off-by: Denton Liu
---
t/t5520-pull.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/
In case an invocation of `git rev-list` fails within the subshell, the
failure will be masked. Remove the subshell and use test_cmp_rev() so
that failures can be discovered.
This change was done with the following sed expressions:
s/test "$(git rev-parse.* \([^)]*\))" = "$(git rev-parse
In case an invocation of a Git command fails within the subshell, the
failure will be masked. Replace the subshell with a file-redirection and
a call to test_cmp.
This change was done with the following GNU sed expressions:
s/\(\s*\)test \([^ ]*\) = "$(\(git [^)]*\))"/\1echo \2 >expect
\
Instead of using `test -n` or `test -z`, replace them respectively with
invocations of test_file_not_empty() and test_must_be_empty().
Signed-off-by: Denton Liu
---
t/t5520-pull.sh | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/t/t5520-pull.sh b/t/t5520-pull.sh
Instead of rolling our own functionality to test the number of lines a
command outputs, use test_line_count() which provides better debugging
information in the case of a failure.
Signed-off-by: Denton Liu
---
t/t5520-pull.sh | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/
Hello all,
### Environment:
$ git --version
git version 2.21.0
### Reproduce:
git clone g...@github.com:JuulLabs-OSS/mcuboot.git
cd mcuboot
git submodule init
git submodule update
git checkout ae01f153b11637feaedbc9d9042172fba2e080c0
### Discussion:
In the above sequence, the last step (check
On 2019-10-17 at 14:33:38, Ralph Ewig wrote:
> Quick follow up question: can the git client pass
> a token read from a cookie with a request? That
> would enable users to sign-in via a browser, store
> the cookie, and then use that as the access token
> to authenticate a git request.
Git has an op
On 2019-10-17 at 05:40:52, Jeff King wrote:
> On Thu, Oct 17, 2019 at 12:53:28AM +, brian m. carlson wrote:
>
> > It's a frequent misconception that the user.name variable controls
> > authentication in some way, and as a result, beginning users frequently
> > attempt to change it when they're
From: Johannes Schindelin
Ever since worktrees were introduced, the `git_path()` function _really_
needed to be called e.g. to get at the path to `logs/HEAD` (`HEAD` is
specific to the worktree). However, the wrong path is returned for
`logs/HEAD.lock`.
This does not matter as long as the Git ex
From: Johannes Schindelin
Without this, you cannot use `--run=<...>` to skip that part, and a run
with `--run=0` (which is a common way to determine the test case number
corresponding to a given test case title).
Signed-off-by: Johannes Schindelin
---
t/t1400-update-ref.sh | 18 ++-
I stumbled over this during my recent work in Git GUI
[https://github.com/gitgitgadget/git/pull/361] that was originally really
only intended to use the correct hooks directory.
It turns out that my fears that index.lock was mishandled were unfounded,
hence this patch series has a lot lower priori
Hi Gábor,
On Wed, 16 Oct 2019, SZEDER Gábor wrote:
> On Wed, Oct 16, 2019 at 07:07:17AM +, Johannes Schindelin via
> GitGitGadget wrote:
> > From: Johannes Schindelin
> >
> > Ever since worktrees were introduced, the `git_path()` function _really_
> > needed to be called e.g. to get at the
On Thu, Oct 17, 2019 at 01:43:43PM -0700, Greg KH wrote:
I wonder if it'd be also possible to then embed gpg signatures over
send-mail payloads so as they can be transparently transferred to the
commit.
That's a crazy idea. It would be nice if we could do that, I like it
:)
It could only po
On Wed, Oct 16, 2019 at 10:45:19AM -0400, Santiago Torres Arias wrote:
> Hi Willy, Vegard.
>
> On Wed, Oct 16, 2019 at 01:10:09PM +0200, Willy Tarreau wrote:
> > Hi Vegard,
> >
> > On Wed, Oct 16, 2019 at 12:22:54PM +0200, Vegard Nossum wrote:
> > > (cross-posted to git, LKML, and the kernel work
Currently, when index-pack resolves deltas, it does not split up delta
trees into threads: each delta base root (an object that is not a
REF_DELTA or OFS_DELTA) can go into its own thread, but all deltas on
that root (direct or indirect) are processed in the same thread.
This is a problem when a r
This is refactoring 2 of 2 to simplify struct base_data.
Whenever we make a struct base_data, immediately calculate its delta
children. This eliminates confusion as to when the
{ref,ofs}_{first,last} fields are initialized.
Before this patch, the delta children were calculated at the last
possibl
A subsequent commit will make the quantum of work smaller, necessitating
more locking. This commit allows resolve_delta() to be called outside
the lock.
Signed-off-by: Jonathan Tan
---
builtin/index-pack.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/builtin/index-
find_{ref,ofs}_delta_{,children} take an enum object_type parameter, but
the object type is already present in the name of the function. Remove
that parameter from these functions.
Signed-off-by: Jonathan Tan
---
builtin/index-pack.c | 26 --
1 file changed, 12 insertions
This is refactoring 1 of 2 to simplify struct base_data.
In index-pack, each thread maintains a doubly-linked list of the delta
chain that it is currently processing (the "base" and "child" pointers
in struct base_data). When a thread exceeds the delta base cache limit
and needs to reclaim memory,
Clarify that core.deltaBaseCacheLimit is per-thread, as can be seen from
the fact that cache usage (base_cache_used in struct thread_local in
builtin/index-pack.c) is tracked individually for each thread and
compared against delta_base_cache_limit.
Signed-off-by: Jonathan Tan
---
Documentation/c
Signed-off-by: Jonathan Tan
---
builtin/index-pack.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/builtin/index-pack.c b/builtin/index-pack.c
index 60a5591039..df6b3b8cf6 100644
--- a/builtin/index-pack.c
+++ b/builtin/index-pack.c
@@ -1210,15 +1210,7 @@ static vo
Thanks, Stolee and Peff, for taking a look at it. Here is a v2. It is
mostly unchanged, except for expanded commit messages and code comments.
I've also added a documentation clarification that
core.deltaBaseCacheLimit is per-thread, appearing as the first patch in
this patch series.
>From patch
Is it (or would it be) possible to set the default strategy and strategy
options as provided by merge/rebase ``-s`` and ``-X`` in gitconfig?
I found myself comparing several conflicts using recursive's -Xpatience,
and in some cases the difference is quite staggering, changing from a
jumbled mess t
On 14/10/19 12:18AM, Johannes Schindelin wrote:
> Hi Pratyush,
>
> On Mon, 14 Oct 2019, Pratyush Yadav wrote:
>
> > On 12/10/19 11:24PM, Johannes Schindelin wrote:
> > > Hi Pratyush,
> > >
> > > On Sat, 12 Oct 2019, Pratyush Yadav wrote:
> > >
> > > > On 08/10/19 04:33AM, Johannes Schindelin via
On 17/10/19 07:08AM, Birger Skogeng Pedersen wrote:
> Hi Pratyush,
>
> On Wed, Oct 16, 2019 at 9:28 PM Pratyush Yadav wrote:
> > I mentioned this earlier, and I'll mention this again: I'm not sure
> > whether this feature would be a good thing for the larger population. So
> > this _might_ not en
On Thu, Oct 17, 2019 at 1:35 PM SZEDER Gábor wrote:
> Complete the paths of existing working trees for 'git worktree's
> 'move', 'remove', 'lock', and 'unlock' subcommands.
> [...]
> Arguably 'git worktree unlock ' should only complete locked
> working trees, but 'git worktree list --porcelain' do
Denton Liu writes:
> There are many += lists in the Makefile and, over time, they have gotten
> slightly out of order, alphabetically. Alphabetically sort all += lists
> to bring them back in order.
> ...
Hmm. I like the general thrust, but ...
> LIB_OBJS += combine-diff.o
> -LIB_OBJS += comm
On Thu, Oct 17, 2019 at 1:35 PM SZEDER Gábor wrote:
> When using the __git_find_on_cmdline() helper function so far we've
> only been interested in which one of a set of words appear on the
> command line. To complete options for some of 'git worktree's
> subcommands in the following patches we'l
we are looking at bitfield constants, and elsewhere in the Git source code,
such cases are handled via bit shift operators rather than octal numbers,
which also makes it easier to spot holes in the range (if, say, 1<<5 was
missing, it is easier to spot it between 1<<4 and 1<<6 than it is to spot a
From: Hariom Verma
We are looking at bitfield constants, and elsewhere in the Git source
code, such cases are handled via bit shift operators rather than octal
numbers, which also makes it easier to spot holes in the range
(if, say, 1<<5 was missing, it is easier to spot it between 1<<4
and 1<<6
The __git_find_on_cmdline() helper function started its life as
__git_find_subcommand() [1], but it served a more general purpose than
looking for subcommands, so later it was renamed accordingly [2].
However, that rename didn't touch the body of the function, and left
the $subcommand local variabl
The following two patches will refactor and extend the
__git_find_on_cmdline() helper function, so let's add a few tests
first to make sure that its basic behavior doesn't change.
Signed-off-by: SZEDER Gábor
---
t/t9902-completion.sh | 28
1 file changed, 28 insertio
Complete paths of working trees and refs for 'git worktree's various
subcommands.
The last two patches do the actual improvements, the first four are
preparatory steps.
An early version of the last patch was already sent to the list as a
PoC over four years ago [1], but I didn't like the part com
The completion function for 'git worktree' uses separate but very
similar case arms to complete --options for each subcommand.
Combine these into a single case arm to avoid repetition.
Note that after this change we won't complete 'git worktree remove's
'--force' option, but that is consistent wi
When using the __git_find_on_cmdline() helper function so far we've
only been interested in which one of a set of words appear on the
command line. To complete options for some of 'git worktree's
subcommands in the following patches we'll need not only that, but the
index of that word on the comma
Complete the paths of existing working trees for 'git worktree's
'move', 'remove', 'lock', and 'unlock' subcommands.
Note that 'git worktree list --porcelain' shows absolute paths, so for
simplicity's sake we'll complete full absolute paths as well (as
opposed to turning them into relative paths b
Complete paths after 'git worktree add ' and refs after 'git
worktree add -b ' and 'git worktree add some/dir '.
Uncharacteristically for a Git command, 'git worktree add' takes a
mandatory path parameter before a commit-ish as its optional last
parameter. In addition, it has both standalone --op
On Thu, Oct 17, 2019 at 12:28 PM Peter Jones wrote:
> Currently, if you do:
>
> $ git branch zonk origin/master
> $ git worktree add zonk zonk
> $ rm -rf zonk
> $ git branch -d zonk
>
> You get the following error:
>
> $ git branch -d zonk
> error: Cannot delete branch 'zonk' checked out at
> '/h
On Thu, Oct 17, 2019 at 12:28:25PM -0400, Peter Jones wrote:
> Currently if you do, for example:
>
> $ git worktree add path foo
>
> And "foo" has already been checked out at some other path, but the user
> has removed it without pruning, you'll get an error that the branch is
> already checked o
Currently if you do, for example:
$ git worktree add path foo
And "foo" has already been checked out at some other path, but the user
has removed it without pruning, you'll get an error that the branch is
already checked out. It isn't meaningfully checked out, the repo's
data is just stale and n
Currently, if you do:
$ git branch zonk origin/master
$ git worktree add zonk zonk
$ rm -rf zonk
$ git branch -d zonk
You get the following error:
$ git branch -d zonk
error: Cannot delete branch 'zonk' checked out at
'/home/pjones/devel/kernel.org/git/zonk'
It isn't meaningfully checked out,
Hi,
I've seen recently some development with a special development flow that is the
source of my feature request.
Description of the feature:
For each treated file, in case of an empty ancestor (file created on both
branches or orphan branch), I found that usually the best way to help (or even
1 - 100 of 124 matches
Mail list logo
