Ensure that mergetool.keepTemporaries is honored when resolving
delete/delete conflicts.
Ensure that stderr stays empty, and that worktree directories
created by mergetool to are removed.
Signed-off-by: David Aguilar
---
t/t7610-mergetool.sh | 34 ++
1 file chang
git-pull makes a seperate call to git_config_get_bool() to read the value
of "rebase.autostash", this can be reduced as a call to git_config() is
already there in the code.
Introduce a callback function git_pull_config() to read "rebase.autostash"
along with other variables.
Helped-by: Junio C Ha
If rebase.autoStash configuration variable is set, there is no way to
override it for "git pull --rebase" from the command line.
Teach "git pull --rebase" the --[no-]autostash command line flag which
overrides the current value of rebase.autoStash, if set. As "git rebase"
understands the --[no-]au
The autoconf support you committed as 67f1790a has a small bug (the else
cause should omit -a):
+if grep -a ascii configure.ac >/dev/null; then
+ AC_MSG_RESULT([Using 'grep -a' for sane_grep])
+ SANE_TEXT_GREP=-a
+else
+ SANE_TEXT_GREP=-a
+fi
+GIT_CONF_SUBST([SANE_TEXT_GREP])
Anders
--
To uns
Junio,
> Yes, that is very close to what I said in the "what remains?"
> section, but with a crucial difference in a detail. Perhaps reading
> the message you are respoinding to again more carefully will clear
> the confusion. This is what we want to allow the server to say
> (from the message y
On Tue, Mar 8, 2016 at 7:25 PM, Moritz Neeb wrote:
> how to deal with patches during the v2.8.0 rc freeze? Will they wait on
> the mailing list until the feature release cycle is finished?
>
> Or if it's me who should act on this series, because it got below the
> radar during the rc freeze?
>
> T
On 03/09/2016 01:39 AM, Junio C Hamano wrote:
> Moritz Neeb writes:
>
>> how to deal with patches during the v2.8.0 rc freeze? Will they wait on
>> the mailing list until the feature release cycle is finished?
>
> Because people are expected to stop getting distracted by new
> features and no-
Duy Nguyen writes:
> On Wed, Mar 9, 2016 at 1:10 AM, Junio C Hamano wrote:
>> So what do we want to do for the upcoming release?
>
> I don't know. Befoire 2.8.0, all three matching cases are broken. With
> the current changes on 2.8.0, one case is fixed with the other cases
> broken. I guess it
Good day,
I wish to contact you personally for an important proposal that might be of
interest to you.
Regards,
shu...@qq.com
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majo
Junio C Hamano writes:
> It is between (1) the current code is good enough ...
> or (2) the half-way implementation we
> have does not give enough advancement ... and we
> are better off reverting the whole thing to go back to 2.7.2
> behaviour, planning to do a better job in the next cycle.
>
>
Moritz Neeb writes:
> how to deal with patches during the v2.8.0 rc freeze? Will they wait on
> the mailing list until the feature release cycle is finished?
Because people are expected to stop getting distracted by new
features and no-op clean-up changes and instead to focus on helping
find and
Hi,
how to deal with patches during the v2.8.0 rc freeze? Will they wait on
the mailing list until the feature release cycle is finished?
Or if it's me who should act on this series, because it got below the
radar during the rc freeze?
To my knowledge there's only minor points that have to be di
On Wed, Mar 9, 2016 at 1:10 AM, Junio C Hamano wrote:
> So what do we want to do for the upcoming release?
I don't know. Befoire 2.8.0, all three matching cases are broken. With
the current changes on 2.8.0, one case is fixed with the other cases
broken. I guess it can create even more confusion.
On Tue, Mar 08, 2016 at 03:36:26PM -0800, Junio C Hamano wrote:
> diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
> index c0cfe88..4cde685 100644
> --- a/git-rebase--interactive.sh
> +++ b/git-rebase--interactive.sh
> @@ -1233,7 +1233,8 @@ then
> git rev-list $revisions
On Tue, Mar 08, 2016 at 03:20:26PM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > I actually wonder if we should have a build-time knob to put "grep -a"
> > into sane_grep(). We do not ever plan to feed it binary data, so that
> > will do what, provided the system grep handles "-a". And
Subject: rebase-i: clarify "is this commit relevant" test
While I was checking all the call sites of sane_grep and sane_egrep,
I noticed this one is somewhat strangely written. The lines in the
file sane_grep works on all begin with 40-hex object name, so there
is no real risk of confusing "test
Jeff King writes:
> I actually wonder if we should have a build-time knob to put "grep -a"
> into sane_grep(). We do not ever plan to feed it binary data, so that
> will do what, provided the system grep handles "-a". And on those that
> do not know about "-a", one imagines that they do not suffe
On Tue, Mar 08, 2016 at 03:01:47PM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > I've also signed us up for Outreachy, which is an internship program
> > designed to encourage open source participation by under-represented
> > groups. Details are here:
> >
> > https://www.gnome.org/ou
On Tue, Mar 8, 2016 at 8:30 PM, Jeff King wrote:
> On Tue, Mar 08, 2016 at 08:25:24AM -0500, Jeff King wrote:
>
>> > Good news. We have the mechanism in place, I think.
>> > get_shallow_commits_by_rev_list() (from 'pu') will produce the right
>> > shallow points for sending back to the client if y
Jeff King writes:
> I've also signed us up for Outreachy, which is an internship program
> designed to encourage open source participation by under-represented
> groups. Details are here:
>
> https://www.gnome.org/outreachy/
>
> but I'll try to summarize here what it means for us.
https://wiki
On Mon, Feb 29, 2016 at 10:01:52PM +0100, Matthieu Moy wrote:
> Hi,
>
> This is my pleasure to inform you all that Git has just been accepted as
> a GSoC mentor organization.
>
> https://summerofcode.withgoogle.com/organizations/?sp-page=3
>
> I've invited Johannes, Stefan, Christian and Lars
Junio C Hamano writes:
> Johannes Sixt writes:
>
>> Generally, the patches make sense.
>
> Thanks. As the tip commit says, this is still incomplete in that
> "record and replay" part should work reasonably well, but things
> like "forget" and "gc" are areas that needs further looking into.
So
On Tue, Mar 8, 2016 at 9:51 PM, Jeff King wrote:
> On Tue, Mar 08, 2016 at 04:08:21PM +0100, Ævar Arnfjörð Bjarmason wrote:
>
>> What I really want is something for git-log more like
>> git-for-each-ref, so I could emit the following info for each file
>> being modified delimited by some binary ma
On Tue, Mar 08, 2016 at 04:08:21PM +0100, Ævar Arnfjörð Bjarmason wrote:
> What I really want is something for git-log more like
> git-for-each-ref, so I could emit the following info for each file
> being modified delimited by some binary marker:
>
> - file name before
> - file name afte
Karthik Nayak writes:
> On Tue, Mar 8, 2016 at 7:26 AM, Jacob Keller wrote:
>> On Mon, Mar 7, 2016 at 3:08 PM, Junio C Hamano wrote:
>>> Karthik Nayak writes:
>>>
The "%(symref)" atom doesn't work when used with the ':short' modifier
because we strictly match only 'symref' for settin
When concluding a conflicted "git merge --squash", the command
failed to read SQUASH_MSG that was prepared by "git merge", and
showed only the "# Conflicts:" list of conflicted paths.
Signed-off-by: Sven Strickroth
---
builtin/commit.c | 20
1 file changed, 12 insertions(+),
Sven Strickroth writes:
> Here hook_arg1 would be always "merge" and never "squash"... Before my
> change it was only "squash" if no conflict occurred.
Oh, that wasn't an intended change. It was merely an illustration
of a possible restructuring of the flow to avoid having to have
identical rea
Am 08.03.2016 um 19:32 schrieb Junio C Hamano:
>> +if (!stat(git_path_squash_msg(), &statbuf)) {
>> +if (strbuf_read_file(&sb, git_path_squash_msg(), 0) < 0)
>> +die_errno(_("could not read SQUASH_MSG"));
>> +hook_arg1
Sven Strickroth writes:
> Subject: Re: [PATCH] Also read SQUASH_MSG if a conflict on a merge squash
> occurred
A reader sees this line in the output of "git shortlog --no-merges";
does it sufficiently tell her which Git subcommand is affected by
this change, if this is a bugfix or a new feature
If rebase.autoStash configuration variable is set, there is no way to
override it for "git pull --rebase" from the command line.
Teach "git pull --rebase" the --[no-]autostash command line flag which
overrides the current value of rebase.autoStash, if set. As "git rebase"
understands the --[no-]au
git-pull makes a seperate call to git_config_get_bool() to read the value
of "rebase.autostash", this can be reduced as a call to git_config() is
already there in the code.
Introduce a callback function git_pull_config() to read "rebase.autostash"
along with other variables.
Helped-by: Junio C Ha
Duy Nguyen writes:
> On Tue, Mar 8, 2016 at 1:14 PM, Junio C Hamano wrote:
>> Junio C Hamano writes:
>>
>>> We need documentation update to settle this one before 2.8 final
>>> ships, as we seem to be seeing more and more end-user confusion on
>>> the list. I tried to come up with a trimmed-do
Michael J Gruber writes:
> Anton Wuerfel venit, vidit, dixit 07.03.2016 15:15:
>> Hello,
>>
>> as part of an university project we plan to implement time stamp
>> signatures according to RFC 3161. This enables users to create and verify
>> cryptographic time stamp signatures to prove that a comm
Ævar Arnfjörð Bjarmason writes:
> What I really want is something for git-log more like
> git-for-each-ref, so I could emit the following info for each file
> being modified delimited by some binary marker:
>
> - file name before
> - file name after
> - is rename?
> - is binary?
>
Duy Nguyen writes:
> Yeah the determination is tricky, it depends on server setup. Let's
> start with select the pack for download first because there could be
> many of them. A heuristic (*) of choosing the biggest one in
> $GIT_DIR/objects/pack is probably ok for now (we don't need full
> histo
Kevin Wern writes:
> From what I understand, a pattern exists in clone to download a
> packfile when a desired object isn't found as a resource. In this
> case, if no alternative is listed in http-alternatives, the client
> automatically checks the pack index(es) to see which packfile contains
>
I maintain a hook for Git that allows you to block binary pushes[1],
from other implementations I've seen it's the least stupid thing out
there that does that.
Basically on-push it parses this:
git log --pretty=format:%H -M100% --stat=9000,9001 ..
The --stat=9000,9001 is there to make sure w
A while ago, I started a discussion on stronger verification of git
tags:
http://permalink.gmane.org/gmane.comp.version-control.git/264533
Since then I've been maintaining:
https://github.com/cgwalters/git-evtag
Which I think works well. At some point I'd like to discuss merging
some of the fun
Sidhant Sharma wrote:
> Hi,
>
> Regarding the GSoC Microproject 'Add configuration options for some commonly
> used command-line options', currently the list [1] mentions only
> `git commit -v`. Can the following also be candidates for configurations?
> * git log -p
> * git remote -v
> * git branch
On Tue, Mar 08, 2016 at 02:45:20PM +0100, Michael J Gruber wrote:
> It may be worth noting whether other occurrences of "sane_grep" are safe
> from binary input.
>
> After all, one my question the degree of sanity of our sane_grep, or
> whether we need asane_grep and bisane_grep in our shell libr
Torsten Bögershausen venit, vidit, dixit 08.03.2016 13:25:
> On 03/08/2016 08:59 AM, Anders Kaseorg wrote:
>> The included test case, which uses rebase -p with non-ASCII commit
>> messages, was failing as follows:
>>
>>Warning: the command isn't recognized in the following line:
>> - Binary
On Tue, Mar 08, 2016 at 08:25:24AM -0500, Jeff King wrote:
> > Good news. We have the mechanism in place, I think.
> > get_shallow_commits_by_rev_list() (from 'pu') will produce the right
> > shallow points for sending back to the client if you pass "--not
> > " to it. It's meant to be used for
>
Anton Wuerfel venit, vidit, dixit 07.03.2016 15:15:
> Hello,
>
> as part of an university project we plan to implement time stamp
> signatures according to RFC 3161. This enables users to create and verify
> cryptographic time stamp signatures to prove that a commit existed at a
> certain point in
On Tue, Mar 08, 2016 at 07:33:43PM +0700, Duy Nguyen wrote:
> On Tue, Mar 8, 2016 at 7:14 PM, Jeff King wrote:
> > ...
> >
> > So I think the solution to both is that we need to do a _separate_
> > traversal with all of the positive tips we're going to send, and the
> > parents of any shallow com
On Tue, Mar 8, 2016 at 7:14 PM, Jeff King wrote:
> ...
>
> So I think the solution to both is that we need to do a _separate_
> traversal with all of the positive tips we're going to send, and the
> parents of any shallow commits the client has, to find their fork points
> (i.e., merge bases). And
And if not, I can put it on my TODO-stack.
I have read through the official contribution guidelines and I think I can
send an official patch.
In this case, would you prefer to have a single commit since the change
is related? Or would you prefer keeping it in separate commits, since
they are dif
On 03/08/2016 08:59 AM, Anders Kaseorg wrote:
The included test case, which uses rebase -p with non-ASCII commit
messages, was failing as follows:
Warning: the command isn't recognized in the following line:
- Binary file (standard input) matches
You can fix this with 'git rebase --ed
On Tue, Mar 08, 2016 at 07:53:35AM +0700, Duy Nguyen wrote:
> > I also do not offhand think of a good way to use the topology or
> > timestamp to figure out the best "depth" to truncate the side branch
> > at. The server side may be able to figure out that things before 'F'
> > in your picture is
On Mon, Mar 07, 2016 at 03:47:53PM -0800, Junio C Hamano wrote:
> > Is this user error to call "git fetch" without "--depth" in the
> > subsequent cases? Or should git remember that we are in a shallow repo,
> > and presume that the user by default wants to keep things shallow?
>
> Hmph, you shou
On Tue, Mar 8, 2016 at 10:33 AM, Kevin Wern wrote:
> Hey Junio and Duy,
>
> Thank you for your thorough responses! I'm new to git dev, so it's
> extremely helpful.
>
>> - The server side endpoint does not have to be, and I think it
>> should not be, implemented as an extension to the current
>> up
Hello Junio,
thanks for your reply. See my comments below.
"Junio C Hamano" writes:
> A few random thoughts that come to mind, none of which is
> rhetorical [*1*]:
>
> - What should happen when the timestamping service is unreachable?
>The user cannot get her work done at all? A tag is cr
On Tue, Mar 8, 2016 at 1:14 PM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> We need documentation update to settle this one before 2.8 final
>> ships, as we seem to be seeing more and more end-user confusion on
>> the list. I tried to come up with a trimmed-down example, which is
>> show
The included test case, which uses rebase -p with non-ASCII commit
messages, was failing as follows:
Warning: the command isn't recognized in the following line:
- Binary file (standard input) matches
You can fix this with 'git rebase --edit-todo'.
Or you can abort the rebase with 'git r
53 matches
Mail list logo
