Re: Python extension commands in git - request for policy change

[Guillaume DE BURE <guillaume.debure@gmail.com>]

Le mardi 27 novembre 2012 02:51:04 David Aguilar a écrit :
> On Tue, Nov 27, 2012 at 1:17 AM, Sitaram Chamarty <sitaramc@gmail.com> 
wrote:
> > On Tue, Nov 27, 2012 at 1:24 PM, David Aguilar <davvid@gmail.com> wrote:
> >> *cough* git-cola *cough*
> >> 
> >> it runs everywhere.  Yes, windows too. It's written in python.
> >> It's been actively maintained since 2007.
> >> 
> >> It's "modern" and has features that don't exist anywhere else.
> >> 
> >> It even has tests.  It even comes with a building full of willing
> >> guinea-pigs^Wtesters that let me know right away when
> >> anything goes wrong.
> >> 
> >> It uses Qt but that's really the whole point of Qt -> cross-platform.
> >> (not sure how that wiki page ended up saying Gnome/GTK?)
> >> 
> >> The DAG aka git-dag (in its master branch, about to be released)
> >> is nicer looking then gitk IMO.  gitk still has some features
> >> that are better too--there's no silver bullet, but the delta
> >> is pretty small.
> > 
> > Gitk does a lot of things that people don't realise, since they're not
> > really documented and you have to scrounge around on the UI.  The
> > thing is, it's just about the most awesome tool for code archeology I
> > have seen.
> > 
> > I realise (from looking at the doc page) that git-cola helps you do
> > all sorts of things, but those are all things I am happier doing at
> > the command line.
> 
> Ditto.  There's actually a few small things I use it for,
> mainly for teasing apart commits.  These days you can use git-gui
> for that, but in the old days it was the only way to interactively
> select individual lines and stage/unstage/revert them, etc.
> I don't think we can line-by-line revert in git-gui yet, though.
> 
> Some other small things that I use: ctrl-g, type something
> for grep, hit enter twice and I'm in my editor on that
> (or any other selected) line.  'spacebar' does xdg-open,
> and 'enter' launches the editor in the status widget;
> small things.  I, too, do most stuff on the command line.
> 
> The grep thing is a good example.  You have tons of output,
> you see the one line that you care about, and you want to jump
> there.  Clicking on that line and hitting enter is the minimal
> effort to do that.  You don't have to click because we also
> have keyboard navigation.  I have a feeling that there's probably
> something I'm missing, though.. another way of working (emacs?)
> that would render all of this custom GUI stuff pointless.
> 
> What I learned about users:
> 
> The commit editor is the #1 thing that got my coworkers finally
> writing better commit messages. It forces the subject/description
> separation and shows yellow, red when the subject gets too long.
> It also auto-wraps.  IMO it makes sense for git-gui to do
> the same these days.
> 
> > Gitk does precisely those things which *require* a GUI, where the
> > amount of information presented overwhelms a text interface.  The
> > display is concisely designed to give you the maximum information at a
> > minimum space use.  For example, a little black square when a commit
> > has a note attached.  Even hovering over the arrow-heads, on complex
> > trees where the line gets broken, does something meaningful.
> > 
> > if I had to pin it down, the feature I use most often is "Show origin
> > of this line".  Other features I use often are
> > 
> >   - review a commit file by file (f and b keys, also spacebar and 'd')
> >   - search by SHA1 (4 digits appear to be enough, regardless of how
> > 
> > big your repo is),
> > 
> >   - search for commits changing path/dir (while still showing all the
> > 
> > commits; i.e., this is not 'git-dag -- README.txt' but within gitk you
> > search up and down for commits touching README.txt
> > 
> >   - and navigating the commit tree looking for stuff
> > 
> > http://sitaramc.github.com/1-basic-usage/gitk.html is my attempt to
> > document some of the stuff I have found and use.
> 
> Wow, this is awesome.
> 
> > One final point: the DAG on the right wastes enormous amounts of
> > space.  Purely subjectively, it is almost jarring on the senses.  (If
> > you reduce it, it becomes unreadable).
> > 
> > With all due respect, git-cola/dag isn't anywhere near what gitk does,
> > at least for people who are not afraid of the command line and only
> > need the GUI to visualise a truly complex tree.
> 
> This is really great feedback.
> cc:ing Guillaume since he had similar ideas.
> 
> thx,

Thanks David for cc:ing me. I'm sorry I was quite below the radar lately, had 
too much work to get back on the dag. What I would really like for the dag is 
to become as useful as the treeview in git extensions 
(http://code.google.com/p/gitextensions/), where it is the central place for 
checkout, merge, cherry picks... 

My only complaint with git extensions is that it is poorly integrated on my 
linux desktop, due to framework choice (let's not start a flame war here, it's 
not the point). On the other hand, git-cola is quite easy to hack on thanks to 
its python roots, well integrated on all OS thanks to Qt, so I thought it 
would be great to make it at least on par.

Had an opportunity to rework the visuals on the dag, but not yet its 
functionalities... As soon as I'm back on normal life, I'll pickup the subject 
again :)

Cheers,

Guillaume

-- 
Skrooge, a free, Open Source, personal finances software for linux, Mac OS, 
Windows
http://skrooge.org