Re: What's cooking in git.git (Jul 2015, #01; Wed, 1)

["Jakub Narębski" <jnareb@gmail.com>]

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