On Wed, Sep 24, 2014 at 03:26:22AM +0200, Daniel Brockman wrote:
> "brian m. carlson" 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 th
"brian m. carlson" 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 in the meantime I'll ju
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) -
Andreas Schwab writes:
> Jeff King 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:AndreasSc
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
Jeff King 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.
--
Andreas Sc
Laszlo Ersek 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. Typically mailbox files
On 09/23/14 22:40, Junio C Hamano wrote:
> Laszlo Ersek writes:
>
>> On 09/23/14 21:56, Junio C Hamano wrote:
>>> Laszlo Ersek 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
>>>
On 09/23/14 22:35, Junio C Hamano wrote:
> Laszlo Ersek writes:
>
>> On 09/23/14 22:02, Junio C Hamano wrote:
>>> Laszlo Ersek 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 yo
Laszlo Ersek writes:
> On 09/23/14 21:56, Junio C Hamano wrote:
>> Laszlo Ersek 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 hand
On 09/23/14 21:56, Junio C Hamano wrote:
> Laszlo Ersek 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 th
On 09/23/14 22:02, Junio C Hamano wrote:
> Laszlo Ersek 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 ... |
>
Laszlo Ersek writes:
> On 09/23/14 22:02, Junio C Hamano wrote:
>> Laszlo Ersek 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
Uwe Kleine-König 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 1411488823 -0700
>committer L
Junio C Hamano 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
> u
Laszlo Ersek 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
>> dos2un
Laszlo Ersek 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 endings no mat
On 09/23/14 20:54, Junio C Hamano wrote:
> Laszlo Ersek 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
>66200a32640a66692066
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
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 r
Laszlo Ersek 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 2 b
Stefan Beller 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
> ---
>
> To be applied on top o
Christian Couder writes:
> On Mon, Sep 22, 2014 at 4:01 PM, Michael S. Tsirkin 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.
>> E.g. I have
>> [am "a"]
>>
Duy Nguyen writes:
> On Tue, Sep 23, 2014 at 2:15 AM, Junio C Hamano 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 need to write a/d/
>> but we wo
[-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
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
On Tue, Sep 23, 2014 at 07:52:32AM -0500, Robert Dailey wrote:
> On Tue, Sep 23, 2014 at 7:47 AM, 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.
>
> Sorry for top post earlier, my mist
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 se
On Sat, Sep 20, 2014 at 08:18:59PM +0200, Andreas Schwab wrote:
> Stepan Kasal 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
> > '
> >
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
---
As far as I can tell, fsck's mode-checking has been totally broken
ba
Am 23. September 2014 14:00 schrieb Phillip Sz :
> 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 majord...@vger.kernel.o
Commented code, which doesn't even compile, is of no use any more?
Signed-off-by: Stefan Beller
---
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
index d63524c..8ad4be8 1
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 t
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: M
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
English grammar with German words doesn't make it a German translation. ;)
Signed-off-by: Stefan Beller
---
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 b/po/de.po
index e5d2b25..bae372
On Tue, Sep 23, 2014 at 7:47 AM, 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.
Sorry for top post earlier, my mistake.
I reviewed the INSTALL file. It doesn't mention anything regarding how
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 wrote:
> On 22.09.2014 21:04, Robert Dailey wrote:
>> I run the following on Ubuntu:
>>
>> fe@BLD01:~/code/git$ autoconf
>>
Hi,
this patch added a comma before the "um". See:
http://www.duden.de/sprachwissen/rechtschreibregeln/komma#K117
Phillip
Signed-off-by: Phillip Sz
---
po/de.po | 86
1 file changed, 43 insertions(+), 43 deletions(-)
diff --git
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
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
2014-09-23 10:43 GMT+02:00 Stefan Beller :
> On 23.09.2014 10:06, Eric Sunshine wrote:
>> On Tue, Sep 23, 2014 at 3:37 AM, Stefan Beller
>> wrote:
>>> English grammar with German words doesn't make it a German translation. ;)
>>> We also need to fix the
>>
>> Sentence fragment.
>
> Yeah, original
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
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
Junio C Hamano writes:
> Sergey Organov writes:
>
>> Vanilla "git rebase" defaults to --fork-point that in some cases
>> makes behavior very different from "git rebase ",
>> where --no-fork-point is assumed. This fact was not mentioned in
>> the DESCRIPTION section of the manual page, even thoug
On 23.09.2014 10:06, Eric Sunshine wrote:
> On Tue, Sep 23, 2014 at 3:37 AM, Stefan Beller 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 form and let the
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 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 resul
On Tue, Sep 23, 2014 at 3:37 AM, Stefan Beller 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
> ---
> po/de.po | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> di
On Tue, Sep 23, 2014 at 3:51 AM, Jeff King 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 wrote:
>> >
>> > I don't mind silencing this one warning (even though I find it a little
>> > ridiculous). I'm slightly concerned th
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 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
On Tue, Sep 23, 2014 at 2:26 AM, Junio C Hamano wrote:
> On Mon, Sep 22, 2014 at 11:04 PM, Jeff King 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 th
On Tue, Sep 23, 2014 at 2:04 AM, Jeff King 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 wrote:
>> > Eric Sunshine writes:
>> >
>> >> The just-released Apple Xcode 6.0.1 has -Wstring-plus-int enabled by
>> >> default
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 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
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 reposito
Hi Michael,
On Mon, Sep 22, 2014 at 4:01 PM, Michael S. Tsirkin 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
> trailers
English grammar with German words doesn't make it a German translation. ;)
We also need to fix the
Signed-off-by: Stefan Beller
---
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
--- a/po/de.po
+++ b/po/de.po
57 matches
Mail list logo
