On Sun, Aug 18, 2019 at 08:14:15AM +0530, Dhaval Patel wrote:
> How to reproduce
>
> [snip]
> Suggested feature -
>
> when I press tab, git diff should autocomplete just like git add.
I think this is somewhat harder of a usecase, as git add generally takes
paths and diff can compare revisions *a
How to reproduce
git init
touch abc.txt
touch abd.txt
git add a*
git commit -m 'first commit'
echo 'hello' > abc.txt
git add a[PRESS TAB]
(This will autocomplete 'git add abc.txt')
git diff a[PRESS TAB]
(This will not give 'git diff abc.txt')
Suggested feature -
when I press tab, git diff should
Dear Git users,
It is my pleasure to announce that Git for Windows 2.23.0 is available from:
https://gitforwindows.org/
Changes since Git for Windows v2.22.0 (June 8th 2019)
New Features
* Comes with Git v2.23.0.
* Comes with patch level 3 of the MSYS2 runtime (Git for Windows
Formatting $(taggername) on headerless tags such as v0.99 in Git
causes a SIGABRT with error "munmap_chunk(): invalid pointer",
because of an oversight in commit f0062d3b74 (ref-filter: free
item->value and item->value->s, 2018-10-19).
Signed-off-by: Mischa POSLAWSKY
---
If I understand correctly
If I remove /etc/httpd/conf.d/git.conf then I just get blank page in
the browser.
the ssl_error log shows
[Sat Aug 17 16:17:08.926093 2019] [cgi:error] [pid 18299] [client
x.x.x.x:25050] AH01215: Request not supported: '/export/gitrepos/ABC/'
On 8/17/2019 4:03 PM, Gaiseric Vandal wrote:
I
On Sat, 17 Aug 2019 at 02:42, Emily Shaffer wrote:
>
> Add a new step to the build to generate a whitelist of git-config
> variables which are appropriate to include in the output of
> git-bugreport. New variables can be added to the whitelist by annotating
> their documentation in Documentation/c
I recently applied the latest patches on centos7, including
gitweb-1.8.3.1-20. When I try to access git repos (either via web
browser or git command line.) Repos are configured to require LDAP
authentication.
I should be able to access repo ABC via
https://myserver.domain.com/git/ABC
I get
Other than cache.h which needs to appear first, and merge-recursive.h
which I want to be second so that we are more likely to notice if
merge-recursive.h has any missing includes, the rest of the list is
long and easier to look through if it's alphabetical.
Signed-off-by: Elijah Newren
---
merge
There are lots of options that callers can set, yet most have a limited
range of valid values, some options are meant for output (e.g.
opt->obuf, which is expected to start empty), and callers are expected
to not set opt->priv. Add several sanity checks to ensure callers
provide sane values.
Sign
If opt->buffer_output is less than 2, then merge_trees(),
merge_recursive(), and merge_recursive_generic() are all supposed to
flush the opt->obuf output buffer to stdout and release any memory it
holds. merge_trees() did not do this. Move the logic that handles this
for merge_recursive_internal(
write_tree_from_memory() appeared to be a merge-recursive special that
basically duplicated write_index_as_tree(). The two have a different
signature, but the bigger difference was just that write_index_as_tree()
would always unconditionally read the index off of disk instead of
working on the cur
It is not at all clear what 'mr' was supposed to stand for, at least not
to me. Pick a clearer name for this variable.
Signed-off-by: Elijah Newren
---
merge-recursive.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index 328711
merge_options has several internal fields that should not be set or read
by external callers. This just complicates the API. Move them into an
opaque merge_options_internal struct that is defined only in
merge-recursive.c and keep these out of merge-recursive.h.
Signed-off-by: Elijah Newren
---
We had a rule to enforce that the index matches head, but it was found
at the beginning of merge_trees() and would only trigger when
opt->call_depth was 0. Since merge_recursive() doesn't call
merge_trees() until after returning from recursing, this meant that the
check wasn't triggered by merge_r
I want to implement the same outward facing API as found within
merge-recursive.h in a different merge strategy. However, that makes
names like MERGE_RECURSIVE_{NORMAL,OURS,THEIRS} look a little funny;
rename to MERGE_VARIANT_{NORMAL,OURS,THEIRS}.
Signed-off-by: Elijah Newren
---
merge-recursiv
No substantive code change, just add some line breaks to fix lines that
have grown in length due to various refactorings. Most remaining lines
of excessive length in merge-recursive include error messages and it's
not clear that splitting those improves things.
Signed-off-by: Elijah Newren
---
The merge_options struct had lots of fields, making it a little
imposing, but the options naturally fall into multiple different groups.
Grouping similar options and adding a comment or two makes it easier to
read, easier for new folks to figure out which options are related, and
thus easier for th
We provided users with the ability to state whether they wanted rename
detection, and to put a limit on how much CPU would be spent. Both of
these fields had multiple configuration parameters for setting them,
with one being a fallback and the other being an override. However,
instead of implemen
In commit 259ccb6cc324 ("merge-recursive: rename merge_options argument
from 'o' to 'opt'", 2019-04-05), I renamed a bunch of function
arguments in merge-recursive.c, but forgot to make that same change to
merge-recursive.h. Make the two match.
Signed-off-by: Elijah Newren
---
merge-recursive.h
merge_trees(), merge_recursive(), and merge_recursive_generic() in
their function headers used four different names for the merge base or
list of merge bases they were passed:
* 'common'
* 'ancestors'
* 'ca'
* 'base_list'
They were able to refer to it four different ways instead of only thr
No substantive code changes (view this with diff --color-moved), but
a few small code cleanups:
* Move structs and an inline function only used by merge-recursive.c
into merge-recursive.c
* Re-order function declarations to be more logical
* Add or fix some explanatory comments
Signed-of
In commit 8daec1df03de ("merge-recursive: switch from (oid,mode) pairs
to a diff_filespec", 2019-04-05), an assertion on a->path && b->path
was added for code readability to document that these both needed to be
non-NULL at this point in the code. However, the subsequent lines also
read o->path, s
From: Derrick Stolee
Improve code readability by introducing an enum to replace the
not-quite-boolean values taken on by detect_directory_renames.
Signed-off-by: Derrick Stolee
Signed-off-by: Elijah Newren
---
builtin/am.c | 2 +-
merge-recursive.c | 24 +++-
merge-r
merge_trees() took a results parameter that would only be written when
opt->call_depth was positive, which is never the case now that
merge_trees_internal() has been split from merge_trees(). Remove the
misleading and unused parameter from merge_trees().
While at it, add some comments explaining
This is the bug that just won't die; there always seems to be another
form of it somewhere. See the commit message of 55f39cf7551b ("merge:
fix misleading pre-merge check documentation", 2018-06-30) for a more
detailed explanation), but in short:
builtin/merge.c contains this important requirem
Commit d7cf3a96e9a0 ("merge-recursive.c: remove implicit dependency on
the_repository", 2019-01-12) and follow-ups like commit 34e7771bc644
("Use the right 'struct repository' instead of the_repository",
2019-06-27), removed most implicit uses of the_repository. Convert
calls to get_commit_tree()
Alternatively, you can view this as "make the merge functions behave
more similarly." merge-recursive has three different entry points:
merge_trees(), merge_recursive(), and merge_recursive_generic(). Two of
these would call diff_warn_rename_limit(), but merge_trees() didn't.
This lead to callers
When running 'git checkout -m' and using diff3 style conflict markers,
we want all the conflict hunks (left-side, "common" or "merge base", and
right-side) to have label markers letting the user know where each came
from. The "common" hunk label (o.ancestor) came from
old_branch_info->name, but th
There is a 'free_buf' label to which all but one of the error paths in
update_file_flags() jump; that error case involves a NULL buf and is
thus not a memory leak. However, make that error case execute the same
deallocation code anyway so that if anyone adds any additional memory
allocations or de
We always want our conflict hunks to be labelled so that users can know
where each came from. The previous commit fixed the one caller in the
codebase which was not setting opt->ancestor (and thus not providing a
label for the "merge base" conflict hunk in diff3-style conflict
markers); add an ass
Before writing a replacement merge strategy for recursive, I decided to
first cleanup the merge API -- streamlining merge-recursive.h and making
it more readable. This includes some minor fixes found along the way.
Changes since v3 (full range-diff below):
* Addressed feedback from Junio and SZ
In commit 7ca56aa07619 ("merge-recursive: add a label for ancestor",
2010-03-20), a label was added for the '||' line to make it have
the more informative heading '|| merged common ancestors', with
the statement:
It would be nicer to use a more informative label. Perhaps someone
w
On Sat, Aug 17, 2019 at 12:24 PM René Scharfe wrote:
> A pax extended header records starts with a decimal number. Its value
s/records/record/
> is the length of the whole record, including its own length.
>
> The calculation of that number if strbuf_append_ext_header() is off by
s/if/in/
> o
On 2019-08-17 at 16:19:29, René Scharfe wrote:
> The code for building pax extended headers has been miscalculating
> lengths slightly shorter than powers of 10 since I wrote it in 2006.
> That affects entries for paths with a length of 990, 991, 9989, 9990,
> 9991, 99988 etc. and link targets 4 c
Now that we're confident our pax extended header calculation is correct,
turn the criticality of the assertion up to the maximum, from warning
right up to BUG. Simplify the test, as the stderr comparison step would
not be reached in case the BUG message is triggered.
Signed-off-by: René Scharfe
One of its callers already passes in a size_t value. Use it
consistently in this function.
Signed-off-by: René Scharfe
---
archive-tar.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/archive-tar.c b/archive-tar.c
index 4395a29ffb..9d09edd547 100644
--- a/archive
A pax extended header records starts with a decimal number. Its value
is the length of the whole record, including its own length.
The calculation of that number if strbuf_append_ext_header() is off by
one in case the length of the rest is close to a higher order of
magnitude. This affects paths
Extended header entries contain a length value that is a bit tricky to
calculate because it includes its own length (number of decimal digits)
as well. We get it wrong in corner cases. Add a check, report wrong
results as a warning and add a test for exercising it.
Signed-off-by: René Scharfe
-
The code for building pax extended headers has been miscalculating
lengths slightly shorter than powers of 10 since I wrote it in 2006.
That affects entries for paths with a length of 990, 991, 9989, 9990,
9991, 99988 etc. and link targets 4 characters shorter. Here's a
series for fixing it.
a
Hi Stephen,
Le 17/08/2019 à 00:56, Stephen Boyd a écrit :
> The Linux kernel receives many patches to the devicetree files each
> release. The hunk header for those patches typically show nothing,
> making it difficult to figure out what node is being modified without
> applying the patch or openi
On 16/08/19 02:36AM, brian m. carlson wrote:
> On 2019-08-15 at 19:50:27, Pratyush Yadav wrote:
> > I tried looking at contrib/completion, and I can see that zsh completion
> > works on top of bash completion, so I don't know why exactly it works
> > for bash but not for zsh.
> >
> > I am not too
Good day!
would like to inform you that your product Git 2.22.0 is now listed on our web
site https://macdownload.informer.com/git3/.
We would be grateful if you place our logo with a link to our review on your
website. On our part, we can offer featuring your application in our Today's
Highl
On 14/08/2019 20:33, Junio C Hamano wrote:
Phillip Wood writes:
That's an important distinction, particularly if GIT_COMMITTER_DATE is
set in the environment - are we aiming to have the author and
committer dates match or are we just resetting the author date to now?
Rohit - do you know which
43 matches
Mail list logo
