provide shortcut to git mv and git rm inside repo by default instead of plain gitless mv/rm

[corbolais]

Hi,

thank you for bash-git-prompt. I love it.

So much that I finally did:

add means to add user defined commands based on pwd being a git repo. Useful i.e. for git mv/rm cmd.

So much more consistent, less evil trap and easier handling now.

Inside git repo: mv calls git mv Outside git repo: mv is plain std mv

Same applies to rm/git rm.

Those to standard commands get shadowed by the new shell functions when in a git repo. The plain old commands then are still available using fully qualified paths (i.e. /bin/mv) but for convenience (w/ bash completion anyways) also as mv_mv and rm_rm.

cheers, c

[magicmonty]

Hi @corbolais,

thank you for this contribution, but I think, this helper is out of scope for a prompt. I don't think a generic prompt should change commands by default. This seems to me something, that belongs into its own project.

but thanks anyway M

[corbolais]

Hi @magicmonty Thank you for your feedback and, yes, basically, I feel the same way you do.

Before I started what became this PR in the end, I tried to figure out where this should go to be of use and land in the right spot. Tougher than initially thought it was.

TL;DR: see last paragraph.

In general, I'd prefer not to clutter a piece of code that has a specific purpose and does it's job right. As the case with bash-git-prompt. Then again, in this particular case, it is (regarding this PR) all about git and it is about git and bash in the case of bash-git-prompt.

I believe with git repositories it is very useful to have a context-sensitive move command. Countless are the devs just moving or removing files in git repos with the standard mv or rm unix commands which is blatantly agnostic of git and git repositories. And if you did just kill a file git got ahold of, git insists in telling you so, boldly. So either you accept your messing things up in the code history and tell git to shut up or "you oughta fix what you broke"(tm).

In the end one has to back up files, restore the mv'd or rm 'd files to finally correctly and consistently git mv and git rm those files.

This is why bash-git-prompt is the proper place: it is creating and undoing the context as required by any context sensitive mv or rm commands to operate in. If need be, more aliases can be added, as the local user wishes. But the bare minimum consensus IMO seems to be a git repo-conscious mv or rm.

No harm should be done with changing these commands anyway, their signature is sufficiently distinct.

One way to merge the PR might be a guard, a configuration variable such as the ones described in the README, to enable its functionality in case one wants the negligible overhead to get context sensitive move and remove behaviour. Would this change address your concern about changing a command by default?

cheers C

[magicmonty]

Hi @corbolais,

well done plea. I will not merge this immediately, but open this to discussion, as I am not the only one who uses the prompt. Configurability will be in any case a first step here.

Greetings M

[ogr3]

I agree with @magicmonty that this seems out of scope for this project. If you really want custom things to happen when in a git repo - maybe use the prompt-callback function in a custom theme?

Sourcing a bash script is something we already have had a serious security issue with in this project, and this approach opens up that potential problem again.

[corbolais]

@magicmonty: looking at the PR, I realize the guard is already in place. If there is no $__GIT_PROMPT_DIR/git_user_cmds.sh file nothing will get parsed, everything is hunky-dory. One could add an additional switch variable for users to turn this feature (temporarily) off even if there's a non-empty file to be parsed.

@ogr3: interesting point, any pointer to an issue from the past?

Regarding the prompt-callback, I fail to see the advantage security-wise. Could you elaborate?

Refactoring such functionality into a theme is counter-intuitive to say the least. As a user I wouldn't suspect a theme to enhance functionality rather than usability. Adding a plugin callback would -- IMO -- be wiser, then.

As an aside, I'd like to further enhance bash-git-prompt to be of use in conjunction with vcsh and myrepos . Should I develop it into a PR? Any plans so far?

cheers

[magicmonty]

@corbolais Integration with vcsh and myrepos could be interesting. But please make a PR for each of them.

I still don't like the idea to source a file everytime the prompt is generated (which happens in your case in setGitPrompt()). A better way would be a function which is created at install time (so the file is sourced just once).

Also the guard variable is needed indeed, as even the test for existence of a file is another system call.

The idea with the plugin callback is interesting. I currently just have no idea how to implement this. If I add a plugin system, it has to be done in such a way, that the plugin-file is sourced just once at the installation of the prompt.

[corbolais]

@magicmonty: about sourcing "a file everytime the prompt is generated", granted, it's far from being an elegant solution. As for now, it's rather a "works for me" situation. Where exactly would you put such code?

[guenhter]

@corbolais Thx for your effort so far. As seen, this is a controversal topic. I still find it useful but also not sure, if it should be in the scope of this project. I believe that this extensions you've created would be even worth an own repo so everyone can decide to use this bash-prompt, your shortcuts or both. Mabye you start your own repo and I'm happy to reference that one then here in the readme so that people get aware.