Turns out, all git programs git-mv uses are capable of operating in
a subdirectory just fine. So don't complain about it.
[jc: I think that sounds sane. You need to grab the exit status from
`git-rev-parse --git-dir`, which I added. Alex Riesen says this
worked fine.]
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
-k requests to keep running on an error condition.
Previously, git-mv stopped on failing renames even with -k.
There are some error conditions which are not checked in the
first phase of git-mv, eg. 'permission denied'. Still, option
-k should work.
Signed-off-by: Josef Weidendorfer <Josef.Weidendorfer@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This gives a better error message when trying to move a directory
into some subdirectory of itself; ie. no real bug fix: renaming
already failed before, but with a strange "invalid argument".
Signed-off-by: Josef Weidendorfer <Josef.Weidendorfer@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When doing multiple renames, and a rename in the middle fails,
git-mv did not store the successful renames in the git index;
this is fixed by delaying the error message on a failed rename
to after the git updating.
Signed-off-by: Josef Weidendorfer <Josef.Weidendorfer@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Small fixes to be consistent with other git scripts:
- usage message is only about options and arguments
- on error, exit(1) without the usage message
Additionally, "beautifies" output with -n a little bit
Signed-off-by: Josef Weidendorfer <Josef.Weidendorfer@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Use update-index --stdin to handle large number of files without
breaking exec() argument storage limit.
[jc: with minor cleanup from the version posted on the list]
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is fixed by putting the file into @changedfiles/@addedfiles,
and not the directory this file is in.
Additionally, this fixes the behavior for attempting to overwrite
a file with a directory, and gives a message for all cases where
overwriting is not possible (file->dir,dir->file,dir->dir).
Thanks for Alexander Litvinov for noting this problem.
Signed-off-by: Josef Weidendorfer <Josef.Weidendorfer@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Needed because generating a target paths will add another slash.
This fixes e.g. "git-mv file dir/", which removed "file" from
version control by renaming it to "dir//file", as
git-update-index does not accept such paths.
Thanks goes to Ben Lau for noting this bug.
Signed-off-by: Josef Weidendorfer <Josef.Weidendorfer@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When moving multiple files at once, it can happen that
files get the same target name, like in
git-mv a/foo b/foo destdir
Both a/foo and b/foo target destdir/foo.
Signed-off-by: Josef Weidendorfer <Josef.Weidendorfer@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
It supersedes git-rename by adding functionality to move multiple
files, directories or symlinks into another directory. It also
provides according documentation.
The implementation renames multiple files, using the arguments from
the command line to produce an array of sources and destinations. In
a first pass, all requested renames are checked for errors, and
overwriting of existing files is only allowed with '-f'. The actual
renaming is done in a second pass. This ensures that any error
condition is checked before anything is changed.
Signed-off-by: Josef Weidendorfer <Josef.Weidendorfer@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
