Re: Git and tagging hook

[Kristis Makris <kristis.makris-tTJs1oqo2yY@public.gmane.org>]

[-- Attachment #1.1: Type: text/plain, Size: 4668 bytes --]

Jan, thanks for trying to clarify this for me.

I am working on adding integration support of Git with bug-trackers,
using Scmbug. There may be an argument here towards/against distributed
bug-trackers when it comes to Git.

Maybe there are things here I don't fully understand yet.

On Tue, 2008-10-14 at 19:22 +0200, Jan Hudec wrote:
> >>> Kristis Makris wrote:
> >>>> I want the integration when I apply the tag to a local repository, NOT
> >>>> only when I push/pull.
> 
> Care to explain why that would ever be useful? It's local, which means that:
>  - the user can take it back without a trace it ever happened (git tag -d or
>    even git update-ref -d) and
>  - noone except the user will see it anyway, so it's not like they should
>    care either.

I have two use cases:

(1) A developer maintains besides his local copy a local bug-tracking
system in which he tracks his changes. We would like to apply various
verification policies when he commits or tags. For example, for tagging
we wants to ensure that he tags giving consistent labels to his
intermediate builds. e.g. as in:

http://files.mkgnu.net/files/scmbug/SCMBUG_RELEASE_0-26-9/manual/html-single/manual.html#VERIFICATION-CHECKS-CONVENTION-BASED-LABELING

Or he may want to have Git force him to also supply a log message along
with a tag, so that he can remember later more accurately why a tag was
created and what it really captures. Even if Git (or other SCM systems)
don't natively support log messages on tags. Scmbug plans to implement
this.

http://bugzilla.mkgnu.net/show_bug.cgi?id=219


(2) I would like to apply various verification policies when work from a
local repository is finally merged with the central repository. I assume
there can/will be a central repository, and there is one "software
product" that is being released somewhere among the many copies.

When its time to merge local changes to a central repository, the
verification policies may deem that changes are not acceptable to be
merged with the mainline. e.g. because log messages are too short,
commits during the merge are issued against bugs in "a central"
bugtracker that are either closed, assigned to someone else, or just
plain wrong bug-numbers that belong to other products:

http://files.mkgnu.net/files/scmbug/SCMBUG_RELEASE_0-26-9/manual/html-single/manual.html#VERIFICATION-CHECKS-VALID-LOG-MESSAGE-SIZE
http://files.mkgnu.net/files/scmbug/SCMBUG_RELEASE_0-26-9/manual/html-single/manual.html#VERIFICATION-CHECKS-OPEN-BUG-STATE
http://files.mkgnu.net/files/scmbug/SCMBUG_RELEASE_0-26-9/manual/html-single/manual.html#VERIFICATION-CHECKS-VALID-BUG-OWNER
http://files.mkgnu.net/files/scmbug/SCMBUG_RELEASE_0-26-9/manual/html-single/manual.html#VERIFICATION-CHECKS-VALID-PRODUCT-NAME

(I'm not very clear whether this is how Git works)

Does someone get to write-up a brand new log comment during the merge
and the merge totally disregards older log comments ? My understanding
is that log comments on the local copy are preserved (and will need to
be mapped to bug-numbers in the central bug-tracker. 

Thus the local verification policies may need to have already been
configured to comply with future verification policies of the central
repository. Else (perhaps considerable) mappings/adjustments will be
needed during the push to the central copy.

> Besides, you don't need git tag to create a tag in git, so the hook wouldn't
> really be guaranteed anyway (I mean, just like the commit hook is not -- you
> can still commit by calling write-tree, commit-tree and update-ref and avoid
> the hook).

I'm assuming someone who follows the recommended avenue of using Git
wants the advantages of hooks. I certainly can't force people that
bypass hooks to use them.

> For integration with issue tracker, the local tag is neither final, nor
> useful to anybody except the user who did it until it hits the central
> repository. And working on the central repository directly does not seem like
> a good idea either.

The local tag is useful to the local user and his local bug-tracker. He
can have tag operations intercepted so that the tag names show up as
versions in his bug-tracker. In this way he can keep track of which bugs
still exist or have recently been introduced/discovered to his local
copy, before he decides to publish his polished, final version:

http://files.mkgnu.net/files/scmbug/SCMBUG_RELEASE_0-26-9/manual/html-single/manual.html#TAGS

And his "local bug-tracker" may be reachable on the web and useful by
others that take a peek at the users progress (even fetching it with
Git).


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 188 bytes --]

_______________________________________________
scmbug-users mailing list
scmbug-users-G8y9j4K4DsPiwOUmbS1EgQ@public.gmane.org
http://lists.mkgnu.net/cgi-bin/mailman/listinfo/scmbug-users