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
Since the damage is done, perhaps removing +x from
On 11/15/2014 08:32 AM, Stefan Beller wrote:
> On 14.11.2014 23:26, Michael Haggerty wrote:
>> There is no reason for $GIT_DIR/config to be executable, plus this
>> change will help clean up repositories affected by the bug that was
>> fixed by the previous commit.
>>
>> Signed-off-by: Michael Hagg
On 14.11.2014 23:26, Michael Haggerty wrote:
> There is no reason for $GIT_DIR/config to be executable, plus this
> change will help clean up repositories affected by the bug that was
> fixed by the previous commit.
>
> Signed-off-by: Michael Haggerty
> ---
> config.c | 12 ++--
> 1 file
Starting with v2.1.0, "git init" creates $GIT_DIR/config with its u+x
bit set. These two patches are "belt and suspenders"--either one would
fix the bug, but IMO it makes sense to apply both of them. Plus, the
second patch will help repair repositories that were created while
this bug was in the wi
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
There is no reason for $GIT_DIR/config to be executable, plus this
change will help clean up repositories affected by the bug that was
fixed by the previous commit.
Signed-off-by: Michael Haggerty
---
config.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/conf
On 11/13/2014 01:22 PM, Duy Nguyen wrote:
> On Thu, Nov 13, 2014 at 12:05 PM, Torsten Bögershausen wrote:
>> From a Git user perspective it could be good to have something like this:
>>
>> a) git status -u
>> b) git status -uno
>> c) git status -umtime
>> d) git status -uwatchman
>>
>> We know tha
$ 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 the server in one quick and simple command.
--
To unsubscribe from thi
On 15 November 2014 10:01, Junio C Hamano wrote:
>> 23 files changed, 375 insertions(+), 7 deletions(-)
>
> I am not sure if this much of code churn is warranted to work around
> issues that only happen on repositories on NFS servers that do not
> keep open-but-deleted files available. Is it an
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 commits are signed off,
Adri sent me this directly but I think it should have gone to the list.
Adri, if you don't mind, Junio can add:
Tested-by: Adri Farr <14farr...@gmail.com>
...to the commit message trailer since it looks like it's happy.
Thanks for testing!
cheers,
David
- Forwarded message from Adri Farr
On Fri, Nov 14, 2014 at 6:21 PM, Jonathan Nieder wrote:
> Hi,
>
> Mike Blume wrote:
>
>> TTY tests were previously skipped on all Mac OS systems because of a
>> bug where reading from pty master occasionally hung. This bug has since
>> been found not to be reproducible under Mac OS 10.9 and 10.10.
A release candidate Git v2.2.0-rc2 is now available for testing
at the usual places. We expect that the final will happen late
next week, and it will be different from this tarball only with
small documentation update changes.
The tarballs are found at:
https://www.kernel.org/pub/software/sc
Jonathan Nieder writes:
> *puzzled* Testing on Yosemite with the following script[1]
> ...
> still seems to hang eventually (after 61 iterations when my officemate
> tried it), reproducing the bug.
Thanks. I've merged it to 'next' and pushed out the result already,
but we may probably have to d
Hi,
Mike Blume wrote:
> TTY tests were previously skipped on all Mac OS systems because of a
> bug where reading from pty master occasionally hung. This bug has since
> been found not to be reproducible under Mac OS 10.9 and 10.10.1.
>
> Therefore, run TTY tests under Mac OS 10.9 (Mavericks) and
Brodie Rao writes:
> This patch adds a gc.garbageexpire setting that, when not set to "now",
> makes gc (and prune, prune-packed, and repack) move garbage into a
> temporary garbage directory instead of deleting it immediately. The
> garbage directory is then cleared out based on gc.garbageexpire
Manzur Mukhitdinov writes:
> When object is replaced with itself git shows unhelpful messages like(git
> log):
> "fatal: replace depth too high for object "
>
> Prevents user from replacing object with itself(with test for checking
> this case).
>
> Signed-off-by: Manzur Mukhitdinov
> ---
Jeff King writes:
> On Fri, Nov 14, 2014 at 06:46:19AM +0100, Elia Pinto wrote:
>
>> > [1] http://en.wikipedia.org/wiki/Date_and_time_representation_by_country
>> > [2] http://en.wikipedia.org/wiki/Calendar_date
>>
>> Isn't not so good to refer to external resources in a commit message ?
>
> It
On Fri, Nov 14, 2014 at 01:51:39PM -0800, 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.
On Fri, Nov 14, 2014 at 05:12:35PM +0100, Adria Farres wrote:
> Hello!,
>
> I sent an email last week, but I'm not sure if I sent it incorrectly, or the
> formatting was very bad, or it went unnoticed. A few days ago a great soul was
Nah, I was just very busy and it slipped through the cracks.
So
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.
>
> Reported-by: Adria Farres <14farr...@gmail.com>
> Signed-off-by: David
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.
Reported-by: Adria Farres <14farr...@gmail.com>
Signed-off-by: David Aguilar
---
git-mergetool--lib.sh
Hi.
On Fri, Nov 14, 2014 at 05:05:28PM +0600, 0xAX wrote:
> Signed-off-by: 0xAX
> -"(все изменения в рабочем каталоги будут потеряны)"
> +"(все изменения в рабочем каталоге будут потеряны)"
I cannot say I see much sense to use software like Git with
translations to national languages, but I con
On Fri, Nov 14, 2014 at 12:41:16PM -0800, Junio C Hamano wrote:
> David, I think this is about your 2b52123f (difftool: add support
> for --trust-exit-code, 2014-10-26). If you have time can you help
> Adria?
>
> Thanks.
Yup, I'll take a look when I have a chance.
My first guess would be that t
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, ...)
> return -1;
> fd = _wopen(wfilename, oflags, mode);
David, I think this is about your 2b52123f (difftool: add support
for --trust-exit-code, 2014-10-26). If you have time can you help
Adria?
Thanks.
Adria Farres <14farr...@gmail.com> writes:
> Hello!,
>
> I sent an email last week, but I'm not sure if I sent it incorrectly, or the
> formatting
Jeff King writes:
> On Thu, Nov 13, 2014 at 01:48:12PM -0800, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>> > I agree they are technically orthogonal, but I cannot think of a case
>> > where I have ever generated actual _pathspecs_, which might have
>> > wildcards, and needed to use "-z".
Mike Blume writes:
> TTY tests were previously skipped on all Mac OS systems because of a
> bug where reading from pty master occasionally hung. This bug has since
> been found not to be reproducible under Mac OS 10.9 and 10.10.1.
>
> Therefore, run TTY tests under Mac OS 10.9 (Mavericks) and hig
Jeff King writes:
> On Fri, Nov 14, 2014 at 11:48:36AM -0800, Michael Blume wrote:
>
>> My understanding is that && and || have equal precedence, and this
>> seems to be borne out in testing at my shell. If the if/then method is
>> clearer I'm happy to go with that.
>
> I think the problem is tha
TTY tests were previously skipped on all Mac OS systems because of a
bug where reading from pty master occasionally hung. This bug has since
been found not to be reproducible under Mac OS 10.9 and 10.10.1.
Therefore, run TTY tests under Mac OS 10.9 (Mavericks) and higher.
Signed-off-by: Mike Blum
0xAX writes:
> When we execute git config --list and $GIT_CONFIG value starts with home
> prefix - ~/ it produces folowing error - fatal: unable to read config
> file '~/.gitconfig': No such file or directory. This patch fixed it with
> expand_user_path for configuration file path before git-conf
On Sat, Nov 15, 2014 at 01:38:36AM +0600, Alex Kuleshov wrote:
> > Yeah, I'd agree it is a little unexpected to expand here. The "~" is
> > mostly a shell thing, and doing:
> >
> > GIT_CONFIG=~/.gitconfig git config --list
> >
> > from the shell generally works, because the shell will expand the
Right, I missed that there was more going on above, thanks =)
On Fri, Nov 14, 2014 at 12:02 PM, Jeff King wrote:
> On Fri, Nov 14, 2014 at 11:48:36AM -0800, Michael Blume wrote:
>
>> My understanding is that && and || have equal precedence, and this
>> seems to be borne out in testing at my shell
Johannes Sixt writes:
> Not a comment, on this paragraph of yours, but while I was walking
> through the code with gdb, I was wondering why the reflog directory is
> being touched at all when core.logallrefupdates is off (in
> log_ref_setup via log_ref_write). With the patch below I now get the
>
On Fri, Nov 14, 2014 at 11:48:36AM -0800, Michael Blume wrote:
> My understanding is that && and || have equal precedence, and this
> seems to be borne out in testing at my shell. If the if/then method is
> clearer I'm happy to go with that.
I think the problem is that there are earlier parts of
My understanding is that && and || have equal precedence, and this
seems to be borne out in testing at my shell. If the if/then method is
clearer I'm happy to go with that.
On Fri, Nov 14, 2014 at 11:23 AM, Johannes Sixt wrote:
> Am 13.11.2014 um 23:40 schrieb Mike Blume:
>> listed bug doesn't re
Hello Eric and Jeff,
>Eric Sunshine
>A few issues:
>
>(1) Style: s/char* /char */
>
>(2) Avoid declaration (of 'newpath') after statement.
>
>(3) You can drop 'newpath' altogether and just assign the result of
>expand_user_path() directly to given_config_source.file.
>
>This code is potentially l
Mike Blume writes:
> listed bug doesn't reproduce on Mac OS Yosemite or Mavericks. For now,
> just enable TTY on Mavericks and higher
What is "listed bug" that begins a sentence in lowercase?
End the description in full-stop, s/higher/&./;
>
> Signed-off-by: Mike Blume
> Improved-by: Junio C H
On Fri, Nov 14, 2014 at 02:19:41PM -0500, Eric Sunshine wrote:
> On Fri, Nov 14, 2014 at 1:29 PM, 0xAX wrote:
> > When we execute git config --list and $GIT_CONFIG value starts with home
> > prefix - ~/ it produces folowing error - fatal: unable to read config
> > file '~/.gitconfig': No such fil
David Aguilar writes:
> On Sun, Nov 09, 2014 at 09:21:49AM -0800, Junio C Hamano wrote:
>>
>> It might be less risky if the updated semantics were to make the
>> paths that are originally in the index but not in $tree untracked
>> (as opposed to "reset --hard" emulation where they will be lost)
Am 13.11.2014 um 23:40 schrieb Mike Blume:
> listed bug doesn't reproduce on Mac OS Yosemite. For now, just enable
> TTY on Yosemite and higher
>
> Signed-off-by: Mike Blume
> Improved-by: Junio C Hamano
> ---
> t/lib-terminal.sh | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
>
On Fri, Nov 14, 2014 at 08:11:18PM +0100, Johannes Sixt wrote:
> Not a comment, on this paragraph of yours, but while I was walking
> through the code with gdb, I was wondering why the reflog directory is
> being touched at all when core.logallrefupdates is off (in
> log_ref_setup via log_ref_writ
On Fri, Nov 14, 2014 at 1:29 PM, 0xAX wrote:
> When we execute git config --list and $GIT_CONFIG value starts with home
> prefix - ~/ it produces folowing error - fatal: unable to read config
> file '~/.gitconfig': No such file or directory. This patch fixed it with
> expand_user_path for configur
(+cc msysgit)
Am 13.11.2014 um 10:08 schrieb Jeff King:
> On Thu, Nov 13, 2014 at 09:50:24AM +0100, Johannes Sixt wrote:
>
>>> That looks more like it is failing the actual test (i.e., the creation
>>> of branch "one" when there is cruft in the reflog). My guess is that
>>> calling open() on a di
When we execute git config --list and $GIT_CONFIG value starts with home
prefix - ~/ it produces folowing error - fatal: unable to read config
file '~/.gitconfig': No such file or directory. This patch fixed it with
expand_user_path for configuration file path before git-config --list
call.
Signed
listed bug doesn't reproduce on Mac OS Yosemite or Mavericks. For now,
just enable TTY on Mavericks and higher
Signed-off-by: Mike Blume
Improved-by: Junio C Hamano
Signed-off-by: Junio C Hamano
Improved-by: John Szakmeister
---
t/lib-terminal.sh | 5 -
1 file changed, 4 insertions(+), 1
Git merge-file works correctly when reading files, but when trying to
write to them, it doesn't prepend current working directory. I've
attached a basic example - running "git merge-file file1 file file2"
from inside sample dir will "fail" silently and write to file1 in repo
root. Running git merge
Hello!,
I sent an email last week, but I'm not sure if I sent it incorrectly, or the
formatting was very bad, or it went unnoticed. A few days ago a great soul was
kind enough to create the --trust-exit-code option that made git respect the
exit code of the difftool. Unfortunately, I haven't been
On Thu, Nov 13, 2014 at 01:48:12PM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > I agree they are technically orthogonal, but I cannot think of a case
> > where I have ever generated actual _pathspecs_, which might have
> > wildcards, and needed to use "-z". The point of using "-z" is t
On Fri, Nov 14, 2014 at 03:39:29PM +0100, Axel Magard wrote:
> Hi folks,
> either I still didn't grasp it or there is a mistake in chapter 3.1 "3.1
> Git Branching - Branches in a Nutshell"
> (http://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell)
>
> The last figure on that page s
Olaf Hering writes:
> Even if I do a fresh clone with --bare, the result can not be updated
> anymore with git fetch. What I'm doing wrong?
A --bare clone has no connection to its origin (there are no remotes).
You want a --mirror.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fin
Hi folks,
either I still didn't grasp it or there is a mistake in chapter 3.1 "3.1
Git Branching - Branches in a Nutshell"
(http://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell)
The last figure on that page shows that branch 'master' and HEAD are
pointing to patch 87ab2, branch 't
W dniu 2014-11-13 13:03, Olaf Hering pisze:
> On Thu, Nov 13, Fredrik Gustafsson wrote:
[...]
Your setup looks familiar to me for a subversion user switching to git
and trying to use git as subversion. The common usecase is not to have
multiple worktrees but to do a checkout to the worktree you n
On Thu, Nov 13, Fredrik Gustafsson wrote:
> That's one of the reason it's not recommended to push into a non-bare
> repository. You should clone your repo-master with the --bare option to
> avoid having a work dir there.
Even if I do a fresh clone with --bare, the result can not be updated
anymor
Signed-off-by: 0xAX
---
po/ru.po | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/po/ru.po b/po/ru.po
index 5987303..0a0754d 100644
--- a/po/ru.po
+++ b/po/ru.po
@@ -863,7 +863,7 @@ msgid ""
"(discard ALL local changes)"
msgstr ""
"Жесткий: переписать индекс и рабочий катало
On Fri, Nov 14, Olaf Hering wrote:
> On Fri, Nov 14, Fredrik Gustafsson wrote:
>
> > On Fri, Nov 14, 2014 at 11:14:27AM +0100, Olaf Hering wrote:
> > > So my repo-master is now "bare". I pushed from repo-branchA into
> > > repo-master and see my commits in both repos. But pushing from
> > > repo-
On Thu, Nov 13, 2014 at 5:40 PM, Mike Blume wrote:
> listed bug doesn't reproduce on Mac OS Yosemite. For now, just enable
> TTY on Yosemite and higher
I've tried the reproduction recipe on Mavericks (`uname -r` => 13.4.0)
and it works fine--still going after 12,000 iterations. Trying the
same t
On Fri, Nov 14, Fredrik Gustafsson wrote:
> On Fri, Nov 14, 2014 at 11:14:27AM +0100, Olaf Hering wrote:
> > So my repo-master is now "bare". I pushed from repo-branchA into
> > repo-master and see my commits in both repos. But pushing from
> > repo-master to the remote fails because repo-master d
On Fri, Nov 14, 2014 at 11:14:27AM +0100, Olaf Hering wrote:
> So my repo-master is now "bare". I pushed from repo-branchA into
> repo-master and see my commits in both repos. But pushing from
> repo-master to the remote fails because repo-master does not have
> outstanding remote commits. However,
On Thu, Nov 13, Fredrik Gustafsson wrote:
> Thanks for sharing your notes! A few comments:
>
> On Thu, Nov 13, 2014 at 04:44:57PM +0100, Olaf Hering wrote:
> > First clone the remote repository as usual. Then create a local branch for
> > each remote branch that is supposed to be worked on:
> > #
On Fri, Nov 14, 2014 at 06:46:19AM +0100, Elia Pinto wrote:
> > [1] http://en.wikipedia.org/wiki/Date_and_time_representation_by_country
> > [2] http://en.wikipedia.org/wiki/Calendar_date
>
> Isn't not so good to refer to external resources in a commit message ?
It is not good to omit any expla
61 matches
Mail list logo
