-1

Git has its own versions of commands such as mv and rm that we really ought to use when doing these operations inside repositories.

However, I'm sure I'm not the only person who often forgets to do this.

Is there any way to automatically use these tools when operating within a git repository?

I'm interested in answers for any of bash, zsh or fish.

0

2 Answers 2

3

git mv does a different thing from normal mv and is very much not a drop-in replacement.

For instance, it doesn't act on untracked files:

touch foo
git mv foo bar

prints

fatal: not under version control, source=foo, destination=bar

And refuses to move the file. Similar things apply to the other commands. They are tools for working with git, so using these commands instead of the normal operating system versions is not a good idea.

Git has its own versions of commands such as mv and rm that we really ought to use when doing these operations inside repositories

You oughtn't.

5
  • I know they do different things... But 9/10 times, if you're in a repo, you want to be using the git ones... But you do raise a valid point I suppose Commented Aug 7, 2022 at 14:49
  • 3
    There’s no way of knowing the intent of the user in such a way that replacing mv/rm with git … is always safe. You’re unlikely to mess anything up if you use mv or rm instead of git …, but using git … instead of mv or rm could have unfortunate results. Commented Aug 7, 2022 at 14:54
  • Not sure I'd agree with that @StephenKitt - It'll mess up your commit history thinking you've deleted and recreated files rather than renaming them a lot of the time. Either way, it's my Torvalds given right to shoot myself in the foot if I want to :P Commented Aug 7, 2022 at 15:12
  • 1
    Right, so mv results in a file deletion and creation, but in my experience if both end up in the same commit git figures out that it’s a rename anyway. Commented Aug 7, 2022 at 15:14
  • 1
    See this entry in the Git FAQ. Commented Aug 7, 2022 at 15:17
1

I suggest you have some myrm / mymv script that git rev-parse in order to detect if you are inside the repo and act accordingly. Something like :

ingitr="$(git rev-parse --is-inside-work-tree 2>/dev/null)"
if [ "$ingitr" ]
then
    git rm $1 ( git mv $1 $2 )
else
    rm $1 ( mv $1 $2 )
fi

Of course this is for a starting point. It should certainly be enhanced in order to take care of options.


However I read from comments that… you should not want that. (I'll remove this answer under pressure… ;-)

4
  • Thanks mate... Whether I should or shouldn't want it is kinda irrelevant... The whole Linux philosophy is that I'm well within my rights to shoot myself in the foot if I want to! Thanks for your help here Commented Aug 7, 2022 at 15:11
  • 1
    @ScottishTapWater : You are welcome. I do believe in the "Provide tools, not policy" adage too !
    – MC68020
    Commented Aug 7, 2022 at 15:17
  • @ScottishTapWater thing is that even within a git repository, you sometimes need to be able to just delete files - not everything in every git repo is part of the index, and only things in the index are handled by git rm. This isn't about shooting yourself in the foot, this is about burning your perfectly good axe whenever you enter a garden, assuming all you need in gardening is a shovel. You're confusing git rm with something it's not! It's not a replacement for rm, it does quite a different job, the only thing they both have in Commented Aug 7, 2022 at 20:25
  • 1
    common (aside from the name) is that after git rm you might end up with a file less. That's why I down-voted this question: it does show insufficient research on what git rm actually does! Commented Aug 7, 2022 at 20:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .