On Fri, Mar 28, 2014 at 10:12:15AM -0700, Junio C Hamano wrote:
By the way, that is rfc2822---do we want rfc822 as its synonym
as well as rfc, I wonder ;-)
Oops, I wrote that as I was literally looking at the code that said
rfc2822 and didn't notice. On the other hand, I have never made the
On Fri, Mar 28, 2014 at 11:09:14AM -, Gerhard Grimm wrote:
So I examined the git source package and found that the author of the
HP-UX port forgot to set
PTHREAD_CFLAGS=-mt
in config.mak.autogen to enable threading.
You probably want to place such manual settings in config.mak. If
On Fri, Mar 28, 2014 at 12:02:46PM -0700, Junio C Hamano wrote:
- teach the is the result sane, even though we may have got a
non-NULL from gmtime? otherwise let's signal a failure by
replacing it with a known sentinel value codepath the new
failure mode Charles's report
On Fri, Mar 28, 2014 at 03:43:29PM -0400, Eric Sunshine wrote:
On Fri, Mar 28, 2014 at 3:01 PM, Jeff King p...@peff.net wrote:
On Fri, Mar 28, 2014 at 11:09:14AM -, Gerhard Grimm wrote:
git submodule init
fails with the output
Assertion failed: err == REG_ESPACE, file compat
On Mon, Mar 31, 2014 at 07:19:09PM +0200, Siggi wrote:
here are the two outputs you wanted to see.
The interesting bit is at the end...
HTTP/1.1 200 OK
Date: Mon, 31 Mar 2014 17:04:57 GMT
* Server Apache/2.2.22 (Ubuntu) is not blacklisted
Server: Apache/2.2.22 (Ubuntu)
X-Powered-By:
On Mon, Mar 31, 2014 at 11:27:53AM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
That being said, git _could_ be more liberal in accepting a content-type
with parameters (even though it does not know about any parameters, and
charset here is completely meaningless). I have
On Mon, Mar 31, 2014 at 10:23:44AM -0700, Junio C Hamano wrote:
SET_PTR() may not be used, but are there places where SET_INT() is
abused with a cast-to-pointer for the same effect? I didn't check,
but if there are such places, converting them to use SET_PTR() with
their existing cast
On Sun, Mar 30, 2014 at 10:29:04AM +0200, Andreas Schwab wrote:
Junio C Hamano gits...@pobox.com writes:
As OPT_SET_PTR() is about setting the pointer value to intptr_t defval,
a follow-up patch on top of this fix (see attached) may not be a bad
thing to have, but that patch alone will
it to a NULL (with this patch, t4212 should pass on
FreeBSD).
Reported-by: René Scharfe l@web.de
Signed-off-by: Jeff King p...@peff.net
---
There are actually a few callers to gmtime and gmtime_r, so I pushed
this fix up into a compat wrapper rather than in time_to_tm to get them
all. It's
...@bloomberg.net
Signed-off-by: Jeff King p...@peff.net
---
t/t4212-log-corrupt.sh | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/t/t4212-log-corrupt.sh b/t/t4212-log-corrupt.sh
index 3fa1715..58b792b 100755
--- a/t/t4212-log-corrupt.sh
+++ b/t/t4212-log-corrupt.sh
@@ -82,11
AIX's gmtime will happily overflow the tm_year field. Let's
catch this error before handing the value to gmtime.
Signed-off-by: Jeff King p...@peff.net
---
This is an alternative to loosening the test in t4212.
It's really not _that_ ugly. The LL here may not be portable, though.
32-bit systems
On Mon, Mar 31, 2014 at 02:48:45PM -0700, Siddharth Agarwal wrote:
On 03/28/2014 03:00 AM, Jeff King wrote:
From: Vicent Marti tan...@gmail.com
When pack-objects is computing the reachability bitmap to serve a
fetch request, it can erroneously die() if some of the UNINTERESTING
objects
On Tue, Apr 01, 2014 at 07:25:54PM +0900, Mike Hommey wrote:
I am currently prototyping a native mercurial remote handler for git,
For my own curiosity, how does this differ from what is in
contrib/remote-helpers/git-remote-hg?
Would adding a fast-import command to handle deltas be considered
On Tue, Apr 01, 2014 at 12:49:00PM +0200, rocketscienc01100101 . wrote:
I tried to get a diff between HEAD and the current version of my
project, so I did git diff.
That actually diffs between the index and the working tree, but if you
haven't used git add to add any changes, the index content
On Tue, Apr 01, 2014 at 10:07:03PM +0900, Mike Hommey wrote:
For my own curiosity, how does this differ from what is in
contrib/remote-helpers/git-remote-hg?
contrib/remote-helpers/git-remote-hg does a local mercurial clone before
doing the git conversion. While this is not really a
On Tue, Apr 01, 2014 at 12:07:22PM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
On Fri, Mar 28, 2014 at 12:30:02PM -0700, Junio C Hamano wrote:
Let's just deal with a simple known cases (like FreeBSD) in the real
code that everybody exercises at runtime, and have
On Tue, Apr 01, 2014 at 05:58:09PM +0200, Michael Haggerty wrote:
When deleting a reference, it might be that another process already
holds the lock on the loose reference file and/or the packed-refs
file. In those cases, there is no alternative but for the delete to
fail. Verify that in
On Tue, Apr 01, 2014 at 05:58:12PM +0200, Michael Haggerty wrote:
When rolling back the lockfile, call close_lock_file() so that the
lock_file's fd field gets set back to -1. This could help prevent
confusion in the face of hypothetical future programming errors.
This also solves a race. We
On Tue, Apr 01, 2014 at 05:58:13PM +0200, Michael Haggerty wrote:
If the call to adjust_shared_perm() fails, lock_file returns -1, which
to the caller looks like any other failure to lock the file. So in
this case, roll back the lockfile before returning so that the lock
file is deleted
On Tue, Apr 01, 2014 at 05:58:10PM +0200, Michael Haggerty wrote:
By the time the if block is entered, the lock_file instance from the
main function block is no longer in use, so re-use that one instead of
allocating a second one.
Note that the lock variable in the if block used to shadow
On Tue, Apr 01, 2014 at 04:02:42PM -0400, Jeff King wrote:
On Tue, Apr 01, 2014 at 05:58:13PM +0200, Michael Haggerty wrote:
If the call to adjust_shared_perm() fails, lock_file returns -1, which
to the caller looks like any other failure to lock the file. So in
this case, roll back
On Tue, Apr 01, 2014 at 05:58:15PM +0200, Michael Haggerty wrote:
diff --git a/lockfile.c b/lockfile.c
index e679e4c..c989f6c 100644
--- a/lockfile.c
+++ b/lockfile.c
@@ -130,6 +130,22 @@ static int lock_file(struct lock_file *lk, const char
*path, int flags)
*/
static const
On Tue, Apr 01, 2014 at 05:58:17PM +0200, Michael Haggerty wrote:
+unable_to_lock_error::
+
+ Emit an error describing that there was an error locking the
+ specified path. The err parameter should be the errno of the
+ problem that caused the failure.
+
On Tue, Apr 01, 2014 at 05:58:20PM +0200, Michael Haggerty wrote:
It's bad manners. Especially since, if unlink_or_warn() failed, the
memory wasn't restored to its original contents.
So make our own copy to work with.
Sounds good...
if (!(flag REF_ISPACKED) || flag REF_ISSYMREF)
On Tue, Apr 01, 2014 at 05:58:22PM +0200, Michael Haggerty wrote:
/*
- * p = path that may be a symlink
- * s = full size of p
- *
- * If p is a symlink, attempt to overwrite p with a path to the real
- * file or directory (which may or may not exist), following a chain of
- * symlinks if
On Tue, Apr 01, 2014 at 05:58:30PM +0200, Michael Haggerty wrote:
Add a new option flag, LOCK_SEPARATE_STAGING_FILE, that can be passed
to hold_lock_file_for_update() or hold_lock_file_for_append() to use a
staging file that is independent of the lock file.
Add a new function
On Tue, Apr 01, 2014 at 05:58:08PM +0200, Michael Haggerty wrote:
I've had this patch series kicking around for a long time, along with
some followup patches to fix a race in reference deletion. I haven't
had the time to get everything done and tested, but let me at least
push this first
an error (and this behavior is specified by ANSI C
and POSIX). FreeBSD's implementation, however, will simply
leave the struct tm untouched. Let's also recognize this
and convert it to a NULL (with this patch, t4212 should pass
on FreeBSD).
Reported-by: René Scharfe l@web.de
Signed-off-by: Jeff King
the objects defeats the purpose of the
optimization, which is to do as little work as possible
to get the bytes to the remote.
Signed-off-by: Jeff King p...@peff.net
---
I happened to be fooling around with git v1.4.0 today, and noticed a
problem fetching from GitHub. Pre-OFS_DELTA git versions
On Wed, Apr 02, 2014 at 08:52:17AM +0200, Torsten Bögershausen wrote:
+ /*
+ * loose. The loose file name is the same as the
+ * lockfile name, minus .lock:
+ */
+ char *loose_filename = xmemdupz(lock-lk-filename,
+
On Wed, Apr 02, 2014 at 10:39:13AM -0700, Junio C Hamano wrote:
However, it's possible that the other side cannot read our
packfile verbatim. For example, we may have objects stored
as OFS_DELTA, but the client is an antique version of git
that only understands REF_DELTA. We negotiate
On Fri, Apr 04, 2014 at 03:28:48PM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
We could convert OFS_DELTA to REF_DELTA on the fly. That _may_ have a
performance impact. Right now, we are basically doing the equivalent of
sendfile(), and conversion would involve iterating
On Sun, Apr 06, 2014 at 11:54:59PM +0200, Michael Haggerty wrote:
I didn't reproduce it experimentally, though. We should be able to just
lk-owner = 0;
before the initial strcpy to fix it, I would think.
I think that using the owner field to avoid this problem is a bit
On Mon, Apr 07, 2014 at 01:33:43AM +0200, Michael Haggerty wrote:
+unable_to_lock_error::
+
+ Emit an error describing that there was an error locking the
+ specified path. The err parameter should be the errno of the
+ problem that caused the failure.
+
+unable_to_lock_die::
On Mon, Apr 07, 2014 at 01:33:44AM +0200, Michael Haggerty wrote:
This function is used for other things besides the index, so rename it
accordingly.
Oh, and here it is. I should really have just read ahead before
responding to patch 1.
We can either re-order these first two, or just not
On Mon, Apr 07, 2014 at 01:33:59AM +0200, Michael Haggerty wrote:
It was previously a bug to call commit_lock_file() with a lock_file
object that was not active (an illegal access would happen within the
function). It was presumably never done, but this would be an easy
programming error to
On Mon, Apr 07, 2014 at 03:12:49PM +0200, Michael Haggerty wrote:
How far *do* you want to go? I'm certainly not opposed to field-test your
current changeset (plus and adjustment to use sig_atomic_t) -- overall it
is an improvement. And then we will see how it works.
For now I think I'd
On Mon, Apr 07, 2014 at 01:33:42AM +0200, Michael Haggerty wrote:
This is a second attempt at renovating the lock file code. Thanks to
Peff, Junio, Torsten, and Eric for their helpful reviews of v1.
v1 of this patch series [1] did some refactoring and then added a new
feature to the
On Mon, Apr 07, 2014 at 01:47:14AM +0300, Dragos Foianu wrote:
The git describe --contains command uses the name_rev() function which
is currently a recursive function. This causes a Stack Overflow when the
history is large enough.
Rewrite name_rev iteratively using a stack on the heap.
On Tue, Apr 08, 2014 at 11:22:44AM -0700, K. Kwan wrote:
My tree would look like this:
- x - x - x (master)
\ x - x (A) x - x (B)
But after merge of branch (A), I would like it to look like this:
- x - x - x x (master)
\/ \
x - x (A) x - x (B)
On Thu, Apr 10, 2014 at 05:36:59PM -0500, Felipe Contreras wrote:
I noticed that this only picks up a publish-branch if
branch.*.pushremote is configured. What happened to the case when
remote.pushdefault is configured?
What happens when branch.*.remote is not configured for @{upstream}?
On Thu, Apr 10, 2014 at 10:24:24AM +1000, Andrew Ardill wrote:
It's normal for an organisation to have a collection of logos to
choose from, with one 'official' version. For example, a black and
white version is useful for print. Similarly, it's useful to have a
couple of different contrast
On Fri, Apr 11, 2014 at 01:24:02AM -0700, Kyle J. McKay wrote:
Since 11502468 and 04c1ee57 (both first appearing in v1.8.5), the
t7001-mv test has used cp -a to perform a copy in several of the
tests.
However, the -a option is not required for a POSIX cp utility and
some platforms' cp
On Fri, Apr 11, 2014 at 08:48:01AM -0500, Felipe Contreras wrote:
I think of @{publish} as the branch the user has configured to push
to; it overrides all other configurations (push.default and push
refspecs). I wouldn't mind having a @{push} *in addition* to @{publish}
that would have the
On Fri, Apr 11, 2014 at 12:24:35PM -0700, Junio C Hamano wrote:
But the branch.master.push setting does not do
anything to git push.
I am not sure I understand this. I thought that the desire behind
the branch.*.push is to allow something like:
... other things in the config ...
On Fri, Apr 11, 2014 at 12:25:17PM -0700, Junio C Hamano wrote:
The mention of dev.git-scm.com gives me a mixed feeling. The
chasm between the developer community and casual end-users who know
about Git primarily via their perusal of git-scm.com is one of the
root causes of this confusion.
On Fri, Apr 11, 2014 at 08:24:48AM -0500, Felipe Contreras wrote:
I would actually like you (everyone) to be honest and answer this
question;
Have you actually analized the logo? Or are you just arguing against
change, because the logo is already used by git-scm.com, and related
stuff?
Is
On Sat, Apr 12, 2014 at 09:12:57AM -0400, Jason Pyeron wrote:
Is it me or is the only way to clear a single invalid password out of the
credential-cache is by git credential-cache exit?
Try the reject action:
$ : remember a credential
$ url() { echo url=https://example.com; }
$ (url;
On Sat, Apr 12, 2014 at 10:05:15AM -0500, Felipe Contreras wrote:
As you can see; some branches are published, others are not. The ones that are
not published don't have a @{publish}, and `git branch -v` doesn't show them.
Why is that hard to understand?
Do you ever push the unpublished
On Wed, Apr 16, 2014 at 04:13:53PM +0200, Stepan Kasal wrote:
Date: Thu, 10 Apr 2014 16:37:15 +0200
This change fixes a gcc warning when building msysGit.
What warning? I'm assuming -Wuninitialized?
diff --git a/config.c b/config.c
index 314d8ee..0b7e4f8 100644
--- a/config.c
+++
On Wed, Apr 16, 2014 at 04:15:19PM +0200, Stepan Kasal wrote:
From: Jean-Jacques Lafay jeanjacques.la...@gmail.com
Date: Sat, 10 Nov 2012 18:36:10 +0100
In large repos, the recursion implementation of contains(commit,
commit_list) may result in a stack overflow. Replace the recursion with
On Thu, Apr 17, 2014 at 07:31:54PM +0200, Johannes Schindelin wrote:
bash -c ulimit -s 64 git tag --contains HEAD actual
[...]
Please see https://github.com/msysgit/git/c63d196 for the fixup, and
https://github.com/msysgit/git/compare/tag-contains%5E...tag-contains for
the updated
On Thu, Apr 17, 2014 at 11:52:56PM +0200, Johannes Schindelin wrote:
I tried running the test on my Linux box, but it doesn't fail with the
existing recursive code.
I cannot recall how I came to choose 64, but I *think* I only tested on
Windows, and I *think* I reduced the number of tags
On Thu, Apr 17, 2014 at 10:04:52AM -0700, Junio C Hamano wrote:
Commit A can be described in terms of both v3.4 and v9.0, and it may
be closer to v9.0 than v3.4, and under that definition we pick the
closest tag, the current describe --contains behaviour may be
correct, but from the human
It's possible to overflow an array in run_external_diff and write a
single NULL onto the stack. The first patch below fixes that. The rest
are cleanups and modernizations I noticed while in the area. It's
possible that patch 3 is also a bug fix, depending on your
interpretation.
[1/6]:
this sort of error impossible.
Noticed-by: Max L infthi.in...@gmail.com
Signed-off-by: Jeff King p...@peff.net
---
This was actually noticed by a GitHub user, who proposed bumping
the array size to 11:
https://github.com/git/git/pull/92
Even though this fix is a bigger change, I'd rather do
We currently use static buffers and a static array for
formatting the environment passed to the external diff.
There's nothing wrong in the code, but it is much easier to
verify that it is correct if we use a dynamic argv_array.
Signed-off-by: Jeff King p...@peff.net
---
diff.c | 14
, but there were differences.
And while we're there, we can mark the error message for
translation, and drop the full stop at the end to make it
more like our other messages.
Signed-off-by: Jeff King p...@peff.net
---
Note that we do have to update one test, which was expecting difftool to
exit with 1
,
meaning that our flush here is redundant.
Signed-off-by: Jeff King p...@peff.net
---
diff.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/diff.c b/diff.c
index b517d01..fdb7f6c 100644
--- a/diff.c
+++ b/diff.c
@@ -2928,7 +2928,6 @@ static void run_external_diff(const char *pgm
Whether we have diff_filespecs to give to the diff command
or not, we always are going to run the program and pass it
the pathname. Let's pull that duplicated part out of the
conditional to make it more obvious.
Signed-off-by: Jeff King p...@peff.net
---
diff.c | 8 +++-
1 file changed, 3
The current logic makes it hard to see what gets put onto
the command line in which cases. Pulling out a helper
function lets us see that we have two sets of file data, and
the second set either uses the original name, or the other
renamed/copy name.
Signed-off-by: Jeff King p...@peff.net
On Sun, Apr 20, 2014 at 02:09:49AM +0400, Max L wrote:
One more note: at this moment the problem is slightly deeper. This
array is next passed to the execvp function, which now falls with
EFAULT on two my machines (both faced this problem after upgrading to
ubuntu 14.04, everything 'worked'
On Sun, Apr 20, 2014 at 04:58:28PM +0700, Duy Nguyen wrote:
- --color-words within unified diff format, using background color to
show what part of the line has changed. This is only enabled for
1-line changes.
See contrib/diff-highlight.
-Peff
--
To unsubscribe from this list: send the line
On Mon, Apr 21, 2014 at 03:07:28PM -0400, Richard Hansen wrote:
Both bash and zsh subject the value of PS1 to parameter expansion,
command substitution, and arithmetic expansion. Rather than include
the raw, unescaped branch name in PS1 when running in two- or
three-argument mode, construct
On Tue, Apr 22, 2014 at 04:59:17PM +0700, Duy Nguyen wrote:
On Sun, Apr 20, 2014 at 9:46 PM, Jeff King p...@peff.net wrote:
On Sun, Apr 20, 2014 at 04:58:28PM +0700, Duy Nguyen wrote:
- --color-words within unified diff format, using background color to
show what part of the line has
On Tue, Apr 22, 2014 at 03:53:02PM -0700, Kyle J. McKay wrote:
So I was trying to use pack.writebitmaps=true and all I got was core dumps.
Eek.
The fix with a real subject line ;) is below. I think perhaps this should be
picked up for the 2.0.0 release. (Patch is against master.)
Yes,
On Tue, Apr 22, 2014 at 05:58:10PM +1000, Bryan Turner wrote:
It looks like the documentation for bitmaps is being included in the
1.9.2 release of Git for Windows but the functionality itself is not
present. For example, doc\git\html\git-config.html includes settings
like these:
On Sun, Apr 20, 2014 at 08:42:15PM -0400, Greg M wrote:
Using git version 1.9.2 I am getting this error:
[normal@laptop tmp]$ git clone https://github.com/mozilla/rust.git
Cloning into 'rust'...
remote: Reusing existing pack: 296648, done.
remote: Counting objects: 80, done.
remote:
On Wed, Apr 23, 2014 at 12:12:14PM -0700, Junio C Hamano wrote:
+ulimit_stack=ulimit -s 64
+test_lazy_prereq ULIMIT 'bash -c '$ulimit_stack''
With this implementaion, ULIMIT implies bash, and we use bash that
appears on user's PATH that may not be the one the user chose to run
git with.
On Wed, Apr 23, 2014 at 09:53:25AM +0200, Stepan Kasal wrote:
I have found out that ulimit -s does not work on Windows.
Adding this as a prerequisite, we will skip the test there.
I found this bit weird, as the test originated on Windows. Did it never
actually cause a failure there (i.e., the
On Wed, Apr 23, 2014 at 02:42:38PM -0500, Felipe Contreras wrote:
It is what the clients of this library expect.
Is it? Passing GIT_DIR to sub-invocations of git will change how they
determine the repo and working tree. Your patch seems to cause failures
all over the test suite.
Without
On Wed, Apr 23, 2014 at 02:59:26PM -0500, Robert Dailey wrote:
I referred back to the documentation for --decorate:
--decorate[=short|full|no]
Print out the ref names of any commits that are shown. If short is
specified, the ref name prefixesrefs/heads/, refs/tags/ and
refs/remotes/ will
On Wed, Apr 23, 2014 at 01:48:05PM -0700, Junio C Hamano wrote:
I don't think so. The point is that we _must_ use bash here, not any
POSIX shell.
Sorry, but I do not understand. Isn't what you want any POSIX
shell with 'ulimit -s 64' supported?
Sure, that would be fine, but the original
On Wed, Apr 23, 2014 at 07:49:09AM -0400, Greg M wrote:
The easiest way to find it is probably to attach a debugger to the
running git-remote-https, and get a backtrace when it dies from SIGPIPE.
You'll probably want to install your system's debug packages for curl,
too.
The
have a fully qualified hostname.
No, we alway warn if the values weren't explicitly provided:
$ git config --global --unset user.email
$ git commit --allow-empty -m foo
[master 1e987ba] foo
Committer: Jeff King p...@sigill.intra.peff.net
Your name and email address were configured
On Thu, Apr 24, 2014 at 12:29:21PM -0700, Junio C Hamano wrote:
David Kastrup d...@gnu.org writes:
Junio C Hamano gits...@pobox.com writes:
Traditionally, because the tool grew in a context of being used in a
project whose participants are at least not malicious, always having
to be
On Thu, Apr 24, 2014 at 02:47:01PM -0700, Junio C Hamano wrote:
And I do agree that the chopped marker would be a very sensible
thing to show in the -S output; I would have chosen $ myself for
that to match an existing practice in (setq truncate-lines t) in
Emacs, though.
Hmm. I do not use
On Thu, Apr 24, 2014 at 11:48:30PM +0200, David Kastrup wrote:
I really think the right solution here is to teach less to make it more
obvious that there is something worth scrolling over to. Here's a very
rough patch for less, if you want to see what I'm thinking of.
Still useless. I'm
On Thu, Apr 24, 2014 at 02:24:39PM +0200, Stepan Kasal wrote:
From: Jean-Jacques Lafay jeanjacques.la...@gmail.com
In large repos, the recursion implementation of contains(commit,
commit_list) may result in a stack overflow. Replace the recursion with
a loop to fix it.
This problem is
On Fri, Apr 25, 2014 at 12:45:27PM -0500, Felipe Contreras wrote:
When I say literally everbody agreed to move away from the name index
(except
Junio and another guy) I mean it. I even composed a list:
http://article.gmane.org/gmane.comp.version-control.git/233469
Jeff King, Jonathan
On Fri, Apr 25, 2014 at 01:27:17PM -0500, Felipe Contreras wrote:
I specifically said everybody agreed to move away from the name 'index', I
didn't say everybody agreed on the staged area although the vast majority
did, and I didn't say anybody agreed on my patches, although some did.
I
On Fri, Apr 25, 2014 at 01:57:59PM -0500, Felipe Contreras wrote:
Maybe I was not clear in my response, so let me try again. I do _not_
necessarily agree that we need to move away from the name index.
So you agree that the index is a bad name, and you agree staging area is a
better name,
-off-by: Jeff King p...@peff.net
---
I care most about the rebase -i thing, especially because it is the
primary method for fixing old mistakes. The segfault fix is a nice
bonus.
The git commit -C empty -m foo thing might be nice, but I don't plan
to work on it further. The semantics would need
On Fri, Apr 25, 2014 at 03:50:26PM -0700, Junio C Hamano wrote:
* jk/external-diff-use-argv-array (2014-04-21) 6 commits
(merged to 'next' on 2014-04-22 at e6d92d7)
+ run_external_diff: refactor cmdline setup logic
+ run_external_diff: hoist common bits out of conditional
+
On Fri, Apr 25, 2014 at 08:36:55PM -0500, Felipe Contreras wrote:
As for the patches themselves, I have not reviewed them carefully, and
would prefer not to. As I mentioned before, though, I would prefer the
short @{p} not be taken for @{publish} until it has proven itself.
Presumably
[+cc Duy, whose patch this is]
On Fri, Apr 25, 2014 at 04:10:49PM -0400, Jörn Engel wrote:
A second option is to add a --pager (or rather --no-pager) option to
the command line and allow the user to specify
GIT_PAGER=git --no-pager -p column --mode='dense color' git -p branch
I think we
On Sat, Apr 26, 2014 at 02:56:15PM +1000, nod.h...@gmail.com wrote:
contrib/subtree/Makefile is a shambles in regards to it's consistency
with other makefiles, which makes subtree overly painful to include in
build scripts.
Two major issues are present:
Firstly, calls to git itself
[+cc Duy for real this time]
On Sat, Apr 26, 2014 at 10:27:07AM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
[+cc Duy, whose patch this is]
On Fri, Apr 25, 2014 at 04:10:49PM -0400, Jörn Engel wrote:
A second option is to add a --pager (or rather --no-pager) option
On Sat, Apr 26, 2014 at 10:24:50AM -0700, Junio C Hamano wrote:
Suvorov Ivan sv...@inbox.ru writes:
I want to extend the functionality of git due to the possibility of
separation of the user repository into 2 parts - one part will be
stored as usual, under version control git, and the
On Sat, Apr 26, 2014 at 10:50:26AM -0700, Dan Albert wrote:
git-imap-send was directly prompting for a password rather than using
git-credential. git-send-email, on the other hand, supports
git-credential.
Yay. These sorts of conversions were definitely on my mind when I did
the original
On Sun, Apr 27, 2014 at 12:35:13PM +1000, James Denholm wrote:
Do we even make [subproject and mainline] anymore? It looks like they are
part
of the tests, but the whole test script runs inside its own trash
directory.
subproject and mainline are actually made in contrib/subtree,
but
On Sat, Apr 26, 2014 at 11:30:11AM -0700, Dan Albert wrote:
I had resent a less broken patch after I noticed the tabs, but it seems to
have gotten lost. Better formatted patch at the bottom of this message.
Your emails (including this one) are multipart/alternatives with an html
part, which
On Sun, Apr 27, 2014 at 09:12:39AM +0700, Duy Nguyen wrote:
The intent of the commit was that is a stupid thing to do, but it's
not so obvious from the first glance, do not freeze my system for my
mistake. But if it stops an actual use case, then I agree it should
be reverted.
Thanks for the
the precomposed/decomposed forms. We already do
something similar for case-insensitive files using
name-hash.c. We might be able to adapt that strategy
here.
Signed-off-by: Jeff King p...@peff.net
---
t/t3910-mac-os-precompose.sh | 10 ++
1 file changed, 10 insertions(+)
diff
On Mon, Apr 28, 2014 at 02:22:21PM +0200, Matthieu Moy wrote:
Not since f82c3ffd862c7 (Wed Feb 5 2014, move LESS/LV pager environment
to Makefile).
The only upstream branch containing this commit is pu. So this patch
should likely not go anywhere else for now.
Oops, indeed, I made
On Mon, Apr 28, 2014 at 09:43:10AM -0700, Junio C Hamano wrote:
Yes, I'd love to see something along that line in the longer term,
showing all the objects as just regular objects under the hood, with
implementation details hidden in the object layer (just like there
is no distinction between
On Sun, Apr 27, 2014 at 10:58:51AM -0700, Dan Albert wrote:
git-imap-send was directly prompting for a password rather than using
git-credential. git-send-email, on the other hand, supports git-credential.
This is a necessary improvement for users that use two factor authentication,
as
On Mon, Apr 28, 2014 at 12:17:28PM -0700, Junio C Hamano wrote:
3. Convert index filenames to their precomposed form when
we read the index from disk. This would be efficient,
but we would have to be careful not to write the
precomposed forms back out to disk.
I think
On Mon, Apr 28, 2014 at 10:48:21AM -0700, Junio C Hamano wrote:
diff --git a/diff.c b/diff.c
index 54d5308..a03744b 100644
--- a/diff.c
+++ b/diff.c
@@ -2894,7 +2894,7 @@ static void run_external_diff(const char *pgm,
int complete_rewrite,
On Mon, Apr 28, 2014 at 09:52:07PM +0200, Torsten Bögershausen wrote:
To my knowledge repos with decomposed unicode should be rare in
practice. I only can speak for european (or latin based) or cyrillic
languages myself:
I've run across several cases in the past few months, but only just
501 - 600 of 13736 matches
Mail list logo
