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

[Nguyen Thai Ngoc Duy]

CCing msysgit. I vaguely remember they had problems with building
Python on Windows. I don't know if it's still an issue.

On Sun, Nov 25, 2012 at 9:44 AM, Eric S. Raymond <e...@thyrsus.com> wrote:
> git presently contains one Python extension command, Pete Wycoff's p4
> importer. If my git-weave code is merged it will acquire another.
> I think we can expect more submissions of Python extensions in the
> future, for two good reasons:
>
> 1. Python has a much richer type ontology than shell; there are many
> things this makes relatively easy that are quite painful in shell.
>
> 2. While Perl shares advantage #1, compared to Python it's a
> maintainability mess - much more difficult to read 6 months later.
>
> On the other hand,
>
> 3. Attitudes in the git dev group seem to be influenced by a
> perception that up-to-date Python versions are not as reliably present
> on our target platforms as Perl is.
>
> 4. Python has the disadvantage that comes with robust growth; you have
> to specify "version x.y or later" as a dependency, mainly because new
> modules keep getting getting folded into the stock Python environment.

These may apply to other languages as well. Where do we draw a line?


> Previous conversation on the list suggests that there has been a tacit
> policy of managing these problems by (a) discouraging (though not entirely
> forbidding) Python extensions, and (b) requiring extension submitters to
> document some dependency on language version.
>
> I think this is suboptimal. By not forbidding the Python language
> entirely, we guarantee having to deal with problems 3 and 4 anyway -
> but by discouraging it, we're buying significant long-term
> maintainability costs. It especially disturbed me to hear of Python
> commands being recoded in C - that is definitely not the right
> direction for reducing expected defect counts, if only because of
> memory-management issues.
>
> We're behind the best-practices curve here. The major Linux
> distributions, which have to deal with almost the same set of
> tradeoffs we do, went to Python for pretty much all glue and
> administration scripts outside /etc a decade ago, and the decision has
> served them well.
>
> That, among other things, means up-to-date versions of Python are
> ubiquitous unless we're looking at Windows - in which case Perl and
> shell actually become much bigger portability problems. Mac OS X
> has kept up to date, too; Lion shipped 2.7.1 and that was a major
> release back at this point.
>
> To be fair, there was a time when being a bit twitchy about Python
> version skew and deployment breadth was justified, but I believe that
> time is now well past us. My basis for believing this is very simple -
> I maintain a lot of Python code for systems programmers with stiff
> portability requirements (things like reposurgeon, coverity-submit,
> freecode-submit, shipper, and the Python tools in gpsd). I know what
> kinds of bug reports I get and what kinds I don't, and in the last
> few years "this breaks on my Python version" has gone from unusual
> to doesn't-happen.
>
> I think my experience with gpsd is particularly instructive. Like
> git, that project has a C core with Python wrappers and extension
> components. Like git, it gets deployed in a lot of odd places by people
> who cannot afford the time to be tolerant about cross-platform
> problems and are quite willing to hit the maintainer with a clue-bat
> when they encounter them. The good news is - they don't have to.
>
> I should also point out that none of Mercurial's problems seem to
> have anything to do with the fact that it's written in Python...
>
> I think we can choose a better policy based on some simple premises.
>
> 1) In 2012, we can specify a "floor" Python version of 2.6 (shipped in
> 2008) and be pretty much guaranteed it will be anywhere we want to
> deploy except Windows. Windows will remain a problem because Python
> isn't part of the stock install, but that's an equal or worse problem
> for shell and Perl - and at least the Python project ships a binary
> installer for Windows.
>
> 2) Python extension commands should test the Python version on startup
> and die loudly but gracefully in the rare case that they don't find
> what they need.
>
> 3) We should be unconditionally be encouraging extensions to move
> from shell and Perl to Python. This would be a clear net gain is
> portability and maintainability.
>
> 4) We should be encouraging C code to move to Python, too. There's
> little gain in portability on this path because modern C has cleaned
> up its act a lot, but the drop in expected bug loads would be well
> worth the porting effort. Segfaults are not your friend, and the x2 to
> x5 drop in line count would do very good things for long-term
> maintainability.
> --
> <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
>
> Live free or die; death is not the worst of evils.
> -- General George Stark.
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majo...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html



--
Duy

[Eric S. Raymond]

Nguyen Thai Ngoc Duy <pcl...@gmail.com>:

> These may apply to other languages as well. Where do we draw a line?

I'm in favor of the general policy of avoiding scripting languages
other than the top three most widely deployed. At the moment that
means shell, Python, Perl; on present trends, in a few years Perl
(dropping in popularity) might be passed by Ruby on the way up.

Or, to put it another way, I'm *not* actually arguing that we ought
to encourage extension commands in Guile or Haskell or whatever else
the in-language-of-the-week is. It would be bad for maintainability
to fragment git's codebase that way.

What I'm arguing is that the tradeoffs within the group {C, shell, Perl,
Python} have changed in ways that favor Python as it has become more
stable and widely deployed. So instead of grudgingly allowing a few
Python extensions in through a back door we ought to be encouraging
more use of it.

[Eric S. Raymond]

Felipe Contreras <felipe.c...@gmail.com>:

> On Sun, Nov 25, 2012 at 6:18 AM, Eric S. Raymond <e...@thyrsus.com> wrote:
> > Nguyen Thai Ngoc Duy <pcl...@gmail.com>:
> >> These may apply to other languages as well. Where do we draw a line?
> >
> > I'm in favor of the general policy of avoiding scripting languages
> > other than the top three most widely deployed. At the moment that
> > means shell, Python, Perl; on present trends, in a few years Perl
> > (dropping in popularity) might be passed by Ruby on the way up.
>

> Top three according to whom?

According to the LOC counts in git's codebase.

[Felipe Contreras]

On Sun, Nov 25, 2012 at 6:18 AM, Eric S. Raymond <e...@thyrsus.com> wrote:
> Nguyen Thai Ngoc Duy <pcl...@gmail.com>:
>> These may apply to other languages as well. Where do we draw a line?
>
> I'm in favor of the general policy of avoiding scripting languages
> other than the top three most widely deployed. At the moment that
> means shell, Python, Perl; on present trends, in a few years Perl
> (dropping in popularity) might be passed by Ruby on the way up.

Top three according to whom?

According to TIOBE it's python, perl, and ruby (if you don't count VB
or PHP), and perl is beating ruby only by a small margin that will
probably disappear soon. However, shell has advantages none of the
above have.

http://1.1.1.4/bmi/www.tiobe.com/content/paperinfo/tpci/images/tpci_trends.png

Cheers.

--
Felipe Contreras

[Pat Thoyts]

Git for Windows simply ships everything we need to run git - so if a
desirable module requires a version of python, we will add that
version plus any required modules into the installer. We already have
a patch to provide python in the msysgit tree - it would just require
polishing up a little. I'm certain this is no problem for the other
windows port (cygwin) either.

[Eric S. Raymond]

Pat Thoyts <patt...@gmail.com>:

> Git for Windows simply ships everything we need to run git - so if a
> desirable module requires a version of python, we will add that
> version plus any required modules into the installer. We already have
> a patch to provide python in the msysgit tree - it would just require
> polishing up a little. I'm certain this is no problem for the other
> windows port (cygwin) either.

Thank you - I think this completely disposes of the "Windows is a blocker
for scripting language X" argument, with the case X = Python in point.

[Felipe Contreras]

Not according to ohloh:

1) shell 33%
2) tcl 9%
3) perl 9.7%

4) python 1.8%

And this is a non-sequitur; you are proposing to change git policies
based on numbers that are a direct result of git's policies?

https://www.ohloh.net/p/git/analyses/latest/languages_summary

--
Felipe Contreras

[Erik Faye-Lund]

As the one who wrote that patch; not at all. That patch is a horrible
mess, and it is not yet proven that the resulting python executable
works any more than a basic hello world.

[Johannes Schindelin]

Hi,

thank you Duy for thinking of Cc:ing the msysGit mailing list. We indeed
do not have a working Python in Git for Windows yet (mainly because I did
not review kusma's patch yet thanks to a non-fun-at-all side track).

On Sun, 25 Nov 2012, Eric S. Raymond wrote:

> Nguyen Thai Ngoc Duy <pcl...@gmail.com>:
> > These may apply to other languages as well. Where do we draw a line?
>
> I'm in favor of the general policy of avoiding scripting languages
> other than the top three most widely deployed.

It is one thing to allow users to use the scripting languages of their
choice to do their work.

It is a different thing completely to allow the core of an important piece
of software like Git to consist of a hodge podge of languages. There are
so many problems already, both technical and social ones [*1*], that I would
really like to caution against letting even more languages creep into the
core. It is bad enough already.

Ciao,
Dscho

Footnote [*1*]: Technical problems include serious performance issues on
Windows when using shell/Perl scripting (see the many, many complaints
about git-svn just as an example), portability problems (I am thankful
that Junio seems to insist at least on POSIX compatibility of shell
scripts still even if there are very vocal forces trying to get lazy on
that front).

And do not underestimate the social problems with *requiring* contributors
to know yet another language well just because you let a core part be
written in that language. There is even a rule of thumb: increase the
number of languages used in your program == halve the number of potential
contributors. And if you think that this is theoretical: look at the mails
we got about Git GUI being written in Tcl/Tk (hardly a difficult language
to learn) and losing contributors over it.

[Eric S. Raymond]

Felipe Contreras <felipe.c...@gmail.com>:

> Not according to ohloh:
>
> 1) shell 33%
> 2) tcl 9%
> 3) perl 9.7%
>
> 4) python 1.8%

Look in the Makefile - all that tcl code is buried in gitk. We're
very, very lucky the author did such a good job, because it's a
potentially serious headache; who can maintain it?

[Eric S. Raymond]

Felipe Contreras <felipe.c...@gmail.com>:
> And gitk is an integral part of git. But if you have different
> numbers, what are they?

I looked at the Makefile. I saw that there are shell variables that collect
C commands, shell command, Perl commands, and Python commands. There are no
collections of other commands. That makes them the top languages in the
universe we are concerned about

Please don't waste further time on quibbling. We all know that gitk is
an uncomfortable special case and that the project would be far better
off, maintainability-wise, if it were successfully ported to one if these
other languages. Trying to catch me out by triumphantly pointing at gitk
is...juvenile.

[Felipe Contreras]

On Sun, Nov 25, 2012 at 6:50 PM, Eric S. Raymond <e...@thyrsus.com> wrote:
> Felipe Contreras <felipe.c...@gmail.com>:
>> Not according to ohloh:
>>
>> 1) shell 33%
>> 2) tcl 9%
>> 3) perl 9.7%
>>
>> 4) python 1.8%
>
> Look in the Makefile - all that tcl code is buried in gitk. We're
> very, very lucky the author did such a good job, because it's a
> potentially serious headache; who can maintain it?

And gitk is an integral part of git. But if you have different
numbers, what are they?

--
Felipe Contreras

[Felipe Contreras]

On Sun, Nov 25, 2012 at 10:56 PM, Eric S. Raymond <e...@thyrsus.com> wrote:
> Felipe Contreras <felipe.c...@gmail.com>:
>> And gitk is an integral part of git. But if you have different
>> numbers, what are they?
>
> I looked at the Makefile. I saw that there are shell variables that collect
> C commands, shell command, Perl commands, and Python commands. There are no
> collections of other commands.

I suppose you are talking about BUILT_INS, and SCRIPT_FOO, but tcl
scripts don't need no SCRIPT_FOO stuff, because they don't need to be
regenerated, in fact, I don't think the shell scripts need to be
regenerated, but that's not important, what is important is this:

all::
ifndef NO_TCLTK
$(QUIET_SUBDIR0)git-gui $(QUIET_SUBDIR1) gitexecdir='$(gitexec_instdir_SQ)' all
$(QUIET_SUBDIR0)gitk-git $(QUIET_SUBDIR1) all
endif

Why are you ignoring that?

> That makes them the top languages in the universe we are concerned about

According to whom?

I find it very curious how you are arguing for a change in the status
quo to move more towards python, and the basis you are using for
choosing python, and not ruby, or other scripting language is
precisely the status quo. However, the only scripts using python are
these:

SCRIPT_PYTHON += git-remote-testgit.py
SCRIPT_PYTHON += git-p4.py

I already re-wrote git-remote-testgit in bash, and it's dubious
whether or not git-remote-testpy (the new name for this old test) will
fulfill any service. Than means 43% of the current python code is
gone.

And what happens if I rewrite git-p4 in ruby? Would you then argue
that ruby is the way to go because 1% of the *current* code-base uses
it?

Interestingly, according to Wikipedia git is written in: C, Bourne
Shell, Tcl, Perl. That seems to be the case.

> Please don't waste further time on quibbling. We all know that gitk is
> an uncomfortable special case and that the project would be far better
> off, maintainability-wise, if it were successfully ported to one if these
> other languages.

As I said, gitk is integral to the git experience. Of course you are
free to disagree, but according to the last user survey 57% of the
responders used some kind of graphical tool (e.g. gitk, tig). How many
use gitk, and how many use something else, we don't really know, but
what we know is that gitk is distributed *by default*.

Nobody is arguing that gitk should not be distributed by default, just
like nobody is arguing that git-p4 shouldn't, but we *know* very few
people use git-p4 (1% according to the survey), and we can reasonably
assume that many more use gitk.

You cannot have your cake and eat it at the same time. If you use the
amount of code as a measure, then you have to agree that Tcl/Tk is a
way bigger language than python in the mainline git world. If not,
then by all means, show us the numbers. But you can't say "the
important languages are A, B, and D, C doesn't count because I don't
like it, and E doesn't count either because we should draw the line at
three", that seems awfully convenient to push your agenda.

And I don't agree that the project would be better off with something
else, if it was, somebody would have proposed an alternative by now,
but there aren't any. I have tried gitg, and giggle, and I have even
contributed to them, but they are just not as good and useful as plain
old gitk, I always keep coming back.

gitk:
* is blazing fast to start
* doesn't have a lot of dependencies: just tcl/tk
* works on Windows without a major fuzz
* is actively maintained
* shows a proper graph (unlike gitg or giggle)

Now, show me an alternative that fulfills all these points. And I'm
pretty sure you won't find one, because if you did, it would have been
already proposed for mainline git... there isn't any. And if you did,
we would start with oh, but it's GTK+, or it's Qt, and how do you make
it work on Windows. No, gitk is just fine, and works great.

Tcl/Tk might not be your cup of tea, and indeed it's rather unmodern,
but that only tells you how an awful job the modern toolkits have done
with regards to portability and flexibility.

You were arguing for portability, well, Tcl/Tk works on all platforms,
here, have a look, there's no other tool that fulfills this:

http://www.mediawiki.org/wiki/Git/Graphical_User_Interfaces

> Trying to catch me out by triumphantly pointing at gitk is...juvenile.

Isn't that what you are doing by triumphantly pointing at git-p4?

Sorry, if you want to cut the line for the languages that git should
use right now at three, then python is out. Maybe in a couple of
years. Maybe. But I doubt it.

Cheers.

--
Felipe Contreras

[David Aguilar]

On Mon, Nov 26, 2012 at 5:11 AM, Felipe Contreras
<felipe.c...@gmail.com> wrote:
> And I don't agree that the project would be better off with something
> else, if it was, somebody would have proposed an alternative by now,
> but there aren't any. I have tried gitg, and giggle, and I have even
> contributed to them, but they are just not as good and useful as plain
> old gitk, I always keep coming back.
>
> gitk:
> * is blazing fast to start
> * doesn't have a lot of dependencies: just tcl/tk
> * works on Windows without a major fuzz
> * is actively maintained
> * shows a proper graph (unlike gitg or giggle)
>
> Now, show me an alternative that fulfills all these points. And I'm
> pretty sure you won't find one, because if you did, it would have been
> already proposed for mainline git... there isn't any. And if you did,
> we would start with oh, but it's GTK+, or it's Qt, and how do you make
> it work on Windows. No, gitk is just fine, and works great.
>
> Tcl/Tk might not be your cup of tea, and indeed it's rather unmodern,
> but that only tells you how an awful job the modern toolkits have done
> with regards to portability and flexibility.
>
> You were arguing for portability, well, Tcl/Tk works on all platforms,
> here, have a look, there's no other tool that fulfills this:
>
> http://www.mediawiki.org/wiki/Git/Graphical_User_Interfaces

*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.

The only point this doesn't fulfill is dependency-free-ness.
With that requirement the answer can *only* be tcl/tk.
So saying, "go look for one you won't find it" is really
a tautology. It's not even an entertaining one.

http://xkcd.com/703/

When the requirement is, "what is the best user experience
possible", then you use a mature GUI library. These are different
requirements and probably different use cases. For the gitk use
case, gitk is the perfect tool.

Anyways, just sayin', you make it sound like this stuff doesn't
exist, but it does. I've never proposed it for mainline
git because I'm very aware of the dependency requirements.

But, if git "recommended" it I would very much appreciate the
extra eyes and contributions. Being in mainline git could
possibly help with that. A submodule under contrib/
would be an interesting experiment.

In any case, I think documenting the python standards
(even if within contrib/ only) is a good thing.

We'd be increasing the overall portability by documenting
what we support and sticking to it, just
like what is done for shell scripts and perl versions.
Eric is helping make that happen, let's not throw
out the baby with the bathwater. FWIW, I would also make
my python expertise available.

This thread has gotten into meta-meta territory --
it's discussing code that has not yet even been written,
and going off on all sorts of tangents.

Let's stay on target. I think bringing up python
as an extension language would help in a these key areas:

- There are a few python modules floating around that
are similar to the ruby grit library. Having an official
python module would be good.

- Commands on the edges of the git experience (GUIs,
import/export/etc) can benefit from python. git-p4
is one example. git-weave is another.

Are there any arguments against it for these use cases?


BTW, Felipe, if you're going to be rewriting python code to ruby,
please, pretty please rewrite that darn GUI ;-)

You can call it "git-new-cola: project kansas"

http://en.wikipedia.org/wiki/New_Coke

I expect a patch by the morning ;-p

I kid, of course, but if you do pull it off I WILL buy you a soda-pop!
--
David

[Felipe Contreras]

On Tue, Nov 27, 2012 at 8:54 AM, David Aguilar <dav...@gmail.com> wrote:
> On Mon, Nov 26, 2012 at 5:11 AM, Felipe Contreras
> <felipe.c...@gmail.com> wrote:

>> http://www.mediawiki.org/wiki/Git/Graphical_User_Interfaces
>
> *cough* git-cola *cough*
>
> it runs everywhere. Yes, windows too. It's written in python.
> It's been actively maintained since 2007.

% sudo pacman -S git-cola
error: target not found: git-cola

http://aur.archlinux.org/packages/gi/git-cola/git-cola.tar.gz
% makepkg

==> Missing Dependencies:
-> python2-pyqt>=4.3
==> Checking buildtime dependencies...
==> Missing Dependencies:
-> asciidoc
-> docbook-xsl
-> rsync
-> xmlto
-> python2-sphinx>=1.1.3

Sorry, no.

I'm not sure if you have been following, but msysgit doesn't seem to
have good support for python, let alone Qt. In my view the fact that
it uses python is not a good thing.

> 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?)

Yes, Qt is cross-platform *in theory*, but have you used any Qt
application in Windows? I haven't.

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

If you mean this one:
http://1.1.1.5/bmi/git-cola.github.com/images/dag.png

Then I wholeheartedly disagree.

> The only point this doesn't fulfill is dependency-free-ness.
> With that requirement the answer can *only* be tcl/tk.
> So saying, "go look for one you won't find it" is really
> a tautology. It's not even an entertaining one.

That's the whole point; there is nothing else. If there was something
else, there would be something else. But there isn't.

> When the requirement is, "what is the best user experience
> possible", then you use a mature GUI library. These are different
> requirements and probably different use cases.

But those are not the requirements.

> Anyways, just sayin', you make it sound like this stuff doesn't
> exist, but it does. I've never proposed it for mainline
> git because I'm very aware of the dependency requirements.

A lot of stuff exists. And people use a lot of those. But they don't
fulfill the requirements that I think gitk does perfectly.

> But, if git "recommended" it I would very much appreciate the
> extra eyes and contributions. Being in mainline git could
> possibly help with that. A submodule under contrib/
> would be an interesting experiment.

It might be, if somebody actually tried to submit the code. But I
honestly doubt so.

> In any case, I think documenting the python standards
> (even if within contrib/ only) is a good thing.
>
> We'd be increasing the overall portability by documenting
> what we support and sticking to it, just
> like what is done for shell scripts and perl versions.
> Eric is helping make that happen, let's not throw
> out the baby with the bathwater. FWIW, I would also make
> my python expertise available.

Nobody has argued that there shouldn't be guidelines for python code.
What I have objected is to 'strict rules'.

> This thread has gotten into meta-meta territory --
> it's discussing code that has not yet even been written,
> and going off on all sorts of tangents.

That is the point; why should we change the policy for code that
hasn't been written yet? That's not how things evolve in git as far as
I have seen.

> BTW, Felipe, if you're going to be rewriting python code to ruby,
> please, pretty please rewrite that darn GUI ;-)

I would need to write a widget toolkit first =/ I think I'll pass. gitk is fine.

Cheers.

--
Felipe Contreras

[Sitaram Chamarty]

On Tue, Nov 27, 2012 at 1:24 PM, David Aguilar <dav...@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.

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.

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.

[David Aguilar]

On Tue, Nov 27, 2012 at 1:17 AM, Sitaram Chamarty <sita...@gmail.com> wrote:
> On Tue, Nov 27, 2012 at 1:24 PM, David Aguilar <dav...@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,
--
David

[Johannes Schindelin]

Hi David,

On Mon, 26 Nov 2012, David Aguilar wrote:

> *cough* git-cola *cough*

If you had a couple of free cycles to help us get Python/Qt compiled in
msysGit, I will be happy to make a Git for Windows package including
git-cola.

Ciao,
Dscho

[Guillaume DE BURE]

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

[Felipe Contreras]

On Sun, Nov 25, 2012 at 10:56 PM, Eric S. Raymond <e...@thyrsus.com> wrote:
> Felipe Contreras <felipe.c...@gmail.com>:
>> And gitk is an integral part of git. But if you have different
>> numbers, what are they?

> Please don't waste further time on quibbling. We all know that gitk is
> an uncomfortable special case and that the project would be far better
> off, maintainability-wise, if it were successfully ported to one if these
> other languages. Trying to catch me out by triumphantly pointing at gitk
> is...juvenile.

Another bit of information I just realized, 'man git' lists gitk as a
'Main porcelain command' as high level as any git command can get.

--
Felipe Contreras