Open otac0n opened 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.
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.
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.
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:
Push, pull and other interactive operations seem fine.
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.
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?
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
John, do you have a second to answer my question two comments up? Thanks.
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.
For a real-world example, see fuel/fuel