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
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:
# git
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, git
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 does not
On Thu, Nov 13, 2014 at 5:40 PM, Mike Blume blume.m...@gmail.com 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.
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-master to the
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
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
Olaf Hering o...@aepfle.de 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,
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 shows
On Thu, Nov 13, 2014 at 01:48:12PM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net 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
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
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
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 blume.m...@gmail.com
Improved-by: Junio C Hamano gits...@pobox.com
Signed-off-by: Junio C Hamano gits...@pobox.com
Improved-by: John Szakmeister
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.
(+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 directory is
On Fri, Nov 14, 2014 at 1:29 PM, 0xAX kuleshovm...@gmail.com 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
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_write).
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 blume.m...@gmail.com
Improved-by: Junio C Hamano gits...@pobox.com
---
t/lib-terminal.sh | 5 -
1 file changed, 4
David Aguilar dav...@gmail.com 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
On Fri, Nov 14, 2014 at 02:19:41PM -0500, Eric Sunshine wrote:
On Fri, Nov 14, 2014 at 1:29 PM, 0xAX kuleshovm...@gmail.com 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
Mike Blume blume.m...@gmail.com 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
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 leaking the
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 j...@kdbg.org wrote:
Am 13.11.2014 um 23:40 schrieb Mike Blume:
listed bug
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 the
Johannes Sixt j...@kdbg.org 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
Right, I missed that there was more going on above, thanks =)
On Fri, Nov 14, 2014 at 12:02 PM, Jeff King p...@peff.net 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
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 ~
before
0xAX kuleshovm...@gmail.com 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
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
Jeff King p...@peff.net 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
Mike Blume blume.m...@gmail.com 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
Jeff King p...@peff.net writes:
On Thu, Nov 13, 2014 at 01:48:12PM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net 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
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 was
Johannes Sixt j...@kdbg.org 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,
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 the
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 dav...@gmail.com
---
David Aguilar dav...@gmail.com 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
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.
Sorry
On Fri, Nov 14, 2014 at 01:51:39PM -0800, Junio C Hamano wrote:
David Aguilar dav...@gmail.com 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
Jeff King p...@peff.net 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
Manzur Mukhitdinov manzu...@gmail.com writes:
When object is replaced with itself git shows unhelpful messages like(git
log):
fatal: replace depth too high for object SHA1
Prevents user from replacing object with itself(with test for checking
this case).
Signed-off-by: Manzur
Brodie Rao bro...@sf.io 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
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
Jonathan Nieder jrnie...@gmail.com 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
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:
On Fri, Nov 14, 2014 at 6:21 PM, Jonathan Nieder jrnie...@gmail.com 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
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
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,
On 15 November 2014 10:01, Junio C Hamano gits...@pobox.com 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
$ 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
On 11/13/2014 01:22 PM, Duy Nguyen wrote:
On Thu, Nov 13, 2014 at 12:05 PM, Torsten Bögershausen tbo...@web.de 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 that
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
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 mhag...@alum.mit.edu
---
config.c | 12 ++--
1 file changed, 10 insertions(+), 2
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 wild.
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 mhag...@alum.mit.edu
---
config.c | 12
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 Haggerty
Michael Haggerty mhag...@alum.mit.edu 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 normalper...@yhbt.net
Since the
58 matches
Mail list logo
