On 04/22/2016 08:05 AM, Matthieu Moy wrote:
> Simon P writes:
> > This patch is inspired from
> >
> > https://github.com/graingert/secure-smtplib/blob/master/src/secure_smtplib/__init__.py
>
> Please, add your sign-off and a proper commit message to your patch,
> see:
>
> https://github.com/git
Hi Dominik,
On Thu, 21 Apr 2016, Dominik Fischer wrote:
> Matthieu Moy writes:
> > any transition plan would be far more painful than the possible benefits
> I agree, it cannot be expected that every external script sets
> GIT_RECURSION_DEPTH before issuing any command just because of this littl
Hi Dominik,
On Thu, 21 Apr 2016, Dominik Fischer wrote:
> Indeed this needs more explanations for everyone who did not read the posts
> before.
Such as is the case for me. And most future readers of the commit messages
;-)
> I strove to create an add.patch configuration option that did the same
Simon P writes:
> Hi,
Hi, and thanks for the patch.
Please, add your sign-off and a proper commit message to your patch,
see:
https://github.com/git-multimail/git-multimail/blob/master/CONTRIBUTING.rst
I'm OK with patches by email, but you may prefer using a pull-request
(among other things,
Introduce --base=auto to record the base commit info automatically, the
base_commit will be the merge base of tip commit of the upstream branch
and revision-range specified in cmdline.
Helped-by: Junio C Hamano
Helped-by: Wu Fengguang
Signed-off-by: Xiaolong Ye
---
Documentation/git-format-pat
Maintainers or third party testers may want to know the exact base tree
the patch series applies to. Teach git format-patch a '--base' option
to record the base tree info and append it at the end of the first
message (either the cover letter or the first patch in the series).
The base tree info co
This allows to record the base commit automatically, it is equivalent
to set --base=auto in cmdline.
The format.useAutoBase has lower priority than command line option,
so if user set format.useAutoBase and pass the command line option in
the meantime, base_commit will be the one passed to command
Make commit_patch_id() available to other builtins.
Helped-by: Junio C Hamano
Signed-off-by: Xiaolong Ye
---
patch-ids.c | 2 +-
patch-ids.h | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/patch-ids.c b/patch-ids.c
index b7b3e5a..a4d0016 100644
--- a/patch-ids.c
+++ b/patc
Thanks for Junio's reviews and suggestions.
This version contains the following changes since v4:
- Refine the commit log as well as the documentation according to
Junio's comments.
- Separate out get_base_commit function from prepare_bases to obtain
the base commit.
- Use repeated pai
On Thu, Apr 14, 2016 at 10:59:57AM -0400, Eric Chamberland wrote:
> just cloned a repo and it checked-out wihtout any error (with git 2.2.0) but
> got come corrupted files (because I got some sdd failures).
>
> Then, I get a git core dump when trying to "git status" into the repo which
> have a "
* tb/convert-eol-autocrlf (2016-04-19) 4 commits
- convert.c: ident + core.autocrlf didn't work
- t0027: test cases for combined attributes
- convert: allow core.autocrlf=input and core.eol=crlf
- t0027: avoid false "unchanged" due to lstat() matching after a change
Setting core.autocrlf to
On Thu, Apr 21, 2016 at 03:20:39PM -0700, Junio C Hamano wrote:
> * jk/push-client-deadlock-fix (2016-04-20) 5 commits
> - t5504: drop sigpipe=ok from push tests
> - fetch-pack: isolate sigpipe in demuxer thread
> - send-pack: isolate sigpipe in demuxer thread
> - run-command: teach async thre
Santiago Torres writes:
> On Thu, Apr 21, 2016 at 03:20:39PM -0700, Junio C Hamano wrote:
>> * st/verify-tag (2016-04-19) 6 commits
>> - tag -v: verfy directly rather than exec-ing verify-tag
>> - verify-tag: move tag verification code to tag.c
>> - verify-tag: prepare verify_tag for libificat
Joey Hess writes:
> Junio C Hamano wrote:
>> merge: GIT_MERGE_ALLOW_UNRELATED_HISTORIES environment
>
> I hope this patch lands, it will save me a lot of bother.
Yup, it is somewhat ugly but the least bad option among command line
option (which would break with older versions of Git), configur
Yaroslav Halchenko wrote:
> - for git-annex (Joey was CCed from the beginning, not sure if annex
> would be affected though), it would be merging of git-annex
> branches while joining multiple annexes for the sync (e.g. by git
> annex assistant).
Not entirely accurate (git-annex merges its
On Thu, Apr 21, 2016 at 03:20:39PM -0700, Junio C Hamano wrote:
> * st/verify-tag (2016-04-19) 6 commits
> - tag -v: verfy directly rather than exec-ing verify-tag
> - verify-tag: move tag verification code to tag.c
> - verify-tag: prepare verify_tag for libification
> - verify-tag: update vari
On Fri, Apr 22, 2016 at 3:50 AM, Junio C Hamano wrote:
> [Cooking]
>
> * pb/commit-verbose-config (2016-04-19) 6 commits
> - commit: add a commit.verbose config variable
> - t7507-commit-verbose: improve test coverage by testing number of diffs
> - parse-options.c: make OPTION_COUNTUP respect
On Thu, Apr 21, 2016 at 10:48 AM, Stefan Beller wrote:
> On Thu, Apr 21, 2016 at 10:45 AM, Junio C Hamano wrote:
>> Stefan Beller writes:
>>
>>> In case of non bare:
>>>
>>> Get the repo and all its submodules from the specified remote.
>>> (As the submodule is right there, that's the be
>
> * sb/clone-shallow-passthru (2016-04-13) 3 commits
> - clone: add t5614 to test cloning submodules with shallowness involved
> - clone: add `--shallow-submodules` flag
> - submodule clone: pass along `local` option
>
> "git clone" learned "--shallow-submodules" option.
>
> Needs review.
>
Junio C Hamano writes:
> Yaroslav Halchenko gave a vague "forcing 'git merge' users to always
> give --allow-unrelated-histories option when they create crap/insane
> merges are not nice", which I couldn't guess the validity due to
> lack of concrete use case. Just in case it is substantiated, h
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 'master' branch now has the fi
Stefan Beller writes:
> Combining Junios and Linus idea:
>
> * We want to have the minimal history, i.e. that tag with the fewest
> cummulative parent commits. (i.e. v3.13-rc7 is better than v3.13
> because `git log --oneline v3.13-rc7 |wc -l` (414317) is smaller tha
> `git log --oneline v3.13 |w
Hi,
It seems that smtplib doesn't check if a certificate is valid (signed by
a trusted CA).
For my personal usage, I patched the starttls code in git-multimail:
only for starttls with smtplib.
This patch is inspired from
https://github.com/graingert/secure-smtplib/blob/master/src/secure_smtplib
Stefan Beller writes:
> On Thu, Apr 21, 2016 at 12:24 PM, Junio C Hamano wrote:
>> An earlier commit said:
>
> And by earlier you meant to say e379fdf34f (2016-03-18, merge: refuse
> to create too cool a merge by default)?
The text quoted does come from that commit, but because there is
nothing
On Thu, 21 Apr 2016, Junio C Hamano wrote:
> >> It is not very productive to make such an emotional statement
> >> without substantiating _why_ a merge that adds a new root, which was
> >> declared in the thread above as "crap" (in the context of the kernel
> >> project),
> > Sorry if my statemen
On Thu, Apr 21, 2016 at 12:27 PM, Junio C Hamano wrote:
> Linus Torvalds writes:
>
>> But this patch is small and simple, and has some excuses for its
>> behavior. What do people think?
>
> I like it that you call it "excuse" not "rationale", as I couldn't
> form a logical connection between your
Yaroslav Halchenko writes:
>> It is not very productive to make such an emotional statement
>> without substantiating _why_ a merge that adds a new root, which was
>> declared in the thread above as "crap" (in the context of the kernel
>> project),
>
> Sorry if my statement sounded too emotional
On Thu, Apr 21, 2016 at 12:24 PM, Junio C Hamano wrote:
> An earlier commit said:
And by earlier you meant to say e379fdf34f (2016-03-18, merge: refuse
to create too cool a merge by default)?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@v
It is rumored that some scripts rely on being able to regularly
create two project merges. Instead of forcing them to pass the
option --allow-unrelated-histories when they call "git merge", allow
them to set and export an environment at the beginning and forget
about it.
This will be less damagin
Because "test_commit five" creates a commit and point it with a tag
'five', doing so on a branch whose name is 'five' will later result
in an 'ambiguous refs' warning. Even though it is harmless because
all the later references are for the tag, there is no reason for the
branch to be called 'five'
It was rumored that in an unspecified workflow it is common to
create what Kernel folks call "crazy" and "insane" merges of two
unrelated histories, and having to give --allow-unrelated-histories
option every time is cumbersome.
Just in case the rumor will substanticated with a proper rationale
in
Yaroslav Halchenko gave a vague "forcing 'git merge' users to always
give --allow-unrelated-histories option when they create crap/insane
merges are not nice", which I couldn't guess the validity due to
lack of concrete use case. Just in case it is substantiated, here
is a series to selectively an
An earlier commit said:
We could add the same option to "git pull" and have it passed
through to underlying "git merge". I do not have a fundamental
opposition against such a feature, but this commit does not do
so and instead leaves it as low-hanging fruit for others,
because
Linus Torvalds writes:
> But this patch is small and simple, and has some excuses for its
> behavior. What do people think?
I like it that you call it "excuse" not "rationale", as I couldn't
form a logical connection between your "4 (2) letters" and "1
(100)" at all ;-)
Modulo the usual sty
On Thu, 21 Apr 2016, Junio C Hamano wrote:
> Yaroslav Halchenko writes:
> > I have decided to try 2.8.1.369.geae769a available from debian
> > experimental and through our (datalad) tests failing I became
> > aware of the
> >
> > https://github.com/git/git/pull/158/commits/e379fdf34fee96
Yaroslav Halchenko wrote:
> which is planned for the next release. I guess it is indeed a
> worthwhile accident-prevention measure BUT not sure if it is so
> important as to cause a change in behavior on which some projects using
> git through the cmdline interface might have been relying upon for
On Thu, Apr 21, 2016 at 11:05 AM, Jeff King wrote:
>
> I actually think the best name for aed06b9 is probably:
>
> v3.13-rc1~65^2^2~42
Sounds likely. I don't know how to find that best match without a
complete rewrite, though.
My recent patch that got
v3.13-rc2~32^2^2~47
comes close to tha
On Thu, Apr 21, 2016 at 10:59:52AM -0700, Linus Torvalds wrote:
> That said, I do think that a much bigger conceptual change that
> actually does full traversal and be much more complicated might be the
> only "correct" solution.
>
> So my patch is just a "improve heuristics" small fixlet rather
On Thu, Apr 21, 2016 at 10:23:10AM -0700, Linus Torvalds wrote:
> > which is technically true, but kind of painful to read. It may be that a
> > reasonable weight is somewhere between "1" and "65535", though.
>
> Based on my tests, the "right" number is somewhere in the 500-1000
> range for this
On Thu, Apr 21, 2016 at 10:43 AM, Linus Torvalds
wrote:
>
> In other words, I'm trying to convince people that my patch not only
> gives a good result, but that the "weight numbers" I use make some
> kind of conceptual sense from a complexity cost angle.
Basically, the patch approximates the nume
On Thu, Apr 21, 2016 at 10:45 AM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> In case of non bare:
>>
>> Get the repo and all its submodules from the specified remote.
>> (As the submodule is right there, that's the best guess to get it from,
>> no need to get it from somewhere
Stefan Beller writes:
> In case of non bare:
>
> Get the repo and all its submodules from the specified remote.
> (As the submodule is right there, that's the best guess to get it from,
> no need to get it from somewhere else. The submodule at the remote
> is the closest match you
On Thu, Apr 21, 2016 at 10:23 AM, Linus Torvalds
wrote:
> On Thu, Apr 21, 2016 at 10:08 AM, Jeff King wrote:
>>
>> Right, because it makes the names longer. We give the second-parent
>> traversal a heuristic cost. If we drop that cost to "1", like:
>
> So I dropped it to 500 (removed the two last
On Thu, Apr 21, 2016 at 10:23 AM, Junio C Hamano wrote:
>
> I think avoiding side branches to describe with the weight is a
> right thing to do, i.e. if you have this history:
>
> X---o---o---o---o---v4.6
> \ /
> o---o
>
> you do not want to explain X as "v4.6~^2
Matthieu Moy writes:
> any transition plan would be far more painful than the possible benefits
I agree, it cannot be expected that every external script sets
GIT_RECURSION_DEPTH before issuing any command just because of this
little option.
As an exercise for GSoC, I implemented it nonethele
Linus Torvalds writes:
> On Thu, Apr 21, 2016 at 9:36 AM, Linus Torvalds
> wrote:
>>
>> This seems to be a git bug.
>>
>> That commit aed06b9 can also be described as
>>
>> v3.13-rc7~9^2~14^2~42
>>
>> so describing it as 'v4.6-rc1~9^2~792' is clearly not closer in any way.
>
> Hmm. I think I
On Thu, Apr 21, 2016 at 10:08 AM, Jeff King wrote:
>
> Right, because it makes the names longer. We give the second-parent
> traversal a heuristic cost. If we drop that cost to "1", like:
So I dropped it to 500 (removed the two last digits), and it gave a
reasonable answer. With 1000, it gave the
On Thu, Apr 21, 2016 at 09:59:13AM -0700, Junio C Hamano wrote:
> Linus Torvalds writes:
>
> > That commit aed06b9 can also be described as
> >
> > v3.13-rc7~9^2~14^2~42
> >
> > so describing it as 'v4.6-rc1~9^2~792' is clearly not closer in any way.
>
> I seem to recall that name-rev had a
On Wed, Apr 20, 2016 at 8:14 PM, Yaroslav Halchenko wrote:
> NB Thank you for the lively discussion!
>
> On Wed, 20 Apr 2016, Stefan Beller wrote:
>
>> >> So currently the protocol doesn't allow to even specify the submodules
>> >> directories.
>
>> > Depends on what you exactly mean by "the proto
On Thu, Apr 21, 2016 at 9:36 AM, Linus Torvalds
wrote:
>
> This seems to be a git bug.
>
> That commit aed06b9 can also be described as
>
> v3.13-rc7~9^2~14^2~42
>
> so describing it as 'v4.6-rc1~9^2~792' is clearly not closer in any way.
Hmm. I think I see what's up. The git distance functio
Linus Torvalds writes:
> That commit aed06b9 can also be described as
>
> v3.13-rc7~9^2~14^2~42
>
> so describing it as 'v4.6-rc1~9^2~792' is clearly not closer in any way.
I seem to recall that name-rev had an unexplained heuristics to
strongly avoid following second parent changes (I see t
Matthieu Moy writes:
> A config variable to set an option by default is good when the user
> wants to set it and forget about it. In this case, you clearly can't
> "forget about it", as running "git add" and "git add -p" correspond to
> really different use-cases.
That is the most sensible expla
Dominik Fischer writes:
> I strove to create an add.patch configuration option that did the same
> as always passing the parameter --patch to git-add. Junio C Hamano
> then made me aware that when set, this option would influence and
> possibly destroy other commands that internally use git-add.
Yaroslav Halchenko writes:
> I have decided to try 2.8.1.369.geae769a available from debian
> experimental and through our (datalad) tests failing I became
> aware of the
>
>
> https://github.com/git/git/pull/158/commits/e379fdf34fee96cd205be83ff4e71699bdc32b18
> merge: refuse to create
Olaf Hering writes:
> On Thu, Apr 21, John Keeping wrote:
>
>> $ git tag --contains aed06b9cfcabf8644ac5f6f108c0b3d01522f88b
>
> Thanks for that, I did not know this variant.
>
> Unless git does not do it for me, I may hackup my script like that to
> find the earlierst tag:
"git tag" has a
On Thu, Apr 21, 2016 at 6:24 AM, Andreas Schwab wrote:
>
> The branches recently pulled by Linus contain commits with rather old
> author dates, eg 8cad489261c564d4ee1db4de4ac365af56807d8a or
> 281baf7a702693deaa45c98ef0c5161006b48257. That will probably cause git
> describe --contains to take a
Indeed this needs more explanations for everyone who did not read the
posts before.
I strove to create an add.patch configuration option that did the same
as always passing the parameter --patch to git-add. Junio C Hamano then
made me aware that when set, this option would influence and possib
Dear Git Gurus,
I guess whenever it rains it indeed pours, so it is me whining again.
I have decided to try 2.8.1.369.geae769a available from debian
experimental and through our (datalad) tests failing I became
aware of the
https://github.com/git/git/pull/158/commits/e379fdf34fee96cd205be8
On Thu, Apr 21, John Keeping wrote:
> $ git tag --contains aed06b9cfcabf8644ac5f6f108c0b3d01522f88b
Thanks for that, I did not know this variant.
Unless git does not do it for me, I may hackup my script like that to
find the earlierst tag:
for i in `git tag --contains aed06b9cfcabf8644ac
Jeff King writes:
> To me, the benefit is that you don't have to care about ignore_case. You
> have asked to compare two paths, and any system-appropriate magic should
> be applied. That may be icase, or it may be weird unicode normalization.
>
> I think the key thing missing is that this is only
On Thu, Apr 21, 2016 at 08:37:32AM -0700, Junio C Hamano wrote:
> >> > While we're at it, how about renaming it to pathcmp (and its friend
> >> > strncmp_icase to pathncmp)?
> >>
> >> Yes, that seems like a good idea. For anyone familiar with
> >> strcasecmp() or stricmp(), having "icase" in the
Hi Dominik,
On Thu, 21 Apr 2016, XZS wrote:
> The following patches try to provide an add.patch configuration variable
> while keeping out of the way of other commands. To do so, an environment
> variable counts how often git was recursively invoked. The variable is
> then only considered in the
Jeff King writes:
> On Thu, Apr 21, 2016 at 10:23:09AM -0400, Eric Sunshine wrote:
>
>> > While we're at it, how about renaming it to pathcmp (and its friend
>> > strncmp_icase to pathncmp)?
>>
>> Yes, that seems like a good idea. For anyone familiar with
>> strcasecmp() or stricmp(), having "ic
On Thu, Apr 21, 2016 at 10:23:09AM -0400, Eric Sunshine wrote:
> > While we're at it, how about renaming it to pathcmp (and its friend
> > strncmp_icase to pathncmp)?
>
> Yes, that seems like a good idea. For anyone familiar with
> strcasecmp() or stricmp(), having "icase" in the name makes it se
On Thu, Apr 21, 2016 at 5:33 AM, Duy Nguyen wrote:
> On Thu, Apr 21, 2016 at 3:19 PM, Duy Nguyen wrote:
>> On Thu, Apr 21, 2016 at 2:20 PM, Eric Sunshine
>> wrote:
>>> On Wed, Apr 20, 2016 at 9:24 AM, Nguyễn Thái Ngọc Duy
>>> wrote:
Signed-off-by: Nguyễn Thái Ngọc Duy
+ strbu
On 03/01/2016 01:52 AM, David Turner wrote:
> The refs infrastructure learns about log-only ref updates, which only
> update the reflog. Later, we will use this to separate symbolic
> reference resolution from ref updating.
>
> Signed-off-by: David Turner
> Signed-off-by: Junio C Hamano
> ---
>
Olaf Hering writes:
> How can I find out whats going on? Is my git(1) 2.8.1 broken, or did
> Linus just pull some junk tree (and does he continue to do so)?
The branches recently pulled by Linus contain commits with rather old
author dates, eg 8cad489261c564d4ee1db4de4ac365af56807d8a or
281baf7a
On Thu, Apr 21, 2016 at 01:30:04PM +0200, Olaf Hering wrote:
> To track the changes in hyperv related files I created some scripts
> years ago to automate the process of finding relevant commits in
> linux.git. Part of that process is to record the tag when a commit
> appeared in mainline. This wor
Olaf Hering writes:
> On Thu, Apr 21, Matthieu Moy wrote:
>
>> My guess is that this commit has been sitting for a long time in a
>> repo outside Linus' linux.git, and got merged only recently.
>
> Thats what it looks like. And thats what I'm complaining about. But in
> fact that file is there si
On Thu, Apr 21, Matthieu Moy wrote:
> My guess is that this commit has been sitting for a long time in a
> repo outside Linus' linux.git, and got merged only recently.
Thats what it looks like. And thats what I'm complaining about. But in
fact that file is there since v3.13-rc7 (if the tag is rea
Olaf Hering writes:
> To track the changes in hyperv related files I created some scripts
> years ago to automate the process of finding relevant commits in
> linux.git. Part of that process is to record the tag when a commit
> appeared in mainline. This worked fine, until very recently.
>
> Sudd
To track the changes in hyperv related files I created some scripts
years ago to automate the process of finding relevant commits in
linux.git. Part of that process is to record the tag when a commit
appeared in mainline. This worked fine, until very recently.
Suddenly years-old commits are declar
On Thu, Apr 21, 2016 at 3:19 PM, Duy Nguyen wrote:
> On Thu, Apr 21, 2016 at 2:20 PM, Eric Sunshine
> wrote:
>> On Wed, Apr 20, 2016 at 9:24 AM, Nguyễn Thái Ngọc Duy
>> wrote:
>>> Signed-off-by: Nguyễn Thái Ngọc Duy
>>> ---
>>> diff --git a/worktree.c b/worktree.c
>>> @@ -178,6 +182,18 @@ str
Some commands may want to act differently when called transitively by
other git commands in contrast to when called by the user directly. The
variable recursion_depth provides all built-ins with a way to tell these
cases apart.
Scripts can use the underlying environment variable GIT_RECURSION_DEPT
Users may like to review their changes when staging by default. It is
also a convenient safety feature for beginners nudging them to have a
second look at their changes when composing a commit.
To this end, the config variable allows to have git-add to always act
like -p was passed.
To not affect
The following patches try to provide an add.patch configuration variable
while keeping out of the way of other commands. To do so, an environment
variable counts how often git was recursively invoked. The variable is
then only considered in the first recursion.
To ensure other commands work as exp
On Thu, Apr 21, 2016 at 2:20 PM, Eric Sunshine wrote:
> On Wed, Apr 20, 2016 at 9:24 AM, Nguyễn Thái Ngọc Duy
> wrote:
>> Signed-off-by: Nguyễn Thái Ngọc Duy
>> ---
>> diff --git a/worktree.c b/worktree.c
>> @@ -178,6 +182,18 @@ struct worktree **get_worktrees(void)
>> }
>> ALLO
On 20 April 2016 at 16:51, Junio C Hamano wrote:
> Luke Diamand writes:
>
>> One thing I wondered about is whether this should be enabled by
>> default or not. Long-time users of git-p4 might be a bit surprised to
>> find their git commits suddenly gaining an extra Job: field.
>
> Ahh, I didn't e
On Wed, Apr 20, 2016 at 9:24 AM, Nguyễn Thái Ngọc Duy wrote:
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> diff --git a/worktree.c b/worktree.c
> @@ -178,6 +182,18 @@ struct worktree **get_worktrees(void)
> }
> ALLOC_GROW(list, counter + 1, alloc);
> list[counter] = NULL;
Hi,
On Thu, 21 Apr 2016, Johannes Sixt wrote:
> Am 20.04.2016 um 23:47 schrieb Andreas Schwab:
> > Shaun Jackman writes:
> >
> > > I'd like to insert a commit between two commits without changing
> > > the committer date or author date of that commit or the subsequent
> > > commits.
> >
> > The
On Wed, Apr 20, 2016 at 9:24 AM, Nguyễn Thái Ngọc Duy wrote:
> This gives the caller more information and they can answer things like,
> "is it the main worktree" or "is it the current worktree". The latter
> question is needed for the "checkout a rebase branch" case later.
>
> Signed-off-by: Nguy
81 matches
Mail list logo
