Re: [feature request] gitweb: tags in history

From: Jean Delvare <khali@linux-fr.org>
Date: Aug 21, 2010, 09:15 UTC
Message-ID: <20100821111555.11879d02@hyperion.delvare>
In-Reply-To: <m3wrrknzph.fsf@localhost.localdomain>

Hi Jakub,

On Sat, 21 Aug 2010 01:22:05 -0700 (PDT), Jakub Narebski wrote:

Show 33 quoted lines

> Jean Delvare <khali@linux-fr.org> writes:
> 
> > I have a feature request for gitweb. In the history view, I would like
> > to be (optionally) able to see the tags, interlaced with the actual
> > commits. The idea is to get an immediate view of all commits that
> > happened between specific tags.
> > 
> > The actual format for displaying the tags can certainly be discussed, I
> > have no strong opinion on this myself. We may want to let the admin
> > filter which tags should show up that way, maybe even letting him/her
> > define primary and secondary tag formats (think main releases vs.
> > release candidates) for nicer output. Then we may want to group (or
> > hide) tags when a file hasn't been modified in a long time. But these
> > are implementation details, even the raw functionality would be quite
> > useful IMHO, and hopefully not too difficult to implement.
> 
> Currently in 'shortlog' view you can see 'ref' markers... which
> include tags.
> 
> For example 'shortlog' view for 'maint' branch has the following
> fragment:
> 
>  2010-07-28 	 Matthieu Moy	 Document ls-files -t as semi-obsolete.
>  2010-07-27 	 Junio C Hamano	 Git 1.7.2.1  [v1.7.2.1]
>  2010-07-27 	 Junio C Hamano	 Sync with 1.7.1.2
>  2010-07-27 	 Junio C Hamano	 Git 1.7.1.2  [v1.7.1.2]
>  2010-07-27 	 Junio C Hamano	 Sync with 1.7.0 series
>  2010-07-27 	 Junio C Hamano	 Git 1.7.0.7  [v1.7.0.7]
> 
> where e.g. [v1.7.2.1] is ref marker for 'v1.7.2.1' tag.
> 
> If you have something different in mind, please provide moackup,
> either as ASCII-art, or link to HTML or image.

Yes, visually this would be very fine with me.

But shortlog is a repository-wide view, while I need the same for history which is a file-specific view. Things are obviously a little more complex there, because for a given file, it is statistically unlikely that each commit affecting the file in question corresponds to a tag. So we have to find the best tag to display in front of each commit (easiest bet would be the next tag time-wise) and maybe improve a bit from there (for example by not showing the same tag twice). But then again I would be very happy with a relatively raw output for the time being.

Thanks,

-- 
Jean Delvare