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
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
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
* 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ó
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
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
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
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,
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
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
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
* 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
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
13 matches
Mail list logo
