[PATCH v5 3/4] format-patch: introduce --base=auto option

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:

[PATCH v5 2/4] format-patch: add '--base' option to record base tree info

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

[PATCH v5 4/4] format-patch: introduce format.useAutoBase configuration

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

[PATCH v5 1/4] patch-ids: make commit_patch_id() a public helper function

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

[PATCH v5 0/4] Add --base option to git-format-patch to record base tree info

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

Re: git status core dump with bad sector!

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

Re: What's cooking in git.git (Apr 2016, #06; Thu, 21)

* 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

Re: What's cooking in git.git (Apr 2016, #06; Thu, 21)

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

Re: What's cooking in git.git (Apr 2016, #06; Thu, 21)

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

Re: 'next'ed --allow-unrelated-histories could cause lots of grief

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

Re: 'next'ed --allow-unrelated-histories could cause lots of grief

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

Re: What's cooking in git.git (Apr 2016, #06; Thu, 21)

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

Re: What's cooking in git.git (Apr 2016, #06; Thu, 21)

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

Re: problems serving non-bare repos with submodules over http

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

Re: What's cooking in git.git (Apr 2016, #06; Thu, 21)

> > * 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. >

Re: [PATCH 0/4] Loosening "two project merge" safety

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

What's cooking in git.git (Apr 2016, #06; Thu, 21)

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

Re: history damage in linux.git

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

[git-multimail] smtplib, check certificate

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

Re: [PATCH 2/4] pull: pass --allow-unrelated-histories to "git merge"

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

Re: 'next'ed --allow-unrelated-histories could cause lots of grief

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

Re: history damage in linux.git

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

Re: 'next'ed --allow-unrelated-histories could cause lots of grief

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

Re: [PATCH 2/4] pull: pass --allow-unrelated-histories to "git merge"

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

[PATCH 3/4] merge: GIT_MERGE_ALLOW_UNRELATED_HISTORIES environment

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

[PATCH 1/4] t3033: avoid 'ambiguous refs' warning

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

[PATCH 4/4] merge: introduce merge.allowUnrelatedhistories configuration option

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

[PATCH 0/4] Loosening "two project merge" safety

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

[PATCH 2/4] pull: pass --allow-unrelated-histories to "git merge"

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,

Re: history damage in linux.git

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)"

Re: 'next'ed --allow-unrelated-histories could cause lots of grief

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 > > > >

Re: 'next'ed --allow-unrelated-histories could cause lots of grief

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

Re: history damage in linux.git

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

Re: history damage in linux.git

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

Re: history damage in linux.git

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

Re: history damage in linux.git

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,

Re: problems serving non-bare repos with submodules over http

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,

Re: problems serving non-bare repos with submodules over http

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

Re: history damage in linux.git

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: >

Re: history damage in linux.git

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

Re: [PATCH/RFC/GSoC 0/2] add a add.patch config variable

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

Re: history damage in linux.git

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

Re: history damage in linux.git

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

Re: history damage in linux.git

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

Re: problems serving non-bare repos with submodules over http

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

Re: history damage in linux.git

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

Re: history damage in linux.git

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

Re: [PATCH/RFC/GSoC 0/2] add a add.patch config variable

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.

Re: [PATCH/RFC/GSoC 0/2] add a add.patch config variable

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

Re: 'next'ed --allow-unrelated-histories could cause lots of grief

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 >

Re: history damage in linux.git

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 >

Re: history damage in linux.git

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:

Re: [PATCH/RFC/GSoC 0/2] add a add.patch config variable

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

'next'ed --allow-unrelated-histories could cause lots of grief

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

Re: history damage in linux.git

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

Re: [PATCH v2 04/12] worktree.c: mark current worktree

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

Re: [PATCH v2 04/12] worktree.c: mark current worktree

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

Re: [PATCH/RFC/GSoC 0/2] add a add.patch config variable

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

Re: [PATCH v2 04/12] worktree.c: mark current worktree

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

Re: [PATCH v2 04/12] worktree.c: mark current worktree

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

Re: [PATCH v2 04/12] worktree.c: mark current worktree

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

Re: [PATCH v7 19/33] refs: allow log-only updates

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 >

Re: history damage in linux.git

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

Re: history damage in linux.git

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

Re: history damage in linux.git

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

Re: history damage in linux.git

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

Re: history damage in linux.git

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

history damage in linux.git

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

Re: [PATCH v2 04/12] worktree.c: mark current worktree

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

[PATCH/RFC/GSoC 1/2] count recursion depth

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

[PATCH/RFC/GSoC 2/2] add a add.patch config variable

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

[PATCH/RFC/GSoC 0/2] add a add.patch config variable

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

Re: [PATCH v2 04/12] worktree.c: mark current worktree

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 @@

Re: [PATCH v2] git-p4: add P4 jobs to git commit message

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

Re: [PATCH v2 04/12] worktree.c: mark current worktree

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,

Re: git rebase -i without altering the committer date

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 > > >

Re: [PATCH v2 03/12] worktree.c: make find_shared_symref() return struct worktree *

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. > >