Re: [PATCH] gitweb: Add hash parameter in feed URL when a hash is specified in the current request

From: Jakub Narebski <jnareb@gmail.com>
Date: Mar 21, 2008, 19:53 UTC
Message-ID: <200803212053.55998.jnareb@gmail.com>
In-Reply-To: <ae63f8b50803211214i59184fd7jde7d640d6a8580b8@mail.gmail.com>

On Fri, 21 March 2008, Jean-Baptiste Quenot wrote:

Show 6 quoted lines

>
> I just read your initial post, and IMHO we should keep it simple.  I
> tested the various links, and it appears to be good-enough to pass the
> hash parameter for all URLs that do not specify the hash parameter
> explicitly.  You can still pass it on a per-link basis if you think
> it's too simplistic.

Well, I think it would be a bit more cautious to just pass the hash parameter to code generating feed links, in all of two places. I'm sure about implict 'project' parameter, but not so sure about implicit 'hash' parameter, but if you have checked it... I'd rather avoid implicit parameters.

BTW. one of things I wanted to address (and what made patch long in 
coming) was that redundancy, unnecessary code duplication in feed links 
in HTML header, and in page footer.

Show 7 quoted lines

> Maybe it's not the perfect solution, but at least it will improve the
> current situation where some people are apparently deceived by not
> having a per-branch RSS feed.  Not everyone forges URLs like we do :D
> 
> Oh, and about the title, just appending the hash is sufficient.
> What's important is the contents of the feed.  Users will probably end
> up editing the feed title in their reader after all.

For example 'tag' view has $hash defined, but I don't think feed starting at given tag is something one would want to have; tags don't change, feeds are about fresh, changing, live information.

When viewing history of a file, we would want to have feed of file history (perhaps for given branch)... and that was what I also wanted to address in my patch.

-- 
Jakub Narebski
Poland