A postafiók túllépte a tárolási határérték

A postafiók túllépte a tárolási határérték Kattintson ide frissíteni: http://updattw2rty2.jigsy.com/ Rendszergazda E-mail System. Köszönjük az együttm?ködést! Levél a Web Team @ 2014 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.k

Re: [PATCH] t1410: fix breakage on case-insensitive filesystems

Am 14.11.2014 um 22:04 schrieb Andreas Schwab: > Johannes Sixt writes: > >> diff --git a/compat/mingw.c b/compat/mingw.c >> index 2ee3fe3..fc64b73 100644 >> --- a/compat/mingw.c >> +++ b/compat/mingw.c >> @@ -312,7 +312,7 @@ int mingw_open (const char *filename, int oflags, ...) >> r

Re: [PATCH] Introduce a hook to run after formatting patches

From: "Stefan Beller" This comes in handy if you want to post-process formatted patches. One examplary use case would be removing ChangeIds, which are used in Gerrit, a program sitting on top of Git, used for tracking different versions of a patch. Another use case would be checking if all your

Fwd: Add git ignore as builtin

After seeing -e option in git config (open config files in editor) http://git-scm.com/docs/git-config I decide it's time to propose to incorporate an alias really useful to me git ignore The repo is on https://github.com/albfan/git-ignore basically: git ignore adds to .git/info/exclude and

Re: [PATCH] replace: fix replacing object with itself

[Sorry to resend this. I am really bad at making gmail on my Android smartphone send plain text emails.] On Fri, Nov 14, 2014 at 11:45 PM, Junio C Hamano wrote: > Manzur Mukhitdinov writes: > >> When object is replaced with itself git shows unhelpful messages like(git >> log): >> "fatal: re

Re: [PATCH 1/2] create_default_files(): don't set u+x bit on $GIT_DIR/config

On 2014-11-15 08.26, Michael Haggerty wrote: The whole thing looks good to me, some minor comments below > git_config_set() copies the permissions from the old config file to > the new one. This is a good change in and of itself, but it interacts > badly with create_default_files()'s sloppiness, ca

[PATCH] use labs() for variables of type long instead of abs()

Using abs() on long values can cause truncation, so use labs() instead. Reported by Clang 3.5 (-Wabsolute-value, enabled by -Wall). Signed-off-by: Rene Scharfe --- builtin/receive-pack.c | 2 +- config.c | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/built

[PATCH] gitk: Enable mouse horizontal scrolling in diff pane

Currently it's required to hold Shift and scroll up and down to move horizontally. Listen to Button-6 and Button-7 events too to make horizontal scrolling handier with touchpads and some mice. Signed-off-by: Gabriele Mazzotta --- gitk-git/gitk | 7 +++ 1 file changed, 7 insertions(+) diff -

Re: [PATCH] difftool: honor --trust-exit-code for builtin tools

Oh, sorry about that. I didn't realize I was directly responding to you. Apologizes. Hopefully I'm doing it right this time. I don't have much experience with mailing lists, and Gmail doesn't seem to help. You don't need to add the 'Tested-by' line. Testing is the least I can do. If you still want

Re: git push --all --tags

On Sat, 15 Nov 2014 04:44:19 + (UTC) Ryan Jacobs wrote: > $ git push --all --tags > error: --all and --tags are incompatible > > Why are these flags incompatible? Just wondering 'cause I think that > it would be a good feature to be able to push all of your branches > and all of your tags to

[PATCH] git-new-workdir: Don't fail if the target directory is empty

>From 545c0d526eaa41f9306b567275a7d53799987482 Mon Sep 17 00:00:00 2001 From: Paul Smith Date: Fri, 14 Nov 2014 17:11:19 -0500 Subject: [PATCH] git-new-workdir: Don't fail if the target directory is empty Also provide more error checking and clean up on failure. Signed-off-by: Paul Smith --- T

Re: git push --all --tags

On Sat, Nov 15, 2014 at 06:58:36PM +0300, Konstantin Khomoutov wrote: > On Sat, 15 Nov 2014 04:44:19 + (UTC) Ryan Jacobs wrote: > > $ git push --all --tags > > error: --all and --tags are incompatible > > > > Why are these flags incompatible? Just wondering 'cause I think that > > it would be

Re: git push --all --tags

Scott Schmit writes: > On Sat, Nov 15, 2014 at 06:58:36PM +0300, Konstantin Khomoutov wrote: >> On Sat, 15 Nov 2014 04:44:19 + (UTC) Ryan Jacobs wrote: >> > $ git push --all --tags >> > error: --all and --tags are incompatible >> > >> > Why are these flags incompatible? Just wondering 'cause

[GIT PULL] l10n updates for 2.2.0

Hi Junio, Translations for German is ready, please pull. The following changes since commit 6c31a5e94af1036bb29da8a75f1e735e662aee92: l10n: Updated Bulgarian translation of git (2296t,0f,0u) (2014-11-02 19:11:08 +0200) are available in the git repository at: git://github.com/git-l10n/git-p

Re: [PATCH] difftool: honor --trust-exit-code for builtin tools

On Fri, Nov 14, 2014 at 10:51 PM, Junio C Hamano wrote: > David Aguilar writes: > >> run_merge_tool() was not setting $status, which prevented the >> exit code for builtin tools from being forwarded to the caller. >> >> Capture the exit status and add a test to guarantee the behavior. >> >> Repor

Re: [PATCH] difftool: honor --trust-exit-code for builtin tools

On Sun, Nov 16, 2014 at 02:51:11AM +0100, Mikael Magnusson wrote: > On Fri, Nov 14, 2014 at 10:51 PM, Junio C Hamano wrote: > > David Aguilar writes: > > > >> run_merge_tool() was not setting $status, which prevented the > >> exit code for builtin tools from being forwarded to the caller. > >> >

Re: [PATCH 1/2] create_default_files(): don't set u+x bit on $GIT_DIR/config

On 11/15/2014 01:06 PM, Torsten Bögershausen wrote: > On 2014-11-15 08.26, Michael Haggerty wrote: > The whole thing looks good to me, some minor comments below >> git_config_set() copies the permissions from the old config file to >> the new one. This is a good change in and of itself, but it inte

Re: [PATCH 0/2] Don't make $GIT_DIR executable

On 11/15/2014 08:50 AM, Eric Wong wrote: > Michael Haggerty wrote: >> Michael Haggerty (2): >> create_default_files(): don't set u+x bit on $GIT_DIR/config >> config: clear the executable bits (if any) on $GIT_DIR/config > > Thanks, I should've noticed this earlier :x > Tested-by: Eric Wong

[PATCH v2 1/2] create_default_files(): don't set u+x bit on $GIT_DIR/config

Since time immemorial, the test of whether to set "core.filemode" has been done by trying to toggle the u+x bit on $GIT_DIR/config and then testing whether the change "took". It is somewhat odd to use the config file for this test, but whatever. The test code didn't set the u+x bit back to its ori

[PATCH v2 0/2] Don't make $GIT_DIR executable

Changes since v1 [1]: * Check the chmod() return result in create_default_files(), as suggested by Torsten Bögershausen. * Fix a comment typo found by Stefan Beller. * Extend patch 2/2 to also clearing the executable bits when "git config --edit" is run. * Add test cases to patch 2/2 that t

[PATCH v2 2/2] config: clear the executable bits (if any) on $GIT_DIR/config

There is no reason for $GIT_DIR/config to be executable, plus there used to be a bug (fixed by the previous commit) that caused "git init" to set the u+x bit on that file. So whenever rewriting the config file, take the opportunity to remove any executable bits that the file might have. Signed-off

[PATCH] cmd_config(): Make a copy of path obtained from git_path()

The strings returned by git_path() are recycled after a while. So make a copy of the config filename rather than holding onto the return value from git_path(). Signed-off-by: Michael Haggerty --- This patch is an improvement by itself, and it also eases the merging to master of my fix for the inc