Comments for pieter's gitx  

Well, view the following commits on stable. This was just the groundwork, after that Pieter added a Preference-field for a. public/private b. asking for confirmation

I fully support this change, but shouldn’t there be any hint to the user that this Gist will be posted anonymously and that he should set github.token and github.user. An additional how-to (maybe hidden by default) in the same window would be great too.

You might consider using NSISOLatin1StringEncoding instead of NSASCIIStringEncoding.

• In the event that the string is ASCII, it will still work (ISO 8859-1 is a superset of ASCII)
• In the event that there are characters with the high bit set, ISO 8859-1 will make an attempt to display them. ASCII may barf out because there’s no high bits allowed.

I really don’t use these rake tasks. You’re free to send in a patch, and I’ll apply it, but personally I don’t really care :)

You could also have used FileUtils.cp_r (see https://www.ruby-doc.org/core/classes/FileUtils.html#M004357)

As long as you’re making a system call, you may as well go ahead and use `ditto` instead of `cp -R`.

ooh, nice and shiny!

Sure, I understand.

I think using —topo-order is fine for small repos anyway.

I just brought this to your attention because I didn’t know if you follow the git ML or not.

@KJG: I can take a look at the two different options

@melo: gitk did use —topo-order until 1.5.0 or so. Then it switched to doing its own topo sorting, which indeed meant that commits are displayed sooner. However, it also means you’ll have to create your own topo ordering which is quite a lot of work and does not have priority on my TODO list.

I’m pretty sure that —topo-order is not recommended by the git maintainers, in particular Linus. I’ll look the reference up.

What I remember from that thread in the ML is that if you use git log without —topo-order, you start receiving commits immediately and you can redraw incrementally your display.

But with —topo-order, git has to walk through all the commits, order them, and then start sending them.

The perceived performance difference between the two approaches is huge, specially with bit repos.

gitk for example, does not use —topo-order.

Best regards,

I kinda like —date-order (it still follows the rule no parent comes before children) but no other graphical git utility displays the rev history using date-order way. I can think of a few reasons why you’d want topo-order instead (i.e. keep commits on a branch grouped together). Maybe make this a preference?

Perhaps we should create a hardlink or do a copy, so that the gitx command will work after moving the bundle?

I suppose Git is GPL’d, so GitX having the same license makes sense?

Whoa, you’re GPL’ing it? Why?

(@xcode:build) I might do that if the build system gets more complex, but for now people can just run “xcodebuild” from the command line which is shorter and doesn’t require any rake knowledge :)

I thought about that, but I don’t like a weird extension behind a README that users might not recognize and confuse them. I hope github will one day detect it’s textile itself :)

FYI, if you rename README → README.textile (etc) then github will render it nicely.

Perhaps a Rakefile with “rake xcode:build” attached to xcodebuild would be cool too?