Patch: Fix formatting to remove whitespace next to gravatar/gist it button in commit history window
meeech
When viewing the history of a commit, there is a large whitespace next
to where the user gavatar / gist it button is.
basically, the #commit_header table gets bumped down.
The fix for this was pretty simple:
in history.css, for the #commit_header style (line 5), just removed
the width: 100% and that fixed it.
Now the gravatar and gist it buttons float to the right, and the
commit_header shows up on the left - no more big whitespace.
Thanks
m.
Johannes Gilger
> When viewing the history of a commit, there is a large whitespace next
> to where the user gavatar / gist it button is.
> basically, the #commit_header table gets bumped down.
Thanks for the hint. However, this patch shows why we should integrate
and release something soon (or else every new patch stands the chance of
being pointless because already included): While this might be true for
stable and for Andre Berg's branches, this is fixed in Nathan's
experimental branch.
Greetings,
Jojo
--
Johannes Gilger <hei...@hackvalue.de>
http://heipei.net
GPG-Key: 0xD47A7FFC
GPG-Fingerprint: 5441 D425 6D4A BD33 B580 618C 3CDC C4D0 D47A 7FFC
Michael Dippery
> and release something soon (or else every new patch stands the chance of
> being pointless because already included): While this might be true for
> stable and for Andre Berg's branches, this is fixed in Nathan's
> experimental branch.
Yeah, it's fixed in my fork as well [1].
I think this brings up a question I've had: What exactly is the status of this project? I appreciate all the work pieter did on GitX, but it seems like he's not terribly active on the project anymore? Is it time to re-organize the project under new development leadership, set up a new "canonical" repo, and get working on this?
GPGMail development was similarly stagnant as a couple months ago, but a few developers stepped up and refocused the project. They set up a main repo on GitHub, granted a few devs write access, relaunched the webpage, and have been moving the project along pretty well. Should we do something similar? Set up a "gitx" organization on GitHub, push in the "latest" common repo, give some devs write access and let them push their experimental changes and whatnot into the repo? That way, we'd have a set of core developers and a repo from which other collaborators could easily get changes.
----
Michael Dippery
mdip...@gmail.com | www.monkey-robot.com
[1] http://github.com/mdippery/gitx/commit/c1d89d6858290f630eab745faaa2c03d2ad6d6a8
Dave Carlton
Johannes Gilger
> I think this brings up a question I've had: What exactly is the status
> of this project? I appreciate all the work pieter did on GitX, but it
> seems like he's not terribly active on the project anymore? Is it time
> to re-organize the project under new development leadership, set up a
> new "canonical" repo, and get working on this?
Hi Michael,
thanks for your mail. Having been inactive the last few months as well,
I started looking at GitX again a few days ago. Right now the project is
completely stalled: No commits (in the official repo), no responses to
the issues on Lighthouse, no ML-traffic here.
The worst part in my opinion is that there now are a lot of forks on
GitHub, some carrying far-reaching branches with quite a lot of good
features, which are a nightmare to reintegrate all at the same time. I
know, I tried to combine branches from Nathan and Andre Berg plus some
private patches today.
So, here is what I personally think would be the best jump-start for
GitX (correct me if you disagree):
- Find a consensus about an OK-branch of one of the developers (I'd
prefer Nathans 'experimental' branch)
- Fix the worst bugs, if any. Accept a few bugs in order to release fast
and _not_ get into stall-mode again.
- Release as fast as possible and get everyone to (re)base their patches
on this new master.
- _After_ the release: Close invalid bug-reports, try to solve open
bugs, bring documentation up to speed, try to reach people with
promising branches on GitHub.
The part about releasing something ASAP is the most important one imho.
It enables people who don't work on core-features (like me) to reply to
bug-reports with definitve statements and try to fix bugs without having
to worry which branch will eventually get nominated.
I don't think Pieter would mind if this moved forward, even if someone
else took charge. The only technical problem at the moment is that a new
release of GitX would have to be signed using Pieter's private key in
order to be auto-updatable from the current stable GitX, which is what
most people are probably running. Or we could branch of to a different
website, release something like 0.8 cold and use Sparke for the new
website in the future.
Josh Bleecher Snyder
> GitX (correct me if you disagree):
> - Find a consensus about an OK-branch of one of the developers (I'd
> prefer Nathans 'experimental' branch)
> - Fix the worst bugs, if any. Accept a few bugs in order to release fast
> and _not_ get into stall-mode again.
> - Release as fast as possible and get everyone to (re)base their patches
> on this new master.
> - _After_ the release: Close invalid bug-reports, try to solve open
> bugs, bring documentation up to speed, try to reach people with
> promising branches on GitHub.
A giant +1 from me on getting this going again.
I'd second Nathan's branch as an excellent choice.
> The part about releasing something ASAP is the most important one imho.
> It enables people who don't work on core-features (like me) to reply to
> bug-reports with definitve statements and try to fix bugs without having
> to worry which branch will eventually get nominated.
100%. I'm in the same boat.
> Or we could branch of to a different
> website, release something like 0.8 cold and use Sparke for the new
> website in the future.
I think we should do whatever has the lowest chance of blocking
forward progress, and from what I've heard, that sounds like a cold
release.
Cheers,
Josh
Nathan Kinsinger
This particular fix was already included in my fork previously and several of the fixes mentioned in the last few messages will be fixed in this next one. For what's it's worth I don't think Dave's auto refresh branch is quite ready yet.
IMHO I think it would be better to have Pieter involved rather than a 'cold' release. Certainly less confusion for the end users. I don't know how many GitX users there are but most will probably not know about it if doesn't update through the app.
I suspect if we came up with a release candidate that he would probably release it.
If he does agree to hand it over to someone else I'm pretty sure it's possible to change over the code signing key, it would just require one last release signed by him. However he has mentioned that he wanted to keep control of the sparkle feed.
--Nathan
Johannes Gilger
> Sorry for not being more communicative about my progress. I'll be
> pushing out another update with my recent changes this weekend.
'experimental'-branch (which is really stable for me btw)?
> This particular fix was already included in my fork previously and
> several of the fixes mentioned in the last few messages will be fixed
> in this next one. For what's it's worth I don't think Dave's auto
> refresh branch is quite ready yet.
No, we don't have to rush that feature. About your branch: I checked
Lighthouse last night and noticed that a lot of open bugs are either
resolved in your branch or have become obsolete for various reasons.
Same for feature request. Releasing this would cut the current number of
issues by at least half.
> I suspect if we came up with a release candidate that he would
> probably release it.
Yeah, that would be optimal. However, the release candidate should not
hang around for long. Danger of stalling again.
> If he does agree to hand it over to someone else I'm pretty sure it's
> possible to change over the code signing key, it would just require
> one last release signed by him. However he has mentioned that he
> wanted to keep control of the sparkle feed.
Yeah, one could use a new keypair or ask Pieter for the old one. If
Pieter kept his old one he would always be able to restart another
GitX-branch with autoupdate for 0.7 users, whatever that might be worth
;)
Volunteers for any of the tasks? Ideas?
Nathan Kinsinger
> About your branch: I checked
> Lighthouse last night and noticed that a lot of open bugs are either
> resolved in your branch or have become obsolete for various reasons.
> Same for feature request. Releasing this would cut the current number of
> issues by at least half.
I just looked at the Todo list on Pieter's wiki page and the same goes for that list.
--Nathan
Josh Bleecher Snyder
I'd be happy to help. Not sure where I'd be the most use (what is the
list of tasks you have in mind?), but I could e.g. systematically
close out bugs / feature requests against a selected branch.
Josh
Johannes Gilger
> I'd be happy to help. Not sure where I'd be the most use (what is the
> list of tasks you have in mind?), but I could e.g. systematically
> close out bugs / feature requests against a selected branch.
Hi Josh,
hopefully we will have a preview in the next few days (or even today,
depends on Nathan ;). With this specific point in development we can try
to reproduce all the bugs in Lighthouse (which is what I've been doing
all day, always referring to GitX 0.8 if it were indeed be based on
Nathan's branch), and assign them to the 0.8 milestone.
If you want privileges on the Issue tracker just contact me.
Furthermore what I would really appreciate is general consolidation of
issues and documentation. We should try to limit ourselves to
Lighthouse, that means closing / transfering tickets from the GitHub
trackers and the annoying GitHub-wiki. Anything redudant should be
deleted as quickly as possible ;). If you're running forks of GitX on
Github make sure to only publish the branches that actually contain
changes. I have just one branch 'bugfixes' on GitHub, since pushing out
Pieter's (or Nathan's) branches to my repo would have no benefit and
only complicate things.
If you're a fan of that you could also try to update the GitX
documentation with screenshots from the soon-to-be-released preview. The
source-code for the GitX-website is in the Gitx repo in the subdir
'Site'. There is noone working on that right now, so don't be afraid
that your commits could clash with something else.
That obviously goes for everyone around. Thankfully we have excellent
Cocoa-programmers like Pieter, Nathan, Dave (etc.), but a fair amount of
grunt-work is needed as well ;)
a7210148
Thanks to the upcoming World Basketball Festival, we now get a “USA” Air
Jordan 2010 Team. It seems as if more people like the Air Jordan 2010 Team
than the original Air Jordan 2010 because of the windowless side panels. I’m
not one of those people who likes the team better; I think the original
http://www.nikeshoescompany.com/ Nike Shoes 2010 Shoes looks much
better.Since this http://www.nikeshoescompany.com/ jordan Shoes Team is
made for the USA team, the colorway should be clear. White can be seen on
the side panels, toe, shoe laces, tongue, part of the midsole and the entire
outsole. Navy blue covers the toe, heel, inner lining and above the midsole.
Red accents appear on the tongue, toe, heel, lace panels and the midsole.
The sneaker is constructed of perforated white leather with larger
perforations placed on the side panels.
--
View this message in context: http://gitx.3079826.n2.nabble.com/Patch-Fix-formatting-to-remove-whitespace-next-to-gravatar-gist-it-button-in-commit-history-window-tp5515592p5537150.html
Sent from the GitX mailing list archive at Nabble.com.
Uli Kusterer
> If he does agree to hand it over to someone else I'm pretty sure it's possible to change over the code signing key, it would just require one last release signed by him. However he has mentioned that he wanted to keep control of the sparkle feed.
Another option would be to make a "paid" update on Pieter's Sparkle feed (may require merging some changes from my Sparkle branch -- not sure whether Andy merged them over yet). A "paid" update is an update with a version number but no enclosure, and will show HTML and provide a "Learn More..." link (so it doesn't really involve any pay). That way, people who have Pieter's version would be notified of a new site with a "cold" update via Sparkle, but would have to manually move to the new version and visit the new website.
Just a thought, particularly if Pieter wanted out and transferring the signature would be an issue of some sort. Though I guess this is just the Sparkle-specific DSA key, so it prolly isn't.
Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."