

Git-number: Use numbers for dealing with files in git - nazri1
https://github.com/holygeek/git-number

======
yuvadam
Not sure how necessary this is - interactive adding (`git add -i`) does all
this much more elegantly.

~~~
Argorak
git add -p Is also a nice alternative. Sadly, it doesn't allow you to revert
an add files like darcs does.

~~~
bostonvaulter2
Not sure exactly what you mean but you should be aware of checkout -p and
reset -p

~~~
Argorak
Close, but not truly the same. In interactive mode, darcs hands you every
change it can find and asks you what to do with it (including reverting the
change). So, if i added a file using `touch`, deleted one using `rm` (but not
`git rm`), added a debug statement to a file and a change in another, the
workflow would be the following:

* Add file foo: Ynr? Y * Remove file bar: Ynr? n * Add debug statement? r #revert, I don't need it anyways * Add change xyz? n # I want this in another commit

Its a real handy way to iterate over _all_ changes in your repos that it
finds. I used it heavily to review all my changes before committing them as
multiple patches.

------
unwind
I find I just use tab-completion. I'm quite used to writing the names of the
files in my project anyway, and find the "hard core" interaction through the
shell quite pleasant, it simply is in line with what you tend to do in the
shell.

Micro-plug: if you use the Geany editor/IDE, you might like
<https://github.com/unwind/gitbrowser> to make switching between files
(opening them if necessary) by substring-searching the filename from the Git
repo pleasant.

------
icefox
Neat little tool. For add's though probably 99% of the time I use 'git add -p'
Not only do I not have to type the file names, but I get a quick little final
code review to boot which seems win all around.

~~~
ch0wn
'git add -i' can also be very helpful. This is my preferred tool for staging
files to commit.

------
canop_fr
Looks similar to scm breeze : <https://github.com/ndbroadbent/scm_breeze>

But scm breeze (which I use every days) seems much more powerful.

------
famoreira
Interesting and useful if your are using the command line version of git.

However since starting to use Magit (git mode for Emacs) I never feel the need
to drop to the console in order to interact with my git repo because Magit has
such a brilliant interface. I encourage people to try out!

------
spuz
This is nice but to be honest I'm surprised it's not a feature already built
into git. It seems strange that for a command line tool the fastest way to
interact with files is to use the mouse to double click and then right click .
Maybe you could submit a patch to git itself?

~~~
jerf
Are you sure you're using your shell with full fluency? I can identify a file
in a nontrivial source tree with the shell far faster than a mouse, and the
advantage only opens up if I start specifying more than one file.

------
glenjamin
The case of adding some files or bits of files is one of the few cases where I
spin up a GUI tool. I find git-cola is excellent at this.

The other GUI case is using qgit when browsing logs in detail.

~~~
etherealG
for the logs in detail case, you should check out log's graph command. i find
it much quicker than any gui tool at the same thing. here's my alias with
color etc:

    
    
      lg = !git log --all --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --date=relative $(git stash list --format=%h)

------
bostonvaulter2
This is fairly similar to git shortcuts, although I think that git shortcuts
is more featureful

~~~
obtu
I assume you are referring to the same thing as canop_fr,
<https://github.com/ndbroadbent/scm_breeze> ?

~~~
bostonvaulter2
Yeah, that's the one. I think the title of the blog that introduced it used
the name git shortcuts.

------
hoschi
Yeah, now I can throw away tig for staging files :D

