Issues - davvid/git-cola

davvid / git-cola

Description:

git-cola: A highly caffeinated Git GUI

Sort by: Priority | Votes | Last Updated

Loading…

1.

4 votes

wishlist
x

Add an interactive rebase GUI with drag + drop editing
0 comments Created 5 months ago by davvid

Title

Body
A 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.
or cancel

A 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

Parsed with GitHub Flavored Markdown
6.

3 votes

wishlist
x

gitk-like history tree view
0 comments Created 5 months ago by davvid

Title

Body
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.
or cancel

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

Parsed with GitHub Flavored Markdown
33.

1 vote

wishlist
x

Provide drop-down with previous commit messages
0 comments Created 6 days ago by ijuma

Title

Body
I 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.
or cancel

I 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

Parsed with GitHub Flavored Markdown
4.

1 vote

wishlist
x

Remember options for dialogs
0 comments Created 5 months ago by davvid

Title

Body
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 :))
or cancel
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

Parsed with GitHub Flavored Markdown
28.

1 vote

wishlist
x

Use pygments to do syntax highlighting on top of diff view
3 comments Created 27 days ago by ugtar

Title

Body
From 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. http://pygments.org/
or cancel
From 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.

http://pygments.org/

Comments
ugtar Tue Oct 27 11:15:37 -0700 2009 | link
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.py
Comment
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.py
or cancel
davvid Wed Oct 28 02:12:08 -0700 2009 | link
The 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.
Comment
The 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: <pre> /* 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; </pre> 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.
or cancel
ugtar Fri Oct 30 11:03:41 -0700 2009 | link

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.

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.
or cancel

Parsed with GitHub Flavored Markdown
17.

0 votes

wishlist
x

Better submodule support
0 comments Created 3 months ago by davvid

Title

Body
Interact with submodules as if they were part of the main repo could be really slick.
or cancel

Interact with submodules as if they were part of the main repo could be really slick.

Comments

Parsed with GitHub Flavored Markdown