davvid / git-cola
- Source
- Commits
- Network (4)
- Issues (7)
- Downloads (27)
- Wiki (3)
- Graphs
-
Branch:
master
click here to add a description
click here to add a homepage
-
2 votes
1 comment Created 19 days ago by ahockerstenusabilityx(Optionally) display the git command that was run in the command output windowwishlistxI would like the git command that was run to be displayed in the "command output" window. The rationale is that I want to be able to learn how git is used from reading the commands that are run.
Yes, I am aware of the GIT_PYTHON_TRACE environment variable, but that gives me output in the terminal, which is not what I want.
Comments
-
6 votes
0 comments Created 8 months ago by davvidAdd an interactive rebase GUI with drag + drop editingwishlistxA gui for 'git rebase -i' would royally rock.
We'd need to check on the status on git-sequencer. Ideally we'd just be providing an interactive front end to the 'rebase -i' text file, though integrating more tightly might mean implementing parts of rebase in python.
Comments
Please log in to comment. -
A reusable widget for grpahically displaying a project's history would be very useful.
There are a first few steps towards this issue in the 'treeview' branch.
gitk performs very well, but users are often confused by the graphical layout of the DAG. A more natural DAG can be constructed using a QGraphicsScene (that's what the 'treeview' branch uses) but it doesn't perform as well since it doesn't have the "one-commit-per-line" limitation like gitk.
Comments
Please log in to comment. -
From Ugo Riboni on the git-cola mailing list:
- The ability to remember options for dialogs, e.g. the "pull" dialog. For example in my workflow i do "pull --rebase" a lot, and having to check the "rebase" checkbox everytime is annoying. Same for "push" and all those other commands with lots of options. (by the way David, thanks for adding that "rebase" option :))
Comments
Please log in to comment. -
0 votes
2 comments Created about 1 month ago by culebron(1.4.1) git-cola locks is wrong password in openSSHusabilityxI pushed to a remote repo over SSH, then in OpenSSH window I entered a password in wrong kbd layout, and git-cola's window locked with nothing happening.
version 1.4.1 Ubuntu 9.10 64bit.
Comments
Can you elaborate a little on the "wrong kbd layout" detail?
How can I reproduce this? Do I simply switch to a different keyboard layout and try to enter a password?
Does the password contain non-ascii characters?
We use an SSH_ASKPASS program in cola.
Do you run git-cola from the shell or from the applications menu?When $SSH_ASKPASS is undefined we use $cola/share/git-cola/bin/ssh-askpass.
On this laptop $SSH_ASKPASS is set to /usr/libexec/openssh/gnome-ssh-askpass.Is that similar to what you have?
Which one is prompting for your password? The one from $cola or the one from the system?You can run them interactively to figure out which is which:
$ /path/to/ssh-askpass "test message"
Please log in to comment.Sorry for taking so long to reply. I see OpenSSH window. (Not @ home right now, can't check). I entered a pw in Russian layout (UTF-8). Let me check the vars tonight @ home.
-
2 votes
0 comments Created 2 months ago by ijumaProvide drop-down with previous commit messageswishlistxI think it would be really useful to have a drop-down with the previous commit messages at the bottom of the commit message editor. Selecting one would cause it to be inserted as the commit message.
It would also be good to have a keyboard shortcut for cycling through them. I didn't find a way to do this with the current UI, but please let me know if I missed something.
Comments
Please log in to comment. -
3 votes
3 comments Created 3 months ago by ugtarUse pygments to do syntax highlighting on top of diff viewwishlistxFrom the mailing list:
"It would be a super hot feature to syntax highlight diffs using pygments. " "Optionally, you could use the diff colors as background (light red, light green), and syntax higlight at the same time. "What if we lighten the red/green background colors, and put the syntax highlighting on top of it. We should probably make the highlighting a preference so it can be turned off.
Comments
a couple of possible routes:
use pygments + qsyntaxhighlighter -- pygments to lexically analyze the text, and set the colors on the various things ourselves.
use our own syntax highlighting in qsyntaxhighligher
use pygments to generate rich text formatted output in our qsyntaxhighlighter subclass
using gnu source highlight via qt: http://srchiliteqt.sourceforge.net/
Useful links:
http://doc.trolltech.com/4.5/qsyntaxhighlighter.html
http://doc.trolltech.com/4.5/richtext-syntaxhighlighter.html
http://lateral.netmanagers.com.ar/static/highlighter.pyThe first option sounds very nice and should be the most practical.
Some things that make things tricky --
remember that we're looking at diff hunks. That complicates things like:/* this is a comment + and this is a new line and this is an existing line @@ -1,20 diff header +2,25 @@ int main() { + int i; char c;As you can see, we only ever see the beginning of the comment inside of
the diff hunk. Syntax highlighting multiple lines means we have to remember
some state and some context, but the "we're looking at diffs here" complicates that since pygments really wants to work on the whole file at once.I remember you mentioning that they support syntax highlighting diffs, but I have a feeling that it doesn't highlight the code inside the hunks. If pygments is smart enough to handle that then I'd be quite impressed.
Please log in to comment.we might have to do some preprocessing to only highlight the diff hunks and ignore the diff headers, but I'd say we shouldn't do more than just naively apply the syntax highlighting to the diff hunks, and let pygments do its thing (maybe we can tell it the language if we know that much). If it's smart enough to figure out a decent hilighting strategy, then more power to it.
Sounds like a good idea.