On Mon, Sep 22, 2014 at 05:10:08PM -0400, Eric Sunshine wrote:
On Mon, Sep 22, 2014 at 1:41 PM, Junio C Hamano gits...@pobox.com wrote:
Eric Sunshine sunsh...@sunshineco.com writes:
The just-released Apple Xcode 6.0.1 has -Wstring-plus-int enabled by
default which complains about pointer
On Mon, Sep 22, 2014 at 11:04 PM, Jeff King p...@peff.net wrote:
I don't mind silencing this one warning (even though I find it a little
ridiculous). I'm slightly concerned that more brain-damage may be coming
our way, but we can deal with that if it ever does.
Like Junio, I prefer keeping
English grammar with German words doesn't make it a German translation. ;)
We also need to fix the
Signed-off-by: Stefan Beller stefanbel...@gmail.com
---
po/de.po | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/po/de.po b/po/de.po
index e5d2b25..bae3723 100644
---
Hi Michael,
On Mon, Sep 22, 2014 at 4:01 PM, Michael S. Tsirkin m...@redhat.com wrote:
Hi Junio, Christian,
it's been a while.
I see that the work on trailers is going on.
I tried going over the documentation but I could not figure
out how would one implement multiple signatures using the
I've found what looks like a bug wherein if you are using an ssh alias
for a git remote, and that remote has a dash in its name, and you
specify the target path as the name of the url itself, git complains
about refs not being valid packed references.
To reproduce, in git 2.1.0 and with a
On Mon, Sep 22, 2014 at 11:26:14PM -0700, Junio C Hamano wrote:
On Mon, Sep 22, 2014 at 11:04 PM, Jeff King p...@peff.net wrote:
I don't mind silencing this one warning (even though I find it a little
ridiculous). I'm slightly concerned that more brain-damage may be coming
our way, but
On Tue, Sep 23, 2014 at 2:04 AM, Jeff King p...@peff.net wrote:
On Mon, Sep 22, 2014 at 05:10:08PM -0400, Eric Sunshine wrote:
On Mon, Sep 22, 2014 at 1:41 PM, Junio C Hamano gits...@pobox.com wrote:
Eric Sunshine sunsh...@sunshineco.com writes:
The just-released Apple Xcode 6.0.1 has
On Tue, Sep 23, 2014 at 2:26 AM, Junio C Hamano gits...@pobox.com wrote:
On Mon, Sep 22, 2014 at 11:04 PM, Jeff King p...@peff.net wrote:
I don't mind silencing this one warning (even though I find it a little
ridiculous). I'm slightly concerned that more brain-damage may be coming
our way,
On Tue, Sep 23, 2014 at 09:45:50AM +0200, Christian Couder wrote:
Hi Michael,
On Mon, Sep 22, 2014 at 4:01 PM, Michael S. Tsirkin m...@redhat.com wrote:
Hi Junio, Christian,
it's been a while.
I see that the work on trailers is going on.
I tried going over the documentation but I
On Tue, Sep 23, 2014 at 3:51 AM, Jeff King p...@peff.net wrote:
On Mon, Sep 22, 2014 at 11:26:14PM -0700, Junio C Hamano wrote:
On Mon, Sep 22, 2014 at 11:04 PM, Jeff King p...@peff.net wrote:
I don't mind silencing this one warning (even though I find it a little
ridiculous). I'm
On Tue, Sep 23, 2014 at 3:37 AM, Stefan Beller stefanbel...@gmail.com wrote:
English grammar with German words doesn't make it a German translation. ;)
We also need to fix the
Sentence fragment.
Signed-off-by: Stefan Beller stefanbel...@gmail.com
---
po/de.po | 8
1 file changed,
On Tue, Sep 23, 2014 at 03:52:21AM -0400, Eric Sunshine wrote:
That is my reading from the warning text, too, but I have to wonder:
wouldn't that mean they should be warning about pointer + pointer, not
pointer + int?
'pointer + pointer' is not legal C, is it? What would the result
On Tue, Sep 23, 2014 at 04:49:55PM +0900, Chris Salzberg wrote:
I've found what looks like a bug wherein if you are using an ssh alias
for a git remote, and that remote has a dash in its name, and you
specify the target path as the name of the url itself, git complains
about refs not being
On 23.09.2014 10:06, Eric Sunshine wrote:
On Tue, Sep 23, 2014 at 3:37 AM, Stefan Beller stefanbel...@gmail.com wrote:
English grammar with German words doesn't make it a German translation. ;)
We also need to fix the
Sentence fragment.
Yeah, originally I intended to just fix the singular
Junio C Hamano gits...@pobox.com writes:
Sergey Organov sorga...@gmail.com writes:
Vanilla git rebase defaults to --fork-point that in some cases
makes behavior very different from git rebase upstream,
where --no-fork-point is assumed. This fact was not mentioned in
the DESCRIPTION section
On Tue, Sep 23, 2014 at 04:20:55AM +1000, Steven Lawler wrote:
Cause:
[remote repo]
url = http://example.com/git/example.com?foo=bar
There is a question mark in the URL of the repo URL.
Is the question mark there because it is separating query parameters
from the path, or is ?foo=bar part
Hi,
#: builtin/describe.c:395
msgid find the tag that comes after the commit
-msgstr findet das Tag, das nach Commit kommt
+msgstr das Tag finden, das nach Commit kommt
das Tag finden, das nach dem Commit kommt
#: builtin/fast-export.c:718
msgid Use the done feature to terminate
2014-09-23 10:43 GMT+02:00 Stefan Beller stefanbel...@gmail.com:
On 23.09.2014 10:06, Eric Sunshine wrote:
On Tue, Sep 23, 2014 at 3:37 AM, Stefan Beller stefanbel...@gmail.com
wrote:
English grammar with German words doesn't make it a German translation. ;)
We also need to fix the
On 09/17/2014 12:19 AM, Jonathan Nieder wrote:
Michael Haggerty wrote:
If closing an open lockfile fails, then we cannot be sure of the
contents of the lockfile
Is that true? It seems more like a bug in close_lock_file: if it
fails, perhaps it should either set lk-fd back to fd or unlink
On 09/17/2014 12:22 AM, Jonathan Nieder wrote:
Michael Haggerty wrote:
If rename() fails, call rollback_lock_file() to delete the lock file
(in case it is still present) and reset the filename field to the
empty string so that the lockfile object is left in a valid state.
Can you spell
Hi,
this patch added a comma before the um. See:
http://www.duden.de/sprachwissen/rechtschreibregeln/komma#K117
Phillip
Signed-off-by: Phillip Sz phillip.sze...@gmail.com
---
po/de.po | 86
1 file changed, 43 insertions(+), 43
But if I type just 'make', I don't see how it will know where my ARM
toolchain is. I'll read the INSTALL file in the meantime.
On Mon, Sep 22, 2014 at 4:22 PM, Stefan Beller stefanbel...@gmail.com wrote:
On 22.09.2014 21:04, Robert Dailey wrote:
I run the following on Ubuntu:
On Tue, Sep 23, 2014 at 7:47 AM, Robert Dailey rcdailey.li...@gmail.com wrote:
But if I type just 'make', I don't see how it will know where my ARM
toolchain is. I'll read the INSTALL file in the meantime.
Sorry for top post earlier, my mistake.
I reviewed the INSTALL file. It doesn't mention
English grammar with German words doesn't make it a German translation. ;)
Signed-off-by: Stefan Beller stefanbel...@gmail.com
---
Here we go again without sentence fragments.
Thanks,
Stefan
po/de.po | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/po/de.po
On 09/17/2014 12:23 AM, Jonathan Nieder wrote:
Michael Haggerty wrote:
* Document the behavior of commit_lock_file() when it fails, namely
that it rolls back the lock_file object and sets errno
appropriately.
* Document the behavior of rollback_lock_file() when called for a
On 09/17/2014 12:28 AM, Jonathan Nieder wrote:
Michael Haggerty wrote:
After commit_lock_file() is called, then the lock_file object is
necessarily either committed or rolled back. So there is no need to
call rollback_lock_file() again in either of these cases.
Signed-off-by: Michael
On 09/17/2014 12:45 AM, Jonathan Nieder wrote:
Michael Haggerty wrote:
We could probably continue to use the filename field to encode the
state by being careful to write characters 1..N-1 of the filename
first, and then overwrite the NUL at filename[0] with the first
character of the
Commented code, which doesn't even compile, is of no use any more?
Signed-off-by: Stefan Beller stefanbel...@gmail.com
---
To be applied on top of sb/merge-recursive-copy-paste-fix
merge-recursive.c | 4
1 file changed, 4 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
Am 23. September 2014 14:00 schrieb Phillip Sz phillip.sze...@gmail.com:
Hi,
this patch added a comma before the um. See:
http://www.duden.de/sprachwissen/rechtschreibregeln/komma#K117
Thanks!
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to
Doing so means that we do not actually get to see bogus
modes; they are converted into one of our known-good modes
by decode_tree_entry. We want to see the raw data so that we
can complain about it.
Signed-off-by: Jeff King p...@peff.net
---
As far as I can tell, fsck's mode-checking has been
On Sat, Sep 20, 2014 at 08:18:59PM +0200, Andreas Schwab wrote:
Stepan Kasal ka...@ucw.cz writes:
diff --git a/t/t7004-tag.sh b/t/t7004-tag.sh
index 143a8ea..a911df0 100755
--- a/t/t7004-tag.sh
+++ b/t/t7004-tag.sh
@@ -1423,4 +1423,30 @@ EOF
test_cmp expect actual
'
On Tue, Sep 23, 2014 at 07:47:11AM -0500, Robert Dailey wrote:
But if I type just 'make', I don't see how it will know where my ARM
toolchain is. I'll read the INSTALL file in the meantime.
It won't. If you are cross-compiling you'll have to specify CC and LD
manually, plus a host of other
On Tue, Sep 23, 2014 at 07:52:32AM -0500, Robert Dailey wrote:
On Tue, Sep 23, 2014 at 7:47 AM, Robert Dailey rcdailey.li...@gmail.com
wrote:
But if I type just 'make', I don't see how it will know where my ARM
toolchain is. I'll read the INSTALL file in the meantime.
Sorry for top post
On Tue, Sep 23, 2014 at 11:47:51AM -0400, Jeff King wrote:
As far as I can tell, fsck's mode-checking has been totally broken
basically forever. Which makes me a little nervous to fix it. :)
linux.git does have some bogus modes, but they are 100664, which is
specifically ignored here unless
[-cc Kirill, as his address seem out-of-date]
On Tue, Sep 23, 2014 at 04:23:43PM +, Edward Thomson wrote:
On Tue, Sep 23, 2014 at 11:47:51AM -0400, Jeff King wrote:
As far as I can tell, fsck's mode-checking has been totally broken
basically forever. Which makes me a little nervous to
Duy Nguyen pclo...@gmail.com writes:
On Tue, Sep 23, 2014 at 2:15 AM, Junio C Hamano gits...@pobox.com wrote:
When we have a/b/c and a/d/e to be written, the first round would
write a/ and then a/b/ with the above, and presumably elsewhere
somebody will write a/b/c; next time around we do
Christian Couder christian.cou...@gmail.com writes:
On Mon, Sep 22, 2014 at 4:01 PM, Michael S. Tsirkin m...@redhat.com wrote:
...
As a reminder, this old patchset (that I replied to) enhanced git am -s
with an option to add different signatures depending on
the option passed to the -s flag.
Stefan Beller stefanbel...@gmail.com writes:
Commented code, which doesn't even compile, is of no use any more?
Apparently that is meant to help debugging the code. An alternative
would be to make it usable again, but removal is fine by me as well.
Signed-off-by: Stefan Beller
Laszlo Ersek ler...@redhat.com writes:
git format-patch master..branch1
The output from this has these (excerpt from od -xc output):
360 f 2 \n \n d i f f - - g i t
66200a32640a666920662d2d69672074
400 a / f
Some background from the git-archive(1) man page:
git-archive behaves differently when given a tree ID versus when
given a commit ID or tag ID. In the first case the current time is
used as the modification time of each file in the archive. In the
latter case the commit time as
Hello,
I just noticed that git-filter-branch doesn't preserve mergetag
annotations in situations where it could. Here is an example (with
linux.git):
$ git checkout -b test 6cd2f85413eef8fe7bcd7c25bf55e7b055fa257c
$ git cat-file commit HEAD | grep mergetag
mergetag object
On 09/23/14 20:54, Junio C Hamano wrote:
Laszlo Ersek ler...@redhat.com writes:
git format-patch master..branch1
The output from this has these (excerpt from od -xc output):
360 f 2 \n \n d i f f - - g i t
66200a32640a6669
Laszlo Ersek ler...@redhat.com writes:
What do you think about accepting only /dev/null\n and /dev/null\r\n?
I thought we agreed that what you are doing is not workable in the
first place, no?
I suspect one way to handle In this project, the files that are
checked out must be with CRLF line
Laszlo Ersek ler...@redhat.com writes:
On 09/23/14 20:54, Junio C Hamano wrote:
...
SMTP transport may be CRLF-unsafe, so I have a suspicion that it may
turn out that what you are trying to do might be an equilvalent of
git format-patch ... |
# first lose all \r\n
Junio C Hamano gits...@pobox.com writes:
SMTP transport may be CRLF-unsafe, so I have a suspicion that it may
turn out that what you are trying to do might be an equilvalent of
git format-patch ... |
# first lose all \r\n
dos2unix |
# then make everything \r\n
Uwe Kleine-König u.kleine-koe...@pengutronix.de writes:
--- /dev/fd/63 2014-09-23 21:07:49.987065017 +0200
+++ /dev/fd/62 2014-09-23 21:07:49.991064988 +0200
@@ -3,32 +3,6 @@
parent 954263938706bf62d36e81b6b49f313390f2ed35
author Linus Torvalds
Laszlo Ersek ler...@redhat.com writes:
On 09/23/14 22:02, Junio C Hamano wrote:
Laszlo Ersek ler...@redhat.com writes:
On 09/23/14 20:54, Junio C Hamano wrote:
...
SMTP transport may be CRLF-unsafe, so I have a suspicion that it may
turn out that what you are trying to do might be an
On 09/23/14 22:02, Junio C Hamano wrote:
Laszlo Ersek ler...@redhat.com writes:
On 09/23/14 20:54, Junio C Hamano wrote:
...
SMTP transport may be CRLF-unsafe, so I have a suspicion that it may
turn out that what you are trying to do might be an equilvalent of
git format-patch ... |
On 09/23/14 21:56, Junio C Hamano wrote:
Laszlo Ersek ler...@redhat.com writes:
What do you think about accepting only /dev/null\n and /dev/null\r\n?
I thought we agreed that what you are doing is not workable in the
first place, no?
I suspect one way to handle In this project, the
Laszlo Ersek ler...@redhat.com writes:
On 09/23/14 21:56, Junio C Hamano wrote:
Laszlo Ersek ler...@redhat.com writes:
What do you think about accepting only /dev/null\n and /dev/null\r\n?
I thought we agreed that what you are doing is not workable in the
first place, no?
I suspect
On 09/23/14 22:35, Junio C Hamano wrote:
Laszlo Ersek ler...@redhat.com writes:
On 09/23/14 22:02, Junio C Hamano wrote:
Laszlo Ersek ler...@redhat.com writes:
On 09/23/14 20:54, Junio C Hamano wrote:
...
SMTP transport may be CRLF-unsafe, so I have a suspicion that it may
turn out that
On 09/23/14 22:40, Junio C Hamano wrote:
Laszlo Ersek ler...@redhat.com writes:
On 09/23/14 21:56, Junio C Hamano wrote:
Laszlo Ersek ler...@redhat.com writes:
What do you think about accepting only /dev/null\n and /dev/null\r\n?
I thought we agreed that what you are doing is not workable
Laszlo Ersek ler...@redhat.com writes:
In summary:
This is not entirely correct, though. But it suggests an avenue for
a possible enhancement.
- the email infrastructure turns all line terminators into CRLFs
Yes, but that is within MTAs and is expected to be invisible at MUA
level.
Jeff King p...@peff.net writes:
But if we do want to keep it, does bumping it to 128 (and bumping the
4000 to 8000 in the test below it) work?
It works for all architectures supported by the openSUSE build service.
https://build.opensuse.org/package/show/home:AndreasSchwab:f/git
Andreas.
--
Am 23.09.2014 um 20:57 schrieb Daniel Brockman:
Some background from the git-archive(1) man page:
git-archive behaves differently when given a tree ID versus when
given a commit ID or tag ID. In the first case the current time is
used as the modification time of each file in the
Andreas Schwab sch...@linux-m68k.org writes:
Jeff King p...@peff.net writes:
But if we do want to keep it, does bumping it to 128 (and bumping the
4000 to 8000 in the test below it) work?
It works for all architectures supported by the openSUSE build service.
On Tue, Sep 23, 2014 at 11:49:24PM +0200, Thomas Braun wrote:
Am 23.09.2014 um 20:57 schrieb Daniel Brockman:
Would it make sense to add an --mtime option to git-archive(1) to enable
explicitly setting the mtime for all files in the archive? It could
just pass through to the tar(1) --mtime
brian m. carlson sand...@crustytoothpaste.net writes:
Git does not invoke tar(1). It has its own tar (actually, pax)
implementation, so any options would have to be implemented in Git.
We'd probably want to make such a change effective in the zip format
as well.
Ah, I see...
Well, I guess
On Wed, Sep 24, 2014 at 03:26:22AM +0200, Daniel Brockman wrote:
brian m. carlson sand...@crustytoothpaste.net writes:
Git does not invoke tar(1). It has its own tar (actually, pax)
implementation, so any options would have to be implemented in Git.
We'd probably want to make such a
59 matches
Mail list logo
