path: root/builtin/mv.c
AgeCommit message (Collapse)Author
2013-10-14mv: Fix spurious warning when moving a file in presence of submodulesJens Lehmann
In commit 0656781fa "git mv" learned to update the submodule path in the .gitmodules file when moving a submodule in the work tree. But since that commit update_path_in_gitmodules() gets called no matter if we moved a submodule or a regular file, which is wrong and leads to a bogus warning when moving a regular file in a repo containing a .gitmodules file: warning: Could not find section in .gitmodules where path=<filename> Fix that by only calling update_path_in_gitmodules() when moving a submodule. To achieve that, we introduce the special SUBMODULE_WITH_GITDIR define to distinguish the cases where we also have to connect work tree and git directory from those where we only need to update the .gitmodules setting. A test for submodules using a .git directory together with a .gitmodules file has been added to t7001. Even though newer git versions will always use a gitfile when cloning submodules, repositories cloned with older git versions will still use this layout. Reported-by: Matthieu Moy <> Signed-off-by: Jens Lehmann <> Signed-off-by: Jonathan Nieder <>
2013-09-09Merge branch 'jl/submodule-mv'Junio C Hamano
"git mv A B" when moving a submodule A does "the right thing", inclusing relocating its working tree and adjusting the paths in the .gitmodules file. * jl/submodule-mv: (53 commits) rm: delete .gitmodules entry of submodules removed from the work tree mv: update the path entry in .gitmodules for moved submodules submodule.c: add .gitmodules staging helper functions mv: move submodules using a gitfile mv: move submodules together with their work trees rm: do not set a variable twice without intermediate reading. t6131 - skip tests if on case-insensitive file system parse_pathspec: accept :(icase)path syntax pathspec: support :(glob) syntax pathspec: make --literal-pathspecs disable pathspec magic pathspec: support :(literal) syntax for noglob pathspec kill limit_pathspec_to_literal() as it's only used by parse_pathspec() parse_pathspec: preserve prefix length via PATHSPEC_PREFIX_ORIGIN parse_pathspec: make sure the prefix part is wildcard-free rename field "raw" to "_raw" in struct pathspec tree-diff: remove the use of pathspec's raw[] in follow-rename codepath remove match_pathspec() in favor of match_pathspec_depth() remove init_pathspec() in favor of parse_pathspec() remove diff_tree_{setup,release}_paths convert common_prefix() to use struct pathspec ...
2013-08-06mv: update the path entry in .gitmodules for moved submodulesJens Lehmann
Currently using "git mv" on a submodule moves the submodule's work tree in that of the superproject. But the submodule's path setting in .gitmodules is left untouched, which is now inconsistent with the work tree and makes git commands that rely on the proper path -> name mapping (like status and diff) behave strangely. Let "git mv" help here by not only moving the submodule's work tree but also updating the "submodule.<submodule name>.path" setting from the .gitmodules file and stage both. This doesn't happen when no .gitmodules file is found and only issues a warning when it doesn't have a section for this submodule. This is because the user might just use plain gitlinks without the .gitmodules file or has already updated the path setting by hand before issuing the "git mv" command (in which case the warning reminds him that mv would have done that for him). Only when .gitmodules is found and contains merge conflicts the mv command will fail and tell the user to resolve the conflict before trying again. Also extend the man page to inform the user about this new feature. Signed-off-by: Jens Lehmann <> Signed-off-by: Junio C Hamano <>
2013-08-05Replace deprecated OPT_BOOLEAN by OPT_BOOLStefan Beller
This task emerged from b04ba2bb (parse-options: deprecate OPT_BOOLEAN, 2011-09-27). All occurrences of the respective variables have been reviewed and none of them relied on the counting up mechanism, but all of them were using the variable as a true boolean. This patch does not change semantics of any command intentionally. Signed-off-by: Stefan Beller <> Signed-off-by: Junio C Hamano <>
2013-07-30mv: move submodules using a gitfileJens Lehmann
When moving a submodule which uses a gitfile to point to the git directory stored in .git/modules/<name> of the superproject two changes must be made to make the submodule work: the .git file and the core.worktree setting must be adjusted to point from work tree to git directory and back. Achieve that by remembering which submodule uses a gitfile by storing the result of read_gitfile() of each submodule. If that is not NULL the new function connect_work_tree_and_git_dir() is called after renaming the submodule's work tree which updates the two settings to the new values. Extend the man page to inform the user about that feature (and while at it change the description to not talk about a script anymore, as mv is a builtin for quite some time now). Signed-off-by: Jens Lehmann <> Signed-off-by: Junio C Hamano <>
2013-07-30mv: move submodules together with their work treesJens Lehmann
Currently the attempt to use "git mv" on a submodule errors out with: fatal: source directory is empty, source=<src>, destination=<dest> The reason is that mv searches for the submodule with a trailing slash in the index, which it doesn't find (because it is stored without a trailing slash). As it doesn't find any index entries inside the submodule it claims the directory would be empty even though it isn't. Fix that by searching for the name without a trailing slash and continue if it is a submodule. Then rename() will move the submodule work tree just like it moves a file. Signed-off-by: Jens Lehmann <> Signed-off-by: Junio C Hamano <>
2013-07-15pathspec: add copy_pathspecNguyễn Thái Ngọc Duy
Because free_pathspec wants to free "items" pointer in the pathspec structure, a simple structure assignment is not enough if you want to copy an existing pathspec into another. Freeing the original will damage the copy unless a deep copy is made. Note that the strings in pathspec->items->match and the array pathspec->raw[] are still shared between the original and the copy. Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2012-08-20i18n: mv: 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 <>
2011-12-20Merge branch 'jk/maint-mv'Junio C Hamano
* jk/maint-mv: mv: be quiet about overwriting mv: improve overwrite warning mv: make non-directory destination error more clear mv: honor --verbose flag docs: mention "-k" for both forms of "git mv"
2011-12-12mv: be quiet about overwritingJeff King
When a user asks us to force a mv and overwrite the destination, we print a warning. However, since a typical use would be: $ git mv one two fatal: destination exists, source=one, destination=two $ git mv -f one two warning: overwriting 'two' this warning is just noise. We already know we're overwriting; that's why we gave -f! This patch silences the warning unless "--verbose" is given. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2011-12-12mv: improve overwrite warningJeff King
When we try to "git mv" over an existing file, the error message is fairly informative: $ git mv one two fatal: destination exists, source=one, destination=two When the user forces the overwrite, we give a warning: $ git mv -f one two warning: destination exists; will overwrite! This is less informative, but still sufficient in the simple rename case, as there is only one rename happening. But when moving files from one directory to another, it becomes useless: $ mkdir three $ touch one two three/one $ git add . $ git mv one two three fatal: destination exists, source=one, destination=three/one $ git mv -f one two three warning: destination exists; will overwrite! The first message is helpful, but the second one gives us no clue about what was overwritten. Let's mention the name of the destination file: $ git mv -f one two three warning: overwriting 'three/one' Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2011-12-12mv: make non-directory destination error more clearJeff King
If you try to "git mv" multiple files onto another non-directory file, you confusingly get the "usage" message: $ touch one two three $ git add . $ git mv one two three usage: git mv [options] <source>... <destination> [...] From the user's perspective, that makes no sense. They just gave parameters that exactly match that usage! This behavior dates back to the original C version of "git mv", which had a usage message like: usage: git mv (<source> <destination> | <source>... <destination>) This was slightly less confusing, because it at least mentions that there are two ways to invoke (but it still isn't clear why what the user provided doesn't work). Instead, let's show an error message like: $ git mv one two three fatal: destination 'three' is not a directory We could leave the usage message in place, too, but it doesn't actually help here. It contains no hints that there are two forms, nor that multi-file form requires that the endpoint be a directory. So it just becomes useless noise that distracts from the real error. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2011-12-12mv: honor --verbose flagJeff King
The code for a verbose flag has been here since "git mv" was converted to C many years ago, but actually getting the "-v" flag from the command line was accidentally lost in the transition. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2011-10-06builtin/mv.c: plug miniscule memory leakBrandon Casey
The "it" string would not be free'ed if base_name was non-NULL. Let's free it. Signed-off-by: Brandon Casey <> Signed-off-by: Junio C Hamano <>
2011-10-06cleanup: use internal memory allocation wrapper functions everywhereBrandon Casey
The "x"-prefixed versions of strdup, malloc, etc. will check whether the allocation was successful and terminate the process otherwise. A few uses of malloc were left alone since they already implemented a graceful path of failure or were in a quasi external library like xdiff. Additionally, the call to malloc in compat/win32/syslog.c was not modified since the syslog() implemented there is a die handler and a call to the x-wrappers within a die handler could result in recursion should memory allocation fail. This will have to be addressed separately. Signed-off-by: Brandon Casey <> Signed-off-by: Junio C Hamano <>
2011-03-10i18n: git-mv "bad" messagesÆvar Arnfjörð Bjarmason
Gettextize messages made by assigning to the "bad" char* variable. Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <>
2011-03-10i18n: git-mv basic messagesÆvar Arnfjörð Bjarmason
Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <>
2010-11-15add OPT__FORCERené Scharfe
Add OPT__FORCE as a helper macro in the same spirit as OPT__VERBOSE to simplify defining -f/--force options. Signed-off-by: Rene Scharfe <> Signed-off-by: Junio C Hamano <>
2010-11-15add description parameter to OPT__DRY_RUNRené Scharfe
Allows better help text to be defined than "dry run". Also make use of the macro in places that already had a different description. No object code changes intended. Signed-off-by: Rene Scharfe <> Signed-off-by: Junio C Hamano <>
2010-07-05string_list: Add STRING_LIST_INIT macro and make use of it.Thiago Farina
Acked-by: Jonathan Nieder <> Signed-off-by: Thiago Farina <> Signed-off-by: Junio C Hamano <>
2010-06-27string_list: Fix argument order for string_list_insertJulian Phillips
Update the definition and callers of string_list_insert to use the string_list as the first argument. This helps make the string_list API easier to use by being more consistent. Signed-off-by: Julian Phillips <> Signed-off-by: Junio C Hamano <>
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 <>