Re: [Monotone-devel] monotone Hacking
Stephen Leake wrote: Ok, that is helpful. Perhaps that file should be mentioned in HACKING; I would not think to look in Changelog for instructions on writing commit messages :). Sure, feel free to add something appropriate. ;) But after you document the detailed changes to each file, you could step back and write a summary of the change at the top of the message, stating the overall purpose of the change. Yeah, it would certainly be nice to have an overview of the change before getting into the gory details. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] monotone Hacking
Derek Scherger [EMAIL PROTECTED] writes: Stephen Leake wrote: I have wondered about the proper format/content for changes in nvm. I'd appreciate some written guidance in HACKING. If nothing else the current ChangeLog file does give a bit of info about this along with saying that it is no longer used. Ok, that is helpful. Perhaps that file should be mentioned in HACKING; I would not think to look in Changelog for instructions on writing commit messages :). I'm with Zack on the value inherent in the process of writing a detailed changelog message. I see it as my own personal code review and often find things that need a little tweak or think of things that should also be done, whether in the current change or in some later one. It is definitely worth doing the review. And documenting the results of the review in the commit message is not a problem. (Note that you _could_ simply record the results in some other file, or just delete them when the review is complete). But after you document the detailed changes to each file, you could step back and write a summary of the change at the top of the message, stating the overall purpose of the change. And then in the detailed list of changes, clearly separate those involved in the main change from the other minor changes. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] monotone Hacking
Richard Levitte [EMAIL PROTECTED] writes: In message [EMAIL PROTECTED] on Tue, 11 Sep 2007 07:12:54 -0400, Stephen Leake [EMAIL PROTECTED] said: stephen_leake On the other hand, that is the way we typically work. I stephen_leake often notice little things while I'm working on one stephen_leake big thing. Would it be better to _not_ fix them? Or stephen_leake do one commit for each little thing? stephen_leake stephen_leake Documentation belongs in .texi files, not in commit stephen_leake messages. Commit messages should help you find when a stephen_leake change occured, and give pointers/hints about why, but stephen_leake the real reasons should be in more stable form. stephen_leake stephen_leake Otherwise, you can get oscillations; changed to a stephen_leake linked list because it's faster on Windows, changed stephen_leake to a red-black tree because it's faster on Gentoo stephen_leake etc. If those comments were in a design file, it would stephen_leake be obvious what's happening. If they are just in the stephen_leake commit messages, it's much harder to notice. You're talking about two different kinds of documentations. When I update my workspace, or even better, when I'm about to, and I want to know what will happen, the most natural is to check out the log. If all the log says is that this and that function was created, this and that function was removed, this and that file was renamed to such and such, it tells me absolutely NOTHING. Ok. I hadn't really thought about it from that point of view. I agree the commit comments should facilitate that task; they should briefly describe the main point of the changes. Enough so that someone unfamiliar with the change can decide whether they need to review the change in more detail or not. It is difficult to describe how much these messages should say. For example, I'm tempted to suggest enough detail to allow someone unfamiliar with the change to understand what it does. But understand at what level? From a user's point of view or a maintainer's point of view? One problem in this area is merging branches. Typically, the only log entry is merged revid revid. Should the commit message try to summarize the purpose of the changes in the branch, or should we be expected to examine the log of the branch? I guess it should not be hard to give a one or two sentence summary of what the branch was for. For a concrete example, I'm about to merge nvm.basic_io.inventory. So the merge commit message could be: Change automate inventory output format to use basic_io Then for more detail, you can still examine the commit messages for each change on the branch. Documentation in .texi files are fine for user documentation, overall architecture, roadmaps, that kind of thing, but to understand what individual changes actually do, it suck 747s through a needles head. It's simply about traceability. Right. There are also comments in code for local design decisions. As for small changes, I see no problem with them getting in as part of something bigger, and being CLEARLY marked as such. Some might say that it's better to try to make them into separate commits, but I personally wouldn't care. If you CAN make them into separate commits, then do. Ok, that's fair. For such small changes, I think the changelog style (listing each file and function modified) is a good one. Unless it affects a lot of functions, like a spelling change. I have wondered about the proper format/content for changes in nvm. I'd appreciate some written guidance in HACKING. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] monotone Hacking
On 9/11/07, Nathaniel Smith [EMAIL PROTECTED] wrote: Just some ideas: Consider (user-visible) features F and G, implemented both in branch A. Each feature can easily constituted of multiple changesets, but I assume for a moment that no single changeset is related to both F and G at the same time. In this case I would like to see exactly two entries in my second level log file (and there is an entry in the first level monotone log for each changeset). So perhaps it would be better to... implement F and G in branches F and G? That at least reduces the proliferation of mechanisms and UI for them. If you mean, rather, that F and G are two general pieces of functionality, and over a long period of time you want to consistently mark all the changes that happen to touch on that functionality, then I guess branches aren't as ideal. Mmm, well I think that branches *are* ideal for this, but they just don't exist in the correct topology of a typical repository because of common workflows, and common development practices, and hard deadlines, etc etc. One of the things I was targeting, was that with 'correct cert attribution' of revisions in monotone, and some very clever scripting, it might be possible to create some of these branches semi-automatically, which afterwards should ease merging in features ? And, of course, these operations should maintain the feature -- changesets relationships (by annotating the constructed (plucked ?) revisions with the necessary certs, see below). The value I see is that the scripting can be independent of the topology of the original branches and revisions as created by common practices. I guess it sounds all a bit theoretical, OTOH, easy browsing of the several implementations of a common feature across branches is an added value. At the monotone level, I guess a UI for that would be something like: -- Commit message editor -- Increase flow through the frobulator to reduce blockage. Keywords: frob, nozzle -- End commit message editr -- I think that having the second level log in a separate file (or stream of some sort) comes in handy when searching for certain features, and for interfacing to external (G)UIs, e.g. to answer questions like 'Does the branch with tag Install-at-Zeemie-Cafe have a data shaper and accelerator ?'. Or suppose you find out that the 'high velocity data shaper' (nozzle) has a severe bug: 'What branches are installed at operational customer sites and have a high velocity data shaper ?'. The way I understand what you are saying is that the shown commit message is literally inserted in the ChangeLog cert. Not that I would be opposed to it, but having additional certs to tag the features would be handy for browsing. So in this case, two certs should be attached to the committed revision, eg. they would show up in the monotone log next to Date: and the other certs as: Feature: frob Feature: nozzle A commit hook can check the commit message, and extract specific sets of information from the commit message, then insert them in the second level log. In addition to this, after the commit has completed, the hook adds the frob and nozzle certs to the committed revision. Then, in the second level log file, you have short description entries like frob: Frobulator, a tool which helps coders and server admins find and fix memory problems nozzle: high velocity data shaper. Hugo -- Hugo Cornelis Ph.D. Research Imaging Center University of Texas Health Science Center at San Antonio 7703 Floyd Curl Drive San Antonio, TX 78284-6240 Phone: 210 567 8112 Fax: 210 567 8152 ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] monotone Hacking
Stephen Leake wrote: I have wondered about the proper format/content for changes in nvm. I'd appreciate some written guidance in HACKING. If nothing else the current ChangeLog file does give a bit of info about this along with saying that it is no longer used. I'm with Zack on the value inherent in the process of writing a detailed changelog message. I see it as my own personal code review and often find things that need a little tweak or think of things that should also be done, whether in the current change or in some later one. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] monotone Hacking
On Sep 11, 2007, at 2:18 AM, William Uther wrote: On 10/09/2007, at 7:49 PM, Thomas Keller wrote: Hi all! I've noticed that the changelog some people use for monotone is not quite GNU-style. I'm sure you all hacked stuff longer than me, so you can correct me at any time, but aren't we forced to use some kind of GNU-style syntax to make it easier to create a ChangeLog file afterwards (for whatever distributions need that)? If not, everybody is - of course - free to use whatever format they do like. I don't like to start a bikeshed discussion here, I just want to be clear. I think it would also be a good idea to include the rules of whatever consense we find here in HACKING. I think including the rules in HACKING would be a good idea. Out of interest, who actually converts log messages directly to change logs? I would have thought that most people who distribute Monotone would find the more abstract changes described in the NEWS file more relevant. Indeed. Personally I have never found ChangeLogs that useful *if* I can resort to the development repository to look for the information I need. And in the case of Monotone it's clear that doing that is possible :-) Browsing through the repository archives is usually easier, more descriptive and far more accurate than what a ChangeLog can say. For packagers (at least for me, again ;-) the NEWS files are much more useful than ChangeLogs because you can quickly get an idea of the most important changes between releases. The exact changes to files is irrelevant, unless you are looking for a specific bug fix for example. (And even in this last case, ChangeLogs are annoying because the information may be spread among multiple entries making it difficult to grasp what happened except for people very familiar with the code.) I'd vote for ditching ChangeLog-style commit messages in favor of more descriptive ones (using the approach of a subject line at the beginning and a large description in the subsequent paragraphs). Why? First of all, Monotone already records the exact changes to the files, and mtn log will tell you which of them were modified, added, removed, etc. There is no need to repeat that in the message. And second, this can prevent committing unrelated changes in a single commit. Using a ChangeLog approach, it is often very tempting to write a message as: * a.cc, b.cc: Did blah, blah, blah. * z.cc: Fixed an unrelated typo. This commit would be conceptually incorrect because it's doing two things at the same time. Using ChangeLog-style messages seems to encourage this approach. Using plain text messages will make one think twice before doing that, because he'll have to explain *why* he is committing that at once. Cheers, -- Julio M. Merino Vidal [EMAIL PROTECTED] ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] monotone Hacking
In message [EMAIL PROTECTED] on Tue, 11 Sep 2007 12:22:43 +0200, Julio M. Merino Vidal [EMAIL PROTECTED] said: jmmv84 Using plain text messages will make one think twice before jmmv84 doing that, because he'll have to explain *why* he is jmmv84 committing that at once. I totally agree with that. There are numerous messages saying that the programmer fiddle with this and that function, created a new one, removed an old one, but NOT ONE WORD about the overall change, its intention or its reasons. Basically, that makes for crap documentation. Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up. -- C.S. Lewis ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] monotone Hacking
Richard Levitte [EMAIL PROTECTED] writes: In message [EMAIL PROTECTED] on Tue, 11 Sep 2007 12:22:43 +0200, Julio M. Merino Vidal [EMAIL PROTECTED] said: jmmv84 Using plain text messages will make one think twice before jmmv84 doing that, because he'll have to explain *why* he is jmmv84 committing that at once. I totally agree with that. There are numerous messages saying that the programmer fiddle with this and that function, created a new one, removed an old one, but NOT ONE WORD about the overall change, its intention or its reasons. Basically, that makes for crap documentation. On the other hand, that is the way we typically work. I often notice little things while I'm working on one big thing. Would it be better to _not_ fix them? Or do one commit for each little thing? Documentation belongs in .texi files, not in commit messages. Commit messages should help you find when a change occured, and give pointers/hints about why, but the real reasons should be in more stable form. Otherwise, you can get oscillations; changed to a linked list because it's faster on Windows, changed to a red-black tree because it's faster on Gentoo etc. If those comments were in a design file, it would be obvious what's happening. If they are just in the commit messages, it's much harder to notice. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] monotone Hacking
On Sep 11, 2007, at 1:12 PM, Stephen Leake wrote: Richard Levitte [EMAIL PROTECTED] writes: In message [EMAIL PROTECTED] on Tue, 11 Sep 2007 12:22:43 +0200, Julio M. Merino Vidal [EMAIL PROTECTED] said: jmmv84 Using plain text messages will make one think twice before jmmv84 doing that, because he'll have to explain *why* he is jmmv84 committing that at once. I totally agree with that. There are numerous messages saying that the programmer fiddle with this and that function, created a new one, removed an old one, but NOT ONE WORD about the overall change, its intention or its reasons. Basically, that makes for crap documentation. On the other hand, that is the way we typically work. I often notice little things while I'm working on one big thing. Would it be better to _not_ fix them? Or do one commit for each little thing? I'm not saying that they do not to be fixed. They indeed have, but those *unrelated* changes have to be committed separately. The cleaner the changesets, the easier it is to later cherrypick/merge/ review/understand specific changes. Documentation belongs in .texi files, not in commit messages. Commit messages should help you find when a change occured, and give pointers/hints about why, but the real reasons should be in more stable form. Agreed; but ChangeSets are not a design document either. Commit messages should explain the reason behind a change or an outline of it, not what the change exactly did (because the latter is already available in the diff and the change's meta-data!). Of course, if that change is important, it should be documented somewhere else to prevent what you mention below. Otherwise, you can get oscillations; changed to a linked list because it's faster on Windows, changed to a red-black tree because it's faster on Gentoo etc. If those comments were in a design file, it would be obvious what's happening. If they are just in the commit messages, it's much harder to notice. -- Julio M. Merino Vidal [EMAIL PROTECTED] ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] monotone Hacking
In message [EMAIL PROTECTED] on Tue, 11 Sep 2007 07:12:54 -0400, Stephen Leake [EMAIL PROTECTED] said: stephen_leake On the other hand, that is the way we typically work. I stephen_leake often notice little things while I'm working on one stephen_leake big thing. Would it be better to _not_ fix them? Or stephen_leake do one commit for each little thing? stephen_leake stephen_leake Documentation belongs in .texi files, not in commit stephen_leake messages. Commit messages should help you find when a stephen_leake change occured, and give pointers/hints about why, but stephen_leake the real reasons should be in more stable form. stephen_leake stephen_leake Otherwise, you can get oscillations; changed to a stephen_leake linked list because it's faster on Windows, changed stephen_leake to a red-black tree because it's faster on Gentoo stephen_leake etc. If those comments were in a design file, it would stephen_leake be obvious what's happening. If they are just in the stephen_leake commit messages, it's much harder to notice. You're talking about two different kinds of documentations. When I update my workspace, or even better, when I'm about to, and I want to know what will happen, the most natural is to check out the log. If all the log says is that this and that function was created, this and that function was removed, this and that file was renamed to such and such, it tells me absolutely NOTHING. I tend to follow pretty carefully what happens (well, apparently not entirely well, considering I missed the changed of semantics for the approve command), among others because I've a background as peer reviewer within programming groups and habits die hard, and for quite a lot of the log messages, my usual reaction is something along the lines of oh, ok, they fiddled with this, that and that, but what the f*ck does it do??, and it's quite possible that these are internal changes that have zero impact on monotone.texi, and the NEWS file has the unfortunate tendency not to be updated before the next release (with a few notable exceptions). And at release time, when I've tried to figure out what changes have actually happened and what they mean so I can update NEWS at least a little bit, I've often found myself saying a series of what the f*ck's (se the quote a few lines up) and scratching my head. Documentation in .texi files are fine for user documentation, overall architecture, roadmaps, that kind of thing, but to understand what individual changes actually do, it suck 747s through a needles head. It's simply about traceability. As for small changes, I see no problem with them getting in as part of something bigger, and being CLEARLY marked as such. Some might say that it's better to try to make them into separate commits, but I personally wouldn't care. If you CAN make them into separate commits, then do. Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up. -- C.S. Lewis ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] monotone Hacking
On 9/11/07, Richard Levitte [EMAIL PROTECTED] wrote: You're talking about two different kinds of documentations. When I update my workspace, or even better, when I'm about to, and I want to know what will happen, the most natural is to check out the log. If all the log says is that this and that function was created, this and that function was removed, this and that file was renamed to such and such, it tells me absolutely NOTHING. Yes, I often find myself in that situation to. I think here is a way to support two different levels of logging in monotone: Using certs, it is possible to link sets of revisions to an entry in an external log file. Then each entry in the external log file can contain a global description of what happened for this set of revisions. That way, and with the help of some shell scripts, you can support two different levels of logging. Thinking about it, I would like to see the second level of logging be connected with test cases, for some of my own projects. I think code reviewers, packagers and team leaders might find such a feature useful, because it might improve communication in a software team. Hugo -- Hugo Cornelis Ph.D. Research Imaging Center University of Texas Health Science Center at San Antonio 7703 Floyd Curl Drive San Antonio, TX 78284-6240 Phone: 210 567 8112 Fax: 210 567 8152 ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] monotone Hacking
On Tue, Sep 11, 2007 at 10:00:49AM -0500, Hugo Cornelis wrote: Using certs, it is possible to link sets of revisions to an entry in an external log file. Then each entry in the external log file can contain a global description of what happened for this set of revisions. That way, and with the help of some shell scripts, you can support two different levels of logging. Thinking about it, I would like to see the second level of logging be connected with test cases, for some of my own projects. I propose that set of revisions ~ branch? It would definitely be nice to have more branch metadata. -- Nathaniel -- The Universe may / Be as large as they say But it wouldn't be missed / If it didn't exist. -- Piet Hein ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] monotone Hacking
On 9/11/07, Nathaniel Smith [EMAIL PROTECTED] wrote: On Tue, Sep 11, 2007 at 10:00:49AM -0500, Hugo Cornelis wrote: Using certs, it is possible to link sets of revisions to an entry in an external log file. Then each entry in the external log file can contain a global description of what happened for this set of revisions. That way, and with the help of some shell scripts, you can support two different levels of logging. Thinking about it, I would like to see the second level of logging be connected with test cases, for some of my own projects. I propose that set of revisions ~ branch? It would definitely be nice to have more branch metadata. Yes, there is a relationship between them, I am not sure what you mean with ~ (what is the difference between '~' and '=' ?). Just some ideas: Consider (user-visible) features F and G, implemented both in branch A. Each feature can easily constituted of multiple changesets, but I assume for a moment that no single changeset is related to both F and G at the same time. In this case I would like to see exactly two entries in my second level log file (and there is an entry in the first level monotone log for each changeset). Say for a moment that F is implemented with F1, F2, G is implemented with G1, G2, G3. So I have 5 entries in the current monotone log. Then I add cert F' to F1 and F2, and add cert G' to G1, G2, G3. In my second level log file, I have (in short yaml notation): F': implements feature F. G': implements feature G. and possibly also: H': planned for year (or whatever) A developer interested in features G and H can inspect/search the second level log file, finds G' and H', (can) relate this to G1, G2, G3, and he also sees that H' is not there yet. The critical point to get right, is the mapping between a feature and its cert. I think that needs a good clear clean UI. It is possible to map the changesets for F and G to separate branches. I guess the relationship with branches comes from the concept of feature-branches and cherry-picking. Then, what I was saying about the tests in the previous mail, could be as follows: My test specifications are in a separate file on my file sytem, for each test, I currently have an entry of the form: write: a command read: expected output So I simply add something like the entry: write: a command read: expected output features: - F' - G' And, in principle, I know to find the core of the code that gets tested by a particular test... in principle, that is... Also I can find the explanation of the user-visible features that the test is related to, using the second log file. Hugo -- Hugo Cornelis Ph.D. Research Imaging Center University of Texas Health Science Center at San Antonio 7703 Floyd Curl Drive San Antonio, TX 78284-6240 Phone: 210 567 8112 Fax: 210 567 8152 ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] monotone Hacking
On Tue, Sep 11, 2007 at 11:57:34AM -0500, Hugo Cornelis wrote: On 9/11/07, Nathaniel Smith [EMAIL PROTECTED] wrote: I propose that set of revisions ~ branch? It would definitely be nice to have more branch metadata. Yes, there is a relationship between them, I am not sure what you mean with ~ (what is the difference between '~' and '=' ?). ~ is like =, just more vague :-). Just some ideas: Consider (user-visible) features F and G, implemented both in branch A. Each feature can easily constituted of multiple changesets, but I assume for a moment that no single changeset is related to both F and G at the same time. In this case I would like to see exactly two entries in my second level log file (and there is an entry in the first level monotone log for each changeset). So perhaps it would be better to... implement F and G in branches F and G? That at least reduces the proliferation of mechanisms and UI for them. If you mean, rather, that F and G are two general pieces of functionality, and over a long period of time you want to consistently mark all the changes that happen to touch on that functionality, then I guess branches aren't as ideal. At the monotone level, I guess a UI for that would be something like: -- Commit message editor -- Increase flow through the frobulator to reduce blockage. Keywords: frob, nozzle -- End commit message editr -- ? -- Nathaniel -- Damn the Solar System. Bad light; planets too distant; pestered with comets; feeble contrivance; could make a better one myself. -- Lord Jeffrey ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] monotone Hacking
On 9/11/07, Richard Levitte [EMAIL PROTECTED] wrote: You're talking about two different kinds of documentations. When I update my workspace, or even better, when I'm about to, and I want to know what will happen, the most natural is to check out the log. If all the log says is that this and that function was created, this and that function was removed, this and that file was renamed to such and such, it tells me absolutely NOTHING. I'm not disagreeing with having why in the commit messages, but I want to put in a good word for including the verbose GNU-style what messages as well. When you're doing archaeology on a code base, it's really really helpful if the commit logs specifically name every file and function that the programmer *intended* to modify with that commit. It lets you grep for all changes that touched a particular thing (file, function, whatever), and it can identify accidental changes (if the diff says something was modified, but the log doesn't mention it). Also, I find writing the detailed logs to be a useful pre-commit mental exercise. I never do them while coding; I always do them by reading back over the current workspace diff just before committing. I've caught lots of errors, accidental failures to remove debugging printfs, etc. this way. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] monotone Hacking
On 11/09/2007, at 9:12 PM, Stephen Leake wrote: Richard Levitte [EMAIL PROTECTED] writes: In message [EMAIL PROTECTED] on Tue, 11 Sep 2007 12:22:43 +0200, Julio M. Merino Vidal [EMAIL PROTECTED] said: jmmv84 Using plain text messages will make one think twice before jmmv84 doing that, because he'll have to explain *why* he is jmmv84 committing that at once. I totally agree with that. There are numerous messages saying that the programmer fiddle with this and that function, created a new one, removed an old one, but NOT ONE WORD about the overall change, its intention or its reasons. Basically, that makes for crap documentation. On the other hand, that is the way we typically work. I often notice little things while I'm working on one big thing. Would it be better to _not_ fix them? Or do one commit for each little thing? Depends upon the policy of the project, but yeah commit one for each little thing is common. Commits are cheap, and if you ever have to revert a commit, having all the non-associated changes in different commits is really useful. Will:-} ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] monotone Hacking
On 10/09/2007, at 7:49 PM, Thomas Keller wrote: Hi all! I've noticed that the changelog some people use for monotone is not quite GNU-style. I'm sure you all hacked stuff longer than me, so you can correct me at any time, but aren't we forced to use some kind of GNU-style syntax to make it easier to create a ChangeLog file afterwards (for whatever distributions need that)? If not, everybody is - of course - free to use whatever format they do like. I don't like to start a bikeshed discussion here, I just want to be clear. I think it would also be a good idea to include the rules of whatever consense we find here in HACKING. I think including the rules in HACKING would be a good idea. Out of interest, who actually converts log messages directly to change logs? I would have thought that most people who distribute Monotone would find the more abstract changes described in the NEWS file more relevant. Will:-} ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
