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:
quoted
quoted
quoted
Kristis Makris wrote:
quoted
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.
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).
From: Andreas Ericsson <hidden> Date: 2016-06-15 22:45:29
Kristis Makris wrote:
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:
quoted
quoted
quoted
quoted
Kristis Makris wrote:
quoted
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'm guessing releases will be cut from some sort of central or official
repository anyway, so I fail to see why tags would need to be verified
at create-time rather than at push-time. It's sometimes useful to create
tags for ones own personal use, and commit messages that are no more than
"wip", without signoff or anything. This needs to be implemented at the
receiving end. Not at each developers end.
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
git supports optional log-messages on tags. There are two different kinds
of tags in git; "annotated" (with logmessage) and "lightweight" (without
logmessage). It's up to each user which sort of tag to create. Using the
example update hook, lightweight tags are by default not allowed to be
pushed to a repository.
(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.
Merges happen in the local repository. When a merge is pushed to the
"release" repo, you can analyze the merges and all commits that the sender
is trying to push.
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:
That sort of work belongs in the update hook then. Cautious users, or
release engineers, might want to enable pre-merge hooks and whatnot.
Try and find out. It would have been faster than writing that paragraph ;-)
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.
quoted
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.
Hooks can also be disabled, and they aren't enabled by default. They're also
not cloned along with a repository (that would be stupid, as I most certainly
don't want the email-on-commit hooks we're using at work), so installing
said hooks would still be a manual job done by each developer that wishes to
comply with the policy you're outlining. I have a hard time seeing how that
can benefit the open community.
quoted
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).
Relying on hooks on the developer side is fragile and *will* break.
It will break often, and it will break badly. Any sort of
"this-commit-is-releasable" verification simply *has* to be done in
the release repository. Otherwise you'll be limiting how devs can
use the scm while gaining absolutely nothing (since it has to be
done in the release repo too for those times when the dev forgot
to enable hook X in a newly cloned repository).
I still haven't figured out what the over-all plan is, so my
advice and warnings may be counter-productive at worst. However,
http://files.mkgnu.net/files/scmbug/doc/latest_manual/html-multi/x113.html
just doesn't make sense to me. It's invalidated by clear and
concise commit messages (which aren't always there, but education
is nine times out of ten better than enforcement; It's better
to understand *why* 6x7 = 42 rather than just knowing that it's
so).
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
From: Daniel Barkalow <hidden> Date: 2016-06-15 22:45:29
On Tue, 14 Oct 2008, Kristis Makris wrote:
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:
quoted
quoted
quoted
quoted
Kristis Makris wrote:
quoted
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.
Git supports using tags for a variety of other purposes in addition to the
traditional ones (for example, you can tag a version as "the changes I'm
sure of" or "the version I know is broken"; furthermore, your regression
testing system could give you a tag that tags the commit you sent for
testing with the test results). The bug tracker integration should only
care about the traditional use (providing a persistant, human-recognizable
name for a revision). Actually, it would probably be best, for integration
with git, to skip tags entirely, and use the hash. With projects using
git, it is routine to know that the bug was found in some particular
flawed commit that didn't get tagged.
In general, you send to the central repository, and it rejects you if (a)
a merge would be required; you have to fetch and merge in your local
repository; or (b) there's something wrong with the changes you're making.
For (a), you make a merge commit and try again; the new commit has a log
message, but the old commits retain their log messages. For (b), you make
a different set of commits that does follow the required policy. "git
rebase -i origin/master" will guide you through this process. In general,
you do this before sharing your changes with anybody else, or at least
before sharing them with anyone who cares about the end result, so that
other people see nice commits. It's also possible to rearrange the changes
you made in a bunch of local commits into a series that looks nice and
makes sense and follows the project rules, when your initial work had you
introducing a lot of silly mistakes and fixing them.
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.
In general, there's a ton of adjustment needed between working on a
project and pushing to the central location in any system. With git,
however, version control may be used locally before these adjustments are
made, and this provides a huge benefit in terms of being able to prepare
commits just how they should be, and in terms of being able to avoid
losing work during the adjustments.
In general, you want to have a local understanding of the central
repository rules, so that you can do this mapping while you don't have
network, but there's no reason to prevent saving your work before it
conforms.
-Daniel
*This .sig left intentionally blank*
That already requires using additional interface to git alone. Using an alias
for creating tags that are synchronized with that local bug-tracker is not
that much more complex than IMHO. Besides you will sometimes want to use git
tags, branches, commits and other things *without* synchronizing them to the
local bug-tracker even if you usually synchronize -- they are often very
useful for manipulating changes.
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
Git does support log messages on tags. It has unannotated tags (which are
just refs) and annotated tags which have a special tag object with the log
message (and optionally PGP signature).
Indeed, the locally made commits are transfered to the upstream repository as
they are. In fact, because the commit id is a SHA1 checksum of all it's
content, including the message and the parent ids (and therefore complete
history), when the commit message is changed, it is no longer the same
commit.
However, git provides many tools (commit --amend, rebase -i, filter-branch)
and has additional extensions (stgit, topgit), that make it easy to create
a new commit based on another one with some change. This is extremely useful
and many people use it really often.
Such new commit will not replace the previous one -- it has different
checksum -- so it's not good thing to do when other people already based
further changes on your commit. But it's very useful for handling work in
progress, quickly diverting to different tasks, making experiments and such.
Therefore it's the push that casts things in stone, but before that you can
easily take back and redo both commits and tags. Additionally it's very
useful to sometimes do commits and tags that you intend to replace later just
to temporarily record some interesting state eg. to divert to other bug that
suddenly got higher priority or to try out different approach.
Thus you only want to run the checks as warnings locally and probably want to
have an option to avoid them in a particular case for performance reasons
(all this stuff is so useful because it's fast). And since the tags that are
ment for publication you will usually pull shortly after making them and
because creating a tag is rather simple, I would say that running the check
on push is sufficient there and the alias helps if you'd really want to run
the check earlier. For commits you can of course use the pre-commit and
post-commit hooks.
[...]
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).
I would rather recommend having per-developer branches (you can actually have
branch hierarchies, so it's rather per-developer branch directories) on the
central repo, where the users would push their work they consider final
enough to show to anybody. Than you can have a "pending" (or "for review" or
both or whatever) state in the central bug-tracker for issues with fixes on
such developer branches. That saves the hassle of installing per-developer
trackers and gives developer more freedom to create temporary stuff locally.
That is not to say that your use case makes no sense. I am just trying to
suggest a workflow, that might fit better with the existing practices used
with git and maybe requiring less work to implement.
As for people replacing their local commits, this is common especially in
Linux (and Git) development model. For Linux patches need to be sent split
into logical steps to make it easier to review them, which is quite important
for a critical piece of code like kernel. But everybody will inevitably make
mistakes when implementing the changes; these mistakes must not appear in the
final submission though, because they would interfere with review. When
developing in Git, each commit will produce one patch in the submission, so
people go and redo their commits multiple times to make them as much readable
as possible and fix bugs they made earlier.
--
Jan 'Bulb' Hudec [off-list ref]
From: Andreas Ericsson <hidden> Date: 2016-06-15 22:45:29
Jan Hudec wrote:
As for people replacing their local commits, this is common especially in
Linux (and Git) development model.
It's common everywhere where projects use peer review.
Results 1 - 50 of about 14,600 for '"PATCH v2" vger.kernel.org'
Results 1 - 50 of about 360,000 for "PATCH v2"
So yes, it is a very common practice and anything interacting with a remote
database based on each commit action will almost certainly be doing something
wrong quite a lot of the time, especially since not all the patch-series end
up being incorporated into a release anyway.
The only sane integration point is the public watering-hole repository used
for the project, and especially the release branch (or the "for-linus" branches
around the world for sub-projects).
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231