* [PATCH] mergetool: Suppress stderr and fix the "both added" test
From: David Aguilar @ 2012-01-21 10:26 UTC (permalink / raw)
To: gitster; +Cc: jcwenger, git
Silence error messages when "git checkout-index" is used to
checkout a stage that does not exist. This can happen now that
mergetool calls checkout_staged_file() unconditionally when
creating the temporary $BASE, $LOCAL, and $REMOTE files.
Fix the test so that it checks the contents of the "both added"
file. The test was passing as a consequence of accidentally
handing a bad path to "cat".
Signed-off-by: David Aguilar <davvid@gmail.com>
---
This applies on top of da/maint-mergetool-twoway in pu.
git-mergetool.sh | 4 +++-
t/t7610-mergetool.sh | 5 +++--
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/git-mergetool.sh b/git-mergetool.sh
index 24bedc5..a9f23f7 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -181,7 +181,9 @@ stage_submodule () {
}
checkout_staged_file () {
- tmpfile=$(expr "$(git checkout-index --temp --stage="$1" "$2")" : '\([^ ]*\) ')
+ tmpfile=$(expr \
+ "$(git checkout-index --temp --stage="$1" "$2" 2>/dev/null)" \
+ : '\([^ ]*\) ')
if test $? -eq 0 -a -n "$tmpfile" ; then
mv -- "$(git rev-parse --show-cdup)$tmpfile" "$3"
diff --git a/t/t7610-mergetool.sh b/t/t7610-mergetool.sh
index 2272743..3f261a3 100755
--- a/t/t7610-mergetool.sh
+++ b/t/t7610-mergetool.sh
@@ -465,8 +465,9 @@ test_expect_success 'directory vs modified submodule' '
test_expect_success 'file with no base' '
git checkout -b test13 branch1 &&
test_must_fail git merge master &&
- git mergetool --no-prompt --tool mybase -- base &&
- test "$(cat "$MERGED")" = "" &&
+ git mergetool --no-prompt --tool mybase -- both &&
+ >expected &&
+ test_cmp both expected &&
git reset --hard master >/dev/null 2>&1
'
--
1.7.7.166.g1cd0c
^ permalink raw reply related
* Re: [PATCH v2 3/3] git-p4: Add test case for complex branch import
From: Luke Diamand @ 2012-01-21 10:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Vitor Antunes, git, Pete Wyckoff
In-Reply-To: <7vehutd59p.fsf@alter.siamese.dyndns.org>
On 21/01/12 04:54, Junio C Hamano wrote:
> Vitor Antunes<vitor.hda@gmail.com> writes:
>
>> + grep -q update file2&&
>
> Do you really need to use "-q" here? Wouldn't it help if you wrote it
> without it while debugging tests with "sh ./t9801-*.sh -v"?
>
> Also how does this series interact with the series Luke posted earlier on
> branches and labels?
Vitor's series applies cleanly to my changes.
However, one thing I noticed in reading through is that it will break if
you end up importing a P4 branch that has spaces (or other shell chars)
in its name. A quick test confirms this.
- the code doesn't handle the names properly
- git and p4 have different ideas about valid branch names
But before rejecting Vitor's changes because of that it would be worth
considering whether we care (much). My own opinion is that if you have
developers who are daft enough to put spaces or dollars in their branch
names then their project is already doomed anyway....
Perhaps it would be enough just to issue a warning ("your project is
doomed; start working on your CV") and skip such branch names rather
than falling over with inexplicable error messages.
>
> Thanks.
^ permalink raw reply
* How to restore "svn mirror generator"?
From: Manuel Reimer @ 2012-01-21 15:45 UTC (permalink / raw)
To: git
Hello,
I want to create a GIT mirror of a SVN repository.
I plan to mirror a SVN server to GIT. I don't want to fetch the full history but
all future commits should be mirrored.
I plan to do this in the following way:
git svn clone -r $REVISION_TO_START_WITH http://domain.tld/path/to/svn
git remote add origin ssh://user@gitserver.tld/mirror.git
git push
Now, from time to time, I want to update with
git svn rebase
git push
I hope, so far I'm on the right way.
But what happens if, for some reason, my local repository gets lost?
How to reconnect GIT and SVN so I'm able to mirror, again?
Is the first step to clone the GIT repository and then, somehow, get the SVN
connected, again, or do I have to do it the other way around?
Yours
Manuel
^ permalink raw reply
* Re: [PATCH v2 3/3] git-p4: Add test case for complex branch import
From: Pete Wyckoff @ 2012-01-21 17:11 UTC (permalink / raw)
To: Luke Diamand; +Cc: Junio C Hamano, Vitor Antunes, git
In-Reply-To: <4F1A98A3.2090607@diamand.org>
luke@diamand.org wrote on Sat, 21 Jan 2012 10:51 +0000:
> On 21/01/12 04:54, Junio C Hamano wrote:
> >Vitor Antunes<vitor.hda@gmail.com> writes:
> >
> >>+ grep -q update file2&&
> >
> >Do you really need to use "-q" here? Wouldn't it help if you wrote it
> >without it while debugging tests with "sh ./t9801-*.sh -v"?
> >
> >Also how does this series interact with the series Luke posted earlier on
> >branches and labels?
>
> Vitor's series applies cleanly to my changes.
>
> However, one thing I noticed in reading through is that it will
> break if you end up importing a P4 branch that has spaces (or other
> shell chars) in its name. A quick test confirms this.
>
> - the code doesn't handle the names properly
> - git and p4 have different ideas about valid branch names
>
> But before rejecting Vitor's changes because of that it would be
> worth considering whether we care (much). My own opinion is that if
> you have developers who are daft enough to put spaces or dollars in
> their branch names then their project is already doomed anyway....
>
> Perhaps it would be enough just to issue a warning ("your project is
> doomed; start working on your CV") and skip such branch names rather
> than falling over with inexplicable error messages.
This doesn't seem like a big deal. The read_pipe and
read_pipe_lines calls shoud be list-ified. That gets rid
of the problem with shell interactions.
For git branch name reserved characters, a little function
to replace the bogus characters with "_" would avoid needing
to go work on the resume. Anything in bad_ref_char() and
check_refname_component(). I agree this doesn't have to be
perfect.
This could be a new patch unrelated to Vitor's series, which
verifies branch names anywhere a new commit is made.
-- Pete
^ permalink raw reply
* [PATCH] optionally deny all pushes
From: Clemens Buchacher @ 2012-01-21 17:49 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
For a mirror repository which is updated only by pulling from upstream,
it is convenient to disallow all pushes. An accidental push from a
downstream repository would mess up the mirror's state as well as future
updates.
Add a boolean configuration variable receive.denyAll. If enabled,
receive-pack will deny all ref updates.
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
---
Documentation/config.txt | 4 ++++
Documentation/git-push.txt | 1 +
builtin/receive-pack.c | 11 +++++++++++
contrib/completion/git-completion.bash | 1 +
t/t5400-send-pack.sh | 17 +++++++++++++++++
t/t5516-fetch-push.sh | 12 ++++++++++++
6 files changed, 46 insertions(+), 0 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 04f5e19..edbddea 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1683,6 +1683,10 @@ receive.unpackLimit::
especially on slow filesystems. If not set, the value of
`transfer.unpackLimit` is used instead.
+receive.denyAll::
+ If set to true, git-receive-pack will deny all ref updates.
+ The repository can not be updated remotely.
+
receive.denyDeletes::
If set to true, git-receive-pack will deny a ref update that deletes
the ref. Use this to prevent such a ref deletion via a push.
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index aede488..7c6cc63 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -219,6 +219,7 @@ remote rejected::
The remote end refused the update. Usually caused by a hook
on the remote side, or because the remote repository has one
of the following safety options in effect:
+ `receive.denyAll` (for all pushes),
`receive.denyCurrentBranch` (for pushes to the checked out
branch), `receive.denyNonFastForwards` (for forced
non-fast-forward updates), `receive.denyDeletes` or
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index d2dcb7e..9cd04f9 100644
--- a/builtin/receive-pack.c
+++ b/builtin/receive-pack.c
@@ -22,6 +22,7 @@ enum deny_action {
DENY_REFUSE
};
+static int deny_all;
static int deny_deletes;
static int deny_non_fast_forwards;
static enum deny_action deny_current_branch = DENY_UNCONFIGURED;
@@ -57,6 +58,11 @@ static enum deny_action parse_deny_action(const char *var, const char *value)
static int receive_pack_config(const char *var, const char *value, void *cb)
{
+ if (strcmp(var, "receive.denyall") == 0) {
+ deny_all = git_config_bool(var, value);
+ return 0;
+ }
+
if (strcmp(var, "receive.denydeletes") == 0) {
deny_deletes = git_config_bool(var, value);
return 0;
@@ -401,6 +407,11 @@ static const char *update(struct command *cmd)
unsigned char *new_sha1 = cmd->new_sha1;
struct ref_lock *lock;
+ if (deny_all) {
+ rp_error("denying all updates");
+ return "update prohibited";
+ }
+
/* only refs/... are allowed */
if (prefixcmp(name, "refs/") || check_refname_format(name + 5, 0)) {
rp_error("refusing to create funny ref '%s' remotely", name);
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index b0062ba..9d63622 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -2250,6 +2250,7 @@ _git_config ()
rebase.autosquash
rebase.stat
receive.autogc
+ receive.denyAll
receive.denyCurrentBranch
receive.denyDeleteCurrent
receive.denyDeletes
diff --git a/t/t5400-send-pack.sh b/t/t5400-send-pack.sh
index 0eace37..e8c9be2 100755
--- a/t/t5400-send-pack.sh
+++ b/t/t5400-send-pack.sh
@@ -222,4 +222,21 @@ test_expect_success 'deny pushing to delete current branch' '
)
'
+test_expect_success 'deny pushing to any branch with denyAll' '
+ rewound_push_setup &&
+ (
+ cd parent &&
+ git config receive.denyCurrentBranch false &&
+ git config receive.denyAll true
+ ) &&
+ (
+ cd child &&
+ test_must_fail git send-pack ../parent master 2>errs
+ ) &&
+ (
+ cd child &&
+ test_must_fail git send-pack ../parent :refs/heads/master 2>errs
+ )
+'
+
test_done
diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh
index b69cf57..d1117c0 100755
--- a/t/t5516-fetch-push.sh
+++ b/t/t5516-fetch-push.sh
@@ -815,6 +815,18 @@ test_expect_success 'allow push to HEAD of bare repository (bare)' '
! grep "warning: updating the current branch" stderr
'
+test_expect_success 'deny push to HEAD of bare repository (denyAll)' '
+ mk_test heads/master &&
+ (
+ cd testrepo &&
+ git checkout master &&
+ git config receive.denyCurrentBranch false &&
+ git config receive.denyAll true &&
+ git config core.bare true
+ ) &&
+ test_must_fail git push testrepo master
+'
+
test_expect_success 'allow push to HEAD of non-bare repository (config)' '
mk_test heads/master &&
(
--
1.7.8
^ permalink raw reply related
* [PATCH] fix git-gui crash due to uninitialized variable
From: Clemens Buchacher @ 2012-01-21 17:57 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Recently, a clone initiated via git gui on Windows crashed on me due to
an "unknown variable cdone". It turns out that there is a code path
where this variable is used uninitialized.
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
---
Looking at the output of display(), it's not clear to me now the
function below could ever be called with total=0. But I can't delve into
it more deeply right now, and this seems like an obvious fix.
git-gui/lib/status_bar.tcl | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/git-gui/lib/status_bar.tcl b/git-gui/lib/status_bar.tcl
index 95cb449..02111a1 100644
--- a/git-gui/lib/status_bar.tcl
+++ b/git-gui/lib/status_bar.tcl
@@ -77,6 +77,7 @@ method start {msg uds} {
method update {have total} {
set pdone 0
+ set cdone 0
if {$total > 0} {
set pdone [expr {100 * $have / $total}]
set cdone [expr {[winfo width $w_c] * $have / $total}]
--
1.7.8
^ permalink raw reply related
* Including git-describe info as version strings for generic "-v" output
From: Harry portobello @ 2012-01-21 19:09 UTC (permalink / raw)
To: git; +Cc: Harry portobello
Hi all,
I hope the subject makes sense -- I'll explain what I'm trying to do.
I'm wondering what the best approaches are to being able to include
output from git-describe [1] for generic version strings in projects
managed by Git? This would have to work from within an
autotools-managed project.
At the moment, I've managed to hook the output from git-describe in to
a few .m4 files, which works only at ./configure time -- but of
course, with this being Git, I'd ideally like the same mechanism to
work in a situation where someone does:
$ git pull && make
It's knowing how to plumb this in to the Makefile.am part I'm hazy over.
Any help would be much appreciated.
Harry
[1] I know it's "git describe"; I'm using its hyphenated form for
clarity of context.
^ permalink raw reply
* [BUG] "git diff FILE BRANCH:FILE" erroneously report FILE does not exist in BRANCH
From: Stefano Lattarini @ 2012-01-21 19:36 UTC (permalink / raw)
To: git
Here is a complete reproducer for the bug:
mkdir foo \
&& cd foo \
&& git init . \
&& >README \
&& git add README \
&& git commit -m "for all" \
&& git checkout -b devel \
&& echo dev > README \
&& git add README \
&& git commit -m "for developers" \
&& git diff devel:README master:README \
&& git diff README master:README
I'd expect the last "git diff" to report the same diffs as the previous one;
instead, it errors out with this bogus message:
fatal: Path 'README' exists on disk, but not in 'master'.
Behaviour verified with git version 1.7.7.3 (installed from official Debian
packages) and the latest git development version (1.7.9.rc0.69.gbddcef, from
master).
Regards, and thanks for your amazing software,
Stefano
^ permalink raw reply
* [PATCH V4] git on Mac OS and precomposed unicode
From: Torsten Bögershausen @ 2012-01-21 19:36 UTC (permalink / raw)
To: git; +Cc: tboegi
Changes since V3:
- Be much more defensive:
Do not set core.precomposedunicode=true, even if the file system
probing indicates that it could be true.
(but we don't say that it should be true).
This is to keep better backward compatibility within git.
The user needs to manually enable the precomposition.
However, the .git/config indicates that we have a new
configuration variable, and will encourage people to use it.
- compat/precomposed_utf8.c:
- re-order #includes
- Added some empty lines to make code easier to read.
- Small fixes (xmalloc, errno handling)
- Make function names more consistent by renaming these functions:
argv_precompose() -> precompose_argv()
str_precompose() -> precompose_str()
- Improved the commit message
Torsten Bögershausen (1):
git on Mac OS and precomposed unicode
Documentation/config.txt | 9 ++
Makefile | 3 +
builtin/init-db.c | 2 +
compat/precomposed_utf8.c | 208 ++++++++++++++++++++++++++++++++++++++++++
compat/precomposed_utf8.h | 30 ++++++
git-compat-util.h | 9 ++
git.c | 1 +
t/t3910-mac-os-precompose.sh | 117 +++++++++++++++++++++++
8 files changed, 379 insertions(+), 0 deletions(-)
create mode 100644 compat/precomposed_utf8.c
create mode 100644 compat/precomposed_utf8.h
create mode 100755 t/t3910-mac-os-precompose.sh
--
1.7.8.rc0.43.gb49a8
^ permalink raw reply
* [PATCH V4] git on Mac OS and precomposed unicode
From: Torsten Bögershausen @ 2012-01-21 19:36 UTC (permalink / raw)
To: git; +Cc: tboegi
Allow git on Mac OS to store file names in the index in precomposed unicode,
while the file system uses decomposed unicode.
The problem:
When a file called "LATIN CAPITAL LETTER A WITH DIAERESIS"
(in utf-8 encoded as 0xc3 0x84) is created, the Mac OS filesystem
converts "precomposed unicode" into "decomposed unicode".
This means that readdir() will return 0x41 0xcc 0x88.
Git under Mac OS reverts the unicode decomposition of filenames.
This is useful when pulling/pushing from repositories containing utf-8
encoded filenames using precomposed utf-8 like Linux or Windows (*).
It allows sharing git repositories stored on a VFAT file system
(e.g. a USB stick), and mounted network share using samba.
* (Not all Windows versions support UTF-8 yet:
Msysgit needs the unicode branch, cygwin supports UTF-8 since 1.7)
A new confguration variable is added: "core.precomposedunicode"
If set to false, git behaves exactly as older versions of git.
When a new git version is installed and there is a repository
where the configuration "core.precomposedunicode" is not present,
the new git is backward compatible.
The code in compat/precomposed_utf8.c implements basically 4 new functions:
precomposed_utf8_opendir(), precomposed_utf8_readdir(),
precomposed_utf8_closedir() precompose_argv()
In order to prevent that ever a file name in decomposed unicode is entering
the index, a "brute force" attempt is taken:
all arguments into git (argv[1]..argv[n]) are converted into
precomposed unicode.
This is done in git.c by calling precompose_argv().
This function is actually a #define, and it is only defined under Mac OS.
Nothing is converted on any other OS.
Auto sensing:
When creating a new git repository with "git init" or "git clone",
"core.precomposedunicode" will be set "false".
The user needs to activate this feature manually.
She typically sets core.precomposedunicode to "true" on HFS and VFAT,
or file systems mounted via SAMBA onto a Linux box.
Signed-off-by: Torsten Bögershausen <tboegi@web.de>
---
Documentation/config.txt | 9 ++
Makefile | 3 +
builtin/init-db.c | 2 +
compat/precomposed_utf8.c | 208 ++++++++++++++++++++++++++++++++++++++++++
compat/precomposed_utf8.h | 30 ++++++
git-compat-util.h | 9 ++
git.c | 1 +
t/t3910-mac-os-precompose.sh | 117 +++++++++++++++++++++++
8 files changed, 379 insertions(+), 0 deletions(-)
create mode 100644 compat/precomposed_utf8.c
create mode 100644 compat/precomposed_utf8.h
create mode 100755 t/t3910-mac-os-precompose.sh
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 2959390..29ba4b0 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -175,6 +175,15 @@ The default is false, except linkgit:git-clone[1] or linkgit:git-init[1]
will probe and set core.ignorecase true if appropriate when the repository
is created.
+core.precomposedunicode::
+ This option is only used by Mac OS implementation of git.
+ When core.precomposedunicode=true,
+ git reverts the unicode decomposition of filenames done by Mac OS.
+ This is useful when pulling/pushing from repositories containing utf-8
+ encoded filenames using precomposed unicode (like Linux).
+ When false, file names are handled fully transparent by git.
+ If in doubt, keep core.precomposedunicode=false.
+
core.trustctime::
If false, the ctime differences between the index and the
working tree are ignored; useful when the inode change time
diff --git a/Makefile b/Makefile
index b21d2f1..a912b45 100644
--- a/Makefile
+++ b/Makefile
@@ -519,6 +519,7 @@ LIB_H += compat/bswap.h
LIB_H += compat/cygwin.h
LIB_H += compat/mingw.h
LIB_H += compat/obstack.h
+LIB_H += compat/precomposed_utf8.h
LIB_H += compat/win32/pthread.h
LIB_H += compat/win32/syslog.h
LIB_H += compat/win32/poll.h
@@ -884,6 +885,8 @@ ifeq ($(uname_S),Darwin)
endif
NO_MEMMEM = YesPlease
USE_ST_TIMESPEC = YesPlease
+ COMPAT_OBJS += compat/precomposed_utf8.o
+ BASIC_CFLAGS += -DPRECOMPOSED_UNICODE
endif
ifeq ($(uname_S),SunOS)
NEEDS_SOCKET = YesPlease
diff --git a/builtin/init-db.c b/builtin/init-db.c
index 0dacb8b..06953df 100644
--- a/builtin/init-db.c
+++ b/builtin/init-db.c
@@ -290,6 +290,8 @@ static int create_default_files(const char *template_path)
strcpy(path + len, "CoNfIg");
if (!access(path, F_OK))
git_config_set("core.ignorecase", "true");
+
+ probe_utf8_pathname_composition(path, len);
}
return reinit;
diff --git a/compat/precomposed_utf8.c b/compat/precomposed_utf8.c
new file mode 100644
index 0000000..285fb45
--- /dev/null
+++ b/compat/precomposed_utf8.c
@@ -0,0 +1,208 @@
+#define __PRECOMPOSED_UNICODE_C__
+
+#include "../cache.h"
+#include "../utf8.h"
+#include <stdlib.h>
+#include <string.h>
+#include <stdio.h>
+#include <stdint.h>
+#include "precomposed_utf8.h"
+
+static int mac_os_precomposed_unicode;
+const static char *repo_encoding = "UTF-8";
+const static char *path_encoding = "UTF-8-MAC";
+
+
+/* Code borrowed from utf8.c */
+#if defined(OLD_ICONV) || (defined(__sun__) && !defined(_XPG6))
+ typedef const char * iconv_ibp;
+#else
+ typedef char * iconv_ibp;
+#endif
+
+static char *reencode_string_iconv(const char *in, size_t insz, iconv_t conv)
+{
+ size_t outsz, outalloc;
+ char *out, *outpos;
+ iconv_ibp cp;
+
+ outsz = insz;
+ outalloc = outsz + 1; /* for terminating NUL */
+ out = xmalloc(outalloc);
+ outpos = out;
+ cp = (iconv_ibp)in;
+
+ while (1) {
+ size_t cnt = iconv(conv, &cp, &insz, &outpos, &outsz);
+
+ if (cnt == -1) {
+ size_t sofar;
+ if (errno != E2BIG) {
+ free(out);
+ return NULL;
+ }
+ /* insz has remaining number of bytes.
+ * since we started outsz the same as insz,
+ * it is likely that insz is not enough for
+ * converting the rest.
+ */
+ sofar = outpos - out;
+ outalloc = sofar + insz * 2 + 32;
+ out = xrealloc(out, outalloc);
+ outpos = out + sofar;
+ outsz = outalloc - sofar - 1;
+ }
+ else {
+ *outpos = '\0';
+ break;
+ }
+ }
+ return out;
+}
+
+static size_t has_utf8(const char *s, size_t maxlen, size_t *strlen_c)
+{
+ const uint8_t *utf8p = (const uint8_t*) s;
+ size_t strlen_chars = 0;
+ size_t ret = 0;
+
+ if ((!utf8p) || (!*utf8p))
+ return 0;
+
+ while((*utf8p) && maxlen) {
+ if (*utf8p & 0x80)
+ ret++;
+ strlen_chars++;
+ utf8p++;
+ maxlen--;
+ }
+ if (strlen_c)
+ *strlen_c = strlen_chars;
+
+ return ret;
+}
+
+
+void probe_utf8_pathname_composition(char *path, int len)
+{
+ const static char *auml_nfc = "\xc3\xa4";
+ const static char *auml_nfd = "\x61\xcc\x88";
+ int output_fd;
+ path[len] = 0;
+ strcpy(path + len, auml_nfc);
+ output_fd = open(path, O_CREAT|O_EXCL|O_RDWR, 0600);
+ if (output_fd >=0) {
+ close(output_fd);
+ path[len] = 0;
+ strcpy(path + len, auml_nfd);
+ if (0 == access(path, R_OK))
+ git_config_set("core.precomposedunicode", "false");
+ path[len] = 0;
+ strcpy(path + len, auml_nfc);
+ unlink(path);
+ }
+}
+
+
+static int precomposed_unicode_config(const char *var, const char *value, void *cb)
+{
+ if (!strcasecmp(var, "core.precomposedunicode")) {
+ mac_os_precomposed_unicode = git_config_bool(var, value);
+ return 0;
+ }
+ return 1;
+}
+
+void precompose_argv(int argc, const char **argv)
+{
+ int i = 0;
+ const char *oldarg;
+ char *newarg;
+ iconv_t ic_precompose;
+
+ git_config(precomposed_unicode_config, NULL);
+ if (!mac_os_precomposed_unicode)
+ return;
+
+ ic_precompose = iconv_open(repo_encoding, path_encoding);
+ if (ic_precompose == (iconv_t) -1)
+ return;
+
+ while (i < argc) {
+ size_t namelen;
+ oldarg = argv[i];
+ if (has_utf8(oldarg, (size_t)-1, &namelen)) {
+ newarg = reencode_string_iconv(oldarg, namelen, ic_precompose);
+ if (newarg)
+ argv[i] = newarg;
+ }
+ i++;
+ }
+ iconv_close(ic_precompose);
+}
+
+
+PRECOMPOSED_UTF_DIR * precomposed_utf8_opendir(const char *dirname)
+{
+ PRECOMPOSED_UTF_DIR *precomposed_utf8_dir;
+ precomposed_utf8_dir = xmalloc(sizeof(PRECOMPOSED_UTF_DIR));
+
+ precomposed_utf8_dir->dirp = opendir(dirname);
+ if (!precomposed_utf8_dir->dirp) {
+ free(precomposed_utf8_dir);
+ return NULL;
+ }
+ precomposed_utf8_dir->ic_precompose = iconv_open(repo_encoding, path_encoding);
+ if (precomposed_utf8_dir->ic_precompose == (iconv_t) -1) {
+ closedir(precomposed_utf8_dir->dirp);
+ free(precomposed_utf8_dir);
+ return NULL;
+ }
+
+ return precomposed_utf8_dir;
+}
+
+struct dirent * precomposed_utf8_readdir(PRECOMPOSED_UTF_DIR *precomposed_utf8_dirp)
+{
+ struct dirent *res;
+ size_t namelen = 0;
+
+ res = readdir(precomposed_utf8_dirp->dirp);
+ if (res && mac_os_precomposed_unicode && has_utf8(res->d_name, (size_t)-1, &namelen)) {
+ int ret_errno = errno;
+ size_t outsz = sizeof(precomposed_utf8_dirp->dirent_nfc.d_name) - 1; /* one for \0 */
+ char *outpos = precomposed_utf8_dirp->dirent_nfc.d_name;
+ iconv_ibp cp;
+ size_t cnt;
+ size_t insz = namelen;
+ cp = (iconv_ibp)res->d_name;
+
+ /* Copy all data except the name */
+ memcpy(&precomposed_utf8_dirp->dirent_nfc, res,
+ sizeof(precomposed_utf8_dirp->dirent_nfc)-sizeof(precomposed_utf8_dirp->dirent_nfc.d_name));
+ errno = 0;
+
+ cnt = iconv(precomposed_utf8_dirp->ic_precompose, &cp, &insz, &outpos, &outsz);
+ if (cnt < sizeof(precomposed_utf8_dirp->dirent_nfc.d_name) -1) {
+ *outpos = 0;
+ errno = ret_errno;
+ return &precomposed_utf8_dirp->dirent_nfc;
+ }
+ errno = ret_errno;
+ }
+ return res;
+}
+
+
+int precomposed_utf8_closedir(PRECOMPOSED_UTF_DIR *precomposed_utf8_dirp)
+{
+ int ret_value;
+ int ret_errno;
+ ret_value = closedir(precomposed_utf8_dirp->dirp);
+ ret_errno = errno;
+ if (precomposed_utf8_dirp->ic_precompose != (iconv_t)-1)
+ iconv_close(precomposed_utf8_dirp->ic_precompose);
+ free(precomposed_utf8_dirp);
+ errno = ret_errno;
+ return ret_value;
+}
diff --git a/compat/precomposed_utf8.h b/compat/precomposed_utf8.h
new file mode 100644
index 0000000..79e65e7
--- /dev/null
+++ b/compat/precomposed_utf8.h
@@ -0,0 +1,30 @@
+#ifndef __PRECOMPOSED_UNICODE_H__
+#include <sys/stat.h>
+#include <sys/types.h>
+#include <dirent.h>
+#include <iconv.h>
+
+
+typedef struct {
+ iconv_t ic_precompose;
+ DIR *dirp;
+ struct dirent dirent_nfc;
+} PRECOMPOSED_UTF_DIR;
+
+char *precompose_str(const char *in, iconv_t ic_precompose);
+void precompose_argv(int argc, const char **argv);
+void probe_utf8_pathname_composition(char *, int);
+
+PRECOMPOSED_UTF_DIR *precomposed_utf8_opendir(const char *dirname);
+struct dirent *precomposed_utf8_readdir(PRECOMPOSED_UTF_DIR *dirp);
+int precomposed_utf8_closedir(PRECOMPOSED_UTF_DIR *dirp);
+
+#ifndef __PRECOMPOSED_UNICODE_C__
+#define opendir(n) precomposed_utf8_opendir(n)
+#define readdir(d) precomposed_utf8_readdir(d)
+#define closedir(d) precomposed_utf8_closedir(d)
+#define DIR PRECOMPOSED_UTF_DIR
+#endif /* __PRECOMPOSED_UNICODE_C__ */
+
+#define __PRECOMPOSED_UNICODE_H__
+#endif /* __PRECOMPOSED_UNICODE_H__ */
diff --git a/git-compat-util.h b/git-compat-util.h
index 230e198..8911743 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -153,6 +153,15 @@
#include "compat/msvc.h"
#endif
+/* used on Mac OS X */
+#ifdef PRECOMPOSED_UNICODE
+#include "compat/precomposed_utf8.h"
+#else
+#define precompose_str(in,i_nfd2nfc)
+#define precompose_argv(c,v)
+#define probe_utf8_pathname_composition(a,b)
+#endif
+
#ifndef NO_LIBGEN_H
#include <libgen.h>
#else
diff --git a/git.c b/git.c
index 8e34903..265db96 100644
--- a/git.c
+++ b/git.c
@@ -298,6 +298,7 @@ static int run_builtin(struct cmd_struct *p, int argc, const char **argv)
startup_info->have_repository) /* get_git_dir() may set up repo, avoid that */
trace_repo_setup(prefix);
}
+ precompose_argv(argc, argv);
commit_pager_choice();
if (!help && p->option & NEED_WORK_TREE)
diff --git a/t/t3910-mac-os-precompose.sh b/t/t3910-mac-os-precompose.sh
new file mode 100755
index 0000000..ba3d83c
--- /dev/null
+++ b/t/t3910-mac-os-precompose.sh
@@ -0,0 +1,117 @@
+#!/bin/sh
+#
+# Copyright (c) 2012 Torsten Bögershausen
+#
+
+test_description='utf-8 decomposed (nfd) converted to precomposed (nfc)'
+
+. ./test-lib.sh
+
+Adiarnfc=`printf '\303\204'`
+Odiarnfc=`printf '\303\226'`
+Adiarnfd=`printf 'A\314\210'`
+Odiarnfd=`printf 'O\314\210'`
+
+mkdir junk &&
+>junk/"$Adiarnfc" &&
+case "$(cd junk && echo *)" in
+ "$Adiarnfd")
+ test_nfd=1
+ ;;
+ *) ;;
+esac
+rm -rf junk
+
+if test "$test_nfd"
+then
+ test_expect_success "detect if nfd needed" '
+ precomposedunicode=`git config core.precomposedunicode` &&
+ test "$precomposedunicode" = false &&
+ git config core.precomposedunicode true
+ '
+ test_expect_success "setup" '
+ >x &&
+ git add x &&
+ git commit -m "1st commit" &&
+ git rm x &&
+ git commit -m "rm x"
+ '
+ test_expect_success "setup case mac" '
+ git checkout -b mac_os
+ '
+ # This will test nfd2nfc in readdir()
+ test_expect_success "add file Adiarnfc" '
+ echo f.Adiarnfc >f.$Adiarnfc &&
+ git add f.$Adiarnfc &&
+ git commit -m "add f.$Adiarnfc"
+ '
+ # This will test nfd2nfc in git stage()
+ test_expect_success "stage file d.Adiarnfd/f.Adiarnfd" '
+ mkdir d.$Adiarnfd &&
+ echo d.$Adiarnfd/f.$Adiarnfd >d.$Adiarnfd/f.$Adiarnfd &&
+ git stage d.$Adiarnfd/f.$Adiarnfd &&
+ git commit -m "add d.$Adiarnfd/f.$Adiarnfd"
+ '
+ test_expect_success "add link Adiarnfc" '
+ ln -s d.$Adiarnfd/f.$Adiarnfd l.$Adiarnfc &&
+ git add l.$Adiarnfc &&
+ git commit -m "add l.Adiarnfc"
+ '
+ # This will test git log
+ test_expect_success "git log f.Adiar" '
+ git log f.$Adiarnfc > f.Adiarnfc.log &&
+ git log f.$Adiarnfd > f.Adiarnfd.log &&
+ test -s f.Adiarnfc.log &&
+ test -s f.Adiarnfd.log &&
+ test_cmp f.Adiarnfc.log f.Adiarnfd.log &&
+ rm f.Adiarnfc.log f.Adiarnfd.log
+ '
+ # This will test git ls-files
+ test_expect_success "git lsfiles f.Adiar" '
+ git ls-files f.$Adiarnfc > f.Adiarnfc.log &&
+ git ls-files f.$Adiarnfd > f.Adiarnfd.log &&
+ test -s f.Adiarnfc.log &&
+ test -s f.Adiarnfd.log &&
+ test_cmp f.Adiarnfc.log f.Adiarnfd.log &&
+ rm f.Adiarnfc.log f.Adiarnfd.log
+ '
+ # This will test git mv
+ test_expect_success "git mv" '
+ git mv f.$Adiarnfd f.$Odiarnfc &&
+ git mv d.$Adiarnfd d.$Odiarnfc &&
+ git mv l.$Adiarnfd l.$Odiarnfc &&
+ git commit -m "mv Adiarnfd Odiarnfc"
+ '
+ # Files can be checked out as nfc
+ # And the link has been corrected from nfd to nfc
+ test_expect_success "git checkout nfc" '
+ rm f.$Odiarnfc &&
+ git checkout f.$Odiarnfc
+ '
+ # Make it possible to checkout files with their NFD names
+ test_expect_success "git checkout file nfd" '
+ rm -f f.* &&
+ git checkout f.$Odiarnfd
+ '
+ # Make it possible to checkout links with their NFD names
+ test_expect_success "git checkout link nfd" '
+ rm l.* &&
+ git checkout l.$Odiarnfd
+ '
+ test_expect_success "setup case mac2" '
+ git checkout master &&
+ git reset --hard &&
+ git checkout -b mac_os_2
+ '
+ # This will test nfd2nfc in git commit
+ test_expect_success "commit file d2.Adiarnfd/f.Adiarnfd" '
+ mkdir d2.$Adiarnfd &&
+ echo d2.$Adiarnfd/f.$Adiarnfd >d2.$Adiarnfd/f.$Adiarnfd &&
+ git add d2.$Adiarnfd/f.$Adiarnfd &&
+ git commit -m "add d2.$Adiarnfd/f.$Adiarnfd" -- d2.$Adiarnfd/f.$Adiarnfd
+ '
+else
+ say "Skipping nfc/nfd tests"
+fi
+
+test_done
--
1.7.8.rc0.43.gb49a8
^ permalink raw reply related
* Re: [PATCH] mergetool: Suppress stderr and fix the "both added" test
From: Junio C Hamano @ 2012-01-21 21:27 UTC (permalink / raw)
To: David Aguilar; +Cc: jcwenger, git
In-Reply-To: <1327141578-54796-1-git-send-email-davvid@gmail.com>
David Aguilar <davvid@gmail.com> writes:
> Silence error messages when "git checkout-index" is used to
> checkout a stage that does not exist. This can happen now that
> mergetool calls checkout_staged_file() unconditionally when
> creating the temporary $BASE, $LOCAL, and $REMOTE files.
>
> Fix the test so that it checks the contents of the "both added"
> file. The test was passing as a consequence of accidentally
> handing a bad path to "cat".
>
> Signed-off-by: David Aguilar <davvid@gmail.com>
> ---
> This applies on top of da/maint-mergetool-twoway in pu.
Thanks.
It might make sense to squash this into the previous patch, which luckily
hasn't hit 'next' yet, though---which I can do locally without need for
re-send if you like.
^ permalink raw reply
* Re: [BUG] "git diff FILE BRANCH:FILE" erroneously report FILE does not exist in BRANCH
From: Carlos Martín Nieto @ 2012-01-21 21:33 UTC (permalink / raw)
To: Stefano Lattarini; +Cc: git
In-Reply-To: <4F1B13BB.8070603@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 623 bytes --]
On Sat, 2012-01-21 at 20:36 +0100, Stefano Lattarini wrote:
> I'd expect the last "git diff" to report the same diffs as the previous one;
> instead, it errors out with this bogus message:
>
> fatal: Path 'README' exists on disk, but not in 'master'.
>
> Behaviour verified with git version 1.7.7.3 (installed from official Debian
> packages) and the latest git development version (1.7.9.rc0.69.gbddcef, from
> master).
>
See http://thread.gmane.org/gmane.comp.version-control.git/188355 for
earlier discussion. I haven't gotten around to see if I can fix it
without upsetting too much code.
cmn
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH] optionally deny all pushes
From: Junio C Hamano @ 2012-01-21 22:02 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: git
In-Reply-To: <20120121174927.GA7128@ecki>
Clemens Buchacher <drizzd@aon.at> writes:
> For a mirror repository which is updated only by pulling from upstream,
> it is convenient to disallow all pushes. An accidental push from a
> downstream repository would mess up the mirror's state as well as future
> updates.
>
> Add a boolean configuration variable receive.denyAll. If enabled,
> receive-pack will deny all ref updates.
>
> Signed-off-by: Clemens Buchacher <drizzd@aon.at>
> ---
I do not like this at all.
Especially given that this seems equivalent to:
$ echo exit 1 >.git/hooks/pre-receive
$ chmod +x .git/hooks/pre-receive
this is a mere configuration bloat, isn't it?
Your patch however raises an interesting point. Our pre-receive rejection
infrastructure does have a room for improvement.
A typical "push" exchange goes like this:
receiver: Here are the refs I have.
sender: I want to update your refs with these.
sender: Here is the object data to complete the updated refs.
receiver: Let's see what you are trying to do... I may say:
- I refuse your proposal to update/delete this branch,
as it is the current branch.
- My hook tells me to refuse your proposal to update this
ref, as it does not fast-forward.
We can see that we could decide to reject the push to update the current
branch even before receiving the bulk of transfer. I suspect it might need
a protocol extension to give the receiver a chance to speak after hearing
the proposed set of updates before receiving the bulk of the data to add a
clean error codepath, but at the worset case, we could immediately close
the connection after hearing what the sender proposes to do tries to touch
the current branch in a way we do not like. In other words, the exchange
could become:
receiver: Here are the refs I have.
sender: I want to update your refs with these.
receiver: Let's see what you are trying to do... I may say:
- I can tell you without actually looking at the commits you
are proposing to place at the tips of my refs that I won't
like this branch to be updated/deleted. Go away.
sender: Here is the object data to complete the updated refs.
receiver: Let's see what you are trying to do...
- My hook tells me to refuse your proposal to update this
ref, as it does not fast-forward.
Your "reject any and all" better fits into that new rejection
codepath. Just like the configuration that rejects updates to the current
branch, the decision your patch wants to make can be made before we see
any object data from the sender.
Another thing to consider is that you do not have to be limited to "all".
Often people want to run "git fetch" on their mothership box receiving
data from their notebook, i.e.
mothership$ git fetch notebook master:refs/remotes/notebook/master
mothership$ git merge notebook/master
but are prevented from doing so due to networking issues (e.g. your
notebook may not allow incoming connections). The right way to emulate
this is to initiate the connection in the reverse direction, running "git
push" on their notebook sending data into their mothership box, i.e.
notebook$ git push mothership master:refs/remotes/notebook/master
mothership$ git merge notebook/master
In such a situation, you may want to configure your mothership repository
to reject any push outside refs/remotes/ hierarchy to prevent mistakes.
We could add "receive.allowed = refs/remotes/*" or something to support
this use case. It might turn out that we may even want to make this the
default for non-bare repositories.
Once that happens, you can naturally say "receive.allowed = none" to do
what your patch wants to do as a narrow special case. Wouldn't that be a
much better approach than a "reject any and all" that can only serve a
single narrow case that can already be done with a simple hook?
^ permalink raw reply
* Re: Including git-describe info as version strings for generic "-v" output
From: Junio C Hamano @ 2012-01-21 22:03 UTC (permalink / raw)
To: Harry portobello; +Cc: git
In-Reply-To: <CAG_NL2So7cf6o+en9ktHGr94Eu5WJ9giWq6OmSxK+ZL4RdtaGA@mail.gmail.com>
Harry portobello <harryportobello@gmail.com> writes:
> I hope the subject makes sense -- I'll explain what I'm trying to do.
Perhaps take a look at GIT-VERSION-GEN that is part of the Git source?
^ permalink raw reply
* Re: [BUG] "git diff FILE BRANCH:FILE" erroneously report FILE does not exist in BRANCH
From: Junio C Hamano @ 2012-01-21 22:08 UTC (permalink / raw)
To: Stefano Lattarini; +Cc: git
In-Reply-To: <4F1B13BB.8070603@gmail.com>
Stefano Lattarini <stefano.lattarini@gmail.com> writes:
> && git diff README master:README
http://thread.gmane.org/gmane.comp.version-control.git/188355/focus=188414
^ permalink raw reply
* Re: [PATCH] fix git-gui crash due to uninitialized variable
From: Junio C Hamano @ 2012-01-21 22:13 UTC (permalink / raw)
To: Clemens Buchacher, Pat Thoyts; +Cc: git
In-Reply-To: <20120121175724.GA7319@ecki>
Clemens Buchacher <drizzd@aon.at> writes:
> Recently, a clone initiated via git gui on Windows crashed on me due to
> an "unknown variable cdone". It turns out that there is a code path
> where this variable is used uninitialized.
>
> Signed-off-by: Clemens Buchacher <drizzd@aon.at>
> ---
Thanks, but Clemens, please don't Cc: me git-gui patches, which I won't
take directly.
Pinging Pat.
> Looking at the output of display(), it's not clear to me now the
> function below could ever be called with total=0. But I can't delve into
> it more deeply right now, and this seems like an obvious fix.
>
> git-gui/lib/status_bar.tcl | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/git-gui/lib/status_bar.tcl b/git-gui/lib/status_bar.tcl
> index 95cb449..02111a1 100644
> --- a/git-gui/lib/status_bar.tcl
> +++ b/git-gui/lib/status_bar.tcl
> @@ -77,6 +77,7 @@ method start {msg uds} {
>
> method update {have total} {
> set pdone 0
> + set cdone 0
> if {$total > 0} {
> set pdone [expr {100 * $have / $total}]
> set cdone [expr {[winfo width $w_c] * $have / $total}]
^ permalink raw reply
* Re: [PATCH V4] git on Mac OS and precomposed unicode
From: Junio C Hamano @ 2012-01-21 22:14 UTC (permalink / raw)
To: Torsten Bögershausen; +Cc: git
In-Reply-To: <201201212036.46681.tboegi@web.de>
Torsten Bögershausen <tboegi@web.de> writes:
> Changes since V3:
>
> - Be much more defensive:
> Do not set core.precomposedunicode=true, even if the file system
> probing indicates that it could be true.
> (but we don't say that it should be true).
> This is to keep better backward compatibility within git.
> The user needs to manually enable the precomposition.
> However, the .git/config indicates that we have a new
> configuration variable, and will encourage people to use it.
>
> - compat/precomposed_utf8.c:
> - re-order #includes
> - Added some empty lines to make code easier to read.
> - Small fixes (xmalloc, errno handling)
>
> - Make function names more consistent by renaming these functions:
> argv_precompose() -> precompose_argv()
> str_precompose() -> precompose_str()
> - Improved the commit message
Next time around, please place these after --- lines in the patch message
itself, without making a single-patch series with a separate cover letter.
Thanks.
^ permalink raw reply
* Re: [PATCH V4] git on Mac OS and precomposed unicode
From: Carlos Martín Nieto @ 2012-01-21 22:28 UTC (permalink / raw)
To: Torsten Bögershausen; +Cc: git
In-Reply-To: <201201212036.57632.tboegi@web.de>
[-- Attachment #1: Type: text/plain, Size: 1131 bytes --]
On Sat, 2012-01-21 at 20:36 +0100, Torsten Bögershausen wrote:
> Allow git on Mac OS to store file names in the index in precomposed unicode,
> while the file system uses decomposed unicode.
>
> The problem:
> When a file called "LATIN CAPITAL LETTER A WITH DIAERESIS"
> (in utf-8 encoded as 0xc3 0x84) is created, the Mac OS filesystem
> converts "precomposed unicode" into "decomposed unicode".
> This means that readdir() will return 0x41 0xcc 0x88.
>
> Git under Mac OS reverts the unicode decomposition of filenames.
>
> This is useful when pulling/pushing from repositories containing utf-8
> encoded filenames using precomposed utf-8 like Linux or Windows (*).
>
> It allows sharing git repositories stored on a VFAT file system
> (e.g. a USB stick), and mounted network share using samba.
>
> * (Not all Windows versions support UTF-8 yet:
> Msysgit needs the unicode branch, cygwin supports UTF-8 since 1.7)
This might be overly pedantic, but Windows doesn't really deal with
UTF-8. To use Unicode you need to use the "wide" variant of the
functions, and those take UTF-16.
cmn
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: git clone, hardlinks and multiple users?
From: Neal Kreitzinger @ 2012-01-21 22:54 UTC (permalink / raw)
To: Marc Herbert; +Cc: git
In-Reply-To: <jfc8eh$ck5$1@dough.gmane.org>
On 1/20/2012 11:31 AM, Marc Herbert wrote:
> Hi,
>
> "git clone" is using hardlinks by default, even when cloning from a
> different user. In such a case the clone ends up with a number of
> files owned by someone else.
>
(I assume your using linux.) It sounds like you specified a url syntax
of /path/to/repo.git in your git-clone which tells git to use hardlinks.
If you want your own copies then specify file:///path/to/repo.git in
git-clone (see git-clone manpage section "GIT URLS":
http://schacon.github.com/git/git-clone.html).
> Since only immutable objects are cloned this seems to work fine.
> However I would like to know if this "multiple users" case works by
> chance or by specification.
>
(I'm not an expert on hardlinks, linux metadata, or git, and haven't
used hardlinks at all with linux or git yet, but do have some experience
with git and permissions.) I think if you plan your permissions to be
based on a primary group then it will "just work". If its not as simple
as a single primary group, then read on for my non-expert conversational
input, or at least skim thru for pointers to the reliable manpage
references...
It sounds like part of your question may actually be a hardlink
question so perhaps this info on hardlinks is useful:
http://linfo.org/hard_link.html to you. In regards to git, it does not
track metadata. However, it will track
"permissions" if you tell it to, but even then it only tracks the
executable bit to determine if its stored in the git repo as executable
or non-executable. If you are "changing" the metadata because you
modified the file contents (or executable bit) then
you are creating a new object (in git) and not modifying the original
hardlinked object (in git or linux) or its metadata (in linux). I
assume the working-tree (ie., WORKTREE/ of WORKTREE/.git repo) of the
clone is indeed a full copy of the files via git-checkout because the
manpage only claims to use hardlinks for the object store (ie.
.git/objects/) to save diskspace on the clone of the object store, not
the checkout of the worktree. Worktree objects only get written
to the object store if you stage them to the index (git-add). Then they
are stored in .git/objects/ according to the sha-1 of their
contents. Therefore, if your worktree copy has a different owner and
you don't modify the contents or executable bit then you can't possibly
stage it because git does not detect a difference in content or
executable bit. On the other hand, if you change the contents or the
executable bit then git will consider that a change and update the
object store, but it will be a new object and not the object
representing the previous version you hardlinked to when you cloned. If
that new object is then in turn pushed to the origin repo and someone
else clones it using hardlinks then they may very well not
be able to access that object if its owner:group excludes them. More
likely, if someone pushes an object with bad permissions then others
will get push errors because git stores objects in subdirs named after
the first two chars of the sha-1 which means other objects in that
subdir will also be inaccessible. If you change permissions in regard
to executable bit on your files without editing contents then I don't
know if git will make a new copy or modify the original inode because
I'm not sure if the executable bit permissions is represented in the
sha-1 contents or not. In the git-init manpage there are options for
permissions/sharing under the --shared option (not to be confused with
the --shared option of git-clone which it totally different). The
git-clone equivalent appears to be "git-clone --config
core.sharedRepository=<your-value>". Maybe these core.sharedRepository
settings in git are smart enough to handle the hardlink shared inode
metadata confusion.
> In other words, is there a guarantee that no later version of git or
> no obscure option I haven't used yet will ever try to touch a
> hardlink in any way like for instance: trying update some metadata
> timestamp or, overwrite it with the same value by lack of
> optimization, or any other kind of side-effect that would obviously
> fail.
>
However, if you cd to .git/objects/ and use chmod to change the
permission directly then I think it would change the permissions on the
inodes your origin is storing as loose objects. I'm not sure what it
would do for packed objects. There are clone options like --shared and
--reference that have special notes on the manpage explaining how you
could break things if you don't know what you're doing (that would
include hardlinks but is not exclusive to hardlinks).
Hope this helps in some way. Perhaps someone better informed will
provide a more accurate and/or clear answer. Let me know what
you find out because I too will have to become more concerned about
diskspace and clone optimization in the very near future.
v/r,
neal
^ permalink raw reply
* Re: [PATCH V4] git on Mac OS and precomposed unicode
From: Junio C Hamano @ 2012-01-21 22:56 UTC (permalink / raw)
To: Torsten Bögershausen; +Cc: git, Nguyễn Thái Ngọc Duy
In-Reply-To: <201201212036.57632.tboegi@web.de>
[Pinging Nguyen who has worked rather extensively on the start-up sequence
for ideas.]
Torsten Bögershausen <tboegi@web.de> writes:
I'll try to reword the log message a bit below.
> When a file called "LATIN CAPITAL LETTER A WITH DIAERESIS" (in utf-8
> encoded as 0xc3 0x84) is created, the Mac OS filesystem converts
> "precomposed unicode" into "decomposed unicode". readdir() will return
> 0x41 0xcc 0x88 for such a file, that does not match what the caller
> thought it created.
>
> To work around this braindamage, allow git on Mac OS to optionally use a
> wrapper for readdir() that converts decomposed unicode back into the
> precomposed form, which most other platforms use natively. This makes it
> easier for Mac OS users to work together on the same project with people
> on other platforms (Note that not all Windows versions support UTF-8
> yet. Msysgit needs the unicode branch, cygwin supports UTF-8 since
> 1.7). This allows sharing git repositories stored on a VFAT file system
> (e.g. a USB stick), and mounted network share using samba.
>
> This new feature is controlled by setting a new configuration variable
> "core.precomposedunicode" to "true". Unless the variable is set to "true",
> Git on Mac OS behaves exactly as before, for backward compatiblity.
>
> The code in compat/precomposed_utf8.c implements basically 4 new
> functions: precomposed_utf8_opendir(), precomposed_utf8_readdir(),
> precomposed_utf8_closedir() precompose_argv()
>
> In order to prevent that ever a file name in decomposed unicode is
> entering the index, a "brute force" attempt is taken: all arguments into
> git (argv[1]..argv[n]) are converted into precomposed unicode. This is
> done in git.c by calling precompose_argv(). This function is actually a
> #define, and it is only defined under Mac OS. Nothing is converted on
> any other platforms.
It may be just me, but the above looks more in line with the usual style
of writing in our existing log messages.
Is this UTF-8 decomposition only an issue on HFS+, or does it happen on
any filesystem mounted on a MacOS box? If the former, then the second line
of the first paragraph needs further rephrasing, e.g. "... is created,
HFS+, the primary filesystem on the Mac OS, converts ...".
> Auto sensing:
> When creating a new git repository with "git init" or "git clone",
> "core.precomposedunicode" will be set "false".
>
> The user needs to activate this feature manually.
> She typically sets core.precomposedunicode to "true" on HFS and VFAT,
> or file systems mounted via SAMBA onto a Linux box.
I am not sure about this design decision.
I agree that it is prudent to introduce a new feature disabled by default,
and I can understand that you tried to make the feature more discoverable
by setting it explicitly to "false".
But I do not think it is a good idea. If a user is on MacOS and has only
HFS+, then it would be more convenient to have the configuration set to
true in $HOME/.gitconfig once and for all, to affect all repositories on
the box. "git init" dropping the explicit "false" to any new repositories
defeats that.
Wouldn't it make more sense if your "git init" did it this way?
* Do not do anything, if you know core.precomposedunicode is already
set (in /etc/gitconfig or $HOME/.gitconfig);
* Otherwise, if the "probe" says "yes, we are on HFS+", issue an
advice message to suggest the user to set it either in the
repository specific .git/config or in $HOME/.gitconfig file.
> +core.precomposedunicode::
> + This option is only used by Mac OS implementation of git.
> + When core.precomposedunicode=true,
> + git reverts the unicode decomposition of filenames done by Mac OS.
> + This is useful when pulling/pushing from repositories containing utf-8
> + encoded filenames using precomposed unicode (like Linux).
I would imagine that if the caller of creat(2) named the path in the
decomposed form, Mac OS would store it unaltered; strictly speaking, we
shouldn't say "reverts". How about:
When set to true, pathnames in decomposed UTF-8 read from the
filesystem are converted to precomposed UTF-8 before they are used by
Git, to improve interoperability with other platforms.
> +void precompose_argv(int argc, const char **argv)
> +{
> + int i = 0;
> + const char *oldarg;
> + char *newarg;
> + iconv_t ic_precompose;
> +
> + git_config(precomposed_unicode_config, NULL);
As the first thing called after main(), I still doubt this is a safe thing
to do (Pinging Nguyen who has worked rather extensively on the start-up
sequence for ideas). This is ifdefed away and will not break things on
other platforms, which may make it even harder to diagnose breakages.
^ permalink raw reply
* Re: Finding all commits which modify a file
From: Neal Kreitzinger @ 2012-01-21 23:16 UTC (permalink / raw)
To: Neal Groothuis; +Cc: git
In-Reply-To: <46043.208.70.151.129.1327095331.squirrel@mail.lo-cal.org>
On 1/20/2012 3:35 PM, Neal Groothuis wrote:
> Hello,
>
> I'm trying to find /all/ commits that change a file in the
> repository...and its proving to be trickier than I thought. :-)
>
> The situation that we were dealing with is this:
>
> - Person A and person B both pull from the same central repository.
>
> - Person A makes a change to file foo.txt and bar.txt, commits, and pushes
> to the central repository.
>
> - Person B makes a similar change to bar.txt and commits it.
>
> - Person B does a fetch and merge. Since both A and B made changes to
> bar.txt, this requires conflicts to be resolved manually.
>
> - B reverts A's changes to foo.txt. (If B is coming from a different
> revision control system, this may happen due to confusion about how merges
> are handled.)
>
> - B commits the changes.
>
> - B makes more changes to bar.txt, commits them, and pushes to the central
> repository.
>
> At this point, A's changes to foo.txt have been undone.
>
> Graphically:
>
> A1
> / ^
> v \
> C1 B2<-B3
> ^ /
> \ v
> B1
>
> B1, B2, and B3 have the same version of foo.txt as C1, A1 modifies it.
>
> Person A discovers that his changes are missing and wants to know what
> happened.
>
> git log foo.txt doesn't help; it won't even show commit A1, due to history
> simplification.
>
> git log --full-history foo.txt will show commit A1. It still won't show
> commit B2, though, which we'd also like to show (because that's where the
> change to foo.txt got removed).
>
> I would think that git log --simplify-merges foo.txt would have done what
> I'd wanted, but it still does not show commit B2. Based on what I'm
> reading in the man page, I would expect the simplification to go like
> this:
>
> A1
> | ^
> | \
> | B2<-B3
> | /
> v v
> C1
>
> (since B1 is TREESAME as C1 if we're only considering foo.txt)
>
> A1
> | ^
> | \
> | B2<-B3
> |
> v
> C1
>
> (since C1 is an ancestor of A1)
>
> However, the actual output only includes A1, not B2.
>
> - Can someone explain this, and/or
> - can someone offer a command to display all commits (including merges)
> in which ANY parent is not TREESAME?
>
Does git-log --all help?
v/r,
neal
^ permalink raw reply
* Re: [PATCH] mergetool: Suppress stderr and fix the "both added" test
From: David Aguilar @ 2012-01-21 23:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: jcwenger@gmail.com, git@vger.kernel.org
In-Reply-To: <7v39b8d9w6.fsf@alter.siamese.dyndns.org>
On Jan 21, 2012, at 1:27 PM, Junio C Hamano <gitster@pobox.com> wrote:
> David Aguilar <davvid@gmail.com> writes:
>
>> Silence error messages when "git checkout-index" is used to
>> checkout a stage that does not exist. This can happen now that
>> mergetool calls checkout_staged_file() unconditionally when
>> creating the temporary $BASE, $LOCAL, and $REMOTE files.
>>
>> Fix the test so that it checks the contents of the "both added"
>> file. The test was passing as a consequence of accidentally
>> handing a bad path to "cat".
>>
>> Signed-off-by: David Aguilar <davvid@gmail.com>
>> ---
>> This applies on top of da/maint-mergetool-twoway in pu.
>
> Thanks.
>
> It might make sense to squash this into the previous patch, which luckily
> hasn't hit 'next' yet, though---which I can do locally without need for
> re-send if you like.
Yes, please squash this commit. This is certainly a fix up.
Thanks,
David
^ permalink raw reply
* Re: [linux.conf.au] VCS Interoperability
From: David Michael Barr @ 2012-01-22 3:39 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: git, Junio C Hamano, Jonathan Nieder, Dmitry Ivankov
In-Reply-To: <CALkWK0kMmDMZ4wiMSmOfwBLzd+xBEA+WKsviu9FVcvj9eZEahg@mail.gmail.com>
Hi all,
>> Next week, I'll be presenting a summary of the past 2 years work
>> on improving svn interoperability for git.
>> I'm requesting feedback from anyone who cares with regard to
>> what they'd like to hear about.
>
> Nice. As a lay person attending the conference, here are a few things
> I think I'd like to hear:
> - Why this project is so challenging compared to say, a git-hg bridge
> or a git-darcs bridge. What makes Subversion especially hard to deal
> with?
> - What is the biggest motivation for developing the svnrdump/ svnrload
> combination? Are there any other usecases for the tools?
> - How has this project contributed to the development of the
> fast-import infrastructure? Can these changes be used to improve
> other/ future remote helpers?
> - You've spoken about exporting Subversion history to Git so far, but
> what about the reverse? Which parts of the picture are still missing?
Thank you for the feedback, it helped a lot with picking a trajectory.
Video is now available: http://youtu.be/0hVuv-wv4Dw
Slides: http://barrbrain.github.com/vcs-interoperability.html
It was my first conference presentation so the usual caveats apply.
I was fortunate to have a small but interested audience.
I look forward to constructive criticism so that I can better represent
our community to the folk Down Under.
--
David Barr
^ permalink raw reply
* Re: Finding all commits which modify a file
From: Tay Ray Chuan @ 2012-01-22 4:03 UTC (permalink / raw)
To: Neal Groothuis; +Cc: git
In-Reply-To: <46043.208.70.151.129.1327095331.squirrel@mail.lo-cal.org>
On Sat, Jan 21, 2012 at 5:35 AM, Neal Groothuis <ngroot@lo-cal.org> wrote:
> Hello,
>
> I'm trying to find /all/ commits that change a file in the
> repository...and its proving to be trickier than I thought. :-)
>
> The situation that we were dealing with is this:
>
> - Person A and person B both pull from the same central repository.
>
> - Person A makes a change to file foo.txt and bar.txt, commits, and pushes
> to the central repository.
>
> - Person B makes a similar change to bar.txt and commits it.
>
> - Person B does a fetch and merge. Since both A and B made changes to
> bar.txt, this requires conflicts to be resolved manually.
>
> - B reverts A's changes to foo.txt. (If B is coming from a different
> revision control system, this may happen due to confusion about how merges
> are handled.)
How is this "revert" done? Was it done at the conflict resolution
level or with a git-revert invocation?
Nonetheless, either way, A's commit would be still be present in the
log history.
>[snip]
> Graphically:
>
> A1
> / ^
> v \
> C1 B2<-B3
> ^ /
> \ v
> B1
>
> B1, B2, and B3 have the same version of foo.txt as C1, A1 modifies it.
Just to clarify, is C1 the commit that both A and B both share when
they first pull in the first step? And B2 is the merge?
--
Cheers,
Ray Chuan
^ permalink raw reply
* [RFC/PATCH git-remote-bzr] Adapt to new semantics of remote-helper "import" command
From: Jonathan Nieder @ 2012-01-22 5:46 UTC (permalink / raw)
To: Gabriel Filion
Cc: git, Simon Poirier, Sverre Rabbelier, Jeff King, David Barr,
Dmitry Ivankov
Git 1.7.7 (commit 9504bc9d, "transport-helper: change import
semantics", 2011-07-16) incompatibly changed the interface of the
"import" capability.
Before, git would always send a single import command, which the
remote helper would respond to with a fast-import stream, terminated
by end of file, meaning there was no way to fetch multiple refs in one
connection. Nowadays, git instead sends a sequence of import lines:
import refs/heads/foo
import refs/heads/bar
terminated by a blank line. The helper is to respond with a
fast-import stream terminated by the "done" command and process
further commands until another blank line indicates the end of the
command stream.
---
Hi Simon and Gabriel,
Here's a rough patch against git://github.com/lelutin/git-remote-bzr.git
master.
Without this patch, whenever I try to use "git clone bzr::<something>",
after doing all the work it removes the resulting repo and exits with
status 141 (SIGPIPE). Maybe the transport-helper should mask SIGPIPE
when writing the final newline to avoid that.
I'd have prefered to write a patch for remote-bzr that works with
older versions of git fast-import, too, but it wasn't obvious how.
Hints welcome.
BTW, would you mind if I sent a patch to include git-remote-bzr in
git.git under contrib/?
Thanks for git remote-bzr! I'd be happy for any thoughts you have.
Ciao,
Jonathan
[1] http://thread.gmane.org/gmane.comp.version-control.git/176002/focus=176606
README.rst | 2 +-
git-remote-bzr | 33 ++++++++++++++++++++++++++++++---
2 files changed, 31 insertions(+), 4 deletions(-)
diff --git a/README.rst b/README.rst
index 3eb3e476..f4dbbeb2 100644
--- a/README.rst
+++ b/README.rst
@@ -34,7 +34,7 @@ Relevant bug reports
Requirements
------------
-- git 1.6.6 or later
+- git 1.7.7 or later
- python 2.5 +
- bzr 2.x
- bzr-fastimport
diff --git a/git-remote-bzr b/git-remote-bzr
index 1e3a05f9..501fffe3 100755
--- a/git-remote-bzr
+++ b/git-remote-bzr
@@ -49,7 +49,7 @@ def do_list(repo, args):
print # end list
-def do_import(repo, args):
+def import_one_ref(repo, args):
"""Import a fast-import stream that is exported from Bazaar."""
if len(args) != 1:
die("Import needs exactly one ref")
@@ -65,6 +65,23 @@ def do_import(repo, args):
if bzrp.wait():
die("'bzr fast-export' returned unexpectedly with code %d",
bzrp.returncode)
+ print "done"
+
+
+def do_import(repo,args):
+ import_one_ref(repo, args)
+
+ cmdline = True
+ while cmdline:
+ cmdline = next_command()
+ if not cmdline:
+ # Return to main processing loop
+ return True
+ cmd = cmdline.pop(0)
+ if cmd != "import":
+ warn("Unexpected command %s during import" % cmd)
+ return False
+ import_one_ref(repo, cmdline)
def do_push(repo, args):
@@ -123,8 +140,8 @@ def sanitize(value):
return value
-def read_one_line(repo):
- """Read and process one command."""
+def next_command():
+ """Read one command."""
line = sys.stdin.readline()
cmdline = line
@@ -138,6 +155,16 @@ def read_one_line(repo):
# Blank line means we're about to quit
return False
+ return cmdline
+
+
+def read_one_line(repo):
+ """Read and process one command."""
+ cmdline = next_command()
+
+ if not cmdline:
+ return False
+
cmd = cmdline.pop(0)
debug("Got command '%s' with args '%s'", cmd, ' '.join(cmdline))
--
1.7.9.rc2
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox