Completion in general is very lacking compared to ZSH, but I'm not sure we can anything about that.

Directories under $prefix/share are supposed to be package names. We should move our Ruby lib directory accordingly.

If the same command has been issued several times in a row, I have to up-arrow an equal number of times to get past it in the history. Would be nice if this could be compacted, like bash does with HISTCONTROL=ignoredups

Currently releasing a version looks like this:

1. make distcheck
2. Add the tarball to the gh-pages branch and push it to GitHub
3. Update the homebrew-gitsh repo with the new URL and SHA1, and pus it to GitHub
4. (Do whatever the debian package requires)

It would be great if this was just make release

I type clear habitually, is this something we should support?

ctrl+c shouldn't emit a stack trace.

We want a way of distributing this as an OS package instead of using Rubygems. It's a program, not a library, and non-Ruby users shouldn't need to understand the Ruby ecosystem to use it.

gitsh doesn't work with hub,

is there a simple fix for this?

For example:

:function pair name nick {
  :set user.name "George Brocklehurst and $name"
  :set user.email "[email protected]"
  :set gitsh.prompt "$nick+$gitsh.prompt"
}

# usage:
# gitsh@ @pair "Mike Burns" mburns
# mburns+gitsh@

When I restart gitsh, I shouldn't lose my history.

According to the README:

Tab completion for git commands, aliases, and branches without modifying your shell settings, and without any extra setup for aliases and third party git commands.

Tab completion works for commands/branches but not for options. For example, if I want to run rebase --continue I can tab-complete the rebase but not the --continue. ZSH allowed me to complete both. It would be nice to add this ability to gitsh.

When a custom git executable is provided (e.g. hub) the GitCommand class uses it, but the GitRepository class doesn't.

Pressing return to get a git status is useful, but it does fill the history with blank lines.

We can probably get around this by manually pushing to Readline::HISTORY when the line isn't blank, instead of letting readline build the history for us.

Hub's a pretty large part of my git workflow, should the script check for / use hub?

It could be smart about trying hub only on unrecognized commands.

Mike's original spike supported the following backslash commands:

• \e Open editor
• \! Run in shell
• \? Help (for gitsh)
• \h Help (for git commands)
• \c Change directory
• \q Quit

Getting the error above, while ruby version is 2.1. Details:

dimitry@dimitry-ubuntu ~/gitsh-0.3 $ ./configure 
checking for a BSD-compatible install... /usr/bin/install -c
...
checking for grep that handles long lines and -e... /bin/grep
checking for ruby version... ruby 1.9.3p194 (2012-04-20 revision 35410) [x86_64-linux]
configure: error: Ruby 2.0 or later is required to install gitsh
dimitry@dimitry-ubuntu ~/gitsh-0.3 $ ruby -v
ruby 2.1.0p0 (2013-12-25 revision 44422) [x86_64-linux]

It might be more idiomatic to encourage users to use "ctrl-d" to quit gitsh - pretty much every shell command that accepts sub-commands interactively (psql, bc, dc, mysql) recognizes this sequence and exits properly (including gitsh).

Instead of tap thoughtbot/gitsh, let's get users to tap thoughtbot/formulae instead.

I get an error from ./configure:

/usr/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:51:in require': cannot load such file -- bundler (LoadError) from /usr/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:51:inrequire'
from ./vendor/vendorize:3:in `

What do I need to do to fix this?

Thanks,
Lawrence

When I tab complete a branch name that does not fit on the current line in a tmux pane the completed name wraps around on the same line, replacing the prompt:

This does not happen outside of tmux in a really small terminal window. Is this a bug or is it perhaps an issue with my tmux setup?

Commands are currently prefixed with /usr/bin/env git and then given directly to the shell as a string. This means things like status ; echo Hello work when they really shouldn't.

It should be possible to customise the prompt via a git config variable.

A colon or two dots should be considered a word separator for tab completion purposes. This would be useful when specifying local:remote pairs of refs or ranges of commits, for example:

@ push staging HEAD:master
@ push origin :some-feature-branch
@ log origin/master..master

Maybe this should be installed somewhere, too?

System Ruby on BSD-ish systems (including OS X) is linked against libedit instead of readline. Unfortunately, libedit isn't very good. Fortunately, there is a pure Ruby implementation of readline we can depend on.

https://github.com/luislavena/rb-readline

Currently we add colour to certain parts of the prompt when the terminal supports it. This will work fine when the colours are added by gitsh, but it will break down if the user has put colours elsewhere in the prompt.

I suggest:

1. Stop implicitly colouring the prompt sigil, and go back to something akin to Mike's prototype (where there are placeholders for the gitsh.prompt setting to start colouring and stop colouring).
2. When we detect the terminal doesn't support colour, remove ANSI colour sequences (because it shouldn't matter if they were added by the program or by the user, the behaviour should be consistent).

I'd like to use ($VISUAL || $EDITOR || vi || ed) to edit a command.

Currently leaving a string open at the end of a command will cause a parse error.

Things to answer, taken directly from @croaky :

• What's expected usage? Do I change into gitsh when I cd into the project for the day? Or only when I need git commands on an ad-hoc basis, then exit?
• If I try to execute a non-gitsh command inside gitsh, does it delegate out to my regular shell?
• Would I want to just turn on gitsh shell-wide rather than having to enter and exit it? Sort of the shell alias equivalent to what we have now in thoughtbot/dotfiles.

Might be useful to make a video.

On OS X, pressing Ctrl-U after typing a word with a space pushes the cursor several whitespaces beyond the prompt. It's as if some imaginary text exists between the cursor and the prompt. It's not possible to bring the cursor back, even by pressing the backspace key unless return is pressed.

e.g. something like %C(00;31) would map to \033[00;31m

See #54 for more discussion.

Homebrew's environment (brew sh) starts a non-login shell. It might still read the user's $PATH customisation though, depending on which shell configuration file it's in.

We need to do something more subtle to make sure we've found a new enough system Ruby.

https://thoughtbot.campfirenow.com/room/344621/paste/1126652848

Filenames with spaces don't appear to be handled correctly for tab completion.

They are completed, but the space is not escaped and the file path is not in quotes.

I'm on OS X Lion (10.7) and installed gitsh manually through the configure && make && make install dance, after exporting the ruby environment variable to point to my MacPorts-installed ruby 2.1 binary:

export RUBY=/opt/local/bin/ruby
./configure --prefix=/usr/local
make
sudo make install

This produces a gitsh installation in /usr/local (which gitsh --> /usr/local/bin/gitsh), but it fails to load with the following message:

/opt/local/lib/ruby2.1/2.1.0/rubygems/core_ext/kernel_require.rb:55:in `require': cannot load such file -- /usr/local/share/gitsh/gems/setup.rb (LoadError)

Indeed, the gems/setup.rb file is nowhere to be found, neither in the resulting installation nor in the source distribution:

 -> ls  /usr/local/share/gitsh/
total 0
drwxr-xr-x  3 root  wheel   102B Feb 11 16:23 ruby/
 -> ls  /usr/local/share/gitsh/gems/setup.rb
ls: /usr/local/share/gitsh/gems/setup.rb: No such file or directory

 -> pwd
/Users/jmpp/Desktop/gitsh-0.3
 -> find . -iname "*setup*" (produces no results).

After configuring, the resulting gitsh script looks as following:

#!/opt/local/bin/ruby

$LOAD_PATH.unshift('/usr/local/share/gitsh/ruby')

require '/usr/local/share/gitsh/gems/setup.rb'
require 'gitsh/cli'

begin
  Gitsh::CLI.new.run
rescue => e
  $stderr.puts "gitsh: Error: #{e.message}"
end

Am I doing something wrong? Thanks for the help!

gitsh should accept commands via STDIN or the path to a script as an argument. Scripting support will require additional features, like variables.

The version number is passed from autoconf to Ruby, we just need a way of displaying it.

As a interested customer of your gem, I don't really know what you're selling.

Show me the money!

gitsh tries to use system ruby which is 1.8.7 on OSX Mountain Lion, but gitsh requires 2.0 or greater.

checking for ruby version... 1.8.7
configure: error: Ruby 2.0 or later is required to install gitsh

For:

• File names
• Treeish names
• Commands
• Remote names

For example:

@ status
(git status)
@ :set foo.bar 1
@ status
(git -c foo.bar=1 status)

Also, reading config variables should be possible:

@ commit -m "Written by $user.name"

I spiked this out as a debugging tool while implementing variables, and it was very useful.

Usage:

@ :set foo "Hello world"
@ :echo "foo is: $foo"
foo is: Hello world

Allow for comment lines that begin with #.

In interactive mode, when the user enters no command, it should be interpreted as status

Would be cool to have gitsh in the Arch User Repository, so we don't miss updates.

Temporary aliases can be created with the :set command, but they aren't tab completable (e.g. :set alias.foo "!echo this is the foo alias").

This could be fixed by making the Completer class depend on an Environment instance instead of a GitRepository instance. A similar refactoring of the Prompter class allowed the prompt to be customised using :set (see 83aedde951f0b397fbc1d65583868f78f6c1718c)