Thanks for the explanation. In my case it seems we have an invalid
index. I modified the gin script [1] to inspect the index and found
valid cached trees in the index for pathes for which the index has no
entries. Will try to find out who/how the index was corrupted.
[1] https://raw.githubusercont
On 2015-01-22 23.07, Junio C Hamano wrote:
> Torsten Bögershausen writes:
>
>> If I run that sequence manually:
>> chmod 755 .
>> touch x
>> chmod a-w .
>> rm x
>> touch y
>>
>> x is gone, (but shoudn't according to POSIX)
>> y is not created, "access denied"
>
> Good (or is that Sad?).
It feels
I have a submodule using HTTP URL. I do this:
$ git submodule init MySubmodule
$ git submodule update MySubmodule
The 2nd command fails because the HTTP URL cannot be resolved, this is
because it requires a proxy. I have "http.proxy" setup properly in the
.git/config of my parent git repository,
While -C implies -M, it is quite common to see both on example command lines
here and there. The unintuitive thing is that if -M appears after -C, then
copy detection is turned off because of how the command line arguments are
handled.
Change this so that when both -C and -M appear, whatever their
Hi,
While fooling around with copy/rename detection, I noticed that it
doesn't detect the case where you copy or rename a file on top of
another:
$ git init
$ (echo foo; echo bar) > foo
$ git add foo
$ git commit -m foo
$ echo 0 > bar
$ git add bar
$ git commit -m bar
$ git mv -f foo bar
$ git co
On Fri, Jan 23, 2015 at 3:19 AM, Junio C Hamano wrote:
> "Kirill A. Shutemov" writes:
>
>> diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
>> index 8197ed29a9ec..a31f7e0430e1 100755
>> --- a/t/t3404-rebase-interactive.sh
>> +++ b/t/t3404-rebase-interactive.sh
>> @@ -103
On Jan 22, 2015, at 11:23, Junio C Hamano wrote:
"Kyle J. McKay" writes:
On Jan 21, 2015, at 14:33, Junio C Hamano wrote:
"Kyle J. McKay" writes:
So since I've not been able to get test 2 or 3 to core dump (even
before 250b3c6c) I tend to believe you are correct in that the code
thinks (i
On Thu, Jan 22, 2015 at 3:42 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>>> -* it might with whitespace fuzz. We haven't been asked to
>>> +* it might with whitespace fuzz. We weren't asked to
>>
>> (not a native speaker):
>> A quick websearch reveals "We haven't been ask
Stefan Beller writes:
>> -* it might with whitespace fuzz. We haven't been asked to
>> +* it might with whitespace fuzz. We weren't asked to
>
> (not a native speaker):
> A quick websearch reveals "We haven't been asked to ..."
> is quite commonly used in the web. So it's more of
On Thu, Jan 22, 2015 at 11:05:29PM +0100, Torsten Bögershausen wrote:
We want to support ssh://bmc@2001:470:1f05:79::1/git/bmc/homedir.git/
because e.g. the Git shipped with Debian (1.7.10.4) (and a lot of other
installations) supports it.
I understand that this used to work, but it probably
On Thu, Jan 22, 2015 at 2:58 PM, Junio C Hamano wrote:
> Signed-off-by: Junio C Hamano
> ---
> builtin/apply.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/builtin/apply.c b/builtin/apply.c
> index 622ee16..31f8733 100644
> --- a/builtin/apply.c
> +++ b/builtin/apply.
By moving the functions up we don't need to have to declare them first
when using them in a later patch.
Signed-off-by: Stefan Beller
---
refs.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/refs.c b/refs.c
index 4580919..6f3cd7b 100644
--- a/
This makes write_ref_sha1 only write the the lock file, committing
needs to be done outside of that function. This will help us change
the ref_transaction_commit in a later patch.
Signed-off-by: Stefan Beller
---
refs.c | 22 +-
1 file changed, 13 insertions(+), 9 deletions(-
By writing the values to the lock file early we have a better sequence
of system calls. Before this commit we had
open(), close(), open(), fdopen(), write(), fclose(), rename()
Now there is:
open(), fdopen(), write(), fclose(), rename()
The first four operations are performed in the fir
This will fix the warnings Ramsay Jones pointed out.
Signed-off-by: Stefan Beller
---
refs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/refs.c b/refs.c
index 9fc0e60..aae3b66 100644
--- a/refs.c
+++ b/refs.c
@@ -3058,12 +3058,12 @@ static int write_sha1_to_lock_file(
Instead of calling unlock_ref before each return in write_ref_sha1
we can call this after the call. This is a first step to split up
write_ref_sha1 into the write and commit phase which is done in a
later patch.
There is a call in each code path after write_ref_sha1 now. Even in
the last hunk in t
This series goes on top of origin/sb/atomic-push-fix for now.
I am inclined to squash the first patch into the last commit of
origin/sb/atomic-push-fix when rerolling that series as it just
fixes the warning Ramsay pointed out. I'd also like to combine
this series with the origin/sb/atomic-push-
When the incoming patch has whitespace errors in a common context
line (i.e. a line that is expected to be found and is not modified
by the patch), "apply --whitespace=fix" corrects the whitespace
errors the line has, in addition to the whitespace error on a line
that is updated by the patch. Howe
"git apply --whitespace=fix" used to be able to assume that fixing
errors will always reduce the size by e.g. stripping whitespaces at
the end of lines or collapsing runs of spaces into tabs at the
beginning of lines. An update to accomodate fixes that lengthens
the result by e.g. expanding leadin
Signed-off-by: Junio C Hamano
---
builtin/apply.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/apply.c b/builtin/apply.c
index 622ee16..31f8733 100644
--- a/builtin/apply.c
+++ b/builtin/apply.c
@@ -2326,7 +2326,7 @@ static int match_fragment(struct image *img,
"git apply --whitespace=fix" used to be able to assume that fixing
errors will always reduce the size by e.g. stripping whitespaces at
the end of lines or collapsing runs of spaces into tabs at the
beginning of lines. An update to accomodate fixes that lengthens
the result by e.g. expanding leadin
Under --whitespace=fix option, match_fragment() function examines
the preimage (the common context and the removed lines in the patch)
and the file being patched and checks if they match after correcting
all whitespace errors. When they are found to match, the common
context lines in the preimage
On Thu, Jan 22, 2015 at 01:35:38PM -0500, Jeff King wrote:
> On Thu, Jan 22, 2015 at 06:36:41PM +0100, Matthieu Moy wrote:
>
> > > Yes, main point is size of executable.
> >
> > The Git executable is a few megabytes, i.e. 0.001% the size of a really
> > small hard disk. The benefit seems really n
Mike Hommey writes:
> On Thu, Jan 22, 2015 at 09:52:55AM -0800, Junio C Hamano wrote:
>
>> Does the new code avoid regressions for them and if so how? That is
>> what was needed in the justification.
>>
>> For remote helpers that support the 'list' command, asking for a
>> symref and asking for
On Thu, Jan 22, 2015 at 09:52:55AM -0800, Junio C Hamano wrote:
> Mike Hommey writes:
>
> > The patch changes the behavior in all cases, because it didn't feel
> > necessary to have a different behavior between the "normal" case and the
> > '?' case: it makes sense to request the ref being pointe
Torsten Bögershausen writes:
> If I run that sequence manually:
> chmod 755 .
> touch x
> chmod a-w .
> rm x
> touch y
>
> x is gone, (but shoudn't according to POSIX)
> y is not created, "access denied"
Good (or is that Sad?).
> diff --git a/t/test-lib.sh b/t/test-lib.sh
> --- a/t/test-lib.sh
On 2015-01-22 21.07, brian m. carlson wrote:
> On Mon, Jan 19, 2015 at 06:21:24PM +0100, Torsten Bögershausen wrote:
>> When parsing an URL, older Git versions did handle
>> URLs like ssh://2001:db8::1/repo.git the same way as
>> ssh://[2001:db8::1]/repo.git
>>
>> Commit 83b058 broke the parsing of
On Thu, Jan 22, 2015 at 10:20:01PM +0100, Johannes Schindelin wrote:
> On 2015-01-22 20:59, Stefan Beller wrote:
> > cc Johannes Schindelin who is working in
> > the fsck at the moment
> >
> > On Thu, Jan 22, 2015 at 11:43 AM, Michael Blume
> > wrote:
> >
> >> CC fsck.o
> >> fsck.c:110:38:
On 2015-01-21 23.33, Junio C Hamano wrote:
> Are you reporting differences between the state before these patches
> and after, or just the fact that with these patches the named tests
> break (which may or may not be broken before the patches)?
>
The intention was to report what is now breaking.
Thanks, all.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Stefan,
On 2015-01-22 20:59, Stefan Beller wrote:
> cc Johannes Schindelin who is working in
> the fsck at the moment
>
> On Thu, Jan 22, 2015 at 11:43 AM, Michael Blume wrote:
>
>> CC fsck.o
>> fsck.c:110:38: warning: comparison of unsigned enum expression >= 0 is
>> always true [-Wtauto
On Thursday 22 January 2015 11:59:54 Stefan Beller wrote:
> cc Johannes Schindelin who is working in
> the fsck at the moment
> cc Peter Wu who worked on builtin/remote.c a few weeks
> ago
>
> I just compiled origin/pu to test and also found a problem (doesn't
> happen in origin/master):
>
> h
On 22/01/15 20:20, Stefan Beller wrote:
> On Thu, Jan 22, 2015 at 12:13 PM, Ramsay Jones
> wrote:
>>
>> Notice the [-Wextra] warnings above. ;-)
>>
>> ATB,
>> Ramsay Jones
>>
>
> Thanks, I put that into my config.mak
> Though recompiling the whole project yields
>
> 4 [-Wempty-body]
>
On Thu, Jan 22, 2015 at 07:32:33PM +, Sven van Haastregt wrote:
Version numbers in asciidoc-generated content (such as man pages)
went missing as of da8a366 (Documentation: refactor common operations
into variables). Fix by putting the underscore back in the variable
name.
Signed-off-by: Sv
"Kirill A. Shutemov" writes:
> diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
> index 8197ed29a9ec..a31f7e0430e1 100755
> --- a/t/t3404-rebase-interactive.sh
> +++ b/t/t3404-rebase-interactive.sh
> @@ -1039,4 +1039,11 @@ test_expect_success 'short SHA-1 collide' '
>
On Thu, Jan 22, 2015 at 12:13 PM, Ramsay Jones
wrote:
>
> Notice the [-Wextra] warnings above. ;-)
>
> ATB,
> Ramsay Jones
>
Thanks, I put that into my config.mak
Though recompiling the whole project yields
4 [-Wempty-body]
477 [-Wmissing-field-initializers]
966 [-Wsign-compare]
On Tue, Jan 20, 2015 at 08:03:33PM +0700, Nguyễn Thái Ngọc Duy wrote:
When a good user sees the "too long, consider -uno" advice when
running `git status`, they should check out the man page to find out
more. This change suggests they try untracked cache before -uno.
Signed-off-by: Nguyễn Thái N
On 22/01/15 19:51, Ramsay Jones wrote:
> On 22/01/15 19:16, Stefan Beller wrote:
>> How do you run sparse on git?
>
> $ make sparse >sp-out 2>&1
>
BTW, you can get gcc to warn about this also:
$ rm refs.o
$ make CFLAGS='-Wall -Wextra' refs.o
* new build flags
CC refs.o
In file inclu
"Kirill A. Shutemov" writes:
> I have tried to fix this before: see 568950388be2, but it doesn't
> really work.
>
> I don't know how it happend, but that commit makes interactive rebase to
> respect core.abbrev only during --edit-todo, but not the initial todo
> list edit.
>
> For this time I've
On Mon, Jan 19, 2015 at 06:21:24PM +0100, Torsten Bögershausen wrote:
When parsing an URL, older Git versions did handle
URLs like ssh://2001:db8::1/repo.git the same way as
ssh://[2001:db8::1]/repo.git
Commit 83b058 broke the parsing of IPV6 adresses without "[]":
It was written in mind that th
cc Johannes Schindelin who is working in
the fsck at the moment
cc Peter Wu who worked on builtin/remote.c a few weeks ago
I just compiled origin/pu to test and also found a problem (doesn't
happen in origin/master):
http.c: In function 'get_preferred_languages':
http.c:1020:2: warning: implici
On 22/01/15 19:16, Stefan Beller wrote:
> How do you run sparse on git?
$ make sparse >sp-out 2>&1
>
> I noticed there is 'make sparse' though I cannot get it working
> here in the corporate world as I have problems with openssl
> headers not being found.
If you can build git with gcc, you sh
These are probably minor, I only bring them up because Git's build is
generally so quiet that it might be worth squashing these too.
CC fsck.o
fsck.c:110:38: warning: comparison of unsigned enum expression >= 0 is
always true [-Wtautological-compare]
if (options->msg_severity && msg_id
Version numbers in asciidoc-generated content (such as man pages)
went missing as of da8a366 (Documentation: refactor common operations
into variables). Fix by putting the underscore back in the variable
name.
Signed-off-by: Sven van Haastregt
---
Documentation/Makefile | 2 +-
1 file changed,
On Thu, Jan 22, 2015 at 8:33 AM, Michael Haggerty wrote:
> On 01/22/2015 02:10 PM, Jeff King wrote:
>> On Thu, Jan 22, 2015 at 12:24:23PM +0100, Michael Haggerty wrote:
>>
>>> I can't figure out where to apply this series or where to fetch it from,
>>> so I can't see these changes in context, so m
"Kyle J. McKay" writes:
> On Jan 21, 2015, at 14:33, Junio C Hamano wrote:
>
>> "Kyle J. McKay" writes:
>>
>>> So since I've not been able to get test 2 or 3 to core dump (even
>>> before 250b3c6c) I tend to believe you are correct in that the code
>>> thinks (incorrectly) that the result should
How do you run sparse on git?
I noticed there is 'make sparse' though I cannot get it working
here in the corporate world as I have problems with openssl
headers not being found.
Also the line numbers seem to bit off compared to what I have
here, did you need to modify/preprocess files to get spa
Duy Nguyen writes:
> On Wed, Jan 21, 2015 at 10:51:02AM -0800, Junio C Hamano wrote:
>> >> It appears that this hijacks a fixed name dir-mtime-test at the root
>> >> level of every project managed by Git. Is that intended?
>> >
>> > I did think about filename clash, but I chose a fixed name anyw
On Thu, Jan 22, 2015 at 06:36:41PM +0100, Matthieu Moy wrote:
> > Yes, main point is size of executable.
>
> The Git executable is a few megabytes, i.e. 0.001% the size of a really
> small hard disk. The benefit seems really negligible to me.
I don't know the layout of the symbols with respect t
On Thu, Jan 22, 2015 at 9:58 AM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> v2 applies to sb/atomic-push instead of next and will result in a one
>> line merge conflict with next.
>
> I acctually tried to apply on 'next' and also on 'sb/atomic-push'
> and both failed.
That's strange inde
Stefan Beller writes:
> v2 applies to sb/atomic-push instead of next and will result in a one
> line merge conflict with next.
I acctually tried to apply on 'next' and also on 'sb/atomic-push'
and both failed. I had to wiggle the patches to make them apply on
the latter, and that is what is que
Mike Hommey writes:
> The patch changes the behavior in all cases, because it didn't feel
> necessary to have a different behavior between the "normal" case and the
> '?' case: it makes sense to request the ref being pointed at than the
> symbolic ref in every case.
>
> Moreover, this makes exist
On Thu, Jan 22, 2015 at 12:00 AM, Junio C Hamano wrote:
> Jeff King writes:
>
>> On Wed, Jan 21, 2015 at 03:23:39PM -0800, Stefan Beller wrote:
>>
>>> (reported as: git update-ref --stdin : too many open files, 2014-12-20)
>>>
>>> First a test case is introduced to demonstrate the failure,
>>> th
Guilt v0.36-rc1 is available for download.
Guilt (Git Quilt) is a series of shell scripts which add a Mercurial
queues-like functionality and interface to git.
Tarballs:
http://guilt.31bits.net/src/
Git repo:
git://repo.or.cz/guilt.git
This is the first release candidate for the long awaited v
Alexander Kuleshov writes:
> Hello Jeff,
>
> Yes, main point is size of executable.
The Git executable is a few megabytes, i.e. 0.001% the size of a really
small hard disk. The benefit seems really negligible to me.
OTOH, debug information allow users to do better bug reports in case of
crash (
Hi Michael,
On 2015-01-22 16:49, Michael Haggerty wrote:
> On 12/23/2014 06:14 PM, Junio C Hamano wrote:
>> Johannes Schindelin writes:
>>> On Tue, 23 Dec 2014, Junio C Hamano wrote:
I suspect that it would be much better if the configuration variables
were organized the other way aroun
Or even still -g as it now, because anyway debugging info will be
removed with stripping
2015-01-22 22:51 GMT+06:00 Alexander Kuleshov :
> Hello Jeff,
>
> Yes, main point is size of executable. I'm sorry, didn't see 'strip' target.
>
> What if we will strip git and other executable files by defaul
Hello Jeff,
Yes, main point is size of executable. I'm sorry, didn't see 'strip' target.
What if we will strip git and other executable files by default and
add -g option and don't strip it if DEBUG=1 passed to make. Something
like this:
git$X: git.o GIT-LDFLAGS $(BUILTIN_OBJS) $(GITLIBS)
$
On 01/22/2015 02:10 PM, Jeff King wrote:
> On Thu, Jan 22, 2015 at 12:24:23PM +0100, Michael Haggerty wrote:
>
>> I can't figure out where to apply this series or where to fetch it from,
>> so I can't see these changes in context, so maybe I'm misunderstanding
>> something. It looks like this code
Replacing echo with printf as in your patch works fine for me.
I've applied Signed-off-by lines from you for the latest commits,
rebased it on top of your current master commit, and pushed
the series to the oslo-2014-v5 branch of git://repo.or.cz/guilt/ceder.git
/ceder
On Thu, Jan 22, 2015 a
On 12/23/2014 06:14 PM, Junio C Hamano wrote:
> Johannes Schindelin writes:
>> On Tue, 23 Dec 2014, Junio C Hamano wrote:
>>> I suspect that it would be much better if the configuration variables
>>> were organized the other way around, e.g.
>>>
>>> $ git config fsck.warn missingTagger,someOth
Hi Junio,
The following changes since commit 627736ca799edacf13881da7e671964a0afb94b8:
Git 2.3.0-rc1 (2015-01-20 17:35:41 -0800)
are available in the git repository at:
git://github.com/git-l10n/git-po master
for you to fetch changes up to 1e607449135792dd117bd528432fc1fbc1115667:
l10n:
On Thu, Jan 22, 2015 at 08:00:36AM -0500, Jeff King wrote:
> On Thu, Jan 22, 2015 at 06:50:37PM +0600, Alexander Kuleshov wrote:
>
> > Standard user has no need in debugging information. This patch adds
> > DEBUG=1 option to compile git with debugging symbols and compile without
> > it by default.
> On Jan 20, 2015, at 7:22 PM, Junio C Hamano wrote:
>
> "Dan Langille (dalangil)" writes:
>
>> I did not test this patch. Is that holding up a commit?
>
> I am hoping that you rebuilt the Git you use with this patch by the
> time you wrote the message I am responding to and have been using i
Signed-off-by: Josef 'Jeff' Sipek
Ok, I think this is all of the patches. I'll wait for you to tell me if the
cmd() echo to printf change breaks anything for you. If not, I'll pull your
series (via git), tag a 0.36-rc1, and push the whole thing to repo.or.cz. :)
Sorry for making this take so
On Sun, May 18, 2014 at 11:59:45PM +0200, Per Cederqvist wrote:
> The "cmd" and "shouldfail" functions checked the exit status of the
> replace_path function instead of the actual command that was running.
> (The $? construct checks the exit status of the last command in a
> pipeline, not the first
Signed-off-by: Josef 'Jeff' Sipek
On Sun, May 18, 2014 at 11:59:50PM +0200, Per Cederqvist wrote:
> The valid_patchname now lets "git check-ref-format" do its job instead
> of trying (and failing) to implement the same rules. See
> git-check-ref-format(1) for a list of the rules. Re-implement r
I just tried to run the regression suite on my OpenIndiana laptop and I got
this failure.
034: --- t-034.out 2015-01-22 14:02:23.634515474 +
+++ /tmp/guilt.log.148782015-01-22 14:03:54.258790788 +
@@ -83,7 +83,7 @@
[master aedb74f] @
Author: Author Name
1 file changed, 1
Signed-off-by: Josef 'Jeff' Sipek
On Mon, May 19, 2014 at 12:00:08AM +0200, Per Cederqvist wrote:
> ---
> Documentation/guilt-header.txt | 5 -
> regression/t-028.out | 9 +
> regression/t-028.sh| 3 +++
> 3 files changed, 16 insertions(+), 1 deletion(-)
>
> d
Hi all,
When cloning
```
$ git svn clone https://geuz.org/svn/gmsh/trunk
```
I'm getting the error
```
[...]
r100 = e2a9b5baa2cebb18591ecb04ff350410d52f36de (refs/remotes/git-svn)
error closing pipe: Bad file descriptor at
/usr/share/perl5/Git/SVN/Fetcher.pm line 335.
error closing pipe: Bad file
On Thu, Jan 22, 2015 at 12:24:23PM +0100, Michael Haggerty wrote:
> I can't figure out where to apply this series or where to fetch it from,
> so I can't see these changes in context, so maybe I'm misunderstanding
> something. It looks like this code is doing
>
> open(), close(), open(), fdop
On Thu, Jan 22, 2015 at 11:54:49AM +0100, Michael Haggerty wrote:
> > +run_with_limited_open_files () {
> > + (ulimit -n 32 && "$@")
> > +}
>
> Regarding the choice of "32", I wonder what is the worst-case number of
> open file descriptors that are needed *before* counting the ones that
> are c
On Thu, Jan 22, 2015 at 06:50:37PM +0600, Alexander Kuleshov wrote:
> Standard user has no need in debugging information. This patch adds
> DEBUG=1 option to compile git with debugging symbols and compile without
> it by default.
This explanation is missing why it is beneficial _not_ to have the
On 22/01/15 02:32, Stefan Beller wrote:
> By closing the file descriptors after creating the lock file we are not
> limiting the size of the transaction by the number of available file
> descriptors.
>
> Signed-off-by: Stefan Beller
> ---
> refs.c| 17 +
> t/t1400
On Thu, Jan 22, 2015 at 11:10:42AM +0100, Michael J Gruber wrote:
> We do have a linear history when we walk with --first-parent :)
Yes, but I do not think it is robust to adding new commits on top. E.g.,
given:
A--B--C---F
\/
D--E
a --first-parent walk from F will show F-C-B
Standard user has no need in debugging information. This patch adds
DEBUG=1 option to compile git with debugging symbols and compile without
it by default.
Signed-off-by: Alexander Kuleshov
---
Makefile | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/Makefile b/Makefi
On Thu, Jan 22, 2015 at 12:59 PM, Kacper Kornet wrote:
> Commit 908a3203632a02568df230c0fccf9a2cd8da24e6 introduced indentation
> to here documents in t3301.sh. However in one place <<-EOF was missing
> -, which broke this test when run with mksh-50d. This commit fixes it.
>
> Signed-off-by: Kacp
On Thu, Jan 22, 2015 at 12:59:36PM +0100, Kacper Kornet wrote:
> Commit 908a3203632a02568df230c0fccf9a2cd8da24e6 introduced indentation
> to here documents in t3301.sh. However in one place <<-EOF was missing
> -, which broke this test when run with mksh-50d. This commit fixes it.
This is defini
Commit 908a3203632a02568df230c0fccf9a2cd8da24e6 introduced indentation
to here documents in t3301.sh. However in one place <<-EOF was missing
-, which broke this test when run with mksh-50d. This commit fixes it.
Signed-off-by: Kacper Kornet
---
t/t3301-notes.sh | 2 +-
1 file changed, 1 insert
On Do, 2015-01-22 at 12:43 +0100, Tobias Getzner wrote:
> Hello,
>
> I’ve noticed git gui and gitk seem to have problems decoding certain
> unicode characters. E.g., when a commit contains the character «👍»
> (thumbs up sign; U+1F44D) in UTF-8 encoding, this character will show
> as «ð» in gitk
On 01/22/2015 03:32 AM, Stefan Beller wrote:
> version2:
Summary: patches 1-4 look good to me. I sent a separate comment about
patch 5, which seems to do more system calls than necessary.
Michael
--
Michael Haggerty
mhag...@alum.mit.edu
--
To unsubscribe from this list: send the line "unsubscr
I have tried to fix this before: see 568950388be2, but it doesn't
really work.
I don't know how it happend, but that commit makes interactive rebase to
respect core.abbrev only during --edit-todo, but not the initial todo
list edit.
For this time I've included a test-case to avoid this frustratio
OPT_SUBCMD can be used for parsing git commands which has not only
short/long options, but subcomands. For example: git bundle (create,
verify and etc...) or git remote (add, rename and etc...)
Signed-off-by: Alexander Kuleshov
---
parse-options.c | 25 +
parse-o
Hello,
I’ve noticed git gui and gitk seem to have problems decoding certain
unicode characters. E.g., when a commit contains the character «👍»
(thumbs up sign; U+1F44D) in UTF-8 encoding, this character will show
as «ð» in gitk. git gui also displays it using the same sequence.
When trying to s
On 01/22/2015 03:32 AM, Stefan Beller wrote:
> By closing the file descriptors after creating the lock file we are not
> limiting the size of the transaction by the number of available file
> descriptors.
>
> Signed-off-by: Stefan Beller
> ---
> refs.c| 17 +
> t/
On 01/22/2015 03:32 AM, Stefan Beller wrote:
> Signed-off-by: Stefan Beller
> ---
> t/t1400-update-ref.sh | 28
> 1 file changed, 28 insertions(+)
>
> diff --git a/t/t1400-update-ref.sh b/t/t1400-update-ref.sh
> index 7b4707b..47d2fe9 100755
> --- a/t/t1400-update-re
On Wed, Jan 21, 2015 at 10:51:02AM -0800, Junio C Hamano wrote:
> >> It appears that this hijacks a fixed name dir-mtime-test at the root
> >> level of every project managed by Git. Is that intended?
> >
> > I did think about filename clash, but I chose a fixed name anyway for
> > simplicity, othe
Scott Schmit schrieb am 22.01.2015 um 02:37:
> On Mon, Jan 19, 2015 at 03:20:51PM +0100, Michael J Gruber wrote:
>> Alexander Kuleshov schrieb am 17.01.2015 um 08:35:
>>> This patch adds support -d/--dry-run option for branch(es) deletion.
>>> If -d/--dry-run option passed to git branch -d branch..
j...@joshtriplett.org schrieb am 21.01.2015 um 00:11:
> On Tue, Jan 20, 2015 at 04:49:53PM -0500, Jeff King wrote:
>> On Mon, Jan 19, 2015 at 05:17:25PM -0800, Josh Triplett wrote:
>>
Can you be a bit more specific about the type count that you are after?
"git describe" counts commits sin
Noralf Trønnes schrieb am 20.01.2015 um 23:26:
> Den 20.01.2015 23:18, skrev Nico Williams:
>> On Tue, Jan 20, 2015 at 10:38:40PM +0100, Noralf Trønnes wrote:
>>> Yes:
>>> $ echo Noralf Trønnes | xxd
>>> 000: 4e6f 7261 6c66 2054 72f8 6e6e 6573 0aNoralf Tr.nnes.
>>>
>>> Is there a command I
Hi Junio,
On 2015-01-21 22:47, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
@@ -1488,8 +1501,13 @@ static const char *unpack(int err_fd, struct
shallow_info *si)
argv_array_pushl(&child.args, "index-pack",
"--stdin", hdr_a
This patch introduce the check in list_and_choose() routine for the list. If
list is empty just return.
It can be useful for example if user selects 'add untracked' and there are no
untracked files, "Add untracked>>" opens. But it does not make sense in this
case, because there are no untracked fi
xgettext sees "% o" and interprets it as a placeholder for an octal
number preceded by a space. However, in this case it's not actually a
placeholder, and most translations will replace the "% o" sequence with
something else. Removing the tcl-format flag from this string prevents
tools like Poedit
On Wed, Jan 21, 2015 at 11:41:51PM -0800, Junio C Hamano wrote:
> Mike Hommey writes:
>
> > Note the most important part is actually between the parens: that only
> > happens when the remote helper returns '?' to the `list` command, which
> > non-git remotes helpers (like git-remote-hg or git-rem
Jeff King writes:
> On Wed, Jan 21, 2015 at 03:23:39PM -0800, Stefan Beller wrote:
>
>> (reported as: git update-ref --stdin : too many open files, 2014-12-20)
>>
>> First a test case is introduced to demonstrate the failure,
>> the patches 2-6 are little refactoring and the last patch
>> fixes
95 matches
Mail list logo
