path: root/builtin/init-db.c
AgeCommit message (Collapse)Author
2012-08-20i18n: init-db: mark parseopt strings for translationNguyễn Thái Ngọc Duy
Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2012-07-09git on Mac OS and precomposed unicodeTorsten Bögershausen
Mac OS X mangles file names containing unicode on file systems HFS+, VFAT or SAMBA. When a file using unicode code points outside ASCII is created on a HFS+ drive, the file name is converted into decomposed unicode and written to disk. No conversion is done if the file name is already decomposed unicode. Calling open("\xc3\x84", ...) with a precomposed "Ä" yields the same result as open("\x41\xcc\x88",...) with a decomposed "Ä". As a consequence, readdir() returns the file names in decomposed unicode, even if the user expects precomposed unicode. Unlike on HFS+, Mac OS X stores files on a VFAT drive (e.g. an USB drive) in precomposed unicode, but readdir() still returns file names in decomposed unicode. When a git repository is stored on a network share using SAMBA, file names are send over the wire and written to disk on the remote system in precomposed unicode, but Mac OS X readdir() returns decomposed unicode to be compatible with its behaviour on HFS+ and VFAT. The unicode decomposition causes many problems: - The names "git add" and other commands get from the end user may often be precomposed form (the decomposed form is not easily input from the keyboard), but when the commands read from the filesystem to see what it is going to update the index with already is on the filesystem, readdir() will give decomposed form, which is different. - Similarly "git log", "git mv" and all other commands that need to compare pathnames found on the command line (often but not always precomposed form; a command line input resulting from globbing may be in decomposed) with pathnames found in the tree objects (should be precomposed form to be compatible with other systems and for consistency in general). - The same for names stored in the index, which should be precomposed, that may need to be compared with the names read from readdir(). NFS mounted from Linux is fully transparent and does not suffer from the above. As Mac OS X treats precomposed and decomposed file names as equal, we can - wrap readdir() on Mac OS X to return the precomposed form, and - normalize decomposed form given from the command line also to the precomposed form, to ensure that all pathnames used in Git are always in the precomposed form. This behaviour can be requested by setting "core.precomposedunicode" configuration variable to true. The code in compat/precomposed_utf8.c implements basically 4 new functions: precomposed_utf8_opendir(), precomposed_utf8_readdir(), precomposed_utf8_closedir() and precompose_argv(). The first three are to wrap opendir(3), readdir(3), and closedir(3) functions. The argv[] conversion allows to use the TAB filename completion done by the shell on command line. It tolerates other tools which use readdir() to feed decomposed file names into git. 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. Helped-by: Junio C Hamano <> Signed-off-by: Torsten Bögershausen <> Signed-off-by: Junio C Hamano <>
2011-12-21builtin/init-db.c: eliminate -Wformat warning on SolarisÆvar Arnfjörð Bjarmason
On Solaris systems we'd warn about an implicit cast of mode_t when we printed things out with the %d format. We'd get this warning under GCC 4.6.0 with Solaris headers: builtin/init-db.c: In function ‘separate_git_dir’: builtin/init-db.c:354:4: warning: format ‘%d’ expects argument of type ‘int’, but argument 2 has type ‘mode_t’ [-Wformat] We've been doing this ever since v1.7.4.1-296-gb57fb80. Just work around this by adding an explicit cast. Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <>
2011-08-22read_gitfile_gently(): rename misnamed function to read_gitfile()Junio C Hamano
The function was not gentle at all to the callers and died without giving them a chance to deal with possible errors. Rename it to read_gitfile(), and update all the callers. As no existing caller needs a true "gently" variant, we do not bother adding one at this point. Signed-off-by: Junio C Hamano <>
2011-05-25Merge branch 'maint'Junio C Hamano
* maint: init/clone: remove short option -L and document --separate-git-dir
2011-05-25init/clone: remove short option -L and document --separate-git-dirNguyen Thai Ngoc Duy
Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2011-04-12i18n: mark init-db messages for translationÆvar Arnfjörð Bjarmason
Mark the init-db messages that were added in v1.7.5-rc1~16^2 (init, clone: support --separate-git-dir for .git file) by Nguyễn Thái Ngọc Duy for translation. This requires splitting up the tests that the patch added so that certain parts of them can be skipped unless the C_LOCALE_OUTPUT prerequisite is satisfied. Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <>
2011-04-02Merge branch 'nd/init-gitdir'Junio C Hamano
* nd/init-gitdir: init, clone: support --separate-git-dir for .git file git-init.txt: move description section up Conflicts: builtin/clone.c
2011-04-02Merge branch 'ab/i18n-st'Junio C Hamano
* ab/i18n-st: (69 commits) i18n: git-shortlog basic messages i18n: git-revert split up "could not revert/apply" message i18n: git-revert literal "me" messages i18n: git-revert "Your local changes" message i18n: git-revert basic messages i18n: git-notes GIT_NOTES_REWRITE_MODE error message i18n: git-notes basic commands i18n: git-gc "Auto packing the repository" message i18n: git-gc basic messages i18n: git-describe basic messages i18n: git-clean clean.requireForce messages i18n: git-clean basic messages i18n: git-bundle basic messages i18n: git-archive basic messages i18n: git-status "renamed: " message i18n: git-status "Initial commit" message i18n: git-status "Changes to be committed" message i18n: git-status shortstatus messages i18n: git-status "nothing to commit" messages i18n: git-status basic messages ... Conflicts: builtin/branch.c builtin/checkout.c builtin/clone.c builtin/commit.c builtin/grep.c builtin/merge.c builtin/push.c builtin/revert.c t/ t/
2011-03-20init, clone: support --separate-git-dir for .git fileNguyễn Thái Ngọc Duy
--separate-git-dir tells git to create git dir at the specified location, instead of where it is supposed to be. A .git file that points to that location will be put in place so that it appears normal to repo discovery process. Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2011-03-17Name make_*_path functions more accuratelyCarlos Martín Nieto
Rename the make_*_path functions so it's clearer what they do, in particlar make clear what the differnce between make_absolute_path and make_nonrelative_path is by renaming them real_path and absolute_path respectively. make_relative_path has an understandable name and is renamed to relative_path to maintain the name convention. The function calls have been replaced 1-to-1 in their usage. Signed-off-by: Carlos Martín Nieto <> Signed-off-by: Junio C Hamano <>
2011-03-10i18n: git-init "Initialized [...] repository" messageÆvar Arnfjörð Bjarmason
These messages could benefit from splitting up. An earlier version of this patch began like this: const char *reinit_shared = _("Reinitialized existing shared Git repository in %s\n"); const char *init_shared = _("Initialized empty shared Git repository in %s\n"); const char *reinit_noshared = _("Reinitialized existing Git repository in %s\n"); const char *init_noshared = _("Initialized empty Git repository in %s\n"); But in the first round of gettextization I'm aiming to keep code changes to a minimum for ease of review. So just add a comment explaining to translators how the sprintf format gets used so they can cope for now if the language's grammar allows. Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Jonathan Nieder <> Signed-off-by: Junio C Hamano <>
2011-03-10i18n: git-init basic messagesÆvar Arnfjörð Bjarmason
Change the user visible strings in init-db.c to use gettext localizations. This only converts messages which needed to be changed from "foo" to _("foo"), and didn't need any TRANSLATORS comments. I haven't marked the messages in init_db_usage or init_db_options for translation, since that would require additional changes in parse-options.c. Those can be done later. Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Jonathan Nieder <> Signed-off-by: Junio C Hamano <>
2011-03-03init: remove unnecessary checkNguyễn Thái Ngọc Duy
git_dir must always be non-NULL so "if (git_dir)" is unnecessary. Before this code, if git_dir == NULL, it will default to DEFAULT_GIT_DIR_ENVIRONMENT. Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2011-02-15clone,init: describe --template using the same wordingMichael J Gruber
This also corrects a wrong description for clone. Signed-off-by: Michael J Gruber <> Signed-off-by: Junio C Hamano <>
2010-12-22Remove all logic from get_git_work_tree()Nguyễn Thái Ngọc Duy
This logic is now only used by cmd_init_db(). setup_* functions do not rely on it any more. Move all the logic to cmd_init_db() and turn get_git_work_tree() into a simple function. Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2010-12-22setup: limit get_git_work_tree()'s to explicit setup case onlyNguyễn Thái Ngọc Duy
get_git_work_tree() takes input as core.worktree, core.bare, GIT_WORK_TREE and decides correct worktree setting. Unfortunately it does not do its job well. core.worktree and GIT_WORK_TREE should only be taken into account, if GIT_DIR is set (which is handled by setup_explicit_git_dir). For other setup cases, only core.bare matters. Add a temporary variable setup_explicit to adjust get_git_work_tree() behavior as such. This variable will be gone once setup_* rework is done. Also remove is_bare_repository_cfg check in set_git_work_tree() to ease the rework. We are going to check for core.bare and core.worktree early before setting worktree. For example, if core.bare is true, no need to set worktree. Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2010-10-06init: plug tiny one-time memory leakJonathan Nieder
The buffer used to construct paths like ".git/objects/info" and ".git/objects/pack" is allocated on the heap and never freed. So free it. While at it, factor out the relevant code into its own function and rename the sha1_dir variable to object_directory (to match the change in everyday usage after the renaming of SHA1_FILE_DIRECTORY in v0.99~603^2~7, 2005). Noticed by valgrind while setting up tests (in test-lib). Signed-off-by: Jonathan Nieder <> Signed-off-by: Junio C Hamano <>
2010-05-10handle "git --bare init <dir>" properlyJeff King
If we know we are creating a bare repository, we use setenv to set the GIT_DIR directory to the current directory (either where we already were, or one we created and chdir'd into with "git init --bare <dir>"). However, with "git --bare init <dir>" (note the --bare as a git wrapper option), the setup code actually sets GIT_DIR for us, but it uses the wrong, original cwd when a directory is given. Because our setenv does not use the overwrite flag, it is ignored. We need to set the overwrite flag, but only when we are given a directory on the command line. That still allows: GIT_DIR=foo.git git init --bare to work. The behavior is changed for: GIT_DIR=foo.git git init --bare bar.git which used to create the repository in foo.git, but now will use bar.git. This is more sane, as command line options should generally override the environment. Noticed by Oliver Hoffmann. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2010-03-10Merge branch 'sd/init-template'Junio C Hamano
* sd/init-template: wrap-for-bin: do not export an empty GIT_TEMPLATE_DIR t/ add test for 'init with init.templatedir set' init: having keywords without value is not a global error. Add a "TEMPLATE DIRECTORY" section to git-init[1]. Add `init.templatedir` configuration variable.
2010-03-10Merge branch 'lt/deepen-builtin-source'Junio C Hamano
* lt/deepen-builtin-source: Move 'builtin-*' into a 'builtin/' subdirectory Conflicts: Makefile
2010-02-22Move 'builtin-*' into a 'builtin/' subdirectoryLinus Torvalds
This shrinks the top-level directory a bit, and makes it much more pleasant to use auto-completion on the thing. Instead of [torvalds@nehalem git]$ em buil<tab> Display all 180 possibilities? (y or n) [torvalds@nehalem git]$ em builtin-sh builtin-shortlog.c builtin-show-branch.c builtin-show-ref.c builtin-shortlog.o builtin-show-branch.o builtin-show-ref.o [torvalds@nehalem git]$ em builtin-shor<tab> builtin-shortlog.c builtin-shortlog.o [torvalds@nehalem git]$ em builtin-shortlog.c you get [torvalds@nehalem git]$ em buil<tab> [type] builtin/ builtin.h [torvalds@nehalem git]$ em builtin [auto-completes to] [torvalds@nehalem git]$ em builtin/sh<tab> [type] shortlog.c shortlog.o show-branch.c show-branch.o show-ref.c show-ref.o [torvalds@nehalem git]$ em builtin/sho [auto-completes to] [torvalds@nehalem git]$ em builtin/shor<tab> [type] shortlog.c shortlog.o [torvalds@nehalem git]$ em builtin/shortlog.c which doesn't seem all that different, but not having that annoying break in "Display all 180 possibilities?" is quite a relief. NOTE! If you do this in a clean tree (no object files etc), or using an editor that has auto-completion rules that ignores '*.o' files, you won't see that annoying 'Display all 180 possibilities?' message - it will just show the choices instead. I think bash has some cut-off around 100 choices or something. So the reason I see this is that I'm using an odd editory, and thus don't have the rules to cut down on auto-completion. But you can simulate that by using 'ls' instead, or something similar. Signed-off-by: Linus Torvalds <> Signed-off-by: Junio C Hamano <>