otac0n / WebGitNet

WebGit .NET is an ASP.NET MVC app that provides access to your git repositories over HTTP. It supports browsing in a web browser AND push / pull over Git's "Smart HTTP protocol".
zlib License
132 stars 62 forks source link

If a repo does not have a `master` branch, it fails to update its HEAD. #58

Open otac0n opened 11 years ago

otac0n commented 11 years ago

For a real-world example, see fuel/fuel

gregsohl commented 11 years ago

Do you have any more detail on this issue? I'm planning several repositories that will not have master branches and am hoping to use WebGitNet for an HTTP front end. Does this bug mean that it won't work at all if I have other branches none of which are named "master"? Will having a dummy branch named "master" allow it to work? Thanks! Great piece of work. I've forked and am contemplating some contribs.

gregsohl commented 11 years ago

I have a repo with two independent branches in it - ProductA and ProductB. I keep it this way due to some external reasons. So the branches operate independently, because they are both orphans. There is no Master branch. This causes WebGitNet to not be able to display any details for the repo because it fails in retrieving the last commit for the repo, and subsequently ViewBag.CurrentTree is not set as a downstream impact. This happens in BrowseController.ViewRepo.

otac0n commented 11 years ago

I'll probably fix this by ensuring that HEAD is set in the post-receive hook.

I'm not certain what the "correct" way to handle this is... GitHub has a little dropdown in their repo settings page. Maybe we need to do the same, here.

gregsohl commented 11 years ago

I just did an extensive set of tests as part of a piece of work for it. All of my tests included a repo that does not have a master branch, that is, no default head. The issues I see are:

  1. The default ViewRepo screen shows no file tree.
  2. There is no direct way to see a file tree for the head of a non-master branch. Yes I can get to the commit list and see the tree from the head commit.
  3. Impact graphs are not available for a selected branch - or at all when there isn't a master branch.

Push, pull and other interactive operations seem fine.

gregsohl commented 11 years ago

I pushed a branch (1 commit) that has just a bit of what I was thinking of to solve this (https://github.com/gregsohl/WebGitNet/commit/3f27ed5ed535de0a4b27cec92991406857c26aa0). Initial goal was that when the user selects a branch from the drop down in ViewRepo it takes them back to ViewRepo, but from the perspective of the branch. With that in place, ViewCommits automatically worked.

View Impact and View Graph need adjustment. What would you think about changing their routes as follows, which would adjust the base path and add a place for the branch to be specified, like it is for View Commts?

From:

   routes.MapRoute(
     "View Graph",
     "browse/{repo}/graph",
     new { controller = "Graph", action = "ViewGraph", routeName = "View Graph", routeIcon = "branch" });

To:

    routes.MapRoute(
      "View Graph",
      "graph/{repo}/{object}",
      new { controller = "Graph", action = "ViewGraph", routeName = "View Graph", routeIcon = "branch", @object = UrlParameter.Optional });

and

From:

    routes.MapRoute(
      "View Repo Impact",
      "browse/{repo}/impact",
      new { controller = "Impact", action = "ViewRepoImpact", routeName = "View Repo Impact", routeIcon = "tasks" });

To:

    routes.MapRoute(
      "View Repo Impact",
      "impact/{repo}/{object}",
      new { controller = "Impact", action = "ViewRepoImpact", routeName = "View Repo Impact", routeIcon = "tasks", @object = UrlParameter.Optional });

This would allow the format of the routes to be similar to ViewCommits and get the base out of Browse and more in line with the associated controller.

gregsohl commented 11 years ago

I'll probably fix this by ensuring that HEAD is set in the post-receive hook. I'm not certain what the "correct" way to handle this is... GitHub has a little dropdown in their repo settings page. Maybe we need to do the same, here. <<<<<<<<

After re-reading your post, I'm not sure I'm fully understanding the problem. In my tests, where I have no master branch, pushes are going fine. What is it that is happening? Is it destructive?

gregsohl commented 11 years ago

BTW, when working on the authorization layer, this was my (fully successful) test plan, again run one at least one repo that did not have a master branch:

Test Plan

1. Client: Web Site
    a. Create Repo (must be member of @create group
        i. With permission
        ii. Without permission
    b. Browse Repo (requires read permission)
        i. Main browse page
            1) With permission
            2) Without permission
        ii. List Commits
            1) With permission
            2) Without permission
        iii. Select Branch to list commits
            1) With permission
            2) Without permission
    c. Edit Repo Description (requires write permission)
        i. With permission
        ii. Without permission
    d. View Impact Graphs (requires read permission)
        i. With permission
        ii. Without permission
    e. View individual commit (requires read permission)
        i. With permission
        ii. Without permission
    f. View commit feeds (requires read permission)
        i. With permission
        ii. Without permission
    g. View file (requires read permission)
        i. With permission
        ii. Without permission
    h. Verify Clone URL
    i. Verify Clone Command
    j. Verify Gravatar
    k. Browse repo list
        i. Verify that Browse repo list shows correct repos display for BrowseList settings
            1) For "AllWithLinks" 
            2) For "AllLinkWithPermission" 
            3) For "OnlyWithPermission"

2. Client: Git Extensions
    a. Clone
        i. With permission
        ii. Without permission
    b. Fetch
        i. With permission
        ii. Without permission
    c. Push to existing branch
        i. With permission
        ii. Without permission
    d. Push new branch
        i. With permission
        ii. Without permission
    e. Pull default branch
        i. With permission
        ii. Without permission
    f. Delete branch
        i. With permission
        ii. Without permission

3. Client: Git (command line)
    a. Clone
        i. With permission
        ii. Without permission
    b. Fetch
        i. With permission
        ii. Without permission
    c. Pull default branch
        i. With permission
        ii. Without permission
    d. Push
        i. With permission
        ii. Without permission
    e. Create new branch and push
        i. With permission
        ii. Without permission
    f. Delete branch
        i. With permission
        ii. Without permission

4. RSS Reader
    a. View repo commit feed
        i. With permission
        ii. Without permission
gregsohl commented 11 years ago

John, do you have a second to answer my question two comments up? Thanks.

otac0n commented 11 years ago

Sorry, I've been a bit busy. If your tests indicated that a repo with no master branch worked just fine, then that is probably not the source of the issue.

I wish I had a more solid repro case on this, but I don't. I'll try to repro tonight.