Hello!
I am a representative of the ChaosCC hacker group.
In the period from 23/06/2019 to 11/08/2019 we got access to your account
git@vger.kernel.org by hacking one of the domain.com mail servers.
Your pass for above account on moment of hack was: e1ysha
You already changed the password?
Sump
On Thu, Aug 15, 2019 at 04:56:05AM +, Yagnatinsky, Mark wrote:
> Okay, first attempt at better phrasing. This may need more paragraph breaks,
> or something.
> Right now it's very wall-of-texty. And probably in a style way too different
> from the rest of the git docs.
> Also, the syntax is
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 familiar with how these auto completion scripts work, so
Here is today's test coverage report.
Thanks,
-Stolee
[1] https://derrickstolee.github.io/git-test-coverage/reports/2019-08-15.htm
[2] https://derrickstolee.github.io/git-test-coverage/reports/2019-08-15.txt
---
pu 6cf2e4a04610efe882eb663cd36436b80b343fa0
jch a23f79a350684bab247289060a
On Thu, Aug 15, 2019 at 04:40:50PM -0700, Junio C Hamano wrote:
> Emily Shaffer writes:
>
> > I think a whitelist of config options to print would grow stale
> > immediately, and the options we're missing would be very likely to be
> > configs to turn on new experimental features - which is proba
On Thu, Aug 15, 2019 at 1:57 PM Junio C Hamano wrote:
>
> Carlo Arenas writes:
>
> > On Wed, Aug 14, 2019 at 4:58 PM Matheus Tavares Bernardino
> > wrote:
> >>
> >> On Wed, Aug 14, 2019 at 6:27 PM Junio C Hamano wrote:
> >> >
> >> [...]
> >> > * mt/grep-submodules-working-tree (2019-07-30) 1 co
On 2019-08-15 at 22:10:29, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > "brian m. carlson" writes:
> >
> >> When applying multiple patches with git am, or when rebasing using the
> >> am backend, it's possible that one of our patches has updated a
> >> gitattributes file. Currently, we c
Emily Shaffer writes:
> I think a whitelist of config options to print would grow stale
> immediately, and the options we're missing would be very likely to be
> configs to turn on new experimental features - which is probably what we
> most want the bugreport for.
The implementation of your "gi
On Thu, Aug 15, 2019 at 03:29:24PM -0700, Junio C Hamano wrote:
> Emily Shaffer writes:
>
> >> > +NOTE
> >> > +
> >> > +Bug reports can be sent to git@vger.kernel.org.
> >>
> >> I am not sure if this belongs here.
> >
> > Sure, I wasn't certain either. Would you rather I remove the "what to
On Thu, Aug 15, 2019 at 07:36:57AM -0700, Junio C Hamano wrote:
> Derrick Stolee writes:
>
> > Config options to consider stripping out:
> >
> > *url*
> > *pass* (anything "password" but also "sendmail.smtppass")
>
> Blacklisting? I wonder if users feel safer if these are limited to
> k
Emily Shaffer writes:
>> > +NOTE
>> > +
>> > +Bug reports can be sent to git@vger.kernel.org.
>>
>> I am not sure if this belongs here.
>
> Sure, I wasn't certain either. Would you rather I remove the "what to do
> with this bugreport" NOTE section entirely?
Not really. You are invoking an
On Thu, Aug 15, 2019 at 10:07:57PM +0200, Johannes Schindelin wrote:
> Hi,
>
> On Thu, 15 Aug 2019, Derrick Stolee wrote:
>
> > On 8/14/2019 10:34 PM, Emily Shaffer wrote:
> > > diff --git a/git-bugreport.sh b/git-bugreport.sh
> > > new file mode 100755
> > > index 00..2200703a51
> > > --
Carlo Marcelo Arenas Belón writes:
> #if LIBCURL_VERSION_NUM < 0x070800
> #define curl_global_init(a) do { /* nothing */ } while (0)
> +#elif LIBCURL_VERSION_NUM >= 0x070c00
> +#define curl_global_init(a) curl_global_init_mem(a, xmalloc, free, \
> +
Junio C Hamano writes:
> "brian m. carlson" writes:
>
>> When applying multiple patches with git am, or when rebasing using the
>> am backend, it's possible that one of our patches has updated a
>> gitattributes file. Currently, we cache this information, so if a
>> file in a subsequent patch ha
On Thu, Aug 15, 2019 at 3:03 PM Elijah Newren wrote:
>
> It appears git.git had a case of a patch being resubmitted and both the
> original (nd/checkout-m-doc-update) and new (nd/checkout-m) versions
> getting applied, with the merge picking to include both versions of some
> of the text rather th
It appears git.git had a case of a patch being resubmitted and both the
original (nd/checkout-m-doc-update) and new (nd/checkout-m) versions
getting applied, with the merge picking to include both versions of some
of the text rather than just one of the two. I have a patch below to
delete the dupl
On Thu, Aug 15, 2019 at 11:10:12AM -0700, Junio C Hamano wrote:
> Emily Shaffer writes:
>
> > diff --git a/Documentation/git-bugreport.txt
> > b/Documentation/git-bugreport.txt
> > new file mode 100644
> > index 00..c5f45bbee8
> > --- /dev/null
> > +++ b/Documentation/git-bugreport.txt
>
f0ed8226c9 (Add custom memory allocator to MinGW and MacOS builds,
2009-05-31) never told cURL about it.
Correct that by using the cURL initializer available since version 7.12 to
point to xmalloc and friends for consistency which then will pass the
allocation requests along when USE_NED_ALLOCATOR
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
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 d0153b
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 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
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
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
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
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
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
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(
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
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
---
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
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
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
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
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()
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
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
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
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
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
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.
Thanks to Dscho and Junio for feedback on v1 & v2.
Changes since v2:
* Addressed feedback from Junio and Dscho
* splitting a cou
QGit's README (
https://github.com/tibirna/qgit/blob/master/README.adoc ) directs me
to this mailing list, so forgive me if this is the wrong place.
Is there a fully built version of QGit 2.8 for Windows?
The latest QGit for Windows I can find is 2.3, from 2008 (
https://sourceforge.net/projects/
On Thu, Aug 15, 2019 at 10:15:24AM -0400, Derrick Stolee wrote:
> > - Do we want to advertise the Git mailing list for bug reports?
>
> That is possible. Isn't there another mailing list for git users?
I know there's an IRC channel for Git users, I dunno about mailing list.
I'm worried that pla
Hi,
On Thu, 15 Aug 2019, Derrick Stolee wrote:
> On 8/14/2019 10:34 PM, Emily Shaffer wrote:
> > diff --git a/git-bugreport.sh b/git-bugreport.sh
> > new file mode 100755
> > index 00..2200703a51
> > --- /dev/null
> > +++ b/git-bugreport.sh
>
> At first I was alarmed by "What? another she
Hi everyone,
I just noticed that checkout.* is not being completed in zsh. I wanted
to set checkout.defaultRemote, but zsh would not auto-complete it.
When I do:
$ git config check
zsh does not auto-fill "checkout."
Doing the same in bash works, so the functionality is there, it just
doesn't
Carlo Marcelo Arenas Belón writes:
> +#elseif LIBCURL_VERSION_NUM >= 0x070c00
#elif
> +#define curl_global_init(a) curl_global_init_mem(a, xmalloc, free, \
> + xrealloc, xstrdup, xcalloc)
> #endif
>
> #if (LIBCURL_VERSION_NUM < 0x070c04) || (LIBC
f0ed8226c9 (Add custom memory allocator to MinGW and MacOS builds, 2009-05-31)
never told cURL about it.
Correct that by using the cURL initializer available since version 7.12 to
point to xmalloc and friends for consistency which then will pass the
allocation requests along when USE_NED_ALLOCATOR
Varun Naik writes:
> diff --git a/diff-lib.c b/diff-lib.c
> index 61812f48c2..29dba467d5 100644
> --- a/diff-lib.c
> +++ b/diff-lib.c
> @@ -433,8 +433,11 @@ static void do_oneway_diff(struct unpack_trees_options
> *o,
>
> /*
>* Something removed from the tree?
> + * Consider
Emily Shaffer writes:
> diff --git a/Documentation/git-bugreport.txt b/Documentation/git-bugreport.txt
> new file mode 100644
> index 00..c5f45bbee8
> --- /dev/null
> +++ b/Documentation/git-bugreport.txt
> @@ -0,0 +1,48 @@
> +git-bugreport(1)
> +
> +
> +NAME
> +
> +gi
Carlo Marcelo Arenas Belón writes:
> f0ed8226c9 (Add custom memory allocator to MinGW and MacOS builds, 2009-05-31)
> never told cURL about it.
>
> Correct that by using the cURL initializer available since version 7.12 to
> point to xmalloc and friends for consistency which then will pass the
>
Jeff King writes:
> On Thu, Aug 15, 2019 at 11:12:45AM +0200, SZEDER Gábor wrote:
>
>> The indent heuristic started out as experimental, but it's now our
>> default diff heuristic since 33de716387 (diff: enable indent heuristic
>> by default, 2017-05-08). Alas, that commit didn't update the
>> d
Carlo Arenas writes:
> On Wed, Aug 14, 2019 at 4:58 PM Matheus Tavares Bernardino
> wrote:
>>
>> On Wed, Aug 14, 2019 at 6:27 PM Junio C Hamano wrote:
>> >
>> [...]
>> > * mt/grep-submodules-working-tree (2019-07-30) 1 commit
>> > (merged to 'next' on 2019-08-02 at e1a46a195f)
>> > + grep: f
Junio C Hamano writes:
> Phillip Wood writes:
>
>> On 14/08/2019 22:20, SZEDER Gábor wrote:
>>
>> I changed the sequencer to always commit the cherry-pick and then run
>> 'git commit --amend' for rewords [1]. Running
>>
>> time env GIT_EDITOR=true GIT_SEQUENCE_EDITOR='sed -i
>> s/pick/rewor
Am 15.08.19 um 18:21 schrieb Varun Naik:
> diff --git a/unpack-trees.c b/unpack-trees.c
> index 50189909b8..5e6d88f36b 100644
> --- a/unpack-trees.c
> +++ b/unpack-trees.c
> @@ -1658,9 +1658,10 @@ static int same(const struct cache_entry *a, const
> struct cache_entry *b)
> return 0;
Phillip Wood writes:
> On 14/08/2019 22:20, SZEDER Gábor wrote:
>
> I changed the sequencer to always commit the cherry-pick and then run
> 'git commit --amend' for rewords [1]. Running
>
> time env GIT_EDITOR=true GIT_SEQUENCE_EDITOR='sed -i
> s/pick/reword/' ../bin-wrappers/git rebase -i
Varun Naik writes:
> On Tue, Aug 13, 2019 at 1:33 PM Junio C Hamano wrote:
>>
>> The original code considered that two entries with the same mode and
>> the same "contents" are the same. As nobody sane tracks an empty
>> file for an extended span of history, that meant that most of the
>> time,
On Thu, Aug 1, 2019 at 9:16 AM Varun Naik wrote:
>
> It is possible to delete a committed file from the index and then add it
> as intent-to-add. Certain forms of `git diff` should show the file.
> After `git reset HEAD`, the file should be identical in the index and
> HEAD. The commands already w
It is possible to delete a committed file from the index and then add it
as intent-to-add. Several variations of "reset" and "checkout" should
resurrect the file in the index from HEAD. "merge" (non-fast-forward),
"cherry-pick", and "revert" should all fail with an error message. This
patch provide
On Tue, Aug 13, 2019 at 1:33 PM Junio C Hamano wrote:
>
> The original code considered that two entries with the same mode and
> the same "contents" are the same. As nobody sane tracks an empty
> file for an extended span of history, that meant that most of the
> time, intent-to-add entries, whic
f0ed8226c9 (Add custom memory allocator to MinGW and MacOS builds, 2009-05-31)
never told cURL about it.
Correct that by using the cURL initializer available since version 7.12 to
point to xmalloc and friends for consistency which then will pass the
allocation requests along when USE_NED_ALLOCATOR
Derrick Stolee writes:
> Config options to consider stripping out:
>
> *url*
> *pass* (anything "password" but also "sendmail.smtppass")
Blacklisting? I wonder if users feel safer if these are limited to
known-benign ones.
>> +echo "[Configured Hooks]"
>> +find "$GIT_DIR/ho
On 8/14/2019 10:34 PM, Emily Shaffer wrote:
> Make it easier for users who encounter a bug to send a report by
> collecting some state information, intended to be viewed by humans
> familiar with Git.
This is an excellent idea! VFS for Git has a similar "diagnose" command
that collects logs, confi
On Thu, Aug 15, 2019 at 11:12:45AM +0200, SZEDER Gábor wrote:
> The indent heuristic started out as experimental, but it's now our
> default diff heuristic since 33de716387 (diff: enable indent heuristic
> by default, 2017-05-08). Alas, that commit didn't update the
> documentation, and the descr
On 14/08/2019 22:20, SZEDER Gábor wrote:
On Mon, Aug 12, 2019 at 09:28:52PM +0100, Phillip Wood wrote:
Save the updated commit message, and after the editor opens up the
third commit's log message, check again where HEAD is pointing to now:
~/tmp/reword (master +|REBASE-i 2/3)$ head -n1 .git
The indent heuristic started out as experimental, but it's now our
default diff heuristic since 33de716387 (diff: enable indent heuristic
by default, 2017-05-08). Alas, that commit didn't update the
documentation, and the description of the 'diff.indentHeuristic'
configuration variable still impli
Hi
I am an occasionally git user and am very used to local revision numbers
mercurial provides in its log command. I don't want to start the
discussion whether local revision numbers are useful or not, nor
whether mercurial is better or not.
I only want to know whether there is any possibilit
68 matches
Mail list logo
