On 2015-07-02 at 00:37, Junio C Hamano wrote: > What's cooking in git.git (Jul 2015, #01; Wed, 1) > -------------------------------------------------- > * tf/gitweb-project-listing (2015-03-19) 5 commits > - gitweb: make category headings into links when they are directories > - gitweb: optionally set project category from its pathname > - gitweb: add a link under the search box to clear a project filter > - gitweb: if the PATH_INFO is incomplete, use it as a project_filter > - gitweb: fix typo in man page > > Update gitweb to make it more pleasant to deal with a hierarchical > forest of repositories. > > Any comments from those who use or have their own code in Gitweb? The first one is a simple typo fix (plural -> singular), so it can be accepted without problems. Second one, "gitweb: if the PATH_INFO is incomplete, use it as a project_filter" looks interesting and quite useful. Though it doesn't do much: it allows for handcrafted URL, and provides mechanism to create breadcrumbs. It doesn't use this feature in its output... Well, I think it doesn't: I cannot check it at this moment. What is missing is a support for query parameters path, and not only path info. Though that *might* be postponed for later patch; the path info API is obvious, query params API for this feature isn't. Thought some thought is needed for generating (or not) breadcrumbs if path_info is turned off. The third, "gitweb: add a link under the search box to clear a project filter" notices a problem... then solves it in strange way. IMVHO a better solution would be to add "List all projects" URL together with " / " (or other separator) conditionally, if $project_filter is set. Or have "List all projects" and add "List projects$limit" if $project_filter is set. The last two, which form the crux of this patch series, looks like a good idea, though not without a few caveats. I am talking here only about conceptual level, not about how it is coded (which has few issues as well): - I think that non-bare repositories "repo/.git" should be treated as one directory entry, i.e. gitweb should not create a separate category for "repo/". This is admittedly a corner case, but useful for git-instaweb - I think that people would want to be able to configure how many levels of directory hierarchy gets turned into categories. Perhaps only top level should be turned into category? Deep hierarchies means deep categories (usually with very few repositories) with current implementation. - New global configuration variable, or new %features entry? > * tr/remerge-diff (2014-11-10) 9 commits > - t4213: avoid "|" in sed regexp > - log --remerge-diff: show what the conflict resolution changed > - name-hash: allow dir hashing even when !ignore_case > - merge-recursive: allow storing conflict hunks in index > - merge_diff_mode: fold all merge diff variants into an enum > - combine-diff: do not pass revs->dense_combined_merges redundantly > - merge-recursive: -Xindex-only to leave worktree unchanged > - merge-recursive: internal flag to avoid touching the worktree > - merge-recursive: remove dead conditional in update_stages() > > "log -p" output learns a new way to let users inspect a merge > commit by showing the differences between the automerged result > with conflicts the person who recorded the merge would have seen > and the final conflict resolution that was recorded in the merge. > > Waiting for a reroll. > ($gmane/256591). Is it something that Atlassian uses as a differentiatior (instead of sending patch upstream): https://developer.atlassian.com/blog/2015/01/a-better-pull-request/ -- Jakub Narębski -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html