when there's a tag and a branch with the same name, git errors out with
`error: dst refspec MY_BRANCH matches more than one.`
git-delete-tag is not affected by this bug
Matching "):" in the end can match commit subjects by mistake i.e. if
commit subject ends with "):" too (e.g. linux project has one such
commit).
To avoid this and any similar problems print summary only (-s).
Restructure output to look exactly as it was before with awk.
Use git-rev-list and builtin --count option
$ time git log --oneline | wc -l
30613
real 0m0.858s
user 0m0.684s
sys 0m0.239s
$ time git rev-list --count HEAD
30613
real 0m0.416s
user 0m0.396s
sys 0m0.018s
It won't delete master. If you have a ligitimate reasn to delete master,
you probably should use delete-branch directly.
It works for multiple branches and it asks for confirmation each time.
-f|--force supresses confirmation
You can answer 'a' (all) when prompted, which means you won't be asked
again.
Added -s --soft arguments as well.
Default roll-back one with HEAD^ and only using ~ if commit count more than 1.
Added auto complete.
Updated documentation.
Attitude adjustment: don't throw errors and say NO as suggested in #114, have a can do attitude instead, leave the errors up to git to report.
Did a rebase merge from the old pull request #46 which we may close now.
Yet it wasn't as simple as that in the end but all things have a resolve:
Added 2 context type arguments to specify --local or --global.
Refactored usage into functions te prevent duplication.
Capable to view and append to both global gitignore as well as the .gitignore from the working folder.
Supports all types of ignore patters including ! negated, comments as well as blank lines.
Complete documentation including several examples.
-h option allows you to undo the last commit without keeping the
changes in the local working directory. Use with care.
Updated documentation to include new option.
As per the bug identified in #127 git-ignore would add duplicate entries in .gitignore which is redundant and should not happen.
grep will suitably verify that the entry doesn't exit but only if the file actually exists or we will get an error on stderr. check if the
file exists with test -f and that the new entry is present or alternatively just go ahead and add the new value which will create the file if it didn't exist.
Running the same command again does not add the duplicate.
