Create shippable commit views

Here is some styling, I used the view of CVS commits in both the new theme, and garland for a guide since ultimately we would want the theme to control most of the output.

Currently these styles only apply to the /commitlog page. I'm working on translating them for the rest. Below is a screenshot link and attached is a patch. Just a heads up I modified the custom text field on the commitlog_global_commits view to make it easier to style the author, date, etc. However, I re-exported all the views so you should be able to get everything by just installing the commitlog module.

Mac OSX - Firefox 3.6.12
http://img.skitch.com/20101119-guytegw7j5sdud83k4b9rhh9de.png

Here's patch round two this includes the css for all of the above views in one file, as well as a few minor changes on each view. I exported the views again so you should just be able to update your own code. Below are screenshots of each view.

Mac OSX - Firefox 3.6.12

global view -- http://img.skitch.com/20101119-pcmpdufyscgwbchhca2bkf2r6k.png
author view -- http://img.skitch.com/20101119-puwri8miw98kcu83iwh2ypc6n.png
repository view -- http://img.skitch.com/20101119-1kh2ft76kpa5yhgbnaf9cgw6yi.png

Adding pre tag to make the commit messages look cleaner makes them run off the page

Doing this:
https://skitch.com/sdboyer/rbfq9/edit-view-commitlog-global-commits-drup...

Produces this:
https://skitch.com/sdboyer/rbfk9/commit-messages-drupal.org-testing-site

I'm going to see if I can fix it. :D

sorry, thought i posted this earlier...

I've committed sarah_p's patch from #4, and have also committed a couple of tweaks and additions.

OK, it's just occurred to me that it's rather silly to have three separate issues for essentially the same view, especially when we're really only using one. So I'm marking those duplicates, and turning this into the master issue for creating a shippable commit view. Also tagging for sprint 5.

Issues that are under 'shippable views umbrella':
#979058: Cause Commit messages to wrap
#979066: Insert and Delete graphics on commitlog

Assigning this to myself to handle the majority of the work, may need help from tizzo and sdboyer to actually get this to shippable.

This also covers #979058: Cause Commit messages to wrap and #1010212: User should be able to page through commitlog views I'm placing the patch here as well because it generally covers the commitlog view not just those issues:
This patch changes the commitlog view/page in the following ways:
- Pager
- Pre-tags that wrap and look generally legible
- Moves the add/removed lines (although this may change later after Mike's additions)
- Hides the Operator ID
- Moves the "Action" field above the file instead of in the middle. (May try to mimic github on this by using an image to represent the action committed, probably next sprint)
- Cleans up the text sizes a little

Image in Firefox in Mac OSX - https://img.skitch.com/20101231-durteg9tx1fya928mb8nehj25k.jpg

Patch in #11 has been committed. Good progress on this, but we're not quite there yet, so putting back to 'needs work'.

Tagging Git Sprint 8

I'm working up a big, definitive post that lays out all the views we actually need. Quickly, though, I want to post this image as there are two crucial changes I'm going to make to the commit log views, both of which are a direct result of how git is different from CVS:

per sarah_p's request, here's a list of the views we ACTUALLY need. I've broken them down into the views set to which they belong, and included graphics as much as possible. Quick reminder - a views set is a group of vcapi views (one backend-agnostic 'base' view, then tailored views for each backend as needed) that all perform the same purpose - e.g. list repositories, show commit logs. We'll probably want separate issues for these, but for the moment it makes sense to have all this information in one place in the meta-issue.

Global commit log - set owned by commitlog (in VCAPI), implemented in plugin versioncontrol/commitlog/includes/plugins/views_sets/global_commit_view.inc. Shows commit log listing of all commits known to all repositories in the system. This is the equivalent to http://drupal.org/cvs ; the exact path it will eventually live at is tbd during sprint 8.

ss of the view as it exists right now:

• Base view
  • View name: commitlog_global_commits
  • Description: A backend-agnostic, global commit log without any backend-specific features.
  • View status: Created & in progress. This is one of the big ones we've been working on.
  • Used on d.o? Never - a git-specific, vc_project-specific version overrides it.
  • Priority: Major, because this is the base template that ALL other commit log views pattern themselves after.
• Git-specific view
  • View name: vc_git_global_commits
  • Description: everything the base view has, but with some git-specific elements: parent commit hash, slightly different appearance of the username; that's all that's defined for initial launch.
  • View status: Created, ready for tweaking.
  • Used on d.o? Never, a vc_project-specific version (below) will override it.
  • Priority: Critical. This is effectively the same view as the project-specific one, that one will just change the output for a single field (to be the project name instead of the repo name).

Project-friendly global commit log - set owned by versioncontrol_project, implemented in plugin versioncontrol_project/plugins/views_sets/project_global_commit_view.inc. Identical to the global commit log except that it shows project name instead of repo name.

• Base view
  • View name: vc_project_global_commits
  • Description: Identical to the global commit log base view, except that it shows project name instead of repo name.
  • View status: Created.
  • Used on d.o? Never - the git-specific version in this set will override it.
  • Priority: Normal; should be identical to the base view from a theming perspective.
• Git-specific view
  • View name: vc_git_project_global_commits
  • Description: same as the git-specific view in the global commit view set, just with the project name instead of repo name (again).
  • View status: Not created yet.
  • Used on d.o? YES. This'll be what we see at whatever the equivalent url to http://drupal.org/cvs is.
  • Priority: Critical, this is a prod view.

Per-repository commit log - set owned by commitlog (in VCAPI), implemented in plugin versioncontrol/commitlog/includes/plugins/views_sets/repository_commit_view.inc. Shows commit log listing of all commits in the specified repository. This is the equivalent to http://drupal.org/project/cvs/343333 .

ss of this view right now:

• Base view
  • View name: commitlog_repository_commits
  • Description: backend-agnostic, so a commit log without any backend-specific features. Shows the commit id, the committer, and a list of files changed.
  • View status: Created, & in progress. This is the per-repo commit view we've been working on.
  • Used on d.o? Never, it will be overridden by the git-specific version.
  • Priority: Normal - we can't roll a stable release of vcapi without this, but it's very similar to the git-specific view in this set and could easily be worked on after that one.
• Git-specific view
  • View name: vc_git_repository_commits
  • Description: everything the base view has, but with some git-specific elements: parent commit hash, slightly different appearance of the username; that's all that's defined for initial launch. The differences between this view and the base view in this set are the same as the differences between the git-specific view and base view in the global commit log set.
  • View status: Created, ready for tweaking. Lives in vc_git.
  • Used on d.o? Yes, this'll be the per-repository commit listing. Unless we have to have a vc_project-specific version of this, but I don't think we will.
  • Priority: Critical - we can't roll a stable release of vcapi without this, but it's very similar to the git-specific view in this set and could easily be worked on after that one.

Per-user commit log - set owned by commitlog (in VCAPI), implemented in plugin commitlog/includes/plugins/views_sets/user_commit_view.inc. Shows commit log listing of all commits made by a particular user (uid) in all repositories known to the system. This is the equivalent to what we see at, for example, http://drupal.org/user/146719/track/code . the exact path it will eventually live at is tbd during sprint 8.

• Base view
  • View name: commitlog_user_commits
  • Description: A backend-agnostic, global commit log that is filtered to show only commits authored/committed by a given user (uid).
  • View status: Created & in progress, though we haven't done much with it.
  • Used on d.o? Never - a git-specific, vc_project-specific version overrides it.
  • Priority: Normal. We can't launch without it, but it's two variations away from prod, so not super-important.
• Git-specific view
  • View name: vc_git_user_commits
  • Description: same differences as in other git-specific views - parent commit hash and slightly different username formatting.
  • View status: Not created yet. Very soon.
  • Used on d.o? Never, a vc_project-specific version (below) will override it.
  • Priority: Critical. This is effectively the same view as the project-specific one, that one will just change the output for a single field (to be the project name instead of the repo name), so may as well make this one good.

Project-friendly per-user commit log - set owned by versioncontrol_project, implemented in plugin versioncontrol_project/plugins/views_sets/project_user_commit_view.inc. Identical to the base vcapi per-user commit log, except that it shows project names instead of repo names (see the pattern? :P).

• Base view
  • View name: vc_project_user_commits
  • Description: Same as the vcapi view set, just with project names instead of repo names.
  • View status: Created.
  • Used on d.o? Never - overridden by the git-specific version in this set.
  • Priority: Normal - just another almost-identical bump in the road on the way to the one we'll actually use.
• Git-specific view
  • View name: vc_git_project_user_commits
  • Description: same differences as in other git-specific views - parent commit hash and slightly different username formatting. and with project names instead of repo names.
  • View status: Not created yet.
  • Used on d.o? Yep.
  • Priority: Critical. This is our prod view.

An exhausting list with a lot of annoying repetition, but hopefully this clears it up.

FYI, the patch in #11 contained a partial regression - seems you pasted the commitlog_commit_items over the commitlog_global_commits view in the defaults, so the global view disappeared. I've restored it.

Also, let me clarify on #15 - those are the commit log views we need. There's a chance we'll also have some views to do for push activity, depending on how #879600: Meta: introduce an activity stream separate from commit logs comes out, but that's likely going to happen late in Spring 9, not right away. These commit log views are the big focus right now.

Also, I realized that this list actually neglects the 'inner' commit items listing view. In #1013188-1: Fix crufty, CVS-driven assumptions in commitlog views, I explain how I added three displays to the view. Now I've also had to make a clone of that view that can be used by vc_project, as some of the file item listings it has to generate need to contain the project name. That view is called vc_project_commit_items, and has been committed to vc_project.

With so many more major issues to attend to right now, I propose the following:

1) Ensure sarah can edit files directly on git-dev by Monday, Jan 10, even though she won't start then.
1a) If some other approach is needed (bzr, etc), I want to set up to be able to do the work also.

2) After the Thursday demo rehearsal, in which the views should (still) be visible and stable, Sarah will theme the views, with a priority to looking good on d.o.

3) If everything is a go with git-dev during the rehearsal, that night Sarah can work and it will be incorporated into the Friday demo if feasible.

4) The theming work will be complete by the January 17 planning meeting (noon PST). it's one of the things that needs to be in place for timely testing and a pre-Chicago launch.

5) The foundational work to get a basic common-denominator theme in place can come during Sprint 9.

@eliza411 - sounds like a plan.

1) is taken care of. Thanks @sdboyer.

I will be doublechecking my testing environment by Mon. Jan 10th, and start editing the views on the 10th as well. More to come!

I've created a little diagram illustrating the hierarchy that all these views sets fall into, and highlighted the actual view that's going to be used on d.o in bold & red text.

This is just an easier visual representation of the verbose information laid out in #15.

I was able to get some work done on the commitlogs see #1025330: Add CSS for Git for the patch. This is a basic conversion of some of the code that was in the bluecheese theme style.css.

(The screenshot is with the addition of a pre-tag on the 'vc-git-global-commits' view on the the message field. Which I'll be working on in this and other related issues).

https://img.skitch.com/20110113-kk42u437fujny4qw8wfga6iep5.png

deleted duplicate comment

Issue for adding pre-tags and li tags to the views in commitlog. #1026440: Fix Commit Log views structure and html types.

Bluecheese issues: For Testing #1025330: Add CSS for Git and for launch #1026462: Making Git look good for launch.

Blocking/related issues on this:
#1026408: Link commit logs to gitweb viewer
#1026484: Group commits by date & Remove Date from commit-global
#1026440: Fix Commit Log views structure and html types.
#1025334: Create per-project commit logs

I went through the commit logs with a fine-toothed comb tonight, and now fully understand where Sarah was coming from. Though what are on git-dev.drupal.org certainly look and smell like commit log views, they are missing several pieces of information compared to the current ones:

1. Commit number links to individual commit view. #1024960: Need view for individual commit message
2. Username links to user profile. #1022308: Global and specific commit logs should show username
3. Time and date of commit is visible. [YES]
4. List of affected files is visible. [YES]
5. Link to parent project of commit exists. [NO ISSUE]
6. Link to diff view in repository viewer exists. #1026408: Link commit logs to gitweb viewer
7. Link to view all commit logs affecting a given file exists. [NO ISSUE]
8. Link to view all commit logs affecting a given branch exists. [NO ISSUE]
9. Commit description exists. [YES]
10. Issue IDs in commit descriptions link to their respective issues. [NO ISSUE]
11. Each commit log view has an RSS feed associated with it. #1024958: Commitlog should provide RSS feeds of each view

I wouldn't necessarily call all of these launch-critical (like 7 and 8, which I never even knew existed before I clicked on everything here), but there's definitely more work to do here before these can be styled.

Since we're tag teaming on this I'm assigning it to mikey_p.

I can see the css from bluecheese, but for some reason the location of the source css is located in a
http://git-dev.drupal.org/files/css/css...

I'm not sure if this is a cache issue or something else, but I can't seem to be able to edit the css to any effect. Since the views have been rearranged I tried to take off the border, but even though it is removed from bluecheese it's still showing up.

https://img.skitch.com/20110123-p6fi8cuty74j1x8yhhwumecj4r.png

Aggressive caching and css optimization are enabled on git-dev and will be after each rebuild. You can log in and disable them as you need. Ping me or sdboyer if you don't know the credentials.

We are highly likely to open for testing tomorrow evening, so we may need to define a window where you working won't cause issues for testers.

Was able to get the css working, and implement some fixes.

To follow the code additions to blue-cheese see #1025330: Add CSS for Git.

Done enough to remove testing blocker tag.

I have not re-read the whole issue, but is this need to be open?

what are the things left to do?

IMHO it would be better to just close this an open specific issues if needed.

Creating specific issues:

Link to parent project of commit exists. [NO ISSUE]

#1387282: Provide an override of vc_git_individual_commit to provide a link to project page

Link to view all commit logs affecting a given file exists. [NO ISSUE]

IMHO this is not really something natural on git, which is our current main target. Anyway I guess someone can open a new issue if needed.

Link to view all commit logs affecting a given branch exists. [NO ISSUE]

#1387292: Provide a view listing all operations of a given branch

Issue IDs in commit descriptions link to their respective issues. [NO ISSUE]

That's working right now ;-)

And closing this.