Re: commit IDs in changelog messsages (was: Introductory mail)
On Thu, 2008-11-13 at 10:11 -0500, James Westby wrote: No, why? Short commit IDs are usually enough in Git. Why not use [f] then? The short ID may be unambiguous when you create the entry, but it's not future proof. The chances of a collision increase over time. Right, but every digit you add you roughly quadruple the size the project needs to get before a collision is likely. Even with 7 digits on a large project you're likely to be safe, because you know you're only looking at commit objects, and furthermore you know the approximate date of the change from the changelog entry[1]. Only one in two projects with 20,000 commits will find a single collision of 7 hex digit commit IDs; with 12, there's only a 0.1% chance that you will find a collision with a hypothetical 1,000,000 commit repository. This is why it is common practice, and safe, to use shortened identifiers in human-read and written locations. Sam. 1. git-rev-parse and friends don't currently have a mechanism for disambiguating collisions with these hints, but that's just a patch or two away should it be required. ___ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
Re: commit IDs in changelog messsages
On Sat, Nov 15 2008, martin f krafft wrote: also sprach Manoj Srivastava [EMAIL PROTECTED] [2008.11.14.0719 +0100]: f) edit ./debian/changelog, adding in any additional language. I generally keep my commit messages and changlog entries distinct, since commit messages explain the code changes to a developer, and changelogs are geared towards the end user. This is why Git allows you to write essays in addition to the short commit summary, which should always be geared to everyone. You did not miss the previous step: e) dch --no-auto-nmu --append -- \ $(git log --abbrev-commit --pretty=oneline HEAD\^.. | \ perl -pli -e 's/\.\.\.//;' -e 's/\s*(\S+) /[$1] /') This adds a line into ./debian/changelog If you missed it, this does provide the commit summary line into the changelog. It also works whether I am in the integration branch, or in the ./debian submodule, which is a required feature for me (I can't use git-dch, because it assumes that ,.debian lives in the integration branch). I think that the body of the commit log is always people working on the code; the Changelog is for people using apt-listchanges or loking at /usr/share/doc/foo/ ;, and is geared more towards user visible changes. manoj -- One of the most overlooked advantages to computers is... If they do foul up, there's no law against whacking them around a little. -- Joe Martin Manoj Srivastava [EMAIL PROTECTED] http://www.golden-gryphon.com/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C ___ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
Re: commit IDs in changelog messsages
On Sat, Nov 15 2008, martin f krafft wrote: also sprach Petr Baudis [EMAIL PROTECTED] [2008.11.14.1301 +0100]: In the long run, I really want to supersede Closes: anyway. Ideally, the bug gets marked 'fix-committed' when a signed-off commit closing the bug hits the repo (or a tag like closes-123456 appears), and an upload would identify bugs closed between the last upload and this one, using the repo and those commit IDs, and then selectively close those bugs. Then why do you actually keep the changelog? Usually about 50% of the times when I look at it is when I need to check when was bug X fixed?. The changelog (a) serves the data about which bug-closing-commits are actually part of the package that is being uploaded to the archive software, so that it can close the corresponding reports in the BTS (b) provides the information needed to answer questions such as yours to the user from a file in the package itself without requiring the user to go online or know the VCS (c) selects only the relevant commits, e.g. it wouldn't contain a commit fix typo in last commit. I think you are missing the apt-listchanges audience (should I upgrade to this version of the package?). Also, the user looking for when a user visible change happened in /usr/share/doc/foo/. I looked recently to see when po4a started taking --previous as an option, for instance. So the BTS and users are the consumers of the changelog. developers are the consumers of the commit log. manoj -- Air pollution is really making us pay through the nose. Manoj Srivastava [EMAIL PROTECTED] http://www.golden-gryphon.com/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C ___ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
Re: commit IDs in changelog messsages (was: Introductory mail)
On Thu, Nov 13, 2008 at 10:11:15AM -0500, James Westby wrote: You mean [fc5473a06be960382582ddbfb40e2a5f824be122] don't you? No, why? Short commit IDs are usually enough in Git. Why not use [f] then? Well, even thought the likelihood of clashes increase trivially with time, we are in the context of changelogs which are made of timestamp-ed entries. Hence it would be relatively simple, the day that a clash does occur, to disambiguate it by choosing the commit which is closest to the timestamp of the changelog entry referencing it. It wouldn't even be necessary to do that always, you can be lazy and do that only upon conflicts. To do that you will need connectivity to the repository, but without that the id is useless any how, and I also observe that most $DVCS help us in this respect, because we know that the full history is always available attached to each commit. Am I overlooking some serious intricacy? Cheers. -- Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7 [EMAIL PROTECTED],pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/ Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime signature.asc Description: Digital signature ___ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
Re: commit IDs in changelog messsages (was: Introductory mail)
On Fri, Nov 14, 2008 at 07:42:02AM +0100, martin f krafft wrote: also sprach Martin Bähr [EMAIL PROTECTED] [2008.11.13.1540 +0100]: On Thu, Nov 13, 2008 at 01:42:44PM +0100, martin f krafft wrote: Except, of course, there is no such thing as an SVN-Commit. r123 is a state, a snapshot, the commit if the diff against r-1. I think hg is like Git well, in git the commit-ids also represent the state of the whole tree like in svn. Yes, but we are talking about commits, about changes which resolve a given bug. It's only SVN's limitation that you cannot do 'svn show r123' and get what you want to see. But trac can help with this. This shows the changeset that leads to r123: https://trac.calendarserver.org/changeset/123 Cheers, -- Guido ___ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
Re: commit IDs in changelog messsages (was: Introductory mail)
* martin f krafft [Fri, 14 Nov 2008 07:42:02 +0100]: Yes, but we are talking about commits, about changes which resolve a given bug. It's only SVN's limitation that you cannot do 'svn show r123' and get what you want to see. % svn diff -c 123 HTH, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org A lie can go round the world before the truth has got its boots on. -- Terry Pratchett ___ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
Re: commit IDs in changelog messsages (was: Introductory mail)
On Wed, Nov 12, 2008 at 01:20:10PM +0100, Stefano Zacchiroli wrote: Following the (good) path of Closes, it should probably be something like [Commit: fed3f3d]. Also, can't it be put inside the same parentheses than Closes, as in (Closes: #7005180, #7005181; Commit: fed3f3d). If we really want a tag in front of the commit identifier we should specify the VCS: [Git:fed3f3d], [Svn:r1234], [Hg:fed3f3d] this would help in the case where a package switches VCSs. Finally, I missed if the aim is finding something Git-specific or not, in the latter case the commit ID can be paired via a VCS identifier, though I acknowledge that it risks to become too heavy ... It's (of course) not git specific at all, that wouldn't help much. In order to link back from the changelog to the VCS, we have all the needed information in debian/control already. I just noticed that Manoj picked up the propsed format for kernel-package too: https://honk.sigxcpu.org/cl2vcs/index.cgi?pkg=kernel-package Cheers, -- Guido ___ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
Re: commit IDs in changelog messsages (was: Introductory mail)
On Wed, Nov 12, 2008 at 11:09:45AM -0500, James Westby wrote: On Wed, 2008-11-12 at 08:39 +0100, martin f krafft wrote: also sprach Guido Günther [EMAIL PROTECTED] [2008.11.08.1419 +0100]: Does this look like a worthwhile extension to the current changelog format? For me it makes reviewing changes a lot easier. I think this is very important to have, but why put them at the front? Changelogs are for consumption by humans and machines, and humans have it easier if they can just start reading on the left side and get the information they want. Machines don't really care very much. So, similar to how we close bugs, how about * fixed segfault during daemon startup (Closes: #7005180) [fed3f3d] instead? You mean [fc5473a06be960382582ddbfb40e2a5f824be122] don't you? You can abbreviate that (git-rev-parse(1), see --short). I don't think we need a VCS identifier there. I don't see why anyone would specify a bzr revision id in a git package. How would this differ from using annotate on the changelog? Do some people write the changelog at the end? Using annotate on the changelog assumes you're committing the changelog entry together with the actual change. That's not a workflow everyone uses and IMHO makes little sense when using a DVCS since merging branches from different people/places creates unnecessary conflicts in the changelog. Cheers, -- Guido ___ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
Re: commit IDs in changelog messsages (was: Introductory mail)
On Thu, Nov 13, 2008 at 10:40:15AM +0100, Guido Günther wrote: I don't have a need for it either - just iff we want to have a qualifier inside the braces we should at least use the type of VCS not only Commit:. OK, but note that there are drawbacks. For example if we go for (Git:af14e5) that would be annoying, as parsing will depend on the number of supported, or known, VCS. That was a wrong design choice of Vcs-* which I don't want to repeat. Hence, if we really want a VCS tag it should be something easily skipped over, e.g.: (Commit:Git:af14e5) where one can skip the tag and look only at the ID if she wants so. Frankly speaking though, this notation already looks too cumbersome to me. Cheers. -- Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7 [EMAIL PROTECTED],pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/ Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime signature.asc Description: Digital signature ___ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
Re: commit IDs in changelog messsages (was: Introductory mail)
Am Donnerstag, den 13.11.2008, 12:54 +0100 schrieb Adeodato Simó:
Though I agree with your reasoning here, I find (2) a tad too verbose
(mostly because of the colon appearing twice, which requires two passes
from your brain, if you see what I mean). May I suggest:
3) (Closes: #1234567, Vcs-Git:fba134)
And Vcs-Hg, Vcs-Bzr, and so on. How does that sound?
I think this syntax is a good compromise and most packagers are familiar
with the notation from debian/control.
If it should be clear to someone outside of Debian (packaging), the
notation {Git,SVN,Hg,*}-Commit might also be reasonable, as it shows
that the entry has something to do with a VCS commit.
Best regards
Manuel
___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
Re: commit IDs in changelog messsages (was: Introductory mail)
also sprach Stefano Zacchiroli [EMAIL PROTECTED] [2008.11.13.1109 +0100]:
OK, but note that there are drawbacks. For example if we go for
(Git:af14e5) that would be annoying, as parsing will depend on the
number of supported, or known, VCS. That was a wrong design choice
of Vcs-* which I don't want to repeat.
I am not sure I agree. Maybe in the context of debian/control, but
I don't see the shortcomings for what we're trying to do.
Let's assume we copy the same scheme as Closes, meaning that
/[cC]loses:\s*(#?\d{6,}(,\s*#?\d{6,})*)/ yields the list of bugs in
$1, then we ought to have something similar for VCS commits.
But instead of one parser, I'd really rather think of it as a number
of parsers, each getting a chance. So Closes would be handled by the
dak-bts parser, and Git: by a git parser, SVN: by an SVN parser,
etc.
So, in any context, there will be a set of parsers, and when we
encounter Bazaar: but there is no Bazaar parser (assuming that...),
then a Commit:Bazaar: would not provide use with any more
information, really: we still couldn't parse it, even though
a generic Commit: parser might get a chance to. Yet, as you said,
the generic Commit: parser would not have knowledge about each VCS
(which I think is the design error you mention), so the benefit
would stay 0.
--
.''`. martin f. krafft [EMAIL PROTECTED]
: :' : proud Debian developer, author, administrator, and user
`. `'` http://people.debian.org/~madduck - http://debiansystem.info
`- Debian - when you have better things to do than fixing systems
most people become bankrupt through having invested too heavily in
the prose of life. to have ruined one's self over poetry is an
honour.
-- oscar wilde
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
Re: commit IDs in changelog messsages (was: Introductory mail)
On Thu, Nov 13, 2008 at 11:22:56AM +0100, martin f krafft wrote: But instead of one parser, I'd really rather think of it as a number of parsers, each getting a chance. So Closes would be handled by the dak-bts parser, and Git: by a git parser, SVN: by an SVN parser, etc. Consider the following two snippets of changelog entry metadata (which I think is what we are aiming to generalize): 1) (Closes: #1234567, git: fba134) 2) (Closes: #1234567, Commit: git:fba134) I do agree that no matter what, if you are not git-aware, the git commit numbers is useless for you. That can't be otherwise. Still, even if you are not git-aware, in snippet (2) you can recognize that git:fba134 is a commit identifier. You don't know what to do with that, but at least you know that it is. On the contrary, in snippet (1) you aren't even able to understand that it is a commit identifier. So, for instance, you can't do neutral stuff like passing it to some other applications which comes after you in a processing pipeline which *might* be git-aware themselves. A real-life use case is dpkg-parsechangelog. With snippet (2) it can output a commit identifier and tell to the world that the VCS in use is git, even if dpkg-parsechangelog is not git-aware itself. With snippet (1) the only possibility is to add to dpkg-parsechangelog the list of recognized VCS tags. It is well possible that this fuss is excessive, as it introduces a more cumbersome syntax we do not tolerate for a relative minor gain. Still, the right(tm) design seems to be (2). Maybe it is just not worth. YMMV. Cheers. -- Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7 [EMAIL PROTECTED],pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/ Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime signature.asc Description: Digital signature ___ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
Re: commit IDs in changelog messsages (was: Introductory mail)
On Thu, Nov 13, 2008 at 01:42:44PM +0100, martin f krafft wrote: Except, of course, there is no such thing as an SVN-Commit. r123 is a state, a snapshot, the commit if the diff against r-1. I think hg is like Git well, in git the commit-ids also represent the state of the whole tree like in svn. but I think bzr also doesn't have commit identifiers. without rechecking, from what i remember reading there are local revision ids which are sequential, but also hashes (either for the commit or the tree) which are global like in git. Anyway, since those are unique within the official repo to which these messages are referring (else it would not make sense, except maybe in the case of Git it makes sense for any dcvs. if i am interested in the commit-id then chances are that i already have a local clone of the repo in which case i can use the global id locally. (this becomes significant for bzr which has both) greetings, martin. -- cooperative communication with sTeam - caudium, pike, roxen and unix offering: programming, training and administration - anywhere in the world -- pike programmer working in china community.gotpike.org unix system- iaeste.(tuwien.ac|or).at open-steam.org administrator caudium.orgis.schon.org Martin Bähr http://www.iaeste.or.at/~mbaehr/ ___ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
Re: commit IDs in changelog messsages (was: Introductory mail)
* James Westby [Wed, 12 Nov 2008 11:09:45 -0500]: How would this differ from using annotate on the changelog? Do some people write the changelog at the end? I think that's what git-dch(1) does. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: James Blunt - You're Beautiful ___ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
