Re: Cannot reset a repo
On 2014-12-06 11.27, Martin Wendt wrote: Hi, I am facing this problem: - Using git version 1.9.3 (Apple Git-50) - cloned a fork from GitHub to my local machine: https://github.com/mar10/cdnjs/ - This repo seems to be broken in some way. At least it is not clean from the beginning and I am not able to reset `git reset --hard` only toggles the modified file from .../sortable to .../Sortable and back (see attached screenshot) Is this a known problem (with case sensitivity)? I think so Any suggestions how to fix it? Try to rename Sortable into Sortable.u: git mv Sortable Sortable.upper (When that does not work) git mv sortable sortable.lower If this is not an option, use a USB Stick, format it with HFS+ case sensitive and clone the repo to the stick -- 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
How to repair a shallow clone (?)
I share a bare repo with Sparkleshare which does an auto-synch. Now the synch had stopped, and trying to push to the central repo by hand gives this: git push origin master fatal: protocol error: expected old/new/ref, got 'shallow 72fb4080921221293e28a97a0e8c78d6100c5186' fatal: The remote end hung up unexpectedly Counting objects: 4, done. Delta compression using up to 2 threads. Compressing objects: 100% (4/4), done. error: pack-objects died of signal 13 error: failed to push some refs to x Both machines have Git 2.0.0 Is this a known issue/problem ? I think I started to clone the repo in a shallow way (SparkleShare asked if I want to clone the complete history, and I probably answered no ) Is there a way to repair this situation ? (Except doing a complete re-clone ?) Thanks for help -- 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
Re: Accept-language test fails on Mac OS
On 2014-12-06 20.44, Yi, EungJun wrote:
Could you tell me your locale information from executing 'locale'
command and the verbose message you can get by accessing any git
repository via HTTP protocol? (e.g. GIT_CURL_VERBOSE=1 git clone
http://github.com/foo/bar )
locale -a
C
C.UTF-8
en_US.utf8
icelandic
is_IS
is_IS.iso88591
is_IS.utf8
POSIX
-
After patching like this:
diff --git a/t/t5550-http-fetch-dumb.sh b/t/t5550-http-fetch-dumb.sh
index fc6e7fc..1e42b42 100755
--- a/t/t5550-http-fetch-dumb.sh
+++ b/t/t5550-http-fetch-dumb.sh
@@ -205,8 +205,8 @@ check_language () {
LANG=$5 \
git ls-remote $HTTPD_URL/dumb/repo.git 21 |
tr -d '\015' |
- sort -u stderr
- grep -i ^Accept-Language: stderr actual
+ sort -u stderr
+ grep -i ^Accept-Language: stderr actual
test_cmp expect actual
}
---
I get this:
expecting success:
check_language ko-KR, *;q=0.1 ko_KR.UTF-8 de_DE.UTF-8 ja_JP.UTF-8
en_US.UTF-8
check_language de-DE, *;q=0.1 de_DE.UTF-8 ja_JP.UTF-8
en_US.UTF-8
check_language ja-JP, *;q=0.1 ja_JP.UTF-8
en_US.UTF-8
check_language en-US, *;q=0.1
en_US.UTF-8
--- expect 2014-12-06 21:00:59.0 +
+++ actual 2014-12-06 21:00:59.0 +
@@ -1 +0,0 @@
-Accept-Language: de-DE, *;q=0.1
not ok 25 - git client sends Accept-Language based on LANGUAGE, LC_ALL,
LC_MESSAGES and LANG
#
# check_language ko-KR, *;q=0.1 ko_KR.UTF-8 de_DE.UTF-8
ja_JP.UTF-8 en_US.UTF-8
# check_language de-DE, *;q=0.1 de_DE.UTF-8
ja_JP.UTF-8 en_US.UTF-8
# check_language ja-JP, *;q=0.1
ja_JP.UTF-8 en_US.UTF-8
# check_language en-US, *;q=0.1
en_US.UTF-8
#
--
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
Re: [PATCH] git-svn: Support for git-svn propset
diff --git a/t/t9148-git-svn-propset.sh b/t/t9148-git-svn-propset.sh
new file mode 100755
index 000..b36a8a2
--- /dev/null
+++ b/t/t9148-git-svn-propset.sh
@@ -0,0 +1,71 @@
+#!/bin/sh
+#
+# Copyright (c) 2014 Alfred Perlstein
+#
+
+test_description='git svn propset tests'
+
+. ./lib-git-svn.sh
+
+foo_subdir2=subdir/subdir2/foo_subdir2
+
In case something goes wrong (for whatever reason):
do we need a chain here ?
+mkdir import
+(cd import
+ mkdir subdir
+ mkdir subdir/subdir2
+ touch foo # for 'add props top level'
touch foo can be written shorter:
foo
+ touch subdir/foo_subdir # for 'add props relative'
+ touch $foo_subdir2# for 'add props subdir'
+ svn_cmd import -m 'import for git svn' . $svnrepo /dev/null
+)
+rm -rf import
+
+test_expect_success 'initialize git svn' 'git svn init $svnrepo'
+test_expect_success 'fetch revisions from svn' 'git svn fetch'
This may look a little bit strange, 2 times test_expect_success in a row,
is the indentention OK ?
+
+# There is a bogus feature about svn propset which means that it will only
+# be taken as a delta for svn dcommit iff the file is also modified.
+# That is fine for now.
there is a bogus feature ?
Small typo: s/iff/if/
How about this:
#The current implementation has a restriction:
#svn propset will be taken as a delta for svn dcommit only
#if the file content is also modified
+test_expect_success 'add props top level' '
+ git svn propset svn:keywords FreeBSD=%H foo
+ echo hello foo
+ git commit -m testing propset foo
+ git svn dcommit
+ svn_cmd co $svnrepo svn_project
+ (cd svn_project test `svn propget svn:keywords foo` =
FreeBSD=%H)
+ rm -rf svn_project
+ '
Is there a reason why there is no after git svn dcommit ?
If yes, it could be better to make this really clear to the readers and write
(This idea is stolen from Peff)
{ git svn dcommit || true }
+
+test_expect_success 'add multiple props' '
+ git svn propset svn:keywords FreeBSD=%H foo
+ git svn propset fbsd:nokeywords yes foo
+ echo hello foo
+ git commit -m testing propset foo
+ git svn dcommit
+ svn_cmd co $svnrepo svn_project
+ (cd svn_project test `svn propget svn:keywords foo` =
FreeBSD=%H)
+ (cd svn_project test `svn propget fbsd:nokeywords foo` = yes)
+ (cd svn_project test `svn proplist -q foo | wc -l` -eq 2)
+ rm -rf svn_project
+ '
+
Ah, another small thing:
the wc -l will not work under Mac OS X.
Please see test_line_count() in t/test-lib-functions.sh
And thanks for improving Git
--
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
Re: Enhancement Request: locale git option
On 12/04/2014 09:55 PM, Jeff King wrote: On Thu, Dec 04, 2014 at 06:21:40PM +0100, Ævar Arnfjörð Bjarmason wrote: That is one of the many reasons why I proposed to have a dictionary of the main technical terms for each language before we even localise git in that language. In an ideal word, we would provide a simple solution for looking these terms up both ways. I don't think we're going to have localised man pages any time soon, are we? I think that's a great idea, and one that's only blocked on someone (hint hint) sending patches for it. It would be neat-o to have something to make translating the docs easier, i.e. PO files for sections of the man pages. There's tools to help with that which we could use. But there's no reason for us not to have translated glossaries in the meantime. By the way, there has been fairly significant volunteer effort put into translating Pro Git (e.g., http://git-scm.com/book/de/v1). I have no idea if the terms they use are similar to the terms we use in the localized messages. It might make sense to: 1. Coordinate with those translators to make sure that the glossary terms are consistent. 2. Figure out how to harness those translators for manpage work. Why did Pro Git get so much volunteer translation done, and the manpages didn't? Did they advertise to the right people? Have an interface that made it easier for non-technical people to get involved? -Peff (Thanks for the pointer, excellent book) I do not know who was first, and who came later, but http://git-scm.com/book/de/v1/Git-Grundlagen-%C3%84nderungen-am-Repository-nachverfolgen uses versioniert as tracked LANG=de_DE.UTF-8 git status gives: nichts zum Commit vorgemerkt, aber es gibt unbeobachtete Dateien (benutzen Sie git add zum Beobachten) Does it make sense to replace beobachten with versionieren ? -- 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
Re: error: core.autocrlf=input conflicts with core.eol=crlf
On 12/05/2014 09:10 AM, Torsten Bögershausen wrote: On 05.12.14 06:42, Alex Stangl wrote: Hi, There seems to be problems with the checks in the git code for conflicts between config values of core.autocrlf and core.eol. Because the various config files are read in separate passes, and the conflict check happens on the fly, it creates a situation where the order of the config file entries matters. This seems like a bug or at least a POLA violation -- ordering of lines within a section of a config file is not usually significant. Example: User has core.autocrlf=input in his ~/.gitconfig. In his project-level .git/config he wants to set core.autocrlf=false and core.eol=crlf. If the core.autocrlf=false comes first, then all is well and no conflict is reported. If the core.eol=crlf line comes first, then at the time this line is getting parsed, core.autocrlf is still set at input from ~/.gitconfig, and execution aborts: error: core.autocrlf=input conflicts with core.eol=crlf It seems like the conflict check should be made at the end of the config file parsing, not on the fly. I was tempted to create a patch, however I am unfamilar with the codebase, and didn't understand all the places where the config file parsing is called, so I'm not sure of the ramifications of any proposed change. A benefit of the current approach is that it reports the line number where it aborted in the config file. Trying to retain this and at the same time defer the check until the end could get complicated. Besides interaction between multiple levels of config files, the same sort of ordering issue can arise in conjunction with command-line config overrides. Example: User has core.autocrlf=input in his project-level .git/config. This command works fine: $ git -c core.autocrlf=false -c core.eol=crlf status This command blows up with conflict error: $ git -c core.eol=crlf -c core.autocrlf=false status I tested with git versions 1.9.3 and 2.1.0. Yes, this is a bug, if someone has a patch: it is welcome. Or a test case showing the problem is welcome too. Beside that, I am working on a patch to remove this restriction completely. I think that it is a legal combination to have a .gitattributes file like this: *.txt text And then set core.autocrlf=input # to avoid CRLF in the repo for e.g. *.c files, and core.eol=crlf # to have *.txt in CRLF in the working tree Which means do not touch any files, -- 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
Re: Enhancement Request: locale git option
On 12/04/2014 08:32 AM, Ulrich Windl wrote: Hi! I'm native German, but German git messages confuse me (yopu'll have to correlate them with the man pages). At the moment git uses the locale settings from the environment, so you can only change git's locale settings by changing the environment (like LANG= git ...). OTOH Git has a flexible hierachical option setting mechanism. Why not allow a Git language (locale) setting system-wde, user-wide, or repository-specific. Regards, Ulrich How about alias git='LANGUAGE=de_DE.UTF-8 git' in your ~/.profile ? (Of course you need to change de to the language you want ) -- 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
Re: [PATCH 12/13] refs.c: use a bit for ref_update have_old
On 12/04/2014 09:29 AM, Stefan Beller wrote:
Somewhat short commit message, especially the motivation is missing.
What do we gain with this patch ?
In the struct the compiler needs to layout 2*20 bytes for the sha's.
It follows an int, typically 4 bytes.
It follows another int, now with one bit.
Then we have the pointer struct ref_lock *lock,
which needs to be aligned on 4 byte boundary for a 32 bit processor,
or an 8 byte boundary for a 64 bit machine.
Our 1 bit int is padded with 31 bits.
We do not gain anything in memory consumption. (unless we declare int flags
to be 31 bits, and the compiler may join have_old and flags together
into one int in memory.
But there is a price to pay:
The generated code to fiddle out the bits from an int becomes more complicated.
You need to fetch the memory from one int, mask and shift.
Some processors can do this, out of my mind some ARM can, some can not.
We need to run the compiler to look at the generated code of course.
Signed-off-by: Stefan Beller sbel...@google.com
---
Notes:
Also a patch, which hasn't been posted on the mailing list before.
refs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/refs.c b/refs.c
index b54b5b3..2942227 100644
--- a/refs.c
+++ b/refs.c
@@ -3532,7 +3532,7 @@ struct ref_update {
unsigned char new_sha1[20];
unsigned char old_sha1[20];
int flags; /* REF_NODEREF? */
- int have_old; /* 1 if old_sha1 is valid, 0 otherwise */
+ int have_old:1; /* 1 if old_sha1 is valid, 0 otherwise */
struct ref_lock *lock;
int type;
char *msg;
--
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
Re: Deprecation warnings under XCode
On 12/03/2014 11:04 AM, David Aguilar wrote: On Tue, Dec 02, 2014 at 10:09:35PM -0500, Eric Sunshine wrote: On Tue, Dec 2, 2014 at 8:12 PM, Michael Blume blume.m...@gmail.com wrote: On Tue, Dec 2, 2014 at 4:37 PM, Eric Sunshine sunsh...@sunshineco.com wrote: On Mon, Dec 1, 2014 at 1:04 PM, Junio C Hamano gits...@pobox.com wrote: I am not a Mac person, but is this about APPLE_COMMON_CRYPTO support added in 4dcd7732 (Makefile: add support for Apple CommonCrypto facility, 2013-05-19) and be4c828b (imap-send: eliminate HMAC deprecation warnings on Mac OS X, 2013-05-19)? [...] In the Makefile we seem to have this: # Define NO_APPLE_COMMON_CRYPTO if you are building on Darwin/Mac OS X # and do not want to use Apple's CommonCrypto library. This allows you # to provide your own OpenSSL library, for example from MacPorts. which makes it sound like using APPLE_COMMON_CRYPTO is the default for Mac. Perhaps those who do want to use CommonCrypto to avoid warnings should not define that macro? It's been a long time [1] since I looked at it, but I believe that David's CommonCrypto patch series only replaced OpenSSL calls for which Apple had provided CommonCrypto replacements. If my memory is correct, there were still plenty of OpenSSL deprecations warnings remaining after his patches (the warnings which started this thread) even without defining NO_APPLE_COMMON_CRYPTO. Thus, David's patches reduced the number of warnings but did not fully eliminate them. Checking again, it still seems to be the case that Apple neglects to provide CommonCrypto replacements for these OpenSSL functions which Apple itself deprecated. [1]: http://thread.gmane.org/gmane.comp.version-control.git/224833 If there's actually no way to address this, is there a simple way to silence deprecation warnings only in this file? I only ask because overall the git build seems to be extremely quiet, and it seems valuable to preserve that, so that warnings we want to act on stick out. An individual developer can add '-Wno-deprecated-declarations' to CFLAGS to suppress these warnings, however, that's pretty much a sledge hammer which would impact deprecations from all included headers, not just Apple's. For this reason, we probably wouldn't want to make this the default. The potentially lesser evil would be this small patch (minus Gmail whitespace damage) which disables the deprecation warnings only for Apple's headers: - 8 - diff --git a/git-compat-util.h b/git-compat-util.h index 400e921..709e84f 100644 --- a/git-compat-util.h +++ b/git-compat-util.h @@ -211,6 +211,8 @@ extern char *gitbasename(char *); #endif #ifndef NO_OPENSSL +#define __AVAILABILITY_MACROS_USES_AVAILABILITY 0 +#define MAC_OS_X_VERSION_MIN_REQUIRED MAC_OS_X_VERSION_10_6 #include openssl/ssl.h #include openssl/err.h #endif - 8 - It's still mildly heavy-handed, in that it could silence legitimate Apple deprecations, but it does give us a clean build with little fuss. An alternative would be to relegate these #defines to the Darwin section of the Makefile if placing them in git-compat-util.h seems too invasive. Considering that Mac OS X is now at 10.10 and these deprecations commenced with Mac OS X 10.7 in July 2011 (3.5 years ago), and Apple still has not provided drop-in CommonCrypto equivalents, it seems unlikely that they will do so any time soon. Consequently, suppressing these otherwise unavoidable warnings may be the best we can do. I'm willing to formalize and submit this as a proper patch if it's not considered too disgusting by the powers-that-be. Tweaking those internal #defines can only come back to bite us in the future when the functions are finally ripped out. CommonCrypto seemed like a viable option at the time, but the remaining deprecated functions don't have any replacements and I wouldn't hold my breath waiting for CC to provide them. It seems like a better approach might be something like [1]. I'd even suggest ripping out all of the commoncrypto stuff if it makes the final curl-ified code easier to read. libcurl 7.30.0 ships with OS X 10.9 (maybe even father back?) so making imap-send default to using openssl for = 10.8 and curl for newer OS X seems like a good long-term solution. [1] http://thread.gmane.org/gmane.comp.version-control.git/255171 Yes, but this patch needs 7.34 :-( 7.30 (as shipped with Mac OS X 10.9) is missing the CURLOPT_LOGIN_OPTIONS Try rm imap-send.o NO_GETTEXT=yes NO_DARWIN_PORTS=Yes USE_CURL_FOR_IMAP_SEND=yes make imap-send.o -- 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
Re: Our cumbersome mailing list workflow
On 2014-12-03 03.20, Stefan Beller wrote:
On Sun, Nov 30, 2014 at 6:46 PM, Junio C Hamano gits...@pobox.com wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
It seems like a few desirable features are being talked about here, and
summarizing the discussion as centralized vs decentralized is too
simplistic. What is really important?
1. Convenient and efficient, including for newcomers
2. Usable while offline
3. Usable in pure-text mode
4. Decentralized
Something else?
So when I started overtaking the ref log series by Ronnie,
Ronnies main concern was missing reviewers time. So my idea was to
make it as accessible as possible, so the reviewing party can use their
time best. However here are a few points, I want to mention:
* Having send emails as well as uploaded it to Gerrit, I either needed
a ChangeId (Gerrit strictly requires them to track inter-patch
diffs), and the
mailing list here strictly avoids them, so I was told.
Ok, that's my problem as I wasn't following the actual procedure of the
Git development model (mailing list only).
* That's why I stopped uploads to Gerrit, so I do not need to care about the
ChangeIds any more. I am not sure if that improved the quality of my
patches
though.
* I seem to not have found the right workflow with the mailing list yet, as I
personally find copying around the inter-patch changelog very inconvenient.
Most of the regulars here just need fewer iterations, so I can understand,
that you find it less annoying. Hopefully I'll also get used to the
nit-picky things
and will require less review iterations in the future.
How are non-regulars/newcomers, who supposingly need more iterations on
a patch, supposed to handle the inter patch change log conveniently?
I tried to keep the inter patch changelog be part of the commit message and
then just before sending the email, I'd move it the non-permanent section
of
the email.
* Editing patches as text files is hard/annoying.
Not sure if I understand. Editing text files isn't that hard, we do it all the
time.
I have setup git send-email,
and that works awesome, as I'd only need one command to send off a series.
Having a step in between makes it more error-prone. So I do git
format-patch
and then inject the inter patch change log, check to remove ChangeId and
then
use git send-email.
How do you inject the inter patch change log ? Is that manually, or is it a
script ?
And at that final manual step I realized I am
far from being
perfect, so sometimes patches arrive on the mailing list, which are
sub quality
in the sense, that there are leftovers, i.e. a ChangeId
* A possible feature, which just comes to my mind:
Would it make sense for format-patch to not just show the diff
stats, but also
include, on which branch it applies? In git.git this is usually the
origin/master
branch, but dealing with patch series, building on top of each other that
may
be a good feature to have.
Thanks for the description (and everybody for the discussion)
In the hope that it may help, I can try to describe my work flow:
- Run a script to send the patch (this is a real example)
#
SRCCOMMIT=119efe90bffee688a3c37d4358667
DSTCOMMIT=$(git log --oneline -n1 | awk '{print $1}')
VERSION=-v 1
PATCHFILE=$( echo $0 | sed -e 's/\.sh$/.patch/')
GIT_TEST_LONG=t
export GIT_TEST_LONG
git am --abort || :
( test -s $PATCHFILE ||
git format-patch $VERSION -s --to=git@vger.kernel.org
--cc=tbo...@web.de --cc=mhag...@alum.mit.edu --stdout $SRCCOMMIT..$DSTCOMMIT
$PATCHFILE )
git checkout $SRCCOMMIT
git am $PATCHFILE
cd t cd .. make
(cd t ./t0001*.sh)
git imap-send $PATCHFILE
#
The script formats a patch file (if that does not exist),
applies the patch on the source commit,
runs make and then the test cases to verify that the patch works.
(For bigger patches more tests or the whole test suite should be run,
for this very isolated work it OK to run a singe test)
Once everything is OK, the patch is stored both on disc and in the Drafts
folder of the email program.
(In your case you can use grep to remove the ChangedId or to check that it had
been removed)
Now it is time to tweak the patch file with an editor:
Add what has been changed since V1
Save the patch file, run the script again to verify that the patch still
applies and works and
put it into the Drafts folder of the mail program.
(That's why I abort the git imap-send in the first round
and press ^C when the password is asked)
Start the favorite email program
(Kmail works, or Thunderbird or
every other program that can send email in plain text)
Have a final look at the patch in the email prgram
(remove the V1 from the header, change PATCH into PATCH/RFC).
Let the spell checker look at it, re-read once more.
If everything is OK, press the send button.
If I send out a V2 version, make a copy of
Re: [PATCH 04/14] hold_lock_file_for_append: pass error message back through a strbuf
On 12/03/2014 06:14 AM, Jonathan Nieder wrote:
This way, the code does not need to carefully safeguard errno to allow
callers to print a reasonable error message when they choose to do
some cleanup before die()-ing.
Fixes a bug waiting to happen where copy_fd would clobber the errno
passed back via hold_lock_file_for_append from read() or write() when
flags did not contain LOCK_DIE_ON_ERROR. Luckily the only caller uses
flags == LOCK_DIE_ON_ERROR, avoiding that bug in practice.
Reported-by: Ronnie Sahlberg sahlb...@google.com
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
The advertised bugfix.
lockfile.c | 29 ++---
lockfile.h | 3 ++-
sha1_file.c | 7 ++-
3 files changed, 18 insertions(+), 21 deletions(-)
diff --git a/lockfile.c b/lockfile.c
index b3020f3..8685c68 100644
--- a/lockfile.c
+++ b/lockfile.c
@@ -179,45 +179,36 @@ int hold_lock_file_for_update(struct lock_file *lk, const
char *path, int flags)
return fd;
}
-int hold_lock_file_for_append(struct lock_file *lk, const char *path, int flags)
+int hold_lock_file_for_append(struct lock_file *lk, const char *path,
+ int flags, struct strbuf *err)
{
int fd, orig_fd;
- struct strbuf err = STRBUF_INIT;
+
+ assert(!(flags LOCK_DIE_ON_ERROR));
+ assert(err !err-len);
What do I miss ?
In the old code we die() printing the errno when LOCK_DIE_ON_ERRORis set.
Now we die() in an assert() or two ?
And should'nt we assert in strbuf_addf() instead ?
And in general, does the commit message deserve an update?
Luckily the only caller uses flags == LOCK_DIE_ON_ERROR,
The first impression was: Why do we not simplify the code and remove
the flag completely ?
This feels somewhat like maintaining dead code, which may be used later.
(Unless it will be used in later commit, and the we could mention it here)
--
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
[PATCH v2] t0027: check the eol conversion warnings
Depending on the file content, eol parameters and .gitattributes
git add may give a warning when the eol of a file will change
when the file is checked out again.
There are 2 different warnings, either CRLF will be replaced... or
LF will be replaced
Let t0027 check for these warnings:
call create_file_in_repo() with additional parameters,
which will be used to call check_warning().
When a file has eol=lf or eol=crlf in .gitattributes, it is handled
as text and should be normalized.
Add missing test cases in t0027.
Signed-off-by: Torsten Bögershausen tbo...@web.de
---
Changes since V1:
- Simplified the diff
- Fixed a bug (LF_mix_CR.err was mixed with CRLF_mix_LF)
- Changed the commit message
t/t0027-auto-crlf.sh | 82 ++--
1 file changed, 66 insertions(+), 16 deletions(-)
diff --git a/t/t0027-auto-crlf.sh b/t/t0027-auto-crlf.sh
index 2a4a6c1..452320d 100755
--- a/t/t0027-auto-crlf.sh
+++ b/t/t0027-auto-crlf.sh
@@ -55,16 +55,41 @@ create_gitattributes () {
esac
}
+check_warning () {
+ case $1 in
+ LF_CRLF) grep LF will be replaced by CRLF $2;;
+ CRLF_LF) grep CRLF will be replaced by LF $2;;
+ '')
+ expect
+ grep will be replaced by $2 actual
+ test_cmp expect actual
+ ;;
+ *) false ;;
+ esac
+}
+
create_file_in_repo () {
crlf=$1
attr=$2
+ lfname=$3
+ crlfname=$4
+ lfmixcrlf=$5
+ lfmixcr=$6
+ crlfnul=$7
create_gitattributes $attr
+ pfx=crlf_${crlf}_attr_${attr}
for f in LF CRLF LF_mix_CR CRLF_mix_LF CRLF_nul
do
- pfx=crlf_${crlf}_attr_${attr}_$f.txt
- cp $f $pfx git -c core.autocrlf=$crlf add $pfx
+ fname=${pfx}_$f.txt
+ cp $f $fname
+ git -c core.autocrlf=$crlf add $fname 2${pfx}_$f.err
done
- git commit -m core.autocrlf $crlf
+ git commit -m core.autocrlf $crlf
+ check_warning $lfname ${pfx}_LF.err
+ check_warning $crlfname ${pfx}_CRLF.err
+ check_warning $lfmixcrlf ${pfx}_CRLF_mix_LF.err
+ check_warning $lfmixcr ${pfx}_LF_mix_CR.err
+ check_warning $crlfnul ${pfx}_CRLF_nul.err
}
check_files_in_repo () {
@@ -140,22 +165,47 @@ test_expect_success 'setup master' '
'
-test_expect_success 'create files' '
- create_file_in_repo false
- create_file_in_repo true
- create_file_in_repo input
- create_file_in_repo false auto
- create_file_in_repo true auto
- create_file_in_repo input auto
+warn_LF_CRLF=LF will be replaced by CRLF
+warn_CRLF_LF=CRLF will be replaced by LF
+
+test_expect_success 'add files empty attr' '
+ create_file_in_repo false
+ create_file_in_repo true LF_CRLF LF_CRLF
+ create_file_in_repo input CRLF_LF CRLF_LF
+'
+
+test_expect_success 'add files attr=auto' '
+ create_file_in_repo false auto CRLF_LF CRLF_LF
+ create_file_in_repo true auto LF_CRLF LF_CRLF
+ create_file_in_repo input auto CRLF_LF CRLF_LF
+'
+
+test_expect_success 'add files attr=text' '
+ create_file_in_repo false text CRLF_LF CRLF_LF
CRLF_LF
+ create_file_in_repo true text LF_CRLF LF_CRLF
LF_CRLF
+ create_file_in_repo input text CRLF_LF CRLF_LF
CRLF_LF
+'
+
+test_expect_success 'add files attr=-text' '
+ create_file_in_repo false -text
+ create_file_in_repo true -text
+ create_file_in_repo input -text
+'
+
+test_expect_success 'add files attr=lf' '
+ create_file_in_repo false lf CRLF_LF CRLF_LF
CRLF_LF
+ create_file_in_repo true lf CRLF_LF CRLF_LF
CRLF_LF
+ create_file_in_repo input lf CRLF_LF CRLF_LF
CRLF_LF
+'
- create_file_in_repo false text
- create_file_in_repo true text
- create_file_in_repo input text
+test_expect_success 'add files attr=crlf' '
+ create_file_in_repo false crlf LF_CRLF LF_CRLF
LF_CRLF
+ create_file_in_repo true crlf LF_CRLF LF_CRLF
LF_CRLF
+ create_file_in_repo input crlf LF_CRLF LF_CRLF
LF_CRLF
+'
- create_file_in_repo false -text
- create_file_in_repo true -text
- create_file_in_repo input -text
+test_expect_success 'create files cleanup' '
rm -f *.txt
git reset --hard
'
--
1.9.1.dirty
--
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
Re: [PATCH] compat: convert modes to use portable file type values
On 2014-11-30 03.41, David Michael wrote:
Some minor comments:
+static inline mode_t mode_native_to_git(mode_t native_mode)
+{
+ if (S_ISREG(native_mode))
+ return 010 | (native_mode 0);
+ else if (S_ISDIR(native_mode))
+ return 004 | (native_mode 0);
+ else if (S_ISLNK(native_mode))
+ return 012 | (native_mode 0);
+ else if (S_ISBLK(native_mode))
+ return 006 | (native_mode 0);
+ else if (S_ISCHR(native_mode))
+ return 002 | (native_mode 0);
+ else if (S_ISFIFO(native_mode))
+ return 001 | (native_mode 0);
+ else /* Non-standard type bits were given. */
+ return native_mode 0;
+}
Could the code be more human-readable ?
static inline mode_t mode_native_to_git(mode_t native_mode)
{
int perm_bits = native_mode 0;
if (S_ISREG(native_mode))
return 010 | perm_bits;
if (S_ISDIR(native_mode))
return 004 | perm_bits;
if (S_ISLNK(native_mode))
return 012 | perm_bits;
if (S_ISBLK(native_mode))
return 006 | perm_bits;
if (S_ISCHR(native_mode))
return 002 | perm_bits;
if (S_ISFIFO(native_mode))
return 001 | perm_bits;
/* Non-standard type bits were given. */
/* Shouldn't we die() here ?? */
return perm_bits;
}
--
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
Re: Deprecation warnings under XCode
On 12/01/2014 04:02 AM, Michael Blume wrote: I have no idea whether this should concern anyone, but my mac build of git shows CC imap-send.o imap-send.c:183:36: warning: 'ERR_error_string' is deprecated: first deprecated in OS X 10.7 [-Wdeprecated-declarations] fprintf(stderr, %s: %s\n, func, ERR_error_string(ERR_get_error(), NULL)); ^ [] Isn't the warning a warning ;-) I don't see this warnings because my openssl comes from /opt/local/include (Mac ports) Does anybody know which new functions exist in Mac OS X versions = 10.7 ? -- 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
Re: [PATCH] compat: convert modes to use portable file type values
On 12/01/2014 04:40 AM, David Michael wrote:
On Sun, Nov 30, 2014 at 3:16 PM, Torsten Bögershausen tbo...@web.de wrote:
[snip]
Could the code be more human-readable ?
static inline mode_t mode_native_to_git(mode_t native_mode)
{
int perm_bits = native_mode 0;
if (S_ISREG(native_mode))
return 010 | perm_bits;
if (S_ISDIR(native_mode))
return 004 | perm_bits;
if (S_ISLNK(native_mode))
return 012 | perm_bits;
if (S_ISBLK(native_mode))
return 006 | perm_bits;
if (S_ISCHR(native_mode))
return 002 | perm_bits;
if (S_ISFIFO(native_mode))
return 001 | perm_bits;
/* Non-standard type bits were given. */
/* Shouldn't we die() here ?? */
return perm_bits;
}
Sure, I can send an updated patch with the new variable and without the elses.
Regarding the question in the last comment: I was assuming if this
case was ever reached, Git would handle the returned mode the same way
as if it encountered an unknown/non-standard file type on a normal
operating system, which could die() if needed in the function that
called stat().
Should I send an updated patch that die()s there?
David
Not yet, please wait with a V2 patch until I finished my thinking ;-)
I take back the suggestion with the die(). I was thinking how to handle
unforeseen types, which may show up on the z/OS some day,
So die() is not a good idea, it is better to ignore them, what the code
does.
Knowing that Git does not track block devices, nor character devices nor
sockets,
the above code could be simplyfied even more, by mapping everything which
is not a directory, a file or a softlink to device type 0)
This is just a suggestion, I want to here from others as well:
int perm_bits = native_mode 0;
if (S_ISREG(native_mode))
return 010 | perm_bits;
if (S_ISDIR(native_mode))
return 004 | perm_bits;
if (S_ISLNK(native_mode))
return 012 | perm_bits;
/* Git does not track S_IFCHR, S_IFBLK, S_IFIFO, S_IFSOCK */
return perm_bits;
--
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
Re: Our cumbersome mailing list workflow
On 2014-11-25 01.28, Michael Haggerty wrote: [] Let me list the aspects of our mailing list workflow that I find cumbersome as a contributor and reviewer: * Submitting patches to the mailing list is an ordeal of configuring format-patch and send-email and getting everything just right, using instructions that depend on the local environment. Typically everything fits into ~/.gitconfig, which can be carried around on a USB-Stick. Is there any details which I miss, or howtows we can improve ? We saw that hardly any GSoC applicants were able to get it right on their first attempt. Submitting a patch series should be as simple as git push. * Once patches are submitted, there is no assurance that you (Junio) will apply them to your tree at the same point that the submitter developed and tested them. * The branch name that you choose for a patch series is not easily derivable from the patches as they appeared in the mailing list. Trying to figure out whether/where the patches exist in your tree is a largely manual task. The reverse mapping, from in-tree commit to the email where it was proposed, is even more difficult to infer. * Your tree has no indication of which version of a patch series (v1, v2, etc) is currently applied. The previous three points combine to make it awkward to get patches into my local repository to review or test. There are two alternatives, both cumbersome and imprecise: * I do git fetch gitster, then try to figure out whether the branch I'm interested in is present, what its name is, and whether the version in your tree is the latest version, then git checkout xy/foobar. There are 12 branches from mh/, so it should be possible to find the name, und run git log gitster/xy/fix_this_bug or so. Even more important, this branch is the single point of truth, because this branch may be merged eventually, and nothing else. * Or I save the emails to a temporary directory (awkward because, Oh Horror, I use Thunderbird and not mutt as email client), hope that I've guessed the right place to apply them, run git am, and later try to remember to clean up the temporary directory. Is there a mutt howto somewhere? * Once I've done that, the supplemental comments from the emails (the cover letter and the text under the ---) are nowhere available in the Git repository. So if I want to see the changes in context plus the supplemental comments, I have to jump back and forth between email client and Git repo. Plus I have to jump around the rest of the email thread to see what comments other reviewers have already made about the series. * Following patch series across iterations is also awkward. To compare two versions, I have to first get both patch series into my repo, which involves digging through the ML history to find older versions, followed by the git am steps. Often submitters are nice enough to put links to previous versions of their patch series in their cover letters, but the links are to a web-based email archive, from which it is even more awkward to grab and apply patches. So in practice I then go back to my email client and search my local archive for my copy of the same email that was referenced in the archive, and apply the patch from there. Finding comments about old versions of a patch series is nearly as much work. In short: We can ask every contributor, if the patch send to the mailing list is available on a public Git-repo, and what the branch name is, like _V2.. Does this makes sense ? As an alternative, you can save the branches locally, after running git-am once, just keep the branch. [] I did enjoy the variety of reviewing some patch series using Gerrit. It is nice that it tracks the evolution of a patch from version to version, and that the comments made on all versions of a patch are summarized in a single place. This makes it easier to avoid commenting on issues that other reviewers have already noted and easier to check that your own comments have been addressed by later versions of the patch. On the other hand, Gerrit seems strongly focused on individual patches rather than on patch series (which might not match our workflow so well), the UI is overwhelming (though I think one could get quite productive with it if one used it every day), and the notification emails come in blizzards. Michael [1] Disclaimer: I work for GitHub. I like Gerrit as well. But it is less efficient to use, a WEB browser is slower (often), and you need to use the mouse... However, if you put your patches on Gerrit, and add the link in your cover-letter, it may be worth a trial. But there is another thing: Once a patch is send out, I would ask the sender to wait and collect comments at least 24 hours before sending a V2. We all living in different time zones, so please let the world spin once. My feeling is that a patch 5 commits should have a waiting time 5 days, otherwise I start reviewing V1, then V2 comes,
Re: [PATCH] t1402: check to delete broken refs
On 11/25/2014 11:56 PM, Stefan Beller wrote: From: Ronnie Sahlberg sahlb...@google.com Signed-off-by: Ronnie Sahlberg sahlb...@google.com Signed-off-by: Stefan Beller sbel...@google.com --- This was also part of the ongoing series from Ronnie. But I think the patch in this form is rather independant, documenting the current state of git branch -d, so it's fine to have it in now. t/t1402-check-ref-format.sh | 8 1 file changed, 8 insertions(+) diff --git a/t/t1402-check-ref-format.sh b/t/t1402-check-ref-format.sh index e5dc62e..08af156 100755 --- a/t/t1402-check-ref-format.sh +++ b/t/t1402-check-ref-format.sh @@ -197,4 +197,12 @@ invalid_ref_normalized 'heads///foo.lock' invalid_ref_normalized 'foo.lock/bar' invalid_ref_normalized 'foo.lock///bar' +test_expect_failure 'git branch -d can delete ref with broken sha1' ' + echo pointing nowhere .git/refs/heads/brokensha1 + test_when_finished rm -f .git/refs/heads/brokensha1 + git branch -d brokensha1 + git branch output + ! grep -e brokensha1 output +' Do we need grep -e here ? It does not give us anything in the pattern we are using. -e PATTERN, --regexp=PATTERN Use PATTERN as the pattern. This can be used to specify multiple search patterns, or to protect a pattern beginning with a hyphen (-). (-e is specified by POSIX.) (And we do not need the either, there is no space in brokensha1) We can simply use: ! grep brokensha1 output + test_done -- 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
Re: [PATCH RFC] CYGWIN: avoid implicit declaration warning
It depends what we mean with old: cygwin 1.5 is old, and I lost my test installation this summer: One netbook was converted from XP to Linux, the other machine needs to be re-installed and CYGWIN 1.5 is no longer available for download. I can confirm that Ramsays patch works with CYGWIN 1.7 32 Bit. Another update: The test suite passes, except t5000 - not ok 48 - archive and :(glob) fatal: pathspec '*.abc' did not match any files -- 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
Re: [PATCH RFC] CYGWIN: avoid implicit declaration warning
Patch looks good to me. Do you know if this has been reported to the Cygwin maintainers? The behavior seems counterintuitive --- I would expect _GNU_SOURCE to override everything else (since I thought that was the point of _GNU_SOURCE). I don't know, it seems that CYGWIN is now in class with some BSD and Mac OS X. Actually Ramsay did send a patch, so that this is obsolete now. -- 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
Re: [PATCH] t5000 on Windows: do not mistake sh.exe as sh
diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh index d01bbdc..4b68bba 100755 --- a/t/t5000-tar-tree.sh +++ b/t/t5000-tar-tree.sh @@ -101,7 +101,7 @@ test_expect_success \ ten=0123456789 hundred=$ten$ten$ten$ten$ten$ten$ten$ten$ten$ten echo long filename a/four$hundred mkdir a/bin - cp /bin/sh a/bin + test-genrandom frotz 50 a/bin/sh That's a fast respose :-) The patch works for me, Thanks -- 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
Re: [PATCHv2] add: ignore only ignored files
On 2014-11-24 18.41, Junio C Hamano wrote: ... Do we refer to t/README from CodingGuidelines where we tell the developers to always write tests to prevent other people from breaking tomorrow what you did today? If not, perhaps that is what needs to be added. That might make sense. It might also be that Torsten simply overlooked it when asking his question (i.e., there is nothing to fix, documentation is not always read completely, and we can move on). Thanks, until yesterday I was unaware of t/README, but now I am :-) -- 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
[PATCH RFC] CYGWIN: avoid implicit declaration warning
gcc under cygwin reports several warnings like this: warning: implicit declaration of function 'memmem' [-Wimplicit-function-declaration] This has been observed under CYGWIN-32 with GCC 4.7.3 as well as CYGWIN-64 with gcc v4.8.3-5 x86-64 Do not #define _XOPEN_SOURCE 600 for CYGWIN. Reported-by: Ramsay Jones ram...@ramsay1.demon.co.uk Signed-off-by: Torsten Bögershausen tbo...@web.de --- This may be a start for a patch, tested under CYGWIN-32, both Windows7 and XP git-compat-util.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/git-compat-util.h b/git-compat-util.h index 400e921..cef2691 100644 --- a/git-compat-util.h +++ b/git-compat-util.h @@ -75,7 +75,8 @@ # endif #elif !defined(__APPLE__) !defined(__FreeBSD__) !defined(__USLC__) \ !defined(_M_UNIX) !defined(__sgi) !defined(__DragonFly__) \ - !defined(__TANDEM) !defined(__QNX__) !defined(__MirBSD__) + !defined(__TANDEM) !defined(__QNX__) !defined(__MirBSD__) \ + !defined(__CYGWIN__) #define _XOPEN_SOURCE 600 /* glibc2 and AIX 5.3L need 500, OpenBSD needs 600 for S_ISLNK() */ #define _XOPEN_SOURCE_EXTENDED 1 /* AIX 5.3L needs this */ #endif -- 1.9.1.dirty -- 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
Re: [PATCH RFC] CYGWIN: avoid implicit declaration warning
On 2014-11-24 00.15, Ramsay Jones wrote: On 23/11/14 18:53, Junio C Hamano wrote: Ramsay Jones ram...@ramsay1.demon.co.uk writes: On 23/11/14 14:16, Torsten Bögershausen wrote: gcc under cygwin reports several warnings like this: warning: implicit declaration of function 'memmem' [-Wimplicit-function-declaration] This has been observed under CYGWIN-32 with GCC 4.7.3 as well as CYGWIN-64 with gcc v4.8.3-5 x86-64 Heh, thanks for looking into this. Your email came at a good time, since I was just about to boot my old laptop into windows XP to test my patch on 32-bit cygwin! (If I had not been watching the F1 Grand Prix on TV, I would already have done so! ;-) ). It's been a while since I updated my 32-bit cygwin installation (about 6 months) but I'm a little surprised you found this issue with gcc 4.7.3 (I'm _almost_ tempted to boot that laptop anyway just to see what versions of software it is running). So you have an old installation to check how well the patched version is accepted by the old set of header files? ... I can, indeed, use this old installation to test this on 32-bit cygwin. sigh, I thought I had dodged that bullet! ;-) It depends what we mean with old: cygwin 1.5 is old, and I lost my test installation this summer: One netbook was converted from XP to Linux, the other machine needs to be re-installed and CYGWIN 1.5 is no longer available for download. I can confirm that Ramsays patch works with CYGWIN 1.7 32 Bit. -- 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
Re: [PATCHv2] add: ignore only ignored files
+test_expect_success 'error out when attempting to add ignored ones but add others' ' +touch a.if +test_must_fail git add a.?? +! (git ls-files | grep \\.ig) +(git ls-files | grep a.if) +' I am somewhat allergic to pipes in our test suite, because they can mask errors (especially with a negated grep, because we do not know if they correctly produced any output at all). But I guess this is matching the surrounding code, and it is quite unlikely for `ls-files` to fail in any meaningful way here. So I think it's fine. -Peff 2 small comments: Why the escaped \\.ig and the unescaped a.if ? The other question, this is a more general one, strikes me every time I see ! grep Should we avoid it by writing test_must_fail instead of ! ? (The current code base has a mixture of both) The following came into my mind when working on another grepy thing, and it may be unnecessary clumsy: test_expect_success 'error out when attempting to add ignored ones but add others' ' touch a.if test_must_fail git add a.?? git ls-files files.txt test_must_fail grep a.ig files.txt /dev/null grep a.if files.txt /dev/null rm files.txt ' (It feels as if there should be a grepnot ;-) The 3rd comment: Thanks for taking this up! -- 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
Re: [PATCHv2] add: ignore only ignored files
On 2014-11-22 20.19, Jeff King wrote: On Sat, Nov 22, 2014 at 03:59:12PM +0100, Torsten Bögershausen wrote: +test_expect_success 'error out when attempting to add ignored ones but add others' ' + touch a.if + test_must_fail git add a.?? + ! (git ls-files | grep \\.ig) + (git ls-files | grep a.if) +' [...] 2 small comments: Why the escaped \\.ig and the unescaped a.if ? I agree that is inconsistent, and I don't see any reason for it. The other question, this is a more general one, strikes me every time I see ! grep Should we avoid it by writing test_must_fail instead of ! ? No. The point of test_must_fail over ! is to check that not only does the command fail, but it fails with a clean exit rather than a signal death. The general philosophy is that this is useful for git (which we are testing), and not for third-party tools that we are using to check our outputs. In other words, we do not expect grep to segfault, and do not need to bother checking it. I do not think there is a real _downside_ to using test_must_fail for grep, except that it is a bit more verbose. We may burn CPU cycles And that describes the goal, of course; actual implementation has been less consistent. Possibly because I do not know that those instructions are written down anywhere. There is a hint in test-lib-functions.sh, but a short notice in CodingGuidelines could be useful, once there is an agreement about grep, which I think we have. We usually catch such things in review these days, but there are many inconsistent spots in the existing suite. The following came into my mind when working on another grepy thing, and it may be unnecessary clumsy: test_expect_success 'error out when attempting to add ignored ones but add others' ' touch a.if test_must_fail git add a.?? git ls-files files.txt test_must_fail grep a.ig files.txt /dev/null grep a.if files.txt /dev/null rm files.txt Right, my allergic to pipes was basically advocating using a tempfile. But as noted above, it should remain ! grep here. And there is no need to redirect the output of grep, as the test suite does it already (in fact, it is preferable not to, because somebody debugging the test with -v will get more output). -Peff I counted 19 test_must_fail grep under t/*sh, and 201 ! grep. As a general rule for further review of shell scripts can we say ? ! git# incorrect, we don't capture e.g. segfaults of signal test_must_fail grep # correct, but not preferred for new code ! grep # preferred for new code test_must_fail git # correct -- 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
[PATCH v3] Improve the filemode trustability check
Some file systems do not support the executable bit: a) The user executable bit is always 0, e.g. VFAT mounted with -onoexec b) The user executable bit is always 1, e.g. cifs mounted with -ofile_mode=0755 c) There are system where user executable bit is 1 even if it should be 0 like b), but the file mode can be maintained locally. chmod -x changes the file mode from 0766 to 0666, until the file system is unmounted and remounted and the file mode is 0766 again. This been observed when a Windows machine with NTFS exports a share to Mac OS X via smb or afp. Case a) and b) are handled by the current code. Case c) qualifies as non trustable executable bit and core.filemode should be false, but this is currently not done. Detect when .git/config has the user executable bit set after creat(.git/config, 0666) and set core.filemode to false. Signed-off-by: Torsten Bögershausen tbo...@web.de --- Thanks for the review, I never paid attention to the re-init. The following works for me: builtin/init-db.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/builtin/init-db.c b/builtin/init-db.c index aab44d2..2619ca5 100644 --- a/builtin/init-db.c +++ b/builtin/init-db.c @@ -256,6 +256,8 @@ static int create_default_files(const char *template_path) !lstat(path, st2) st1.st_mode != st2.st_mode !chmod(path, st1.st_mode)); + if (filemode !reinit (st1.st_mode S_IXUSR)) + filemode = 0; } git_config_set(core.filemode, filemode ? true : false); -- 2.0.0.GIT -- 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
Re: [PATCH RFC] t0027: check the eol conversion warnings
On 20.11.14 23:37, Junio C Hamano wrote: --- At a glance it is very hard to see what we might be _losing_ with this change that claims to add new kinds of tests on top of existing ones. I am guessing that add-check-warn roughly corresponds to the old create-file-in-repo but they have different calling conventions, or something? Perhaps split it into two patches (or more), each of which does one thing and one thing well? I suspect that even with a two-patch split (e.g. the first of which only renames the function without adding the new grep in error messages that could be localized and give false failures code, and the second adds the lf/crlf stuff) might make this at least readable. I dunno. We shouldn't loose anything. The diff is hard to read, as some code is re-defined and re-used (and a diff side-by-side looks nicer than the patch) I will come back with a new commit message, which should explain things better ( or a 2-stepped patch) The long term idea is to improve the gray areas in convert.c, and to do that we need a reliable test frame work, to see what is improved or broken. -- 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
[PATCH v2] Improve the filemode trustability check
Some file systems do not support the executable bit:
a) The user executable bit is always 0, e.g. VFAT mounted with -onoexec
b) The user executable bit is always 1, e.g. cifs mounted with -ofile_mode=0755
c) There are system where user executable bit is 1 even if it should be 0
like b), but the file mode can be maintained locally. chmod -x changes the
file mode from 0766 to 0666, until the file system is unmounted and
remounted and the file mode is 0766 again.
This been observed when a Windows machine with NTFS exports a share to
Mac OS X via smb or afp.
Case a) and b) are handled by the current code.
Case c) qualifies as non trustable executable bit and core.filemode
should be false, but this is currently not done.
Detect when .git/config has the user executable bit set after
creat(.git/config, 0666) and set core.filemode to false.
Signed-off-by: Torsten Bögershausen tbo...@web.de
---
Changes since V1:
- Improved commit msg (hopefully)
- Simplified the patch
builtin/init-db.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/builtin/init-db.c b/builtin/init-db.c
index aab44d2..195a88b 100644
--- a/builtin/init-db.c
+++ b/builtin/init-db.c
@@ -252,7 +252,8 @@ static int create_default_files(const char *template_path)
filemode = TEST_FILEMODE;
if (TEST_FILEMODE !lstat(path, st1)) {
struct stat st2;
- filemode = (!chmod(path, st1.st_mode ^ S_IXUSR)
+ filemode = (!(st1.st_mode S_IXUSR)
+ !chmod(path, st1.st_mode ^ S_IXUSR)
!lstat(path, st2)
st1.st_mode != st2.st_mode
!chmod(path, st1.st_mode));
--
2.0.0.GIT
--
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
[PATCH RFC] t0027: check the eol conversion warnings
Add tests to check the warnings when adding file with eol=lf and eol=crlf.
Add a function check_warning() to check the warnings on stderr
CRLF will be replaced... or LF will be replaced...
Signed-off-by: Torsten Bögershausen tbo...@web.de
---
t/t0027-auto-crlf.sh | 103 +++
1 file changed, 80 insertions(+), 23 deletions(-)
diff --git a/t/t0027-auto-crlf.sh b/t/t0027-auto-crlf.sh
index 2a4a6c1..9570947 100755
--- a/t/t0027-auto-crlf.sh
+++ b/t/t0027-auto-crlf.sh
@@ -55,16 +55,36 @@ create_gitattributes () {
esac
}
-create_file_in_repo () {
+check_warning () {
+ case $1 in
+ LF_CRLF) grep LF will be replaced by CRLF $2;;
+ CRLF_LF) grep CRLF will be replaced by LF $2;;
+ *) test_cmp /dev/null $2;;
+ esac
+}
+
+add_check_warn () {
crlf=$1
attr=$2
+ lfname=$3
+ crlfname=$4
+ lfmixcrlf=$5
+ lfmixcr=$6
+ crlfnul=$7
create_gitattributes $attr
+ pfx=crlf_${crlf}_attr_${attr}
for f in LF CRLF LF_mix_CR CRLF_mix_LF CRLF_nul
do
- pfx=crlf_${crlf}_attr_${attr}_$f.txt
- cp $f $pfx git -c core.autocrlf=$crlf add $pfx
+ fname=${pfx}_$f.txt
+ cp $f $fname
+ git -c core.autocrlf=$crlf add $fname 2${pfx}_$f.err
done
- git commit -m core.autocrlf $crlf
+ git commit -m core.autocrlf $crlf
+ check_warning $lfname ${pfx}_LF.err
+ check_warning $crlfname ${pfx}_CRLF.err
+ check_warning $lfmixcrlf ${pfx}_LF_mix_CR.err
+ check_warning $lfmixcr ${pfx}_LF_mix_CR.err
+ check_warning $crlfnul ${pfx}_CRLF_nul.err
}
check_files_in_repo () {
@@ -140,50 +160,87 @@ test_expect_success 'setup master' '
'
-test_expect_success 'create files' '
- create_file_in_repo false
- create_file_in_repo true
- create_file_in_repo input
- create_file_in_repo false auto
- create_file_in_repo true auto
- create_file_in_repo input auto
+warn_LF_CRLF=LF will be replaced by CRLF
+warn_CRLF_LF=CRLF will be replaced by LF
+
+test_expect_success 'add files empty attr' '
+ add_check_warn false
+ add_check_warn true LF_CRLF
+ add_check_warn input CRLF_LF
+'
- create_file_in_repo false text
- create_file_in_repo true text
- create_file_in_repo input text
+test_expect_success 'add files attr=auto' '
+ add_check_warn false auto CRLF_LF
+ add_check_warn true auto LF_CRLF
+ add_check_warn input auto CRLF_LF
+'
- create_file_in_repo false -text
- create_file_in_repo true -text
- create_file_in_repo input -text
+test_expect_success 'add files attr=text' '
+ add_check_warn false text CRLF_LF
CRLF_LF
+ add_check_warn true text LF_CRLF LF_CRLF LF_CRLF
+ add_check_warn input text CRLF_LF
CRLF_LF
+'
+
+test_expect_success 'add files attr=-text' '
+ add_check_warn false -text
+ add_check_warn true -text
+ add_check_warn input -text
+'
+
+test_expect_success 'add files attr=lf' '
+ add_check_warn false lf CRLF_LF
CRLF_LF
+ add_check_warn true lf CRLF_LF
CRLF_LF
+ add_check_warn input lf CRLF_LF
CRLF_LF
+'
+
+test_expect_success 'add files attr=crlf' '
+ add_check_warn false crlf LF_CRLF LF_CRLF LF_CRLF
+ add_check_warn true crlf LF_CRLF LF_CRLF LF_CRLF
+ add_check_warn input crlf LF_CRLF LF_CRLF LF_CRLF
+'
+
+test_expect_success 'create files cleanup' '
rm -f *.txt
git reset --hard
'
-test_expect_success 'commit empty gitattribues' '
+test_expect_success 'check file in repo empty gitattribues' '
check_files_in_repo false LF CRLF CRLF_mix_LF LF_mix_CR
CRLF_nul
check_files_in_repo trueLF LF LF LF_mix_CR
CRLF_nul
check_files_in_repo input LF LF LF LF_mix_CR CRLF_nul
'
-test_expect_success 'commit text=auto' '
+test_expect_success 'check file in repo text=auto' '
check_files_in_repo false auto LF LF LF LF_mix_CR
CRLF_nul
check_files_in_repo true auto LF LF LF LF_mix_CR
CRLF_nul
check_files_in_repo input auto LF LF LF LF_mix_CR CRLF_nul
'
-test_expect_success 'commit text' '
+test_expect_success 'check file in repo text' '
check_files_in_repo false text LF LF LF LF_mix_CR LF_nul
check_files_in_repo true text LF LF LF
[PATCH] Improve the filemode trustability check
Some file systems do not support the executable bit:
a) The user executable bit is always 0, e.g. VFAT mounted with -onoexec
b) The user executable bit is always 1, e.g. cifs mounted with -ofile_mode=0755
c) There are system where user executable bit is 1 even if it should be 0
like b), but the file mode can be maintained locally. chmod -x changes the
file mode from 0766 to 0666, until the file system is unmounted and
remounted and the file mode is 0766 again.
This been observed when a Windows machine with NTFS exports a share to
Mac OS X via smb or afp.
Case a) and b) are handled by the current code.
Case c) qualifies as non trustable executable bit and core.filemode
should be false, but this is not done.
Solution:
Detect when .git/config has the user executable bit set after
creat(.git/config, 0666) and set core.filemode to false.
Signed-off-by: Torsten Bögershausen tbo...@web.de
---
This should go on top of mh/config-flip-xbit-back-after-checking
Michael, thanks for the test case.
And no, I havent seen any systems with behaving like d)
builtin/init-db.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin/init-db.c b/builtin/init-db.c
index aab44d2..9b50dde 100644
--- a/builtin/init-db.c
+++ b/builtin/init-db.c
@@ -252,10 +252,10 @@ static int create_default_files(const char *template_path)
filemode = TEST_FILEMODE;
if (TEST_FILEMODE !lstat(path, st1)) {
struct stat st2;
- filemode = (!chmod(path, st1.st_mode ^ S_IXUSR)
+ filemode = (!chmod(path, st1.st_mode | S_IXUSR)
!lstat(path, st2)
st1.st_mode != st2.st_mode
- !chmod(path, st1.st_mode));
+ !chmod(path, st1.st_mode (~S_IXUSR)));
}
git_config_set(core.filemode, filemode ? true : false);
--
1.9.1.dirty
--
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
Re: [PATCH v2 1/2] create_default_files(): don't set u+x bit on $GIT_DIR/config
On 11/17/2014 02:40 AM, Eric Sunshine wrote:
On Sun, Nov 16, 2014 at 2:21 AM, Michael Haggerty mhag...@alum.mit.edu wrote:
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 original state
itself, instead relying on the subsequent call to git_config_set() to
re-write the config file with correct permissions.
But ever since
daa22c6f8d config: preserve config file permissions on edits (2014-05-06)
git_config_set() copies the permissions from the old config file to
the new one. This is a good change in and of itself, but it interacts
badly with create_default_files()'s sloppiness, causing git init to
leave the executable bit set on $GIT_DIR/config.
So change create_default_files() to reset the permissions on
$GIT_DIR/config after its test.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
Should this patch include a test in t1300 to ensure that this bug does
not resurface (and to prove that this patch indeed fixes it)?
builtin/init-db.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/builtin/init-db.c b/builtin/init-db.c
index 56f85e2..4c8021d 100644
--- a/builtin/init-db.c
+++ b/builtin/init-db.c
@@ -255,6 +255,7 @@ static int create_default_files(const char *template_path)
filemode = (!chmod(path, st1.st_mode ^ S_IXUSR)
!lstat(path, st2)
st1.st_mode != st2.st_mode);
+ filemode = !chmod(path, st1.st_mode);
}
git_config_set(core.filemode, filemode ? true : false);
--
Sorry for the late reply, I actually had prepared a complete different patch
for a different problem, but it touches the very same lines of code.
(And we may want to add a
!chmod(path, st1.st_mode ~S_IXUSR)
at the end of the operation)
There are systems when a file created with 666 have 766, and we
do not handle this situation yet.
Michael, if there is a chance that you integrate my small code changes
in your patch ?
-
commit 3228bedef6d45bfaf8986b6367f9388738476345
Author: Torsten Bögershausen tbo...@web.de
Date: Sun Oct 19 00:15:00 2014 +0200
Improve the filemode trustability check
Some file systems do not fully support the executable bit:
a) The user executable bit is always 0
b) The user executable bit is always 1
c) Is similar to b):
When a file is created with mode 0666 the file mode on disc is 766
and the user executable bit is 1 even if it should be 0 like b)
There are smbfs implementations where the file mode can be
maintained
locally and chmod -x changes the file mode from 0766 to 0666.
When the file system is unmounted and remounted,
the file mode is 0766 and executable bit is 1 again.
A typical example for a) is a VFAT drive mounted with -onoexec,
or cifs with -ofile_mode=0644.
b) is VFAT mounted with -oexec or cifs is mounted with -ofile_mode=0755
The behaviour described in c) has been observed when a Windows
machine with
NTFS exports a share via smb (or afp) to Mac OS X.
(CIFS is an enhanced version of SMB
The command to mount on the command line may differ,
e.g mount.cifs under Linux or mount_smbfs under Mac OS X)
Case a) and b) are detected by the current code.
Case c) qualifies as non trustable executable bit,
and core.filemode should be false by default.
Solution:
Detect when .git/config has the user executable bit set after
creat(.git/config, 0666) and set core.filemode to false.
diff --git a/builtin/init-db.c b/builtin/init-db.c
index 587a505..d3e4fb3 100644
--- a/builtin/init-db.c
+++ b/builtin/init-db.c
@@ -249,13 +249,11 @@ static int create_default_files(const char
*template_path)
strcpy(path + len, config);
/* Check filemode trustability */
-filemode = TEST_FILEMODE;
-if (TEST_FILEMODE !lstat(path, st1)) {
-struct stat st2;
-filemode = (!chmod(path, st1.st_mode ^ S_IXUSR)
-!lstat(path, st2)
-st1.st_mode != st2.st_mode);
-}
+filemode = TEST_FILEMODE
+!lstat(path, st1) !(st1.st_mode S_IXUSR)
+!chmod(path, st1.st_mode | S_IXUSR)
+!lstat(path, st1) (st1.st_mode S_IXUSR);
+
git_config_set(core.filemode, filemode ? true : false);
if (is_bare_repository())
--
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
Re: [PATCH 1/2] create_default_files(): don't set u+x bit on $GIT_DIR/config
On 2014-11-15 08.26, Michael Haggerty wrote: The whole thing looks good to me, some minor comments below git_config_set() copies the permissions from the old config file to the new one. This is a good change in and of itself, but it interacts badly with create_default_files()'s sloppiness, causing git init to leave the executable bit set on $GIT_DIR/config. So change create_default_files() to reset the permissions on s/permissions/executable bit/ ? $GIT_DIR/config after its test. Signed-off-by: Michael Haggerty mhag...@alum.mit.edu --- builtin/init-db.c | 1 + 1 file changed, 1 insertion(+) diff --git a/builtin/init-db.c b/builtin/init-db.c index 56f85e2..95ca5e4 100644 --- a/builtin/init-db.c +++ b/builtin/init-db.c @@ -255,6 +255,7 @@ static int create_default_files(const char *template_path) filemode = (!chmod(path, st1.st_mode ^ S_IXUSR) !lstat(path, st2) st1.st_mode != st2.st_mode); + chmod(path, st1.st_mode); A blind chmod() is good, but I think checking the return code is better. filemode = (!chmod(path, st1.st_mode)); } git_config_set(core.filemode, filemode ? true : false); -- 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
Re: [RFC] On watchman support
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 a) and b) already exist. c) Can be convenient to have, in order to do benchmarking and testing. When the UNTR extension is not found, Git can give an error, saying something like this: No mtime information found, use git update-index --untracked-cache d) does not yet exist Of course we may want to configure the default for git status in a default variable, like status.findUntrackedFiles, which can be empty , mtime or watchman, and we may add other backends later. While git status is in the spotlight, these optimizations have wider impact. Faster index read/refresh/write helps the majority of commands. Faster untracked listing hits git-status, git-add, git-commit -A... This is why I go with environment variable for temporarily disabling something, or we'll need many config and command line options, one per command. A short test showed that watchman compiles under Mac OS. The patch did not compile out of the box (both Git and watchman declare there own version of usage(), some C99 complaints from the compiler in watchman, nothing that can not be fixed easily) Yeah it's not perfect. It's mainly to show speeding up refresh with watchman could be done easily and with low impact I will test the mtime patch under networked file systems the next weeks. Thinks become to get a little bit clearer. What I can understand is that we have 2 different update-helpers for Git, thanks for that. just in case there is re-roll, does the following makes sense: We want to enable them (probably only one at a time) either by command line or persistent in a repo. As I think we have 2 different update helpers (and may be more in the future) GIT_UPDATE_HELPER=dirmtime git status GIT_UPDATE_HELPER=watchman git status GIT_UPDATE_HELPER=none git status of course we want to be able to configure it: git config core.updatehelper dirmtime After configuring we may want to override it: GIT_UPDATE_HELPER=none git status or git -c core.updatehelper=none status Hmm.. you remind me mtime series may have this as an advantage over watchman.. I had the time to do a short test, sharing a copy of git.git under NFS: The time for git status dropped from 0.4 seconds to 0.15 seconds or so. Very nice. The next test will be to share the same repo under samba to Windows and Mac OS and see how this works. -- 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
Re: [PATCH] allow TTY tests to run under recent Mac OS
On 11/13/2014 11:01 PM, Mike Blume wrote: 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 --- t/lib-terminal.sh | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/t/lib-terminal.sh b/t/lib-terminal.sh index 5184549..1311ce0 100644 --- a/t/lib-terminal.sh +++ b/t/lib-terminal.sh @@ -29,7 +29,10 @@ test_lazy_prereq TTY ' # After 2000 iterations or so it hangs. # https://rt.cpan.org/Ticket/Display.html?id=65692 # - test $(uname -s) != Darwin + # Under Mac OS X 10.10.1 and Perl 5.18.2, this problem + # appears to be gone. + # + [[ test $(uname -s) != Darwin || test $(uname -r | cut -d. -f1) -ge 14 ]] This seems to be bash syntax (the [[ can (and should) be easily avoided) Another question: Is this related to perl or Mac OS ? The commit message is indicating that the combination of Mac OS 10.10.1 and perl 5.18.2 is working, but the code does not reflect this. Does it make sense to test for the perl version in the code? Or is it OK to mention Under Mac OS X 10.10.1 which ships with Perl 5.18.2, this problem perl $TEST_DIRECTORY/test-terminal.perl \ sh -c test -t 1 test -t 2 -- 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
Re: Set file modification time on checkout
On 2014-11-13 05.45, Patrick Hemmer wrote: The request is to allow git to set the file modification time on checkout to the commit-author-date of the commit which last modified the file. Yes I know this is in the FAQ, but the FAQ entry is missing an increasingly common use case: docker. When docker builds an image, it generates layers of images based on each build step. Adding a file would be a build step, and for this action it generates a hash based on the file modification time content. Why do they do this? The file content is the only thing that matters. The other thing is to use a hook, utilizing test-chmtime from test-chmtime.c -- 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
Re: mac test failure -- 2gb clone
On 2014-11-12 22.57, Michael Blume wrote: [t5705-clone-2gb.sh broken on Mac OS] It is most probably even broken on every platform, since we renovated the URL parser in 2013. (More info can be found here:) git log t/t5601-clone.sh I missed t5705-clone-2gb.sh, because it has its own enabler variable GIT_TEST_CLONE_2GB instead of using EXPENSIVE as other tests do. We can say that it as a regression that the URL file://. is no longer supported, and change it like this: diff --git a/t/t5705-clone-2gb.sh b/t/t5705-clone-2gb.sh index e9783c3..a713118 100755 --- a/t/t5705-clone-2gb.sh +++ b/t/t5705-clone-2gb.sh @@ -46,7 +46,7 @@ test_expect_success CLONE_2GB 'clone - bare' ' test_expect_success CLONE_2GB 'clone - with worktree, file:// protocol' ' - git clone file://. clone-wt + git clone file://$(pwd) clone-wt ' Thanks for reporting. Does someone wants to send a patch for t5705-clone-2gb.sh ? -- 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
Re: [RFC] On watchman support
On 2014-11-11 13.49, Duy Nguyen wrote: I've come to the last piece to speed up git status, watchman support. And I realized it's not as good as I thought. Watchman could be used for two things: to avoid refreshing the index, and to avoid searching for ignored files. The first one can be done (with the patch below as demonstration). And it should keep refresh cost to near zero in the best case, the cost is proportional to the number of modified files. For avoiding searching for ignored files. My intention was to build on top of untracked cache. If watchman can tell me what files are added or deleted since last observed time, then I can invalidate just directories that contain them, or even better, calculate ignore status for those files only. This is important because in reality compilers and editors tend to update files by creating a new version then rename them, updating directory mtime and invalidating untracked cache as a consequence. As you edit more files (or your rebuild touches more dirs), untracked cache performance drops (until the next git status). The numbers I posted so far are the best case. The problem with watchman is it cannot tell me new files since the last observed time (let's say 'T'). If a file exists at 'T', gets deleted then recreated, then watchman tells me it's a new file. I want to separate those from ones that do not exist before 'T'. David's watchman approach does not have this problem because he keeps track of all entries under $GIT_WORK_TREE and knows which files are truely new. But I don't really want to keep the whole file list around, especially when watchman already manages the same list. So we got a few options: 1) Convince watchman devs to add something to make it work 2) Fork watchman 3) Make another daemon to keep file list around, or put it in a shared memory. 4) Move David's watchman series forward (and maybe make use of shared mem for fs_cache). 5) Go with something similar to the patch below and accept untracked cache performance degrades from time to time 6) ?? I'm working on 1). 2) is just bad taste, listed for completeness only. If we go with 3) and watchman starts to support Windows (seems to be in their plan), we'll need to rework some how. And I really don't like 3) If 1-3 does not work out, we're left without 4) and 5). We could support both, but proobably not worth the code complexity and should just go with one. And if we go with 4) we should probably think of dropping untracked cache if watchman will support Windows in the end. 4) also has another advantage over untracked cache, that it could speed up listing ignored files as well as untracked files. Comments? [remove the patch] 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 a) and b) already exist. c) Can be convenient to have, in order to do benchmarking and testing. When the UNTR extension is not found, Git can give an error, saying something like this: No mtime information found, use git update-index --untracked-cache d) does not yet exist Of course we may want to configure the default for git status in a default variable, like status.findUntrackedFiles, which can be empty , mtime or watchman, and we may add other backends later. A short test showed that watchman compiles under Mac OS. The patch did not compile out of the box (both Git and watchman declare there own version of usage(), some C99 complaints from the compiler in watchman, nothing that can not be fixed easily) I will test the mtime patch under networked file systems the next weeks. The short version: Go with c), d) then 5) until we have something better :-) -- 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
[PATCH] t5705: Use the correct file:// URL
A URL like file;//. is (no longer) supported by Git: Typically there is no host, and RFC1738 says that file:///path should be used. Update t5705 to use a working URL. Reported-by: Michael Blume blume.m...@gmail.com Signed-off-by: Torsten Bögershausen tbo...@web.de --- t/t5705-clone-2gb.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/t/t5705-clone-2gb.sh b/t/t5705-clone-2gb.sh index e9783c3..191d6d3 100755 --- a/t/t5705-clone-2gb.sh +++ b/t/t5705-clone-2gb.sh @@ -46,7 +46,7 @@ test_expect_success CLONE_2GB 'clone - bare' ' test_expect_success CLONE_2GB 'clone - with worktree, file:// protocol' ' - git clone file://. clone-wt + git clone file://$(pwd) clone-wt ' -- 1.9.1.dirty -- 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
Re: [PATCH v2 22/22] untracked cache: guard and disable on system changes
On 11/10/2014 12:47 AM, Duy Nguyen wrote: Some updates from the test lab, Windows 7 Working means git update-index --untracked-cache reports Testing...OK Rejected means ..does not change.. cygwin + NTFS: Working cygwin + VFAT: Rejected The same good news for Msysgit, running your github branch (I needed to create an empty compat/win32/sys/utsname.h to get it compiled) And I'm still not sure if we need to store the OS in the index, or if it is enough to store the $pwd. -- 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
Re: [PATCH v2 21/22] mingw32: add uname()
On 2014-11-09 09.36, Duy Nguyen wrote:
On Sun, Nov 9, 2014 at 10:32 AM, Eric Sunshine sunsh...@sunshineco.com
wrote:
On Sat, Nov 8, 2014 at 4:39 AM, Nguyễn Thái Ngọc Duy pclo...@gmail.com
wrote:
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
diff --git a/compat/mingw.c b/compat/mingw.c
index c5c37e5..b817678 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -2128,3 +2128,14 @@ void mingw_startup()
/* initialize Unicode console */
winansi_init();
}
+
+int uname(struct utsname *buf)
+{
+ DWORD v = GetVersion();
+ memset(buf, 0, sizeof(*buf));
+ sprintf(buf-sysname, Windows);
strcpy() maybe?
It was originally strcpy, then I wanted to get fancy and show Win3.1,
Win95... but it got complicated (couldn't just do it based on the last
bit of 'v'). Will revert.
Why not use strlcpy() ?
(This feels little like an overkill, but on the other hand it is safe to use
regardless
how long the buf is, and it is a good example how to avoid overrunning code)
--
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
Re: [PATCH] git-imap-send: use libcurl for implementation
On 2014-08-27 00.40, Bernhard Reiter wrote: Use libcurl's high-level API functions to implement git-imap-send instead of the previous low-level OpenSSL-based functions. This doesn't seem to fully work under Debian 7: /home/tb/projects/git/git.pu/imap-send.c:1546: undefined reference to `curl_append_msgs_to_imap' Some more info: curl-config --vernum 071a00 (echo 072200; curl-config --vernum) 2/dev/null | sort -r 072200 071a00 (echo 072200; curl-config --vernum) 2/dev/null | sort -r | sed -ne 2p 071a00 -- 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
Re: What's cooking in git.git (Nov 2014, #01; Wed, 5)
* jt/timer-settime (2014-08-29) 6 commits - use timer_settime() for new platforms - autoconf: check for timer_settime() - autoconf: check for struct itimerspec - autoconf: check for struct sigevent - autoconf: check for struct timespec - autoconf: check for timer_t Reviewed, discussed and wanting for a reroll. Every time I want to test pu under Mac OS X this patch has to be reverted manually. Is there a chance to remove the V1 version from pu until we got the V2 version, please ? -- 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
Re: [PATCH] t1410: fix breakage on case-insensitive filesystems
On 09.11.14 18:34, Michael Blume wrote: Works for me, thanks =) I'm curious now, is there an automated build of git running on a mac anywhere? There's a mac mini running jenkins in my office and it's possible I could convince someone to let me set up a git build that'll e-mail me if there's a test failure. The basic idea is to run make clean git fetch git.git git checkout git.git/pu make -k test (and pipe stdlog+stdout into a file) I have a script here doing that, if you want, I can send it to you -- 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
Re: [PATCH v2 22/22] untracked cache: guard and disable on system changes
On 2014-11-08 10.39, Nguyễn Thái Ngọc Duy wrote: If the user enables untracked cache, then - move worktree to an unsupported filesystem How do we detect this move ? Shouldn't we be able to detect an unsupported file system (by probing if stat(root_dir_of_repo) == stat(what_we_have_in_index_file)) - or simply upgrade OS - or move the whole (portable) disk from one machine to another How does this effect Git ? I would rather expect an update of Git to be an issue, but knowing that Git strongly tends to be backward compatible, there shouldn't be a issue. - or access a shared fs from another machine This is interesting. I have done some basic test on git.git using a medium fast laptop talking to a medium fast server using a medium normal WLAN. git status was is in a range of 2-3 seconds, with your patch 1-1.5 seconds. (That all depends on the network load, some caching here or there) But roughly twice the speed, very nice! I will do some tests with networking file systems, like Linux+ext4 -- SMB -- Windows (cygwin/Git for Windows) Linux+ext4 -- SMB -- Mac OS X Linux+ext4 -- NFS -- Linux Windows-- SMB -- Linux Windows-- SMB -- Mac OS X (and then we have some cases where a virtual machine runs a shared FS with a host file system, where the untracked cache looks promising) I am not really sure when we need this protection. What I understand is that stat(dir).mtime must be reliable. Another problem may be mixing old Git with new Git, but the old Git should write an index file without UNTR, and we should be safe ? The new Git will write an index file with UNTR, which the old Git will ignore. What do I miss ? -- 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
Re: [PATCH] t1410: fix breakage on case-insensitive filesystems
On 2014-11-09 22.36, Michael Blume wrote: Actually I have a build break in pu on my mac right now. Seems to build fine in ubuntu, but: progress.c:66:15: error: use of undeclared identifier 'CLOCK_MONOTONIC' timer_create(CLOCK_MONOTONIC, sev, progress_timer); That is not an unkown issue. You need to revert one commit (this is my copy of pu from today) Revert use timer_settime() for new platforms This reverts commit 0950f08806208b4e3d0aff5f4f7d497637ba4cab. -- 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
Re: Installed git 2.1.3 on sparc 8, but got core dump during 'git clone'
On 2014-11-06 08.38, victor wrote: Hi Jeff, Thanks for your help, as your suggestion, I can compile/install git with --disable_ptheads now. It seems as if your Git still wants to create a pthread, Did you use --disable-pthreads or --disable_ptheads ? -- 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
Re: [PATCH 01/19] dir.c: optionally compute sha-1 of a .gitignore file
On 2014-10-27 13.10, Nguyễn Thái Ngọc Duy wrote: [] Nice serious, I can imagine to test benchmark it (so I assume there is a branch on github or so ?) Another thing: Can we switch the feature off? It could be nice to benchmark with and without the cache on the command line, and besides that we may want to switch it on or off, depending on the file system. I think this can be easily done when reading and writing the index file. (But may cost a config variable, core.dirmtime ??) To my knowledge there is support for the mtime in SAMBA (and probably NFS), but I can help to find out more. diff --git a/dir.c b/dir.c +static int add_excludes(const char *fname, const char *base, int baselen, + struct exclude_list *el, int check_index, + struct sha1_stat *ss, int ss_valid) Cosmetic question: does it make sense to write struct sha1_stat *sha1_stat or struct sha1_stat *s_stat -- 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
Re: [PATCH 18/19] update-index: test the system before enabling untracked cache
On 2014-10-27 13.10, Nguyễn Thái Ngọc Duy wrote:
[]
+static void xmkdir(const char *path)
+{
+ if (mkdir(path, 0700))
+ die_errno(_(failed to create directory %s), path);
+}
Does it makes sense to ignore EINTR and do a retry ?
Another question is if the function could be called mkdir_or_die() instead?
I realized that there are 2 families of xfunc() in wrapper.c, some die, some
retry.
--
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
Re: [PATCH 02/19] untracked cache: record .gitignore information and dir hierarchy
On 2014-10-27 13.10, Nguyễn Thái Ngọc Duy wrote:
dir.c | 150
--
dir.h | 60 +++
2 files changed, 189 insertions(+), 21 deletions(-)
[]
+struct untracked_cache_dir {
+ struct untracked_cache_dir **dirs;
+ char **untracked;
+ /* null SHA-1 means this directory does not have .gitignore */
+ unsigned char exclude_sha1[20];
+ struct stat_data stat_data;
+ unsigned int check_only : 1;
+ unsigned int untracked_nr : 29;
+ unsigned int untracked_alloc, dirs_nr, dirs_alloc;
+ char name[1];
+};
Are we utilizing the CPU and the L2 cache in a good way ?
I would consider to re-arrange, according to the following rule:
- 64 bit ints first (we do not have any)
- pointers (may be 64 or 32 bits)
- structs
- ints
- chars
And then we have the question why untracked_nr gets 29 bits,
and check_only one bit, which means we have 2 bits spare ?
From what I know from CPUs and compilers it could be slighty better to give
32 bits to untracked_nr and either 1 bit to check_only,
or simply make check_only a char.
Or do I miss something ?
+ struct untracked_cache_dir **dirs;
+ char **untracked;
+ /* null SHA-1 means this directory does not have .gitignore */
+ struct stat_data stat_data;
+ unsigned char exclude_sha1[20];
+ unsigned int check_only : 1;
+ unsigned int untracked_nr : 29;
+ unsigned int untracked_alloc, dirs_nr, dirs_alloc;
+ char name[1];
--
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
[PATCH V2] core.filemode may need manual action
core.filemode is set automatically when a repo is created. But when a repo is exported via CIFS or cygwin is mixed with Git for Windows or Eclipse core.filemode may better be set manually to false. Update and improve the documentation Helped-by: Junio C Hamano gits...@pobox.com Signed-off-by: Torsten Bögershausen tbo...@web.de --- Thanks for careful reading. Changes since V1: - The '+' at an otherwise empty line generates an empty line in html, so s/^$/+/ - Changed msygit into Git for Windows - Mention Eclipse - Minor changes in the wording, remove one comma - Remove the The default is true, except This line is maybe confusing. The default is true is not wrong as such, we have int trust_executable_bit = 1; But: these days most repos have core.filemode defined, so describing this default gives not much new information to the user. (please correct me if that is wrong) Especially the except is not really helpful, because the default is always true, and git.git will always probe. Any thoughts ? Now we mention the probing 2 times, I am not 100% happy with this, please see V2B Another thing is that both Git for Windows and Eclipse can not handle the filemode, and should silently ignore the flag, which is a different patch. Documentation/config.txt | 23 +++ 1 file changed, 19 insertions(+), 4 deletions(-) diff --git a/Documentation/config.txt b/Documentation/config.txt index 04a1e2f..959dc11 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -204,12 +204,27 @@ advice.*:: -- core.fileMode:: - If false, the executable bit differences between the index and - the working tree are ignored; useful on broken filesystems like FAT. + Tells Git if the executable bit of files in the working tree + is to be honored. ++ + Some filesystems lose the executable bit when a file that is + marked as executable is checked out, or checks out an + non-executable file with executable bit on. git init and + git clone probe the filesystem to see if it records + executable bit correctly when they create a new repository + and this variable is automatically set as necessary. ++ + A repository, however, may be on a filesystem that handles + the filemode correctly, and this variable is set to 'true' + when created, but later may be made accessible from another + environment that loses the filemode (e.g. exporting ext4 via + CIFS mount, visiting a Cygwin created repository with + Git for Windows or Eclipse). + In such a case it may be necessary to set this variable to 'false'. See linkgit:git-update-index[1]. + -The default is true, except linkgit:git-clone[1] or linkgit:git-init[1] -will probe and set core.fileMode false if appropriate when the +linkgit:git-clone[1] or linkgit:git-init[1] +will probe and set core.fileMode to true or false when the repository is created. core.ignorecase:: -- 2.1.0.rc2.210.g636bceb -- 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
[PATCH V2B] core.filemode may need manual action
core.filemode is set automatically when a repo is created. But when a repo is exported via CIFS or cygwin is mixed with Git for Windows or Eclipse core.filemode may better be set manually to false. Update and improve the documentation Helped-by: Junio C Hamano gits...@pobox.com Signed-off-by: Torsten Bögershausen tbo...@web.de --- Does this makes more sence ? Documentation/config.txt | 23 ++- 1 file changed, 18 insertions(+), 5 deletions(-) diff --git a/Documentation/config.txt b/Documentation/config.txt index 04a1e2f..3127e5d 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -204,13 +204,26 @@ advice.*:: -- core.fileMode:: - If false, the executable bit differences between the index and - the working tree are ignored; useful on broken filesystems like FAT. + Tells Git if the executable bit of files in the working tree + is to be honored. ++ + Some filesystems lose the executable bit when a file that is + marked as executable is checked out, or checks out an + non-executable file with executable bit on. + linkgit:git-clone[1] or linkgit:git-init[1] probe the filesystem + to see if it handles the executable bit correctly + and this variable is automatically set as necessary. ++ + A repository, however, may be on a filesystem that handles + the filemode correctly, and this variable is set to 'true' + when created, but later may be made accessible from another + environment that loses the filemode (e.g. exporting ext4 via + CIFS mount, visiting a Cygwin created repository with + Git for Windows or Eclipse). + In such a case it may be necessary to set this variable to 'false'. See linkgit:git-update-index[1]. + -The default is true, except linkgit:git-clone[1] or linkgit:git-init[1] -will probe and set core.fileMode false if appropriate when the -repository is created. +The default is true (when core.filemode is not specified in the config file). core.ignorecase:: If true, this option enables various workarounds to enable -- 2.1.0.rc2.210.g636bceb -- 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
[PATCH] core.filemode may need manual action
core.filemode is set automatically when a repo is created. But when a repo is exported via CIFS or cygwin is mixed with Git for Windows core.filemode may better be set manually to false. Update and improve the documentation. Helped-by: Junio C Hamano gits...@pobox.com Signed-off-by: Torsten Bögershausen tbo...@web.de --- Does this reflect the discussion via email ? Or is more tweaking needed ? Documentation/config.txt | 19 +-- 1 file changed, 17 insertions(+), 2 deletions(-) diff --git a/Documentation/config.txt b/Documentation/config.txt index 4333636..b4fea43 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -204,8 +204,23 @@ advice.*:: -- core.fileMode:: - If false, the executable bit differences between the index and - the working tree are ignored; useful on broken filesystems like FAT. + Tells Git if the executable bit of files in the working tree + is to be honored. + + Some filesystems lose the executable bit when a file that is + marked as executable is checked out, or checks out an + non-executable file with executable bit on. git init and + git clone probe the filesystem to see if it records + executable bit correctly when they create a new repository + and this variable is automatically set as necessary. + + A repository, however, may be on a filesystem that records + the filemode correctly, and this variable is set to 'true' + when created, but later may be made accessible from another + environment that loses the filemode (e.g. exporting ext4 via + CIFS mount, visiting a Cygwin managed repository with + MsysGit). In such a case, it may be necessary to set this + variable to 'false'. See linkgit:git-update-index[1]. + The default is true, except linkgit:git-clone[1] or linkgit:git-init[1] -- 2.0.0.GIT -- 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
Re: [PATCH] init - Honour the global core.filemode setting
On 2014-10-02 19.02, Junio C Hamano wrote: Torsten Bögershausen tbo...@web.de writes: On 2014-10-01 19.10, Junio C Hamano wrote: Hilco Wijbenga hilco.wijbe...@gmail.com writes: Perhaps I completely misunderstand the meaning of core.filemode but I thought it determined whether Git cared about changes in file properties? By setting it to false, you tell Git that the filesystem you placed the repository does not correctly represent the filemode (especially the executable bit). core.fileMode in git config --help reads: core.fileMode If false, the executable bit differences between the index and the working tree are ignored; useful on broken filesystems like FAT. See git-update- index(1). Out of my head: Could the following be a starting point: core.fileMode If false, the executable bit differences between the index and the working tree are ignored. This may be usefull when visiting a cygwin repo with a non-cygwin Git client. (should we mention msysgit ? should we mention JGit/EGit ?) Between these two sentences, there may still be the same cognitive gap that may have lead to the original confusion. The first sentence says what happens, as it should. But it is not directly clear what makes the executable bit differ and when it is a useful thing to ignore the differences, so the second sentence that says This may be useful does not give the reader very much. Clearly a major improvement. Does this (still) include the original line See linkgit:git-update-index[1] which helps the user to add *.sh files executable to the index, even if core.filemode is false ? One minor improvement below. Here is my attempt. Tells Git if the executable bit of files in the working tree is to be honored. Some filesystems lose the executable bit when a file that is marked as executable is checked out, or checks out an non-executable file with executable bit on. git init and git clone probe the filesystem to see if it records executable bit correctly when they create a new repository and this variable is automatically set as necessary. A repository, however, may be on a filesystem that records the filemode correctly, and this variable is set to 'true' when created, but later may be made accessible from another environment that loses the filemode (e.g. exporting ext4 via CIFS mount, visiting a Cygwin managed repository with MsysGit). In such a case, it may be necessary to set this variable to 'false'. -- 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
Re: [PATCH 1/3] fdopen_lock_file(): access a lockfile using stdio
On 01.10.14 13:14, Michael Haggerty wrote:
[]
Nice done, small comments inline
diff --git a/lockfile.c b/lockfile.c
index d27e61c..e046027 100644
--- a/lockfile.c
+++ b/lockfile.c
@@ -7,20 +7,29 @@
static struct lock_file *volatile lock_file_list;
-static void remove_lock_files(void)
+static void remove_lock_files(int skip_fclose)
Even if the motivation to skip is clear now and here,
I would consider to do it the other way around,
and actively order the fclose():
static void remove_lock_files(int call_fclose)
{
pid_t me = getpid();
while (lock_file_list) {
- if (lock_file_list-owner == me)
+ if (lock_file_list-owner == me) {
+ /* fclose() is not safe to call in a signal handler */
+ if (skip_fclose)
+ lock_file_list-fp = NULL;
rollback_lock_file(lock_file_list);
+ }
lock_file_list = lock_file_list-next;
}
}
+static void remove_lock_files_on_exit(void)
+{
+ remove_lock_files(0);
What does 0 mean ?
remove_lock_files(LK_DO_FCLOSE) ?
+}
+
static void remove_lock_files_on_signal(int signo)
{
- remove_lock_files();
+ remove_lock_files(1);
And what does this 1 mean ?
remove_lock_files(LK_SKIP_FCLOSE) ?
We can even have an emum, or use #define
--
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
Re: [PATCH] init - Honour the global core.filemode setting
On 2014-10-01 19.10, Junio C Hamano wrote: Hilco Wijbenga hilco.wijbe...@gmail.com writes: Perhaps I completely misunderstand the meaning of core.filemode but I thought it determined whether Git cared about changes in file properties? By setting it to false, you tell Git that the filesystem you placed the repository does not correctly represent the filemode (especially the executable bit). core.fileMode in git config --help reads: core.fileMode If false, the executable bit differences between the index and the working tree are ignored; useful on broken filesystems like FAT. See git-update- index(1). Out of my head: Could the following be a starting point: core.fileMode If false, the executable bit differences between the index and the working tree are ignored. This may be usefull when visiting a cygwin repo with a non-cygwin Git client. (should we mention msysgit ? should we mention JGit/EGit ?) This may even be useful for a repo on a SAMBA network mount, which may show all file permissions as 0755. See git-update-index(1) for changing the executable bit in the index. The default is true, except git-clone(1) or git-init(1) will probe and set core.fileMode false if appropriate when the repository is created. Maybe our documentation is not clear enough. A contribution from somebody new to Git we would appreciate would be to point out which part of these sentences are unclear; that way, people can work on improving its phrasing. Thanks. -- 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
Re: Failing tests in t0027-autocrlf.sh under msysgit/git-win-sdk
On 2014-10-02 14.39, Thomas Braun wrote: Hi, I've enabled EXPENSIVE and ran the git test suite under msysgit/git-win-sdk with git version 2.1.0.9753.g360f311.dirty. Now I have some failing tests in t0027-autocrlf.sh in the MINGW only section which puzzle me. The offending test sets are diff --git a/t/t0027-auto-crlf.sh b/t/t0027-auto-crlf.sh index 72dd3e8..90c4cd1 100755 --- a/t/t0027-auto-crlf.sh +++ b/t/t0027-auto-crlf.sh @@ -245,18 +245,18 @@ if test_have_prereq MINGW then check_files_in_ws false LFCRLF CRLF_mix_LF LF_mix_CR CRLF_nul check_files_in_ws true CRLF CRLF CRLF_mix_LF LF_mix_CR CRLF_nul -check_files_in_ws false autoLFCRLF CRLF_mix_LF LF_mix_CR CRLF_nul +# check_files_in_ws false autoLFCRLF CRLF_mix_LF LF_mix_CRCRLF_nul # first broken check_files_in_ws true autoCRLF CRLF CRLF LF_mix_CR CRLF_nul -check_files_in_ws false textLFCRLF CRLF_mix_LF LF_mix_CR CRLF_nul +# check_files_in_ws false textLFCRLF CRLF_mix_LF LF_mix_CRCRLF_nul # broken check_files_in_ws true textCRLF CRLF CRLF CRLF_mix_CR CRLF_nul check_files_in_ws false -text LFCRLF CRLF_mix_LF LF_mix_CR CRLF_nul check_files_in_ws true -text LFCRLF CRLF_mix_LF LF_mix_CR CRLF_nul check_files_in_ws native false LFCRLF CRLF_mix_LF LF_mix_CR CRLF_nul check_files_in_ws native true CRLF CRLF CRLF_mix_LF LF_mix_CR CRLF_nul -check_files_in_ws native false autoLFCRLF CRLF_mix_LF LF_mix_CR CRLF_nul +# check_files_in_ws native false autoLFCRLF CRLF_mix_LF LF_mix_CRCRLF_nul # broken check_files_in_ws native true autoCRLF CRLF CRLF LF_mix_CR CRLF_nul -check_files_in_ws native false textLFCRLF CRLF_mix_LF LF_mix_CR CRLF_nul +# check_files_in_ws native false textLFCRLF CRLF_mix_LF LF_mix_CRCRLF_nul # broken check_files_in_ws native true textCRLF CRLF CRLF CRLF_mix_CR CRLF_nul check_files_in_ws native false -text LFCRLF CRLF_mix_LF LF_mix_CR CRLF_nul check_files_in_ws native true -text LFCRLF CRLF_mix_LF LF_mix_CR CRLF_nul I tried with NATIVE_CRLF = YesPlease but 117 failed too. First question, under what MINGW system do these tests pass? Second question any hints how to tackle this? The first failing test is not ok 117 - checkout core.eol= core.autocrlf=false gitattributes=auto file=LF # # compare_ws_file eol__crlf_false_attr_auto_ LF crlf_false_attr__LF.txt # where I have in the trash directory $ diff -Nur *expect* *actual* --- LF.expect 2014-10-02 12:15:17 + +++ eol__crlf_false_attr_auto_.actual.crlf_false_attr__LF.txt 2014-10-02 12:15 First things first: We have a file with LF in the repo, and check it out. Read it like this: eol__crlf_false_attr_auto_.actual ^ *.txt auto in .gitconfig ^ core.autocrlf is false ^ core.eol is unset The file is expected to have LF in the working tree, but has CRLF :17 + @@ -1,3 +1,3 @@ -000 l i n e 1 \n l i n e 2 \n l i n e -020 3 -021 +000 l i n e 1 \r \n l i n e 2 \r \n l i +020 n e 3 +023 Reading convert.h tells me that for undefined NATIVE_CRLF the native EOL is LF. Which looks like the test is correct. Thomas Which version of t0027 do you have: The latest version in git.git is this one, and should pass (but I may have missed something) commit f6975a6b119128de1c5a89e6cd64f75ed1de2177 Author: Torsten Bögershausen tbo...@web.de Date: Sat Aug 16 22:16:58 2014 +0200 t0027: Tests for core.eol=native, eol=lf, eol=crlf Add test cases for core.eol native and (unset). (MINGW uses CRLF, all other systems LF as native line endings) Add test cases for the attributes eol=lf and eol=crlf Other minor changes: - Use the more portable 'tr' instead of 'od -c' to convert '\n' into 'Q' and '\0' into 'N' - Style fixes for shell functions according to the coding guide lines - Replace txtbin with attr Signed-off-by: Torsten Bögershausen tbo...@web.de Signed-off-by: Junio C Hamano gits...@pobox.com -- 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
Re: [PATCH] init - Honour the global core.filemode setting
On 2014-09-28 02.37, Hilco Wijbenga wrote:
If ~/.gitconfig contains a core.filemode entry then git init
should honour that setting.
Signed-off-by: Hilco Wijbenga hilco.wijbe...@gmail.com
---
This bit me at work where I have to work with Windows. Git on Cygwin
and the Eclipse Git plugin do not agree on file attributes so I had
set filemode = false in ~/.gitconfig.
This feels strange.
Each and every repo has a core.filemode setting.
Or should have.
Did you manage to create a repo without core.filemode in repo/.git/config ?
And if yes, how?
A few weeks later, I did a git init and, some time later yet, I
noticed the strange behaviour of Cygwin/Eclipse again.
I do not fully understand which strange behaviour you experied,
so I need to guess.
This was very
surprising because things had been working well until then. It took
quite a bit of research before I realized that git init always sets
filemode. I think filemode should only be set if not set already
in the global config (similar to log_all_ref_updates).
That is part of the whole story:
In general, git init probes the file system, if the executable bit
is working as expected.
So if you create a Git repository under VFAT, the executable bit is not
supported.
Git will notice that, and set core.filemode = false.
NTFS is a different story:
Cygwin has support for the executable bit under NTFS, but Msysit does not.
So if you share a Git repository between Msysgit and cygwin, it may be better
to set core.filemode to false.
There is however a problem with your patch, or 2:
When you set core.filemode = false in your ~/.gitconfig,
another developer may have core.filemode = true in his config.
If you manage to share the repo using a network, git will behave different
for the 2 users.
Solution:
Set core.filemode for this repo alwways in the repo. (as we do today in git.git)
When you run git init with ~/.gitconfig = true, you should
anyway probe the file system, as it may not support file mode, and
core.filemode may be false.
So the solution that I can see is:
(Some pseudo-code:)
if (git config (global config ) == false) ||
(git config (~/.config ) == false) then
git_config_set(core.filemode, false);
else
probe the file system and set core.filemode as we do today
fi
The usual caveat applies: this is my first patch. Having said that,
please feel free to be pedantic and strict. It's a small patch so I
would imagine that fixing any problems should not take long (assuming
it is acceptable at all, of course). I'd like to know I did it right.
:-)
AFAICT, all tests passed. Should a separate test be added for this change?
I think yes.
Under which system did you test ?
Windows?
CYWGIN ?
MingWW/Msysgit ?
Linux ?
- /* Check filemode trustability */
- filemode = TEST_FILEMODE;
- if (TEST_FILEMODE !lstat(path, st1)) {
- struct stat st2;
- filemode = (!chmod(path, st1.st_mode ^ S_IXUSR)
- !lstat(path, st2)
- st1.st_mode != st2.st_mode);
+ /* Do not override the global filemode setting. */
+ if (trust_executable_bit == -1) {
+ /* Check filemode trustability */
+ filemode = TEST_FILEMODE;
+ if (TEST_FILEMODE !lstat(path, st1)) {
+ struct stat st2;
+ filemode = (!chmod(path, st1.st_mode ^ S_IXUSR)
+ !lstat(path, st2)
+ st1.st_mode != st2.st_mode);
+ }
+ git_config_set(core.filemode, filemode ? true : false);
The indentation seems to be broken ?
(We use one TAB, for better info please see Documentation/CodingGuidelines)
[snip]
--
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
Re: [RFC/PATCH] notes: Allow adding empty notes with -C
On 2014-09-21 05.00, Johan Herland wrote: [] diff --git a/t/t3301-notes.sh b/t/t3301-notes.sh index cfd67ff..a6c399b 100755 --- a/t/t3301-notes.sh +++ b/t/t3301-notes.sh @@ -1239,4 +1239,23 @@ test_expect_success 'git notes get-ref (--ref)' ' test $(GIT_NOTES_REF=refs/notes/bar git notes --ref=baz get-ref) = refs/notes/baz ' +cat expect EOF Git style for shell scripts: Plase put no space between or or and the file name: cat expect EOF +commit 085b0d1309902c3148feb5a136515bdb9a1cd614 +Author: A U Thor aut...@example.com +Date: Thu Apr 7 15:28:13 2005 -0700 + +16th + +Notes (foo): +EOF + +test_expect_success 'can create empty note with git notes add -C $empty_blob' ' + test_commit 16th + blob=e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 + git notes add -C $blob + git log -1 actual git log -1 actual + test_cmp expect actual + test $(git notes list HEAD) = $blob +' + test_done -- 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
Re: [Bug] git status -unormal -- 'foo[b]/' won't display content of 'foo[b]/
On 2014-09-21 20.04, Rémi Vanicat wrote: Hello, I found what look like a bug in git status: `git status -unormal foo[b]/` won't output the content of the directory foo[b] when `git status -unormal foo/` will output the content of the directory foo: $ mkdir 'foo[b]' $ touch 'foo[b]/bar' $ git status -unormal 'foo[b]/' On branch master Untracked files: (use git add file... to include in what will be committed) foo[b]/ nothing added to commit but untracked files present (use git add to track) $ mkdir 'foo' $ touch 'foo/bar' $ git status -unormal 'foo/' On branch master Untracked files: (use git add file... to include in what will be committed) foo/bar nothing added to commit but untracked files present (use git add to track) The documentation of git status contain nothing about treating bracket specially. Quoting the brackets do not solve the problem. see https://github.com/magit/magit/issues/1512 for discussion about it (in the case of git status --porcelain). git status takes a pathspec as a parameter, which is not the same as a filename. A pathspec can contain wildcards like '*' or '?' or things like *[ch]. This is known as shell glob syntax (or so), and used automatically by all shells. Git allows to use git add *.[ch] (where the shell expands the glob) or git add '*.[ch]' where Git does the expansion. You can turn of the glob handling in a pathspec by using this: GIT_LITERAL_PATHSPECS=1 git status -unormal 'foo[b]/' On branch master Initial commit Untracked files: (use git add file... to include in what will be committed) foo[b]/bar --- Side note: If somebody feels that the documentation can be better: we appreciate patches. -- 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
Re: Broken handling of URL with literal IPv6 address
On 2014-09-18 13.29, Christian Taube wrote: Hello, I was sent here from the IRC channel. Using git 2.1.0, the command git clone ssh://[2001:db8::1]/repo.git succeeds, but adding a username to the URL like this git clone ssh://user@[2001:db8::1]/repo.git fails with an invalid hostname message: Cloning into 'repo.git'... ssh: Could not resolve hostname [2001: Name or service not known fatal: Could not read from remote repository. I found this workaround: git clone ssh://[user@2001:db8::1]/repo.git but this seems to be contrary to the definition of URLs in RFC 3986. http://tools.ietf.org/html/rfc3986 Please have a look at this. Thank you! -- Christian Taube This is indeed a bug. We handle literal IPv6 adresses OK, we handle ssh://user@host OK. But it seems as if you are the first one using the combination of both, thanks for the bug report. If somebody want to have a look in the Git source tree: connect.c, t/t5500-fetch-pack.sh and t/t5601-clone.sh may deserve an update. -- 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
Re: [PATCH v5 08/35] lock_file(): always add lock_file object to lock_file_list
On 09/16/2014 09:33 PM, Michael Haggerty wrote:
[]
diff --git a/lockfile.c b/lockfile.c
index 983c3ec..00c972c 100644
--- a/lockfile.c
+++ b/lockfile.c
@@ -129,6 +129,22 @@ static int lock_file(struct lock_file *lk, const char
*path, int flags)
*/
static const size_t max_path_len = sizeof(lk-filename) - 5;
+ if (!lock_file_list) {
+ /* One-time initialization */
+ sigchain_push_common(remove_lock_file_on_signal);
+ atexit(remove_lock_file);
+ }
+
+ if (!lk-on_list) {
+ /* Initialize *lk and add it to lock_file_list: */
+ lk-fd = -1;
+ lk-owner = 0;
+ lk-on_list = 1;
+ lk-filename[0] = 0;
Does it makes sense to change the order here:
Do the full initialization, and once that is completed, set on_list = 1
+ lk-filename[0] = 0;
+ lk-on_list = 1;
--
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
Re: [boinc_dev] (local ?) BOINC repo broken again -or- how to act on the CR/LF changes made upstream
On 12.09.14 20:19, Rom Walton wrote: Try: git checkout -f master git pull origin I committed fixes for that stuff this morning. - Rom It seems as if we added CRLF's to the repo: od -c html/languages/translations/hu.po | grep \\\r 0577300# # \r \n # P r i v a t e m e I checked the latest Git, and it handles the CRLF ok. It may be that there is a bug in the tools you are using. Would you mind to tell us which tools and versions you used to create commit ce97e855d0aa188757722c2 ? -- 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
Re: [boinc_dev] (local ?) BOINC repo broken again -or- how to act on the CR/LF changes made upstream
On 09/14/2014 10:51 AM, Torsten Bögershausen wrote: It may be that there is a bug in the tools you are using. I use git 2.1.0 The question was how the commit had been produced: Rom, what are you using ? -- 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
Re: Issue with 'git diff' and non ascii characters
On 2014-09-12 08.53, Giulio Cesare Solaroli wrote: Hello, I have spotted a problem using 'git diff' when non ascii characters are involved. Not sure if the problem is due to the name of the file, or its content. Cheers, Giulio Cesare Steps to reproduce the problem: $ sw_vers ProductName: Mac OS X ProductVersion: 10.9.4 BuildVersion: 13E28 $ git --version git version 1.8.5.2 (Apple Git-48) $ mkdir test $ cd test $ echo prova tèst.md $ git init Initialized empty Git repository in /private/tmp/test/.git/ $ git add * $ git commit -m first commit [master (root-commit) ebbe2a3] first commit 1 file changed, 1 insertion(+) create mode 100644 t\303\250st.md $ echo provà tèst.md $ git status On branch master Changes not staged for commit: (use git add file... to update what will be committed) (use git checkout -- file... to discard changes in working directory) modified: t\303\250st.md no changes added to commit (use git add and/or git commit -a) $ git diff tèst.md $ The problem is not the contents of the file, but the file name. The following should help: git config core.quotepath false -- 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
Re: Check out git-author
On 09/08/2014 07:19 AM, Jeff King wrote: Have you tried git log -L 2235,2235:fs/ext4/mballoc.c -- fs/ext4/mballoc.c? Can you compare your approach to that of log -L? -Peff Nice, but it doesn't seem to work 100 % (?) tb@linux:~/projects/git/git.pu/t$ git log t3910-mac-os-precompose.sh | grep ^commit commit 1265886303778b5a2631c41c6ee61094c5fda7b0 commit a4cf6b4b91835c1d8d13ebb5cf3ce9241e181f1b commit 750b2e4785e5956122b3c565af65eb1929714fba commit 92b0c8bed0d3f6ed5442e3ffa178413772faa31b commit 308566eb8b35b9279082bd5398c4252169d52b22 commit 76759c7dff53e8c84e975b88cb8245587c14c7ba I'm quite sure that line 15 looks like this in the original commit 76759c7d: junk/$Adiarnfc But it is not shown: tb@linux:~/projects/git/git.pu/t$ git log -L 15,15:t3910-mac-os-precompose.sh -- t3910-mac-os-precompose.sh commit 308566eb8b35b9279082bd5398c4252169d52b22 Author: Michael J Gruber g...@drmicha.warpmail.net Date: Mon Jul 30 11:57:18 2012 +0200 t3910: use the UTF8_NFD_TO_NFC test prereq Besides reusing the new test prerequisite, this fixes also the issue that the current output is not TAP compliant and produces the output no reason given [for skipping]. Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net Signed-off-by: Junio C Hamano gits...@pobox.com diff --git a/t/t3910-mac-os-precompose.sh b/t/t3910-mac-os-precompose.sh --- a/t/t3910-mac-os-precompose.sh +++ b/t/t3910-mac-os-precompose.sh @@ -10,0 +15,1 @@ + But line 20 seems to work better (I shortened the output by using grep): tb@linux:~/projects/git/git.pu/t$ git log -L 20,20:t3910-mac-os-precompose.sh -- t3910-mac-os-precompose.sh | grep ^commit commit a4cf6b4b91835c1d8d13ebb5cf3ce9241e181f1b commit 308566eb8b35b9279082bd5398c4252169d52b22 commit 76759c7dff53e8c84e975b88cb8245587c14c7ba -- 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
Re: Git improvement for line feed processing: LF versus CR-LF
On 09/08/2014 10:55 AM, Francis ANDRE wrote: Hi [] All text file line endings in the repository must be Unix-style (LF). This includes Visual Studio project and solution files (.sln, .vcproj, .vcxproj, .vcxproj.filters). But git-gui translates states: warning: LF will be replaced by CRLF in file.txt. The file will have its original line endings in your working directory. Could you add a option to git-gui to specify to translate or not the end of line of the cloned repository so that my fixes be accepted by the owner of the repository. Thanks Unless I'm completely wrong, such an option already exists, please see http://git-htmldocs.googlecode.com/git/gitattributes.html -- 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
Re: [RFH] renaming strcmp/strncmp-icase
On 2014-09-08 20.52, Junio C Hamano wrote:
There are these two functions in dir.c that has only a handful of
callers outside:
int strcmp_icase(const char *a, const char *b);
int strncmp_icase(const char *a, const char *b, size_t count);
How many of you would think these are about comparing two strings in
a case-insensitive way?
If you raised your hand (like I did), you were wrong. These do
comparison case-insensitively only on a case-insensitive filesystem,
and hence calling it makes sense only for pathnames you grabbed out
of the filesystem via readdir() (or the user gave us, intending to
name paths).
To avoid confusion, I think they should be renamed to stress the
fact that these are about comparing *PATHS*. As I always say, I am
bad at naming things and good suggestions are appreciated.
FYI, there are names I thought about and haven't managed to convince
myself that they are good.
A good name for the non-n variant may be compare_paths(), but that
is used in combine-diff.c. compare_pathnames() may be a
compromise.
However, either of these makes it hard to come up with a
corresponding name for the n (counted) variant. The best I could
do was compare_pathnames_counted(), but a nice similarity to
strcmp()/strncmp() pair is lost.
pathnamecmp()/pathnamencmp() perhaps?
I dunno.
And then we have this in name-hash.c:
(Which may explain the icase suffix ?)
static int same_name(const struct cache_entry *ce, const char *name, int
namelen, int icase)
{
int len = ce_namelen(ce);
/*
* Always do exact compare, even if we want a case-ignoring comparison;
* we do the quick exact one first, because it will be the common case.
*/
if (len == namelen !memcmp(name, ce-name, len))
return 1;
if (!icase)
return 0;
return slow_same_name(name, namelen, ce-name, len);
}
---
static int slow_same_name(const char *name1, int len1, const char *name2, int
len2)
{
if (len1 != len2)
return 0;
while (len1) {
unsigned char c1 = *name1++;
unsigned char c2 = *name2++;
len1--;
if (c1 != c2) {
c1 = toupper(c1);
c2 = toupper(c2);
if (c1 != c2)
return 0;
}
}
return 1;
}
--
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
Re: [PATCH v4 00/32] Lockfile correctness and refactoring
On 2014-09-06 09.50, Michael Haggerty wrote:
Sorry for the long delay since v3. This version mostly cleans up a
couple more places where the lockfile object was left in an
ill-defined state.
No problem with the delay.
The most important question is if we do the lk-active handling right.
Set it to false as seen as possible, and to true as late as possible,
then die() cleanly.
So the -acive handling looks (more or less, please see below) and
deserves another critical review, may be.
Instead of commenting each patch, I collected a mixture of small questions
and possible suggestions into a diff file.
diff --git a/lockfile.c b/lockfile.c
index e54d260..7f27ea2 100644
--- a/lockfile.c
+++ b/lockfile.c
@@ -18,6 +18,10 @@
*Usually, if $FILENAME is a symlink, then it is resolved, and the
*file ultimately pointed to is the one that is locked and later
*replaced. However, if LOCK_NODEREF is used, then $FILENAME
+LOCK_NODEREF can be read either as
+LOCK_NODE_REF or LOCK_NO_DEREF
+should we change it ?
+
*itself is locked and later replaced, even if it is a symlink.
*
* 2. Write the new file contents to the lockfile.
@@ -46,9 +50,18 @@
* state:
* - the lockfile exists
* - active is set
- * - filename holds the filename of the lockfile
+ * - filename holds the filename of the lockfile in a strbuf
* - fd holds a file descriptor open for writing to the lockfile
* - owner holds the PID of the process that locked the file
+question: Why do we need the PID here ?
+Do we open a lock file and do a fork() ?
+And if yes, the child gets a new PID, what happens when the
+child gets a signal ?
+Who owns the lockfile, the parent, the child, both ?
+The child has access to all data, the fd is open and can be used,
+why do we not allow a rollback, when the child dies ?
+
+
*
* - Locked, lockfile closed (after close_lock_file()). Same as the
* previous state, except that the lockfile is closed and fd is -1.
@@ -57,7 +70,7 @@
* rollback_lock_file(), or a failed attempt to lock). In this
* state:
* - active is unset
- * - filename is the empty string (usually, though there are
+ * - filename is an empty string buffer (usually, though there are
* transitory states in which this condition doesn't hold)
* - fd is -1
* - the object is left registered in the lock_file_list, and
@@ -68,7 +81,7 @@
static struct lock_file *volatile lock_file_list;
-static void remove_lock_file(void)
+static void remove_lock_files(void)
{
pid_t me = getpid();
@@ -79,9 +92,9 @@ static void remove_lock_file(void)
}
}
-static void remove_lock_file_on_signal(int signo)
+static void remove_lock_files_on_signal(int signo)
{
-remove_lock_file();
+remove_lock_files();
sigchain_pop(signo);
raise(signo);
}
@@ -93,7 +106,7 @@ static void remove_lock_file_on_signal(int signo)
* /, if any). If path is empty or the root directory (/), set
* path to the empty string.
*/
-static void trim_last_path_elm(struct strbuf *path)
+static void trim_last_path_elem(struct strbuf *path)
{
int i = path-len;
@@ -143,7 +156,7 @@ static void resolve_symlink(struct strbuf *path)
* link is a relative path, so replace the
* last element of p with it.
*/
-trim_last_path_elm(path);
+trim_last_path_elem(path);
strbuf_addbuf(path, link);
}
@@ -153,13 +166,16 @@ static void resolve_symlink(struct strbuf *path)
/* Make sure errno contains a meaningful value on error */
static int lock_file(struct lock_file *lk, const char *path, int flags)
{
+struct stat st;
+int mode = 0666;
if (!lock_file_list) {
/* One-time initialization */
-sigchain_push_common(remove_lock_file_on_signal);
-atexit(remove_lock_file);
+sigchain_push_common(remove_lock_files_on_signal);
+atexit(remove_lock_files);
}
-assert(!lk-active);
+ if (lk-active)
+die(lk-active %s, path);
if (!lk-on_list) {
/* Initialize *lk and add it to lock_file_list: */
@@ -167,16 +183,25 @@ static int lock_file(struct lock_file *lk, const char
*path, int flags)
lk-active = 0;
lk-owner = 0;
lk-on_list = 1;
-strbuf_init(lk-filename, 0);
+strbuf_init(lk-filename, strlen(path) + LOCK_SUFFIX_LEN);
lk-next = lock_file_list;
lock_file_list = lk;
}
+strbuf_reset(lk-filename); /* Better to be save */
strbuf_addstr(lk-filename, path);
if (!(flags LOCK_NODEREF))
resolve_symlink(lk-filename);
strbuf_addstr(lk-filename, LOCK_SUFFIX);
-lk-fd = open(lk-filename.buf, O_RDWR | O_CREAT | O_EXCL, 0666);
+/*
+ * adjust_shared_perm() will widen permissions if needed,
+ * otherwise keep permissions restrictive
+ *
+ */
+if (!stat(path, st))
+mode = st.st_mode 0;
+
+lk-fd = open(lk-filename.buf, O_RDWR | O_CREAT
Re: [RFC PATCHv3 1/4] am: avoid re-directing stdin twice
On 2014-09-06 09.34, Junio C Hamano wrote: Stephen Boyd bebar...@gmail.com writes: I see Stephen who wrote the original Thunderbird save-as is already on the Cc list. How about doing it this way instead? It was so long ago I can't even remember writing that patch. But I googled the thread from 4.5 years ago and I see that you suggested we use tr because \r is not portable[1]. Hmph. That's unfortunate that this may be one of those things that even though it is in POSIX the real world prevents us from using it. I wonder if things changed over the past four years, though. Can folks on OSX or BSD do a quick check? I may have missed the discussion, does this help? \r can be used with tr, but not with sed: tb@macosx:/tmp cat ./xx.sh #!/bin/sh which tr printf AB\rCD\n | tr 'A\r\n\BCD' 'aRNbcd' | xxd printf E\rE | tr -d '\r' | xxd which sed printf AB\rCD\n | sed -e 's/\r/R/g' | xxd printf E\rE | sed -e 's/\r//g' | xxd tb@macosx:/tmp ./xx.sh /usr/bin/tr 000: 6162 5263 644e abRcdN 000: 4545 EE /usr/bin/sed 000: 4142 0d43 440a AB.CD. 000: 450d 450aE.E. tb@macosx:/tmp -- 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
Re: Bug-directors upper letters names.
On 2014-09-06 08.05, Mateusz M wrote: Last days I found special case. A changed packages name (all letter to lowercase). After merge with other branch there were still uppercase letters.All the rest code is after refactoring. Is it a bug ? Unless you provide more information what had been done, what is the expected result versus what is on the file system, this question is impossible to answer (at least for me) Do you use a case-insensitive file system like Windows or Mac OS? What does git status say? What does git ls-files say ? What does ls -1 say ? -- 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
progress.c does not compile under Mac OS X
progress.c:66: error: ‘CLOCK_MONOTONIC’ undeclared (first use in this function)
You can not cast a undeclared into void in git-compat-uitl.h:
#define timer_create(clockid, sevp, timerp) ((void) (clockid), (void) (sevp),
(void) (timerp), errno
Removing the cast of a define into (void) makes the compilation error in line
66 go away:
#ifdef NO_TIMER_SETTIME
-#define timer_create(clockid, sevp, timerp) ((void) (clockid), (void) (sevp),
(void) (timerp), errno = ENOSYS, -1)
+#define timer_create(clockid, sevp, timerp) ((void) (sevp), (void) (timerp),
errno = ENOSYS, -1)
But now we have a bunch of other problems:
progress.c:71: warning: assignment makes integer from pointer without a cast
progress.c:71: error: invalid operands to binary / (have ‘long int *’ and ‘long
int’)
progress.c:71: warning: statement with no effect
progress.c:71: error: ‘_ivalue_it_value’ undeclared (first use in this function)
progress.c:71: error: (Each undeclared identifier is reported only once
progress.c:71: error: for each function it appears in.)
progress.c:71: error: invalid operands to binary / (have ‘long int *’ and ‘long
int’)
progress.c:74: error: expected ‘while’ before ‘static’
progress.c:82: error: nested functions are disabled, use -fnested-functions to
re-enable
progress.c:82: error: invalid storage class for function ‘display’
progress.c: In function ‘display’:
progress.c:92: warning: implicit declaration of function ‘clear_progress_signal’
progress.c: In function ‘set_progress_signal’:
progress.c:126: error: nested functions are disabled, use -fnested-functions to
re-enable
progress.c:126: error: invalid storage class for function ‘throughput_string’
progress.c:135: error: nested functions are disabled, use -fnested-functions to
re-enable
progress.c:199: error: nested functions are disabled, use -fnested-functions to
re-enable
progress.c:205: error: nested functions are disabled, use -fnested-functions to
re-enable
progress.c:225: error: nested functions are disabled, use -fnested-functions to
re-enable
progress.c:230: error: nested functions are disabled, use -fnested-functions to
re-enable
progress.c:235: error: nested functions are disabled, use -fnested-functions to
re-enable
progress.c:264: error: expected declaration or statement at end of input
And then we have the question why we do not check the return value of
timer_create() in progress.c#66:
timer_create(CLOCK_MONOTONIC, sev, progress_timer);
value.it_interval.tv_sec = 1;
value.it_interval.tv_nsec = 0;
value.it_value = value.it_interval;
timer_settime(progress_timer, 0, value, NULL);
--
Should it be something like this ?
if (!timer_create(CLOCK_MONOTONIC, sev, progress_timer)) {
value.it_interval.tv_sec = 1;
value.it_interval.tv_nsec = 0;
value.it_value = value.it_interval;
timer_settime(progress_timer, 0, value, NULL);
}
(And possibly more changes to handle errors when calling
timer_delete(progress_timer)
(Sorry, no, I don't have a patch at hand.
It feels as if the macros in git-compat-util.h could be converted into real
functions,
in compat/timer_settime.c (or so) so that we can test-compile under Linux)
--
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
Re: [PATCH] contrib/svn-fe: fix Makefile
On 08/26/2014 02:44 PM, Maxim Bublis wrote: Fixes several problems: * include config.mak.uname, config.mak.autogen and config.mak in order to use settings for prefix and other such things; * link xdiff/lib.a as it is a requirement for libgit.a; * fix CFLAGS and EXTLIBS for Linux and Mac OS X. --- contrib/svn-fe/Makefile | 47 ++- 1 file changed, 38 insertions(+), 9 deletions(-) diff --git a/contrib/svn-fe/Makefile b/contrib/svn-fe/Makefile index 360d8da..8e1d622 100644 --- a/contrib/svn-fe/Makefile +++ b/contrib/svn-fe/Makefile @@ -1,18 +1,45 @@ all:: svn-fe$X -CC = gcc +CC = cc RM = rm -f MV = mv CFLAGS = -g -O2 -Wall LDFLAGS = -ALL_CFLAGS = $(CFLAGS) -ALL_LDFLAGS = $(LDFLAGS) -EXTLIBS = +EXTLIBS = -lz + +include ../../config.mak.uname +-include ../../config.mak.autogen +-include ../../config.mak + +ifeq ($(uname_S),Darwin) + CFLAGS += -I/opt/local/include + LDFLAGS += -L/opt/local/lib +endif + Should it be possible to disable this by using NO_DARWIN_PORTS like we do in the main Makefile ? -- 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
Re: [PATCH] Undefine strlcpy if needed.
On 2014-08-24 18.18, Ramsay Jones wrote: On 24/08/14 12:13, tsuna wrote: On Sun, Aug 24, 2014 at 4:10 AM, Ramsay Jones ram...@ramsay1.demon.co.uk wrote: Hmm, which version of OS X are we talking about? OS X 10.9.4: $ uname -a Darwin damogran.local 13.3.0 Darwin Kernel Version 13.3.0: Tue Jun 3 21:27:35 PDT 2014; root:xnu-2422.110.17~1/RELEASE_X86_64 x86_64 Hmm, does 'uname -r' return 13.3.0 or 13.4.0? (or something else!) config.mak.uname contains this: ifeq ($(shell expr $(uname_R) : '[15]\.'),2) NO_STRLCPY = YesPlease What does ./configure put in config.mak.autogen for NO_STRLCPY? NO_STRLCPY= OK, so I've got to my limit here! ;-) The conditional shown above (from config.mak.uname) should not have set NO_STRLCPY (assuming that 'uname -r' is returning 13.3.0 or 13.4.0). So, unless NO_STRLCPY is being set somewhere else (command-line, environment), this should just work. puzzled. :( I guess I saw all the warnings because I did just a “git pull —rebase make -j8” without running “make configure ./configure”. Yes, but use of configure is supposed to be optional ... Hopefully, someone who actually knows OS X can solve the mystery. ATB, Ramsay Jones I need to admit that I can not reproduce the warning here, uname -r gives 13.3.0 Could it be that something is special on your machine ? Something in the environment ? Does a fresh clone help ? -- 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
Re: [PATCH v2 1/3] Push the NATIVE_CRLF Makefile variable to C and added a test for native.
On 2014-08-23 00.54, Junio C Hamano wrote: Torsten Bögershausen tbo...@web.de writes: Commit 95f31e9a correctly points out that the NATIVE_CRLF setting is incorrectly set on Mingw git. However, the Makefile variable is not propagated to the C preprocessor and results in no change. This patch pushes the definition to the C code and adds a test to validate that when core.eol as native is crlf, we actually normalize text files to this line ending convention when core.autocrlf is false. Signed-off-by: Pat Thoyts pattho...@users.sourceforge.net Signed-off-by: Stepan Kasal ka...@ucw.cz Signed-off-by: Torsten Bögershausen tbo...@web.de --- Who should I record as the author of this patch? Sorry for missing this, here is what Mingw says: commit 0caba2cacbb9d8e6a31783b45f1a13e52dec6ce8 Author: Pat Thoyts pattho...@users.sourceforge.net Date: Mon Nov 26 00:24:00 2012 + Push the NATIVE_CRLF Makefile variable to C and added a test for native. Commit 95f31e9a correctly points out that the NATIVE_CRLF setting is [] -- 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
[PATCH v2 1/3] Push the NATIVE_CRLF Makefile variable to C and added a test for native.
Commit 95f31e9a correctly points out that the NATIVE_CRLF setting is incorrectly set on Mingw git. However, the Makefile variable is not propagated to the C preprocessor and results in no change. This patch pushes the definition to the C code and adds a test to validate that when core.eol as native is crlf, we actually normalize text files to this line ending convention when core.autocrlf is false. Signed-off-by: Pat Thoyts pattho...@users.sourceforge.net Signed-off-by: Stepan Kasal ka...@ucw.cz Signed-off-by: Torsten Bögershausen tbo...@web.de --- This mini series mainly updates git.git with patches from msysgit: Patch 1 is taken as is, Patch 2 is taken as is, and Patch 3 is the outcome of the code-review Thanks for careful reading Makefile | 3 +++ t/t0026-eol-config.sh | 18 ++ 2 files changed, 21 insertions(+) diff --git a/Makefile b/Makefile index 2320de5..517036e 100644 --- a/Makefile +++ b/Makefile @@ -1479,6 +1479,9 @@ ifdef NO_REGEX COMPAT_CFLAGS += -Icompat/regex COMPAT_OBJS += compat/regex/regex.o endif +ifdef NATIVE_CRLF + BASIC_CFLAGS += -DNATIVE_CRLF +endif ifdef USE_NED_ALLOCATOR COMPAT_CFLAGS += -Icompat/nedmalloc diff --git a/t/t0026-eol-config.sh b/t/t0026-eol-config.sh index 4807b0f..43a580a 100755 --- a/t/t0026-eol-config.sh +++ b/t/t0026-eol-config.sh @@ -80,4 +80,22 @@ test_expect_success 'autocrlf=true overrides unset eol' ' test -z $onediff test -z $twodiff ' +test_expect_success NATIVE_CRLF 'eol native is crlf' ' + + rm -rf native_eol mkdir native_eol + ( cd native_eol + printf *.txt text\n .gitattributes + printf one\r\ntwo\r\nthree\r\n filedos.txt + printf one\ntwo\nthree\n fileunix.txt + git init + git config core.autocrlf false + git config core.eol native + git add filedos.txt fileunix.txt + git commit -m first + rm file*.txt + git reset --hard HEAD + has_cr filedos.txt has_cr fileunix.txt + ) +' + test_done -- 2.1.0.rc2.210.g636bceb -- 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
[PATCH v2 3/3] t0026: Add missing
Fix the broken chain Reported-By: Eric Sunshine sunsh...@sunshineco.com Signed-off-by: Torsten Bögershausen tbo...@web.de --- t/t0026-eol-config.sh | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/t/t0026-eol-config.sh b/t/t0026-eol-config.sh index 43a580a..4806969 100755 --- a/t/t0026-eol-config.sh +++ b/t/t0026-eol-config.sh @@ -84,9 +84,9 @@ test_expect_success NATIVE_CRLF 'eol native is crlf' ' rm -rf native_eol mkdir native_eol ( cd native_eol - printf *.txt text\n .gitattributes - printf one\r\ntwo\r\nthree\r\n filedos.txt - printf one\ntwo\nthree\n fileunix.txt + printf *.txt text\n .gitattributes + printf one\r\ntwo\r\nthree\r\n filedos.txt + printf one\ntwo\nthree\n fileunix.txt git init git config core.autocrlf false git config core.eol native -- 2.1.0.rc2.210.g636bceb -- 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
[PATCH v2 2/3] MinGW: Update tests to handle a native eol of crlf
Some of the tests were written with the assumption that the native eol would always be lf. After defining NATIVE_CRLF on MinGW, these tests began failing. This change will update the tests to also handle a native eol of crlf. Signed-off-by: Brice Lambson brice...@live.com Signed-off-by: Torsten Bögershausen tbo...@web.de --- t/t6038-merge-text-auto.sh | 54 +- t/test-lib.sh | 1 + 2 files changed, 35 insertions(+), 20 deletions(-) diff --git a/t/t6038-merge-text-auto.sh b/t/t6038-merge-text-auto.sh index d9c2d38..85c10b0 100755 --- a/t/t6038-merge-text-auto.sh +++ b/t/t6038-merge-text-auto.sh @@ -72,6 +72,10 @@ test_expect_success 'Merge after setting text=auto' ' same line EOF + if test_have_prereq NATIVE_CRLF; then + append_cr expected expected.temp + mv expected.temp expected + fi git config merge.renormalize true git rm -fr . rm -f .gitattributes @@ -86,6 +90,10 @@ test_expect_success 'Merge addition of text=auto' ' same line EOF + if test_have_prereq NATIVE_CRLF; then + append_cr expected expected.temp + mv expected.temp expected + fi git config merge.renormalize true git rm -fr . rm -f .gitattributes @@ -95,16 +103,19 @@ test_expect_success 'Merge addition of text=auto' ' ' test_expect_success 'Detect CRLF/LF conflict after setting text=auto' ' - q_to_cr -\EOF expected - - first line - same line - === - first lineQ - same lineQ - - EOF - + echo expected + if test_have_prereq NATIVE_CRLF; then + echo first line | append_cr expected + echo same line | append_cr expected + echo === | append_cr expected + else + echo first line expected + echo same line expected + echo === expected + fi + echo first line | append_cr expected + echo same line | append_cr expected + echo expected git config merge.renormalize false rm -f .gitattributes git reset --hard a @@ -114,16 +125,19 @@ test_expect_success 'Detect CRLF/LF conflict after setting text=auto' ' ' test_expect_success 'Detect LF/CRLF conflict from addition of text=auto' ' - q_to_cr -\EOF expected - - first lineQ - same lineQ - === - first line - same line - - EOF - + echo expected + echo first line | append_cr expected + echo same line | append_cr expected + if test_have_prereq NATIVE_CRLF; then + echo === | append_cr expected + echo first line | append_cr expected + echo same line | append_cr expected + else + echo === expected + echo first line expected + echo same line expected + fi + echo expected git config merge.renormalize false rm -f .gitattributes git reset --hard b diff --git a/t/test-lib.sh b/t/test-lib.sh index b1bc65b..aceb418 100644 --- a/t/test-lib.sh +++ b/t/test-lib.sh @@ -871,6 +871,7 @@ case $(uname -s) in # exec does not inherit the PID test_set_prereq MINGW test_set_prereq NOT_CYGWIN + test_set_prereq NATIVE_CRLF test_set_prereq SED_STRIPS_CR test_set_prereq GREP_STRIPS_CR GIT_TEST_CMP=mingw_test_cmp -- 2.1.0.rc2.210.g636bceb -- 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
[PATCH] Push the NATIVE_CRLF Makefile variable to C and added a test for native.
Commit 95f31e9a correctly points out that the NATIVE_CRLF setting is incorrectly set on Mingw git. However, the Makefile variable is not propagated to the C preprocessor and results in no change. This patch pushes the definition to the C code and adds a test to validate that when core.eol as native is crlf, we actually normalize text files to this line ending convention when core.autocrlf is false. Signed-off-by: Pat Thoyts pattho...@users.sourceforge.net Signed-off-by: Stepan Kasal ka...@ucw.cz Signed-off-by: Torsten Bögershausen tbo...@web.de --- (This is from MINGW, and some part of my brain thougth that this was send upstream, but it wasn't. Only 95f31e9a is in git.git) Makefile | 3 +++ t/t0026-eol-config.sh | 18 ++ 2 files changed, 21 insertions(+) diff --git a/Makefile b/Makefile index 63a210d..13311d2 100644 --- a/Makefile +++ b/Makefile @@ -1481,6 +1481,9 @@ ifdef NO_REGEX COMPAT_CFLAGS += -Icompat/regex COMPAT_OBJS += compat/regex/regex.o endif +ifdef NATIVE_CRLF + BASIC_CFLAGS += -DNATIVE_CRLF +endif ifdef USE_NED_ALLOCATOR COMPAT_CFLAGS += -Icompat/nedmalloc diff --git a/t/t0026-eol-config.sh b/t/t0026-eol-config.sh index 4807b0f..43a580a 100755 --- a/t/t0026-eol-config.sh +++ b/t/t0026-eol-config.sh @@ -80,4 +80,22 @@ test_expect_success 'autocrlf=true overrides unset eol' ' test -z $onediff test -z $twodiff ' +test_expect_success NATIVE_CRLF 'eol native is crlf' ' + + rm -rf native_eol mkdir native_eol + ( cd native_eol + printf *.txt text\n .gitattributes + printf one\r\ntwo\r\nthree\r\n filedos.txt + printf one\ntwo\nthree\n fileunix.txt + git init + git config core.autocrlf false + git config core.eol native + git add filedos.txt fileunix.txt + git commit -m first + rm file*.txt + git reset --hard HEAD + has_cr filedos.txt has_cr fileunix.txt + ) +' + test_done -- 2.1.0.rc2.210.g636bceb -- 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
Re: [PATCH v3 03/10] setup: convert setup_git_directory_gently_1 et al. to strbuf
On 2014-07-28 20.26, René Scharfe wrote:
Convert setup_git_directory_gently_1() and its helper functions
setup_explicit_git_dir(), setup_discovered_git_dir() and
setup_bare_git_dir() to use a struct strbuf to hold the current working
directory. Replacing the PATH_MAX-sized buffer used before removes a
path length limition on some file systems. The functions are converted
all in one go because they all read and write the variable cwd.
Signed-off-by: Rene Scharfe l@web.de
---
setup.c | 85
+
1 file changed, 43 insertions(+), 42 deletions(-)
diff --git a/setup.c b/setup.c
index 0a22f8b..c8b8a97 100644
--- a/setup.c
+++ b/setup.c
@@ -387,7 +387,7 @@ const char *read_gitfile(const char *path)
}
static const char *setup_explicit_git_dir(const char *gitdirenv,
- char *cwd, int len,
+ struct strbuf *cwd,
int *nongit_ok)
{
const char *work_tree_env = getenv(GIT_WORK_TREE_ENVIRONMENT);
@@ -441,7 +441,7 @@ static const char *setup_explicit_git_dir(const char
*gitdirenv,
die_errno(Could not chdir to '%s',
git_work_tree_cfg);
if (!getcwd(core_worktree, PATH_MAX))
die_errno(Could not get directory '%s',
git_work_tree_cfg);
- if (chdir(cwd))
+ if (chdir(cwd-buf))
die_errno(Could not come back to cwd);
set_git_work_tree(core_worktree);
}
@@ -459,21 +459,20 @@ static const char *setup_explicit_git_dir(const char
*gitdirenv,
worktree = get_git_work_tree();
/* both get_git_work_tree() and cwd are already normalized */
- if (!strcmp(cwd, worktree)) { /* cwd == worktree */
+ if (!strcmp(cwd-buf, worktree)) { /* cwd == worktree */
set_git_dir(gitdirenv);
free(gitfile);
return NULL;
}
- offset = dir_inside_of(cwd, worktree);
+ offset = dir_inside_of(cwd-buf, worktree);
if (offset = 0) { /* cwd inside worktree? */
set_git_dir(real_path(gitdirenv));
if (chdir(worktree))
die_errno(Could not chdir to '%s', worktree);
- cwd[len++] = '/';
- cwd[len] = '\0';
+ strbuf_addch(cwd, '/');
free(gitfile);
- return cwd + offset;
+ return cwd-buf + offset;
}
/* cwd outside worktree */
@@ -483,7 +482,7 @@ static const char *setup_explicit_git_dir(const char
*gitdirenv,
}
static const char *setup_discovered_git_dir(const char *gitdir,
- char *cwd, int offset, int len,
+ struct strbuf *cwd, int offset,
int *nongit_ok)
{
if (check_repository_format_gently(gitdir, nongit_ok))
@@ -491,17 +490,17 @@ static const char *setup_discovered_git_dir(const char
*gitdir,
/* --work-tree is set without --git-dir; use discovered one */
if (getenv(GIT_WORK_TREE_ENVIRONMENT) || git_work_tree_cfg) {
- if (offset != len !is_absolute_path(gitdir))
+ if (offset != cwd-len !is_absolute_path(gitdir))
gitdir = xstrdup(real_path(gitdir));
- if (chdir(cwd))
+ if (chdir(cwd-buf))
die_errno(Could not come back to cwd);
- return setup_explicit_git_dir(gitdir, cwd, len, nongit_ok);
+ return setup_explicit_git_dir(gitdir, cwd, nongit_ok);
}
/* #16.2, #17.2, #20.2, #21.2, #24, #25, #28, #29 (see t1510) */
if (is_bare_repository_cfg 0) {
- set_git_dir(offset == len ? gitdir : real_path(gitdir));
- if (chdir(cwd))
+ set_git_dir(offset == cwd-len ? gitdir : real_path(gitdir));
+ if (chdir(cwd-buf))
die_errno(Could not come back to cwd);
return NULL;
}
@@ -512,18 +511,18 @@ static const char *setup_discovered_git_dir(const char
*gitdir,
set_git_dir(gitdir);
inside_git_dir = 0;
inside_work_tree = 1;
- if (offset == len)
+ if (offset == cwd-len)
return NULL;
/* Make offset point to past the '/', and add a '/' at the end */
offset++;
- cwd[len++] = '/';
- cwd[len] = 0;
- return cwd + offset;
+ strbuf_addch(cwd, '/');
+ return cwd-buf + offset;
}
/* #16.1, #17.1, #20.1, #21.1, #22.1 (see t1510) */
-static const char *setup_bare_git_dir(char *cwd, int offset, int len, int
*nongit_ok)
+static const char *setup_bare_git_dir(struct strbuf *cwd, int offset,
+ int
[PATCH 2/2] Push the Makefile variable NATIVE_CRLF to C
Re-do the fix in 757543ae0c5d8d: Propagate the Makefile variable NATIVE_CRLF to the C preprocessor Signed-off-by: Torsten Bögershausen tbo...@web.de --- Makefile | 4 1 file changed, 4 insertions(+) diff --git a/Makefile b/Makefile index 63a210d..00ba537 100644 --- a/Makefile +++ b/Makefile @@ -1482,6 +1482,10 @@ ifdef NO_REGEX COMPAT_OBJS += compat/regex/regex.o endif +ifdef NATIVE_CRLF + BASIC_CFLAGS += -DNATIVE_CRLF +endif + ifdef USE_NED_ALLOCATOR COMPAT_CFLAGS += -Icompat/nedmalloc COMPAT_OBJS += compat/nedmalloc/nedmalloc.o -- 2.1.0.rc2.210.g636bceb -- 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
[PATCH 1/2] t0027: Tests for core.eol=native, eol=lf, eol=crlf
Add test cases for core.eol native and (unset).
(MINGW uses CRLF, all other systems LF as native line endings)
Add test cases for the attributes eol=lf and eol=crlf
Other minor changes:
- Use the more portable 'tr' instead of 'od -c' to convert '\n' into 'Q'
and '\0' into 'N'
- Style fixes for shell functions according to the coding guide lines
- Replace txtbin with attr
Signed-off-by: Torsten Bögershausen tbo...@web.de
---
t/t0027-auto-crlf.sh | 220 ---
1 file changed, 120 insertions(+), 100 deletions(-)
diff --git a/t/t0027-auto-crlf.sh b/t/t0027-auto-crlf.sh
index 72dd3e8..2a4a6c1 100755
--- a/t/t0027-auto-crlf.sh
+++ b/t/t0027-auto-crlf.sh
@@ -10,30 +10,26 @@ then
test_done
fi
-
-compare_files()
-{
- od -c $1 $1.expect
- od -c $2 $2.actual
+compare_files () {
+ tr '\015\000' QN $1 $1.expect
+ tr '\015\000' QN $2 $2.actual
test_cmp $1.expect $2.actual
rm $1.expect $2.actual
}
-compare_ws_file()
-{
+compare_ws_file () {
pfx=$1
exp=$2.expect
act=$pfx.actual.$3
- od -c $2 $exp
- od -c $3 $act
+ tr '\015\000' QN $2 $exp
+ tr '\015\000' QN $3 $act
test_cmp $exp $act
rm $exp $act
}
-create_gitattributes()
-{
- txtbin=$1
- case $txtbin in
+create_gitattributes () {
+ attr=$1
+ case $attr in
auto)
echo *.txt text=auto .gitattributes
;;
@@ -43,35 +39,43 @@ create_gitattributes()
-text)
echo *.txt -text .gitattributes
;;
- *)
+ crlf)
+ echo *.txt eol=crlf .gitattributes
+ ;;
+ lf)
+ echo *.txt eol=lf .gitattributes
+ ;;
+ )
echo .gitattributes
;;
+ *)
+ echo 2 invalid attribute: $attr
+ exit 1
+ ;;
esac
}
-create_file_in_repo()
-{
+create_file_in_repo () {
crlf=$1
- txtbin=$2
- create_gitattributes $txtbin
+ attr=$2
+ create_gitattributes $attr
for f in LF CRLF LF_mix_CR CRLF_mix_LF CRLF_nul
do
- pfx=crlf_${crlf}_attr_${txtbin}_$f.txt
+ pfx=crlf_${crlf}_attr_${attr}_$f.txt
cp $f $pfx git -c core.autocrlf=$crlf add $pfx
done
git commit -m core.autocrlf $crlf
}
-check_files_in_repo()
-{
+check_files_in_repo () {
crlf=$1
- txtbin=$2
+ attr=$2
lfname=$3
crlfname=$4
lfmixcrlf=$5
lfmixcr=$6
crlfnul=$7
- pfx=crlf_${crlf}_attr_${txtbin}_
+ pfx=crlf_${crlf}_attr_${attr}_
compare_files $lfname ${pfx}LF.txt
compare_files $crlfname ${pfx}CRLF.txt
compare_files $lfmixcrlf ${pfx}CRLF_mix_LF.txt
@@ -80,19 +84,18 @@ check_files_in_repo()
}
-check_files_in_ws()
-{
+check_files_in_ws () {
eol=$1
crlf=$2
- txtbin=$3
+ attr=$3
lfname=$4
crlfname=$5
lfmixcrlf=$6
lfmixcr=$7
crlfnul=$8
- create_gitattributes $txtbin
+ create_gitattributes $attr
git config core.autocrlf $crlf
- pfx=eol_${eol}_crlf_${crlf}_attr_${txtbin}_
+ pfx=eol_${eol}_crlf_${crlf}_attr_${attr}_
src=crlf_false_attr__
for f in LF CRLF LF_mix_CR CRLF_mix_LF CRLF_nul
do
@@ -104,42 +107,24 @@ check_files_in_ws()
fi
done
-
- test_expect_success checkout core.eol=$eol core.autocrlf=$crlf
gitattributes=$txtbin file=LF
+ test_expect_success checkout core.eol=$eol core.autocrlf=$crlf
gitattributes=$attr file=LF
compare_ws_file $pfx $lfname${src}LF.txt
- test_expect_success checkout core.eol=$eol core.autocrlf=$crlf
gitattributes=$txtbin file=CRLF
+ test_expect_success checkout core.eol=$eol core.autocrlf=$crlf
gitattributes=$attr file=CRLF
compare_ws_file $pfx $crlfname ${src}CRLF.txt
- test_expect_success checkout core.eol=$eol core.autocrlf=$crlf
gitattributes=$txtbin file=CRLF_mix_LF
+ test_expect_success checkout core.eol=$eol core.autocrlf=$crlf
gitattributes=$attr file=CRLF_mix_LF
compare_ws_file $pfx $lfmixcrlf ${src}CRLF_mix_LF.txt
- test_expect_success checkout core.eol=$eol core.autocrlf=$crlf
gitattributes=$txtbin file=LF_mix_CR
+ test_expect_success checkout core.eol=$eol core.autocrlf=$crlf
gitattributes=$attr file=LF_mix_CR
compare_ws_file $pfx $lfmixcr ${src}LF_mix_CR.txt
- test_expect_success checkout core.eol=$eol core.autocrlf=$crlf
gitattributes=$txtbin file=CRLF_nul
+ test_expect_success checkout core.eol=$eol core.autocrlf=$crlf
gitattributes=$attr file=CRLF_nul
t5534 broken when gpg not installed
(I couldn't find a post for this patch) The following is needed for systems without gpg to make t5534 pass: diff --git a/t/t5534-push-signed.sh b/t/t5534-push-signed.sh index 3acc864..ee5aaff 100755 --- a/t/t5534-push-signed.sh +++ b/t/t5534-push-signed.sh @@ -45,7 +45,7 @@ test_expect_success 'unsigned push does not send push certificate' ' ! test -s dst/push-cert ' -test_expect_success 'signed push sends push certificate' ' +test_expect_success GPG 'signed push sends push certificate' ' prepare_dst mkdir -p dst/.git/hooks write_script dst/.git/hooks/post-receive -\EOF -- 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
Re: Git on Mac OS X 10.4.10
On 08/14/2014 02:13 PM, Markus Hitter wrote: I'm new to this list, so: Hello everybody! My backup servers run Mac OS X 10.4.10. Yes, these are old, but very reliable and easily up to the task. And Mac OS X 10.4 is the latest OS supported there (PowerPC G3). Recently I tried to upgrade to v2.0.4 (from 1.7.11.4). Issue 1: I get many of these warnings: LINK [many cases] /usr/bin/ld: warning multiple definitions of symbol _regcomp libgit.a(regex.o) definition of _regcomp in section (__TEXT,__text) /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/../../../libSystem.dylib(regcomp.So) definition of _regcomp /usr/bin/ld: warning multiple definitions of symbol _regexec libgit.a(regex.o) definition of _regexec in section (__TEXT,__text) /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/../../../libSystem.dylib(regexec.So) definition of _regexec /usr/bin/ld: warning multiple definitions of symbol _regfree libgit.a(regex.o) definition of _regfree in section (__TEXT,__text) /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/../../../libSystem.dylib(regfree.So) definition of _regfree Is this expected? No. Git has its own regcomp() (and the regXXX() ) in ./compat/regex/*, and for some reasons the linker picks them both from libgit.a (which is a static library) and the dynamic library in libSystem.dylib Either the linker needs to be convinced not to do that (by changing the command line to the linker, changing the order of libraries may help, I don't know) Or each regcomp in the .h and .c files is changed into git_regcomp. This change shouldn't break anything. Issue 2: I need this simple patch ... --- compat/apple-common-crypto.h.org2014-07-30 23:19:53.0 +0200 +++ compat/apple-common-crypto.h2014-08-14 12:57:37.0 +0200 @@ -2,7 +2,7 @@ #define OPENSSL_NO_MD5 #define HEADER_HMAC_H #define HEADER_SHA_H -#include CommonCrypto/CommonHMAC.h +//#include CommonCrypto/CommonHMAC.h #define HMAC_CTX CCHmacContext #define HMAC_Init(hmac, key, len, algo) CCHmacInit(hmac, algo, key, len) #define HMAC_Update CCHmacUpdate The CommonCrypto/CommonHMAC.h is in Mac OS X 10.6 .. 10.9, but not in 10.4 (I don't know about 10.5). You can try to tweak the makefiles, search for NO_APPLE_COMMON_CRYPTO, and set NO_APPLE_COMMON_CRYPTO, but only for Darwin 10.3 (or below) ... and this command sequence ... make all touch imap-send.o touch git-imap-send make all ... to get it compiling. All, except git-imap-send, obviously, which is no loss for my purposes. I tried many releases, the patch requirement started with about v1.9.1, the git-imap-send failure somewhere between 1.8.1.6 and 1.8.4.3. Trying to be a good Open Source citizen, how would I proceed? If you want to share your changes, please send a patch to this list. Thanks, Markus -- 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
Re: [PATCH v3 1/3] lockfile.c: remove PATH_MAX limitation (except in resolve_symlink)
On 08/01/2014 07:55 PM, Junio C Hamano wrote:
Junio C Hamano gits...@pobox.com writes:
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
Somewhat underexplained, given that it seems to add some new
semantics.
+static void clear_filename(struct lock_file *lk)
+{
+ free(lk-filename);
+ lk-filename = NULL;
+}
It is good to abstract out lk-filename[0] = '\0', which used to be
the way we say that we are done with the lock. But I am somewhat
surprised to see that there aren't so many locations that used to
check !!lk-filename[0] to see if we are done with the lock to require
a corresponding wrapper.
static void remove_lock_file(void)
{
pid_t me = getpid();
while (lock_file_list) {
if (lock_file_list-owner == me
- lock_file_list-filename[0]) {
+ lock_file_list-filename) {
... and this seems to be the only location?
While looking at possible fallout of merging this topic to any
branch, I am starting to suspect that it is probably a bad idea for
clear-filename to free lk-filename. I am wondering if it would be
safer to do:
- in lock_file(), free lk-filename if it already exists before
what you do in that function with your series;
- update is this lock already held? check !!lk-filename[0] to
check for (lk-filename !!lk-filename[0]);
- in clear_filename(), clear lk-filename[0] = '\0', but do not
free lk-filename itself.
Then existing callers that never suspected that lk-filename can be
NULL and thought that it does not need freeing can keep doing the
same thing as before without leaking nor breaking.
If we want to adopt the new world order at once, alternatively, you
can keep the code in this series but then lk-filename needs to be
renamed to something that the current code base has not heard of to
force breakage at the link time for us to notice.
I grepped for 'lk-filename' and checked if the ones in read-cache.c
and refs.c are OK (they seem to be), but that is not a very robust
check.
I dunno.
My first impression reading this patch was to rename
clear_filename() into free_and_clear_filename() or better free_filename(),
but I never pressed the send button ;-)
Reading the discussion above makes me wonder if lk-filename may be replaced by
a strbuf
some day, and in this case clear_filename() will become reset_filenmae() ?
--
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
Re: error: Tweaking file descriptors doesn't work with this MSVCRT.dll on wine
On 07/28/2014 12:39 PM, Duy Nguyen wrote: I know wine is kind of second citizen but is there a cheap trick to make it work on wine? Reverting fcd428f (Win32: fix broken pipe detection - 2012-03-01) could result in conflicts in compat that I'm not comfortable resolving. I don't have Windows at home. Wine is the only option for me (or if somebody has a modern.ie image for KVM, or a simple recipe to make one, that'd be great). Fix wine is not really an option. Is it only that patch that needs to be reverted to make things work got wine? For me It seems as if the patch is not that huge, and manually do a copy-paste with the help of a diff tool can be done. It seems as if even both implemenations can live side-by-side in the code. And if there is a run-time detection for wine, we could switch between the old one and the new one which is dependent on how MSVCRT.dll has layed out internal data structures: ioinfo structure (exposed by MSVCRT.dll via __pioinfo Sorry being not more helpful -- 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
Re: git add -i failed in 2.0.3
On 07/27/2014 05:26 PM, Guang Chen wrote: I use brew upgrade git to this version on OSX. And when I use git add -i, it says: Which version did you use before? Was it installed with brew as well ? Can't locate Git.pm in @INC (@INC contains: @@@/git/2.0.3/lib/perl5/site_perl /Applications/Xcode.app/Contents/Developer/Library/Perl/5.16/darwin-thread-multi-2level /Library/Developer/CommandLineTools/Library/Perl/5.16/darwin-thread-multi-2level /Users/guangchen/.opam/system/lib/perl5/darwin-thread-multi-2level /Users/guangchen/.opam/system/lib/perl5 /Library/Perl/5.16/darwin-thread-multi-2level /Library/Perl/5.16 /Network/Library/Perl/5.16/darwin-thread-multi-2level /Network/Library/Perl/5.16 /Library/Perl/Updates/5.16.2 /System/Library/Perl/5.16/darwin-thread-multi-2level /System/Library/Perl/5.16 /System/Library/Perl/Extras/5.16/darwin-thread-multi-2level /System/Library/Perl/Extras/5.16 .) at /usr/local/Cellar/git/2.0.3/libexec/git-core/git-add--interactive line 7. BEGIN failed--compilation aborted at /usr/local/Cellar/git/2.0.3/libexec/git-core/git-add--interactive line 7. Do you have Git.pm on your disc, somewhere under /usr/local/Cellar/git ? Which perl do you have, (may be more than 1?) I tend to have different perl installations under Mac OS, whch needs tweeking in the PATH, to have the right one in the PATH before e.g. the one that comes with Mac OS. (Or write a wrapper script that sets up the PATH and then calls git) What does type perl in a command window say? -- 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
Re: git add -i failed in 2.0.3
[please avoid top-posting] On 07/29/2014 08:55 AM, Guang Chen wrote: I used 1.9.2 before, it was installed with brew as well. I didn’t found Git.pm under /usr/local/Cellar/git/, /usr/local/Cellar/git/2.0.3/, and I looked at /usr/local/Cellar/git/1.9.2/, there isn’t a Git.pm either. type perl says: perl is /usr/bin/perl Additionally, perl --version says: This is perl 5, version 16, subversion 2 (v5.16.2) built for darwin-thread-multi-2level (with 3 registered patches, see perl -V for more detail) On Jul 29, 2014, at 14:37, Torsten Bögershausen tbo...@web.de wrote: On 07/27/2014 05:26 PM, Guang Chen wrote: I use brew upgrade git to this version on OSX. And when I use git add -i, it says: Which version did you use before? Was it installed with brew as well ? Can't locate Git.pm in @INC (@INC contains: @@@/git/2.0.3/lib/perl5/site_perl /Applications/Xcode.app/Contents/Developer/Library/Perl/5.16/darwin-thread-multi-2level /Library/Developer/CommandLineTools/Library/Perl/5.16/darwin-thread-multi-2level /Users/guangchen/.opam/system/lib/perl5/darwin-thread-multi-2level /Users/guangchen/.opam/system/lib/perl5 /Library/Perl/5.16/darwin-thread-multi-2level /Library/Perl/5.16 /Network/Library/Perl/5.16/darwin-thread-multi-2level /Network/Library/Perl/5.16 /Library/Perl/Updates/5.16.2 /System/Library/Perl/5.16/darwin-thread-multi-2level /System/Library/Perl/5.16 /System/Library/Perl/Extras/5.16/darwin-thread-multi-2level /System/Library/Perl/Extras/5.16 .) at /usr/local/Cellar/git/2.0.3/libexec/git-core/git-add--interactive line 7. BEGIN failed--compilation aborted at /usr/local/Cellar/git/2.0.3/libexec/git-core/git-add--interactive line 7. Do you have Git.pm on your disc, somewhere under /usr/local/Cellar/git ? Which perl do you have, (may be more than 1?) I tend to have different perl installations under Mac OS, whch needs tweeking in the PATH, to have the right one in the PATH before e.g. the one that comes with Mac OS. (Or write a wrapper script that sets up the PATH and then calls git) What does type perl in a command window say? So git add -i needs perl (which is there) and Git.pm (which isn't there) There doesn't seem to be a Git.pm at all on your disc ? I haven't used brew myself, I use to clone git from git://git.kernel.org/pub/scm/git/git.git, checkout the version I want, and run make install which installs git under $HOME/bin, and Git.pm under /Users/tb/share/perl/5.14.2/Git.pm You can try that, clone into a directory, run make -k, and see if there is a Git.pm ? -- 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
Re: git_inetd_server: run git-http-backend using inetd
On 07/19/2014 07:06 PM, Jonathan Nieder wrote:
Torsten Bögershausen wrote:
Jonathan, (I'm good in searching, but bad in finding)
could you point out where the source code for the git package for
debian is ?
I recently learned about mDNS, and will probably do some tests
and experiments later, and would like to test the lookup feature
of 0010.
Thanks. It's at git://git.debian.org/~jrnieder-guest/git branch
release+patches and mirrored at http://repo.or.cz/r/git/debian
With my limited reading of the RFC and the code, and without having
test environment, my spontanous (and probably incomplete) change could
look like this:
- Treat host:9418 the same as host
- When the hosts ends with .local, do not use DNS.
static int git_tcp_connect_sock(char *host, int flags)
{
struct strbuf error_message = STRBUF_INIT;
int sockfd = -1, gai = 0;
const char *port = NULL;
struct host *hosts = NULL;
int j, n = 0;
get_host_and_port(host, port);
if (!port)
port = STR(DEFAULT_GIT_PORT);
n = get_srv(host, hosts);
if ((n = 0) ends_with(host, .local)) {
/*
host.local is really local, do not send it to a DNS resolver
The user may try host without .local
*/
die(Unable to look up %s, host);
}
if (!n) {
hosts = xmalloc(sizeof(*hosts));
hosts[0].hostname = xstrdup(host);
hosts[0].port = xstrdup(port);
[snip]
--
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
Re: git_inetd_server: run git-http-backend using inetd
On 07/20/2014 08:10 AM, Torsten Bögershausen wrote: On 07/19/2014 07:06 PM, Jonathan Nieder wrote: Torsten Bögershausen wrote: Jonathan, (I'm good in searching, but bad in finding) could you point out where the source code for the git package for debian is ? I recently learned about mDNS, and will probably do some tests and experiments later, and would like to test the lookup feature of 0010. Thanks. It's at git://git.debian.org/~jrnieder-guest/git branch release+patches and mirrored at http://repo.or.cz/r/git/debian I probably need to correct myself: Donwloaded your branch, compiled and tested. On my test system the lookup timed out after 1.9 sec for DNS, and 5 seconds for MDNS (the lookup failed in both cases) I'm not sure any more how to improve things here, and the question remains why Kyle has 15 seconds timeout ? Would it be possible to run wireshark, and give us an example of the URL's you have been using ? -- 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
Re: git_inetd_server: run git-http-backend using inetd
On 07/18/2014 12:10 AM, Jonathan Nieder wrote: Hi, Kyle J. McKay wrote: When I then try to fetch using a git://host/... URL where host is an mDNS host name, the 0010 patch causes git to attempt to lookup a DNS SRV record on the non-mDNS regular DNS service (a violation of RFC 6762 [4] section 22) and this is what has to time out before the real fetch can start. That patch uses res_query from libresolv to do the lookup. It doesn't know what DNS server to use and relies on system libraries to get it right. It was added to respond to a feature request within Debian but it is intended to eventually go upstream. I'm glad you found this issue before that could happen. :) Should git automatically disable the SRV lookups when it sees one of the six domains named in RFC6762, or is there some system library call that can use mDNS when appropriate automatically (or get partway there without having to hard-code the domains)? Thanks, Jonathan (My apologies, if this is spamish), but just to verify what is going on: git fetch git://host.local/... results in a DNS lookup ? Kyle, did you verify the lookup with wireshark or a similar tool? Jonathan, (I'm good in searching, but bad in finding) could you point out where the source code for the git package for debian is ? I recently learned about mDNS, and will probably do some tests and experiments later, and would like to test the lookup feature of 0010. Thanks. /Torsten -- 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
Re: [PATCH v9 1/4] cache-tree: Create/update cache-tree on checkout
On 07/13/2014 10:28 PM, David Turner wrote: From: David Turner dtur...@twopensource.com [] diff --git a/cache-tree.c b/cache-tree.c index 7fa524a..f951d7d 100644 --- a/cache-tree.c +++ b/cache-tree.c @@ -239,9 +239,12 @@ static int update_one(struct cache_tree *it, struct strbuf buffer; int missing_ok = flags WRITE_TREE_MISSING_OK; int dryrun = flags WRITE_TREE_DRY_RUN; + int repair = flags WRITE_TREE_REPAIR; int to_invalidate = 0; int i; + assert(!(dryrun repair)); I think something in the spirit of die(dryrun and repaiir can not be used together\n) Would be nicer to the user as well as being more reliable (as assert may be a no-op in some systems) -- 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
Re: git pull crash
On 2014-07-11 12.49, Ronald Bos wrote: Hi all, I am running git on Windows 8.1 (with all the latest updates installed), and it consequently crashes when I run git pull in my cloned working copy. I attached a screen shot of the message window (it is in Dutch...) This is my git version: $ git --version git version 1.9.4.msysgit.0 Is this a known problem? I don't know. It may that your repo is triggering a bug which has been fixed on a later base-line, or it is unfixed because nobody had the very same problem yet. Is there something I can do to help find out what is causing the problem? Try to send what the screen shot does in text, after translating it into english. Not everybody understands Dutch (or wants to open attachments) I can think about 2 different things: - Back up the repo into which you want to pull into, so that the scanrio can be re-run under the same condition, But with a different version of msysGit. - Download the source for msysGit from here: http://msysgit.github.io/ Compile and test, if the bug is on the latest version, or if it is gone. (I remember that some crashes had been fixed, but not all the details) And/or - If the repo you try to pull from is public, can you give us the URL ? If yes then some helpful people may be able to re-produce it. If no, is there a dummy (or better say test) repo, which is public and causes git to crash ? Anyway, I would suggest to compile and re-test with the latest version of msysGit, and let us know the results. -- 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
No fchmd. was: Re: [PATCH 00/14] Add submodule test harness
On 07/09/2014 11:57 PM, Junio C Hamano wrote:
Eric Wong normalper...@yhbt.net writes:
Junio C Hamano gits...@pobox.com wrote:
Johannes Sixt j...@kdbg.org writes:
Am 08.07.2014 21:34, schrieb Jens Lehmann:
And Msysgit complains
error: fchmod on c:/xxxt/trash
directory.t7613-merge-submodule/submodule_update_repo/.git/modules/sub1/config.lock
failed: Function not implemented
I'm not sure what this is about, seems to happen during the cp -R of
the repo under .git/modules into the submodule.
No. It happens because fchmod() is not implemented in our Windows port.
Please see my band-aid patch at
http://thread.gmane.org/gmane.comp.version-control.git/248154/focus=20266
The sub-thread ended inconclusive.
We need to start somewhere, and a no-op fchmod() in your patch may
be as a good place to start as anything. At least we would then
keep the old behaviour without introducing any new failure.
Right, this likely makes the most sense for single-user systems or
systesm without a *nix-like permission system.
An alternative might be to use chmod() after we are done writing to
the config.lock in order to avoid the use of fchmod() altogether,
which I think can replace the existing two callsites of fchmod().
That approach might be a more expedient, but may turn out to be
undesirable in the longer term.
In that case, we would need to open with mode=0600 to avoid a window
where the file may be world-readable with any data in it.
Yes, of course.
To elaborate what I was alluding to at the end of the message you
are responding to a bit more, if we were to move this grab perms
from existing file (if there is any) and propagate to the new one
into the lockfile API,
- in hold_lock_file_for_update(), we would record the permission of
the original file, if any, to a new field in struct lock_file;
- open with 0600 or tighter in lock_file(), and
- either before closing the file use fchmod() or after closing and
moving the file use chmod() to propagate the permission.
If the original did not exist, we would pass 0666 to open as before
in lock_file() and do not bother chmod/fchmod at the end.
Or something like that, perhaps.
Isn't the whole problem starting here:
in config.c:
fd = hold_lock_file_for_update(lock, config_filename, 0);
In lockfile.c:
/* This should return a meaningful errno on failure */
int hold_lock_file_for_update(struct lock_file *lk, const char *path,
int flags)
{
int fd = lock_file(lk, path, flags);
which leads to
static int lock_file(struct lock_file *lk, const char *path, int flags)
[]
lk-fd = open(lk-filename.buf, O_RDWR | O_CREAT | O_EXCL, 0666);
There is no way to tell which permissions the new lockfile should have.
That is somewhat unlucky.
On the other hand, shouldn't we call
adjust_shared_perm(const char *path) from path.c on the config file?
And to all files which are fiddled through the lock_file API?
In other words, the lockfile could be created with the restrictive
permissions
600, and once the lockfile had been closed and renamed into the final name
we apply adjust_shared_perm() on it ?
Or probably directly after close() ?
I think there are 2 different things missing here:
- Be able to specify permissions to hold_lock_file_for_update(),
especially restrictive ones, like 600 and not 666.
- Adjust the permissions for shared files in a shared repo.
This is probably needed for a shared repo, when the user itself
has a umask which is too restrictive and adjust_shared_perm()
must be run to widen the permissions.
Do I miss something ?
--
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
Re: No fchmd. was: Re: [PATCH 00/14] Add submodule test harness
On 2014-07-10 21.49, Junio C Hamano wrote:
[]
If we limit the case to Inherit permissions from the file we are
replacing by taking a lock on it, which is the topic of discussion
in this thread, we do not have to worry about how to configure the
value (we do not have to) and adding a new parameter to tell the
mode to hold-lock-file-for-update is unneeded (the function will
have a pathname of the original and can learn the current permission
bits itself).
So something like this:
(I will probably not have the time to make a proper patch :-(
diff --git a/lockfile.c b/lockfile.c
index 4899270..134d5c8 100644
--- a/lockfile.c
+++ b/lockfile.c
@@ -156,6 +156,11 @@ static void resolve_symlink(struct strbuf *path)
/* Make sure errno contains a meaningful value on error */
static int lock_file(struct lock_file *lk, const char *path, int flags)
{
+ int perms = 0666;
+ struct stat st;
+ if (!lstat(path, st))
+ perms = st.st_mode 0777;
+
if (!lock_file_list) {
/* One-time initialization */
sigchain_push_common(remove_lock_file_on_signal);
@@ -179,7 +184,7 @@ static int lock_file(struct lock_file *lk, const char
*path, int flags)
if (!(flags LOCK_NODEREF))
resolve_symlink(lk-filename);
strbuf_addstr(lk-filename, LOCK_SUFFIX);
- lk-fd = open(lk-filename.buf, O_RDWR | O_CREAT | O_EXCL, 0666);
+ lk-fd = open(lk-filename.buf, O_RDWR | O_CREAT | O_EXCL, perms);
if (lk-fd 0) {
strbuf_reset(lk-filename);
return -1;
--
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
Re: [PATCH 00/14] Add submodule test harness
There seems to be some other trouble under Mac OS, not yet fully tracked down, (may be related to the diff -r) Torsten sees failures of this kind under Mac OS: diff -r .git/modules/sub1/config sub1/.git/config 6d5 worktree = ../../../sub1 8a8 worktree = ../../../sub1 So the config contains the same content, but the worktree setting moved to a different line. This seems to be the result of setting core.worktree in the test_git_directory_is_unchanged function just before the diff -r, but only under Mac OS. So I was suspecting diff -r beinng non-portable, but that doesn't seem to be the problem here. (But I wouldn't be surprised if there where problems with diff -r on some Unix systems) Anyway, checking all the files in the working tree seems to be a good thing to do, but that does not necessarily work for .git/config. A brute force approach could be to simply run the config file(s) through sort and compare them: sort .git/modules/sub1/config expect sort sub1/.git/config actual test_cmp expect actual rm expect actual cp git/modules/sub1/config sub1/.git/config [end of scriptlet] And here the dumps of the 2 config files: ... Branch remove_sub1 set up to track remote branch remove_sub1 from origin. warning: unable to rmdir sub1: Directory not empty Updating 68c8810..81b9f6a Fast-forward .gitmodules | 4 1 file changed, 4 deletions(-) delete mode 100644 .gitmodules - [core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true worktree = ../../../sub1 ignorecase = true precomposeunicode = true [remote origin] url = /Users/tb/projects/git/tb.140704_JensLehman/t/trash directory.t7613-merge-submodule/submodule_update_repo/. fetch = +refs/heads/*:refs/remotes/origin/* [branch master] remote = origin merge = refs/heads/master [core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true ignorecase = true precomposeunicode = true worktree = ../../../sub1 [remote origin] url = /Users/tb/projects/git/tb.140704_JensLehman/t/trash directory.t7613-merge-submodule/submodule_update_repo/. fetch = +refs/heads/*:refs/remotes/origin/* [branch master] remote = origin merge = refs/heads/master = diff -r .git/modules/sub1/config sub1/.git/config 6d5 worktree = ../../../sub1 8a8 worktree = ../../../sub1 not ok 7 - git merge: removed submodule leaves submodule containing a .git directory alone -- 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
No fchmod() under msygit - Was: Re: [PATCH 00/14] Add submodule test harness
On 07/08/2014 10:25 PM, Ramsay Jones wrote:
On 08/07/14 20:34, Jens Lehmann wrote:
Am 07.07.2014 21:40, schrieb Torsten Bögershausen:
On 2014-07-07 19.05, Junio C Hamano wrote:
Jens Lehmann jens.lehm...@web.de writes:
Junio, do you want me to resend 02/14 without the non-portable echo -n
or could you just squash the following diff in?
Amended locally here already; thanks, both.
There seems to be some other trouble under Mac OS, not yet fully tracked down,
(may be related to the diff -r)
Torsten sees failures of this kind under Mac OS:
diff -r .git/modules/sub1/config sub1/.git/config
6d5
worktree = ../../../sub1
8a8
worktree = ../../../sub1
So the config contains the same content, but the worktree setting moved
to a different line. This seems to be the result of setting core.worktree
in the test_git_directory_is_unchanged function just before the diff -r,
but only under Mac OS.
And Msysgit complains
error: fchmod on c:/xxxt/trash
directory.t7613-merge-submodule/submodule_update_repo/.git/modules/sub1/config.lock
failed: Function not implemented
I'm not sure what this is about, seems to happen during the cp -R of
the repo under .git/modules into the submodule.
I haven't looked into this at all, but from the above message, and
noting that fchmod() is not implemented in mingw (see compat/mingw.h
line 91), and the following:
$ git grep -n fchmodcommit daa22c6f8da466bd7a438f1bc27375fd737ffcf3
Author: Eric Wong normalper...@yhbt.net
Date: Tue May 6 00:17:14 2014 +
config: preserve config file permissions on edits
compat/mingw.h:91:static inline int fchmod(int fildes, mode_t mode)
config.c:1639: if (fchmod(fd, st.st_mode 0) 0) {
config.c:1640: error(fchmod on %s failed: %s,
config.c:1818: if (fchmod(out_fd, st.st_mode 0) 0) {
config.c:1819: ret = error(fchmod on %s failed: %s,
$
[I happen to be on the pu branch at the moment, so YMMV!]
Both calls to fchmod() above are on config lock files, one
in git_config_set_multivar_in_file() and the other in
git_config_rename_section_in_file().
commit daa22c6f8da466bd7a438f1bc27375fd737ffcf3
Author: Eric Wong normalper...@yhbt.net
Date: Tue May 6 00:17:14 2014 +
config: preserve config file permissions on edits
(And why is it 0 and not 0777)
Can we avoid the fchmod() all together ?
--
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
Re: [PATCH 00/14] Add submodule test harness
On 2014-07-07 19.05, Junio C Hamano wrote: Jens Lehmann jens.lehm...@web.de writes: Junio, do you want me to resend 02/14 without the non-portable echo -n or could you just squash the following diff in? Amended locally here already; thanks, both. There seems to be some other trouble under Mac OS, not yet fully tracked down, (may be related to the diff -r) And Msysgit complains error: fchmod on c:/xxxt/trash directory.t7613-merge-submodule/submodule_update_repo/.git/modules/sub1/config.lock failed: Function not implemented -- 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
Re: [PATCH v2] git-am: add option to extract email Message-Id: tag into commit log
--- a/git-am.sh
+++ b/git-am.sh
@@ -39,6 +39,7 @@ committer-date-is-author-datelie about committer date
ignore-date use current timestamp for author date
rerere-autoupdate update the index with reused conflict resolution if
possible
S,gpg-sign? GPG-sign commits
+m,message-idcopy the Message-Id: header to the commit's tag stanza
rebasing* (internal use for git-rebase)
. git-sh-setup
@@ -371,7 +372,7 @@ split_patches () {
prec=4
dotest=$GIT_DIR/rebase-apply
sign= utf8=t keep= keepcr= skip= interactive= resolved= rebasing= abort=
-resolvemsg= resume= scissors= no_inbody_headers=
+resolvemsg= resume= scissors= no_inbody_headers= message_id=
git_apply_opt=
committer_date_is_author_date=
ignore_date=
@@ -442,6 +443,8 @@ it will be removed. Please do not use it anymore.
gpg_sign_opt=-S ;;
--gpg-sign=*)
gpg_sign_opt=-S${1#--gpg-sign=} ;;
+ -m|--message-id)
+ message_id=t ;;
--)
shift; break ;;
*)
@@ -565,6 +568,7 @@ Use \git am --abort\ to remove it.)
echo $git_apply_opt $dotest/apply-opt
echo $threeway $dotest/threeway
echo $sign $dotest/sign
+ echo $message_id $dotest/message-id
echo $utf8 $dotest/utf8
echo $keep $dotest/keep
echo $scissors $dotest/scissors
@@ -757,6 +761,10 @@ To restore the original branch and stop patching run
\\$cmdline --abort\.
then
cat $dotest/msg-clean
fi
+ if test 't' == $message_id
The == is bash special, please use = instead
And the 't' can be written as t, so that the whole line looks like this:
if test t = $message_id
--
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
Re: [PATCH 00/14] Add submodule test harness
(Not sure if this is the right thread) (I haven't checked if this is fixed in your latest version) On what I have on pu 7a0da7902cbbc9a876b90c9, Tue Jul 1 14:51:53 2014 -0700 Many submodule tests are broken. One problem is here: lib-submodule-update.sh:264: possible problem: echo -n is not portable (please use printf): echo -n sub1 lib-submodule-update.sh:507: possible problem: echo -n is not portable (please use printf): echo -n sub1 You can remove the empty echo -n to create an empty file: sub1 -- 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
Re: [PATCH v4] git-am: add option to extract email Message-Id: tag into commit log
diff --git a/git-am.sh b/git-am.sh
index ee61a77..fd0181f 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -39,6 +39,7 @@ committer-date-is-author-datelie about committer date
ignore-date use current timestamp for author date
rerere-autoupdate update the index with reused conflict resolution if
possible
S,gpg-sign? GPG-sign commits
+m,message-idcopy the Message-Id: header to the commit's tag stanza
rebasing* (internal use for git-rebase)
. git-sh-setup
@@ -371,7 +372,7 @@ split_patches () {
prec=4
dotest=$GIT_DIR/rebase-apply
sign= utf8=t keep= keepcr= skip= interactive= resolved= rebasing= abort=
-resolvemsg= resume= scissors= no_inbody_headers=
+resolvemsg= resume= scissors= no_inbody_headers= message_id=
git_apply_opt=
committer_date_is_author_date=
ignore_date=
@@ -442,6 +443,8 @@ it will be removed. Please do not use it anymore.
gpg_sign_opt=-S ;;
--gpg-sign=*)
gpg_sign_opt=-S${1#--gpg-sign=} ;;
+ -m|--message-id)
+ message_id=t ;;
--)
shift; break ;;
*)
@@ -565,6 +568,7 @@ Use \git am --abort\ to remove it.)
echo $git_apply_opt $dotest/apply-opt
echo $threeway $dotest/threeway
echo $sign $dotest/sign
+ echo $message_id $dotest/message-id
echo $utf8 $dotest/utf8
echo $keep $dotest/keep
echo $scissors $dotest/scissors
@@ -651,6 +655,10 @@ then
else
SIGNOFF=
fi
+if test $(cat $dotest/message-id) = t
Does the usage of '' inside of '' look good, or can we write like this:
if test $(cat $dotest/message-id) = t
--
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
