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:
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
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
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
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
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
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
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
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
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
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
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
>
> * 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
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
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
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
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
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
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
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
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
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
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
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
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 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,
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)"
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
> >
> >
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
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
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,
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,
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
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:
>
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
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
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
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
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
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
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
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
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.
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
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
>
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
>
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:
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
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
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
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
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
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
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
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
>
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
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
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
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
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
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
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
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
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
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
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 @@
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
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,
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
> > >
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.
>
>
77 matches
Mail list logo