2016-11-29 23:55 GMT+02:00 Jeff King :
> On Mon, Nov 28, 2016 at 10:34:51PM +0200, Dāvis Mosāns wrote:
>
>> I'm trying to fetch a remote repository over https but sadly it
>> timeouts too soon.
>>
>> $ git fetch -v upstream
>> POST git-upload-pack (gzip 1148 to 641 bytes)
>> POST git-upload-pack (g
On Tue, Nov 29, 2016 at 11:21 AM, Stefan Beller wrote:
>
>>
>> * dt/empty-submodule-in-merge (2016-11-17) 1 commit
>> - submodules: allow empty working-tree dirs in merge/cherry-pick
>>
>> Waiting for review
>
> That slipped by me. Will review.
>
I reviewed what you have queued and it still loo
On Tue, Nov 29, 2016 at 11:28 AM, Junio C Hamano wrote:
> Duy Nguyen writes:
>
>> Another way, as pointed out by j6t, is go with "move within filesystem
>> only", at least at the first step. Which is probably a good idea
>> anyway so we can concentrate on git-specific stuff before going to
>> min
On Wed, Nov 30, 2016 at 4:14 AM, Johannes Sixt wrote:
>> diff --git a/copy.c b/copy.c
>> index 4de6a11..b232aec 100644
>> --- a/copy.c
>> +++ b/copy.c
>> @@ -65,3 +65,9 @@ int copy_file_with_time(const char *dst, const char
>> *src, int mode)
>> return copy_times(dst, src);
>>
Good day!
Software.informer.com would like to inform you that your product GIT by github
2.10.2.1 has been reviewed by our editors and your program got "100% Clean
Award" http://git.software.informer.com/.
We would be grateful if you place our award with a link to our review on your
website. O
Jeff King writes:
> On Tue, Nov 29, 2016 at 01:21:51PM -0800, Junio C Hamano wrote:
>
>> The latest feature release Git v2.11.0 is now available at the
>> usual places. It is comprised of 673 non-merge commits since
>> v2.10.0, contributed by 74 people, 15 of which are new faces.
>> [...]
>> Jef
On Mon, Nov 28, 2016 at 10:34:51PM +0200, Dāvis Mosāns wrote:
> I'm trying to fetch a remote repository over https but sadly it
> timeouts too soon.
>
> $ git fetch -v upstream
> POST git-upload-pack (gzip 1148 to 641 bytes)
> POST git-upload-pack (gzip 1148 to 644 bytes)
> [...]
> Is there some
Jeff King writes:
> I think it's arguable whether "--global" should behave the same.
I know you know this and I am writing this message for others.
I admit that I wondered if "a single file" ought to cover these
short-hand notations like --global and --local while re-reading the
log message of
On Tue, Nov 29, 2016 at 02:53:08PM -0500, Eli Barzilay wrote:
> > This already is documented, and I think it is clear enough.
> >
> >--[no-]includes
> > Respect include.* directives in config files when
> > looking up values. Defaults to off when a spec
On Tue, Nov 29, 2016 at 01:21:51PM -0800, Junio C Hamano wrote:
> The latest feature release Git v2.11.0 is now available at the
> usual places. It is comprised of 673 non-merge commits since
> v2.10.0, contributed by 74 people, 15 of which are new faces.
> [...]
> Jeff King (117):
> [...]
>
Welcome to the Git development community.
This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.
* Mailing list and the community
The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports
The latest feature release Git v2.11.0 is now available at the
usual places. It is comprised of 673 non-merge commits since
v2.10.0, contributed by 74 people, 15 of which are new faces.
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/
The following public repositories
Am 29.11.2016 um 14:56 schrieb Duy Nguyen:
If you drop all the "copy.c: " patches and squash this to "worktree
move: new command", and if Windows rename() can move directories, then
git should build and new tests pass.
Thanks! rename() can move directories on Windows, provided that
*nothing* i
Johannes Schindelin writes:
> So the suggestion by both you and Peff, to use an environment variable,
> which is either global, or requires the user to set it manually per
> session, is simply not a good idea at all.
As I already said, I do not have a strong preference between config
and env. I
On Tue, Nov 29, 2016 at 09:36:55PM +0100, Johannes Schindelin wrote:
> So the suggestion by both you and Peff, to use an environment variable,
> which is either global, or requires the user to set it manually per
> session, is simply not a good idea at all.
No, my suggestion was to use config and
Torsten Bögershausen writes:
> Thanks for the review - how about this:
>
>
> convert: git cherry-pick -Xrenormalize did not work
>
> Working with a repo that used to be all CRLF. At some point it
> was changed to all LF, with `text=auto` in .gitattributes.
> Trying to cherry-pick a commit from be
Hi Junio,
On Mon, 28 Nov 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > However, I have been bitten time and again by problems that occurred only
> > in production, our test suite (despite taking already waay too long to
> > be truly useful in my daily development) was simp
On Tue, Nov 29, 2016 at 10:42:18AM -0800, Junio C Hamano wrote:
> tbo...@web.de writes:
>
> > From: Torsten Bögershausen
> >
> > Working with a repo that used to be all CRLF. At some point it
> > was changed to all LF, with `text=auto` in .gitattributes.
> > Trying to cherry-pick a commit from be
On Tue, Nov 29, 2016 at 2:46 PM, Junio C Hamano wrote:
> Eli Barzilay writes:
>
>> So this is at least a documentation issue,...
>
> This already is documented, and I think it is clear enough.
>
>--[no-]includes
> Respect include.* directives in config files when
>
Eli Barzilay writes:
> So this is at least a documentation issue,...
This already is documented, and I think it is clear enough.
--[no-]includes
Respect include.* directives in config files when
looking up values. Defaults to off when a
I just noticed something weird: if I have this in my ~/.gitconfig:
[x]
x = global
[include]
path = .gitconfig.more
and .gitconfig.more has
[x]
x = more
then I get:
1. git config x.x => more
2. git config --global x.x => global
3.
Jiang Xin writes:
> Final l10n updates for this release cycle, please pull.
Thanks!
On Tue, Nov 29, 2016 at 11:26 AM, Junio C Hamano wrote:
>>> Need to read it over again, deal with SQUASH, and may ask for a
>>> reroll.
>>
>> Ok, I looked over it again and I may see some issues:
>
> OK then I'll procrastinate on this.
This is not what I had in mind when typing out the issues.
Duy Nguyen writes:
> Another way, as pointed out by j6t, is go with "move within filesystem
> only", at least at the first step. Which is probably a good idea
> anyway so we can concentrate on git-specific stuff before going to
> minor and complicated copy/move details.
Yup, that is a very sensi
Stefan Beller writes:
> On Mon, Nov 28, 2016 at 4:15 PM, Junio C Hamano wrote:
>>
>> * sb/push-make-submodule-check-the-default (2016-10-10) 2 commits
>> - push: change submodule default to check when submodules exist
>> - submodule add: extend force flag to add existing repos
>>
>> Turn the
On Mon, Nov 28, 2016 at 4:15 PM, Junio C Hamano wrote:
>
> * sb/push-make-submodule-check-the-default (2016-10-10) 2 commits
> - push: change submodule default to check when submodules exist
> - submodule add: extend force flag to add existing repos
>
> Turn the default of "push.recurseSubmodul
tbo...@web.de writes:
> From: Torsten Bögershausen
>
> Sincec commit 6523728499e7 'convert: unify the "auto" handling of CRLF'
> the normalization instruction in Documentation/gitattributes.txt
> doesn't work any more.
Aside from s/Sincec/Since/, the above made it sound as if the named
commit wa
Luke Diamand writes:
> On 28 November 2016 at 19:06, Junio C Hamano wrote:
>> Vinicius Kursancew writes:
>>
>>> This patch adds a "--shelve" option to the submit subcommand, it will
>>> save the changes to a perforce shelve instead of commiting them.
>
> Looks good to me, thanks!
>
> Works a tr
David Aguilar writes:
> Built-in merge tools contain a hard-coded assumption about
> whether or not a tool's exit code can be trusted to determine
> the success or failure of a merge. Tools whose exit codes are
> not trusted contain calls to check_unchanged() in their
> merge_cmd() functions.
>
On 2016-11-29 at 19:35:38 +0100, Junio C Hamano wrote:
> Tobias Klauser writes:
>
> > s/paht/path/ in the "Backwards compatibility notes" section of the
> > 2.11.0 release notes.
> >
> > Signed-off-by: Tobias Klauser
> > ---
>
> This looks somewhat familiar. Perhaps
>
> https://public-inbo
On Mon, 2016-11-21 at 09:23 -0800, Junio C Hamano wrote:
> Jacob Keller writes:
>
> > > We have %s and %b so that we can reconstruct the whole thing by
> > > using both. It is unclear how %bT fits in this picture. I
> > > wonder
> > > if we also need another placeholder that expands to the body
tbo...@web.de writes:
> From: Torsten Bögershausen
>
> Working with a repo that used to be all CRLF. At some point it
> was changed to all LF, with `text=auto` in .gitattributes.
> Trying to cherry-pick a commit from before the switchover fails:
>
> $ git cherry-pick -Xrenormalize
> fatal: C
On Tue, Nov 29, 2016 at 10:31:51AM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > I'm actually considering scrapping the approach you've queued above, and
> > just teaching verify_path() to reject any index entry starting with
> > ".git" that is a symlink.
>
> Hmph, that's a thought.
I
Tobias Klauser writes:
> s/paht/path/ in the "Backwards compatibility notes" section of the
> 2.11.0 release notes.
>
> Signed-off-by: Tobias Klauser
> ---
This looks somewhat familiar. Perhaps
https://public-inbox.org/git/1477668782.1869.4.ca...@seestieto.com/
> Documentation/RelNotes/
Jeff King writes:
> I'm actually considering scrapping the approach you've queued above, and
> just teaching verify_path() to reject any index entry starting with
> ".git" that is a symlink.
Hmph, that's a thought.
On Tue, Nov 29, 2016 at 1:51 AM, Alessandro Renieri wrote:
> On Redhat Enterprise gitk returns the following error when launched:
>
> Error in startup script: unknown color name "lime"
> (processing "-fill" option)
> invoked from within
> "$progresscanv create rect -1 0 0 $h -fill lime"
>
On Mon, Nov 28, 2016 at 2:11 PM, Brandon Williams wrote:
> On 11/10, Stefan Beller wrote:
>> @@ -500,6 +586,18 @@ void copy_pathspec(struct pathspec *dst, const struct
>> pathspec *src)
>>
>> void clear_pathspec(struct pathspec *pathspec)
>> {
>> + int i, j;
>> + for (i = 0; i < pathspe
Signed-off-by: Ramsay Jones
---
Hi Johannes,
If you need to re-roll your 'js/difftool-builtin' branch, could
you please squash this into the relevant patch.
Thanks!
Also, due to a problem in my config.mak file on Linux (a commented
out line that had a line continuation '\', gr!), gcc issu
From: Torsten Bögershausen
Working with a repo that used to be all CRLF. At some point it
was changed to all LF, with `text=auto` in .gitattributes.
Trying to cherry-pick a commit from before the switchover fails:
$ git cherry-pick -Xrenormalize
fatal: CRLF would be replaced by LF in [path]
On Tue, Nov 29, 2016 at 07:08:16PM +0700, Duy Nguyen wrote:
> On Tue, Nov 29, 2016 at 3:20 AM, Junio C Hamano wrote:
> > Junio C Hamano writes:
> >
> >> Does this round address the issue raised in
> >>
> >> http://public-inbox.org/git/alpine.DEB.2.20.1611161041040.3746@virtualbox
> >>
> >> by D
Hi Junio,
Final l10n updates for this release cycle, please pull.
The following changes since commit 6366c34b895613482fa32f1abe1c3ca043905ad2:
l10n: de.po: translate 210 new messages (2016-11-28 18:49:25 +0100)
are available in the git repository at:
git://github.com/git-l10n/git-po tags/l
On 28 November 2016 at 19:06, Junio C Hamano wrote:
> Vinicius Kursancew writes:
>
>> This patch adds a "--shelve" option to the submit subcommand, it will
>> save the changes to a perforce shelve instead of commiting them.
Looks good to me, thanks!
Works a treat.
Ack.
>>
>> Vinicius Kursance
On Tue, Nov 29, 2016 at 4:25 AM, Johannes Sixt wrote:
> Am 28.11.2016 um 21:20 schrieb Junio C Hamano:
>>
>> Junio C Hamano writes:
>>
>>> Does this round address the issue raised in
>>>
>>>
>>> http://public-inbox.org/git/alpine.DEB.2.20.1611161041040.3746@virtualbox
>>>
>>> by Dscho?
>>>
>>> Ev
On Tue, Nov 29, 2016 at 3:20 AM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> Does this round address the issue raised in
>>
>> http://public-inbox.org/git/alpine.DEB.2.20.1611161041040.3746@virtualbox
>>
>> by Dscho?
It does not (and is sort of expected), quoting from the commit messag
Did you get my request?
I've just upgraded to macOS 10.12.1 and now I can't paste into git-gui
(the commit message box).
It seems to work if the text is copied from within git-gui but not from
outside. I've tried using the latest dmg from
https://git-scm.com/download/mac (2.10.1) but it doesn't fix the problem.
s/paht/path/ in the "Backwards compatibility notes" section of the
2.11.0 release notes.
Signed-off-by: Tobias Klauser
---
Documentation/RelNotes/2.11.0.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/RelNotes/2.11.0.txt
b/Documentation/RelNotes/2.11.0.txt
On Redhat Enterprise gitk returns the following error when launched:
Error in startup script: unknown color name "lime"
(processing "-fill" option)
invoked from within
"$progresscanv create rect -1 0 0 $h -fill lime"
(procedure "makewindow" line 201)
invoked from within
"makewindow
Built-in merge tools contain a hard-coded assumption about
whether or not a tool's exit code can be trusted to determine
the success or failure of a merge. Tools whose exit codes are
not trusted contain calls to check_unchanged() in their
merge_cmd() functions.
A problem with this is that the tru
Allow vimdiff users to signal that they do not want to use the
result of a merge by exiting with ":cquit", which tells Vim to
exit with an error code.
This is better than the current behavior because it allows users
to directly flag that the merge is bad, using a standard Vim
feature, rather than
50 matches
Mail list logo
