Re: [fossil-users] Tags in comment document
Thus said Philip Bennefall on Sun, 07 Sep 2014 19:39:40 +0200: However, non-propagating tags added with tag add do not show up. So even though both tags are non-propagating, one of them shows up but not the other. fossil tag modifies artifacts *AFTER* they have been created. fossil checkin --tag causes the checkin to add a tag to the new artifact's manifest. This also means that when you use fossil checkin --tag, that this tag will only ever show up once during that very checkin that you are about to commit. Try this; modify a file (test repository if needs be): fossil ci --tag newtag You see it in your editor for the commit message, right? Complete the checkin. Then modify a file and make another commit: fossil ci Do you see newtag in the comment document in your editor? Why? Andy -- TAI64 timestamp: 4000540d4831 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Tags in comment document
Thus said Andy Bradford on 08 Sep 2014 00:09:18 -0600: fossil tag modifies artifacts *AFTER* they have been created. Minor technicality... it doesn't modify the artifact per se, it generates a control file artifact that applies to the artifact. Andy -- TAI64 timestamp: 4000540d4a51 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Tags in comment document
On 9/7/2014 17:10, Will Parsons wrote: I have to admit that I *hate* to mistype a commit message and have it frozen for all time. Using an editor just seems so much easier... Fossil lets you edit commit messages. In true Fossil fashion, the old message isn't overwritten, just *overridden*, so someone can still dig up your errors, but at least they don't show up by default in the timeline any more. I'll put in my vote for always using $EDITOR, by the way. Sometimes one of my commit messages actually stretches to the point of needing paragraphs, either because the problem it fixes is particularly complex or because the solution/feature is. That brings up a Fossil nit: the timeline compresses whitespace in commit messages, so you can't see paragraph breaks without digging down into the individual checkin. I wish it would not collapse double newlines. I'm fine with it joining lines separated by only a single newline, so that my max-72-column wide commit messages fill the window width in the browser, but if I put in a double newline, fossil ui should show a paragraph break. I will say that I treat a multi-paragraph commit message as a warning sign. I ask myself if the commit message is getting long because either the checkin is overly complex, or because I don't really understand what's going on. Sometimes I can simplify or clarify the change or its checkin comment, but not always. Sometimes the act of composing such a long checkin comment clues me into a better fix, which I would never have discovered if I didn't try to thoroughly explain the whys of each change. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Tags in comment document
On Mon, Sep 8, 2014 at 10:49 AM, Warren Young war...@etr-usa.com wrote: the timeline compresses whitespace in commit messages, so you can't see paragraph breaks without digging down into the individual checkin. I wish it would not collapse double newlines. Have you tried selecting the Allow block-markup in timeline option on the Admin/Timeline page ? -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Tags in comment document
On Mon, Sep 8, 2014 at 10:49 AM, Warren Young war...@etr-usa.com wrote: Sometimes one of my commit messages actually stretches to the point of needing paragraphs, either because the problem it fixes is particularly complex or because the solution/feature is. On the problem description side, I use tickets - even for my personal projects. Doing it for work got me in to the habit. And when I don't use a ticket, I put the details in the source comments (which may be a better place, anyway, On the fix description side, I put any detail commentary in the source comments and include a reference to the ticket. Even if you are putting the details in the commit comment, they still need to be in the source comments where the fix was made. If a fix requires changes in widely separated parts of the code, I pick one place as the epicenter and have the satellites reference that (of course, the satellite comments still need and get localized details). Almost always, I can keep commit comments down a few lines ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Tags in comment document
On Mon, Sep 8, 2014 at 6:26 PM, Ron W ronw.m...@gmail.com wrote: On the fix description side, I put any detail commentary in the source comments and include a reference to the ticket. Even if you In my experience a ticket number is the longest-lasting/maintainable approach (though _all_ of my colleagues complain when i do it, i refuse to remove ticket numbers from code, and i re-add them and raise a ruckus if a fellow coder removes them during review). A ticket can be indefinitely extended with new information, which is particularly useful for big (large scope/impact) bugs/changes. It also provides the history (including political decisions) of a particular fix/RFE, and doesn't require updating the source code comments every time the specifics of the ticket change. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Tags in comment document
On 9/8/2014 08:51, Richard Hipp wrote: On Mon, Sep 8, 2014 at 10:49 AM, Warren Young war...@etr-usa.com mailto:war...@etr-usa.com wrote: I wish it would not collapse double newlines. Have you tried selecting the Allow block-markup in timeline option on the Admin/Timeline page ? Beautiful, thanks! That mostly does what I want. It didn't cope with a packed bullet list: - item 1 - item 2 - item 3 I had to put a blank line between each. I don't think I will ask you to add a Markdown option for comment formatting to fix this, however. :) ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Tags in comment document
On Mon, Sep 8, 2014 at 12:32 PM, Stephan Beal sgb...@googlemail.com wrote: In my experience a ticket number is the longest-lasting/maintainable approach (though _all_ of my colleagues complain when i do it, What don't they like about putting ticket IDs in the code comments? ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Tags in comment document
On Mon, Sep 8, 2014 at 7:14 PM, Ron W ronw.m...@gmail.com wrote: On Mon, Sep 8, 2014 at 12:32 PM, Stephan Beal sgb...@googlemail.com wrote: In my experience a ticket number is the longest-lasting/maintainable approach (though _all_ of my colleagues complain when i do it, What don't they like about putting ticket IDs in the code comments? i haven't the slightest clue, and not one of them has been able to explain it to me, despite offering them thought/role-playing experiments such as: You are venturing through some deep, dark code and come across the following runes written on the wall: /* PRT-123 */ What do you do? The answer, invariably (and correctly), is go look up that ticket number in Jira. RIGHT! But they still don't like seeing it. Seems to be just a force of habit. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Tags in comment document
On Mon, Sep 8, 2014 at 1:18 PM, Stephan Beal sgb...@googlemail.com wrote: The answer, invariably (and correctly), is go look up that ticket number in Jira. RIGHT! But they still don't like seeing it. Seems to be just a force of habit. I think perhaps your experimental subjects are expecting that to be the answer. I think a better experiment might be to find a complex change one of them made, then ask them to explain to you what they were trying to do. Or, maybe, pick a complex issue then, after you devise the real fix, devise a bizarre version of the fix - without any reference to the issue - then let them try to review that. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Tags in comment document
On Tue, Sep 9, 2014 at 12:17 AM, Ron W ronw.m...@gmail.com wrote: I think perhaps your experimental subjects are expecting that to be the answer. Very possibly. I think a better experiment might be to find a complex change one of them made, then ask them to explain to you what they were trying to do. Or, maybe, pick a complex issue then, after you devise the real fix, devise a bizarre version of the fix - without any reference to the issue - then let them try to review that. LOL! That's not a bad idea, especially if they wait until 4 weeks after the commit to review it, in which case i can answer any questions with, how should i know? That was four weeks ago! Did nobody write a ticket number in the comments? ;) -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Tags in comment document
On Sat, Sep 6, 2014 at 11:25 PM, Will Parsons varro@nodomain.invalid wrote: It's so much easier to compose the message and correct typing mistakes if one is doing it in an editor rather than on the command line. Not if one has mastered command-line editing. :) -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Tags in comment document
On Sat, Sep 6, 2014 at 8:56 PM, Philip Bennefall phi...@blastbay.com wrote: Personally I use what is called a screen reader, which enables blind and visually impaired users to use computers. When writing in a text editor such as notepad it is easier and more convenient to edit text, as opposed to doing it straight on the command line if it spans over more than a single line. Hence my preference for the editor approach; Done! It's the current trunk. All tags provided via --tag will show show up in the same area as the other tags. Regarding whether they should be labeled as tags or branches is splitting hairs, so i left that part as-is. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Tags in comment document
Thank you! That was quick. I am wondering though, whether tags added using the tag add command should also show up? For example, I did: fossil tag add testing trunk But that did not show up in the editor output. The tags I added using --tag in the commit command show up just fine now though, which is great. Kind regards, Philip Bennefall On 9/7/2014 10:52 AM, Stephan Beal wrote: On Sat, Sep 6, 2014 at 8:56 PM, Philip Bennefall phi...@blastbay.com mailto:phi...@blastbay.com wrote: Personally I use what is called a screen reader, which enables blind and visually impaired users to use computers. When writing in a text editor such as notepad it is easier and more convenient to edit text, as opposed to doing it straight on the command line if it spans over more than a single line. Hence my preference for the editor approach; Done! It's the current trunk. All tags provided via --tag will show show up in the same area as the other tags. Regarding whether they should be labeled as tags or branches is splitting hairs, so i left that part as-is. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Tags in comment document
On Sun, Sep 7, 2014 at 4:46 PM, Philip Bennefall phi...@blastbay.com wrote: Thank you! That was quick. I am wondering though, whether tags added using the tag add command should also show up? For example, I did: fossil tag add testing trunk But that did not show up in the editor output. That's a good question. i'll ponder that while awaiting opinions from others. Perhaps we should separate them into: current branch(es): ... current non-branch tag(s): ... new tag(s): (--tags flag) But the first two details can be seen by running 'fossil status' before commit. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Tags in comment document
Just to be sure I understand you correctly, is there then a conceptual difference between tags added with tag add and --tag in the commit command? I thought that they were the same, with the main difference being that tags added in the commit command never propagate. Kind regards, Philip Bennefall On 9/7/2014 4:58 PM, Stephan Beal wrote: On Sun, Sep 7, 2014 at 4:46 PM, Philip Bennefall phi...@blastbay.com mailto:phi...@blastbay.com wrote: Thank you! That was quick. I am wondering though, whether tags added using the tag add command should also show up? For example, I did: fossil tag add testing trunk But that did not show up in the editor output. That's a good question. i'll ponder that while awaiting opinions from others. Perhaps we should separate them into: current branch(es): ... current non-branch tag(s): ... new tag(s): (--tags flag) But the first two details can be seen by running 'fossil status' before commit. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Tags in comment document
Thus said Philip Bennefall on Sun, 07 Sep 2014 16:46:49 +0200: fossil tag add testing trunk But that did not show up in the editor output. The tags I added using --tag in the commit command show up just fine now though, which is great. Is that because the tag is not propagating? Try adding a tag that is propagating. Andy -- TAI64 timestamp: 4000540c7e5c ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Tags in comment document
On Sun, Sep 7, 2014 at 5:42 PM, Philip Bennefall phi...@blastbay.com wrote: Just to be sure I understand you correctly, is there then a conceptual difference between tags added with tag add and --tag in the commit command? No funcational difference. I thought that they were the same, with the main difference being that tags added in the commit command never propagate. In principle a tag added via the CLI should be able to be any of the 3 tag types: a) propagating b) non-propagating c) cancel (a.k.a. anti-tag) The only syntactic difference between the three is their initial starting character: *propagating +non-propagating -cancel However, the --tag option appears: http://fossil-scm.org/index.html/info/9c962d6971b7b92374b0159e5c3068a7bc8f8797?ln=1236 to assume that all tags passed in this way are symbolic tags[1], and will in fact do non-intuitive things if you try to use: --tag '*propagating' (with an asterisk in front to make it look like a propagating tag). IMO the '*' at the front of the name should be respected to mean this is a propagating tag, and a '-' at the front could/should be used to mean cancel the tag. Potential points for improvement at some point. [1] http://fossil-scm.org/index.html/doc/tip/www/branching.wiki -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Tags in comment document
Yes, it definitely makes sense that --tag should honor *, - and +. When it comes to the tags output in the editor document, could the tags added with tag add be included as well or are there some difficulties there? I should say that I am a relatively new Fossil user, and while I am comfortable using it I have next to no knowledge about the internals. Kind regards, Philip Bennefall On 9/7/2014 5:56 PM, Stephan Beal wrote: On Sun, Sep 7, 2014 at 5:42 PM, Philip Bennefall phi...@blastbay.com mailto:phi...@blastbay.com wrote: Just to be sure I understand you correctly, is there then a conceptual difference between tags added with tag add and --tag in the commit command? No funcational difference. I thought that they were the same, with the main difference being that tags added in the commit command never propagate. In principle a tag added via the CLI should be able to be any of the 3 tag types: a) propagating b) non-propagating c) cancel (a.k.a. anti-tag) The only syntactic difference between the three is their initial starting character: *propagating +non-propagating -cancel However, the --tag option appears: http://fossil-scm.org/index.html/info/9c962d6971b7b92374b0159e5c3068a7bc8f8797?ln=1236 to assume that all tags passed in this way are symbolic tags[1], and will in fact do non-intuitive things if you try to use: --tag '*propagating' (with an asterisk in front to make it look like a propagating tag). IMO the '*' at the front of the name should be respected to mean this is a propagating tag, and a '-' at the front could/should be used to mean cancel the tag. Potential points for improvement at some point. [1] http://fossil-scm.org/index.html/doc/tip/www/branching.wiki -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Tags in comment document
Thus said Stephan Beal on Sun, 07 Sep 2014 17:56:37 +0200: to assume that all tags passed in this way are symbolic tags[1], and will in fact do non-intuitive things if you try to use: --tag '*propagating' (with an asterisk in front to make it look like a propagating tag). IMO the '*' at the front of the name should be respected to mean this is a propagating tag, and a '-' at the front could/should be used to mean cancel the tag. Potential points for improvement at some point. Probably could use some improvement, but aren't these covered already? fossil tag add ?--raw? ?--propagate? TAGNAME CHECK-IN ?VALUE? fossil tag cancel ?--raw? TAGNAME CHECK-IN If I want propagate shouldn't I use --propagate rather than rely on knowing some implementation detail about Fossil's manifest internals? If I do: fossil tag add --propagate '*test' c43801ea69b2292c5ea31732425f69d885e38cd9 It does what I expect. It creates a propagating tag on that checkin that has a * in it's name. Even if I use --raw, I still don't have to know anything about * (but I do have to know the difference between a tag that begins with sym- and one that does not: fossil tag add --raw --propagate 'sym-*test' c43801ea69b2292c5ea31732425f69d885e38cd9 But these things I can learn by looking at a checkin and seeing the raw names of tags. I suppose I can also learn about the fact that * is used in manifests to signify propation. Andy -- TAI64 timestamp: 4000540c874f ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Tags in comment document
Thus said Stephan Beal on Sun, 07 Sep 2014 17:56:37 +0200: However, the --tag option appears: Ooh, we're talking about --tag, not ``fossil tag'' so maybe my previous comments were off the mark. Your comments were about making --tag understand things. Excuse the interference. Andy -- TAI64 timestamp: 4000540c8863 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Tags in comment document
On Sun, Sep 7, 2014 at 6:23 PM, Philip Bennefall phi...@blastbay.com wrote: Yes, it definitely makes sense that --tag should honor *, - and +. When it comes to the tags output in the editor document, could the tags added with tag add be included as well or are there some difficulties there? It's not difficult to do, just needs to be done. However, my fingers are done coding for the weekend ;). I should say that I am a relatively new Fossil user, and while I am comfortable using it I have next to no knowledge about the internals. The list of tags is something we already fetch in several places, so it's just a matter of plugging that in. As for making --tag support all three types of tags, that looks to be a more delicate/intricate fix. @Andy B.: yes, the 'tag' command can be used to do all of this, but --tag was added as a convenient way of doing it in the same step as the commit. In libfossil's tag app (f-tag), the first character can be used to set the type of tag: f-tag -t +normal -v normal-tag -t -cancel -v 'cancel this tag' -t '*propagating' -v 'propagate this tag' ... -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Tags in comment document
Thus said Stephan Beal on Sun, 07 Sep 2014 17:56:37 +0200: to assume that all tags passed in this way are symbolic tags[1], and will in fact do non-intuitive things if you try to use: --tag '*propagating' (with an asterisk in front to make it look like a propagating tag). There were not surprises here. I did: fossil ci --tag '*surprise' -m test And it created a non-propagating tag named '*surprise'. Again, I'm working off the assumption that most people won't know about *, nor would they expect * to mean anything other than * in a tag name. And given that most people won't know what * means, if they do happen to want a * they won't get any surprises. They will, however, if --tag interpreted the * to mean propagating. I suppose it isn't hard to cancel the tag and learn that * means to add a propagating symbolic tag. Now what if I want a non-symbolic tag? And I want one tag to be static and one propagating? Andy -- TAI64 timestamp: 4000540c89e6 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Tags in comment document
@Andy: Yes, you are right. If I add --propagate to the tag add command, it does show up in the output in the editor. @Stephan: I ran some tests regarding tags, and have the following results: 1. Tags added with the --tag option in commit show up as expected, and they do not propagate. 2. Tags added with tag add --propagate show up, and obviously propagate. 3. Tags added with tag add (without --propagate) do not show up. So in summary, it seems that non-propagating tags now show up in the editor output if they are added as part of the commit command but not if they are added with tag add. Kind regards, Philip Bennefall On 9/7/2014 6:31 PM, Stephan Beal wrote: On Sun, Sep 7, 2014 at 6:23 PM, Philip Bennefall phi...@blastbay.com mailto:phi...@blastbay.com wrote: Yes, it definitely makes sense that --tag should honor *, - and +. When it comes to the tags output in the editor document, could the tags added with tag add be included as well or are there some difficulties there? It's not difficult to do, just needs to be done. However, my fingers are done coding for the weekend ;). I should say that I am a relatively new Fossil user, and while I am comfortable using it I have next to no knowledge about the internals. The list of tags is something we already fetch in several places, so it's just a matter of plugging that in. As for making --tag support all three types of tags, that looks to be a more delicate/intricate fix. @Andy B.: yes, the 'tag' command can be used to do all of this, but --tag was added as a convenient way of doing it in the same step as the commit. In libfossil's tag app (f-tag), the first character can be used to set the type of tag: f-tag -t +normal -v normal-tag -t -cancel -v 'cancel this tag' -t '*propagating' -v 'propagate this tag' ... -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Tags in comment document
Thus said Philip Bennefall on Sun, 07 Sep 2014 18:40:32 +0200: So in summary, it seems that non-propagating tags now show up in the editor output if they are added as part of the commit command but not if they are added with tag add. And that is working as designed. A non-propagating tag exists only on the checkin to which it was applied. It is historical and only applies to that checkin and will never show up in your editor when committing a new checkin unless it was added again with the --tag option. It sounds like you expected --tag to create a propagating tag. At the moment, as Stephan said, there is no way to do this with --tag. There certainly is an argument that there should be, but how should it be implemented? And how much of the underlying tags implementation should it expose? For example, what if I want the tag to not be symbolic and propagating? Currently there exist a few options that add tags: --bgcolor COLOR --branch NEW-BRANCH-NAME --branchcolor COLOR --close --tag Maybe there should be a --propagating-tag option that allows a propagating symbolic tag? Or maybe a more generic --rawtag which allows me to specify all kinds of tags (similar to fossil tag)? Or maybe people who want more than a symbolic tag just use fossil tag? Andy -- TAI64 timestamp: 4000540c8f4f ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Tags in comment document
On Sun, Sep 7, 2014 at 7:00 PM, Andy Bradford amb-fos...@bradfords.org wrote: There certainly is an argument that there should be, but how should it be implemented? And how much of the underlying tags implementation should it expose? For example, what if I want the tag to not be symbolic and propagating? In libfossil i went with the easy route: if the first character is one of +/-/*, then treat it as the appropriate tag type. i cannot imagine that any sensible person would use such characters as the first character of a tag, but... stranger things have happened. Or maybe people who want more than a symbolic tag just use fossil tag? +1 to that. The ability to add them at commit-time is a bit of a bonus points feature, IMO. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Tags in comment document
On Sun, Sep 7, 2014 at 7:55 PM, Ron W ronw.m...@gmail.com wrote: It's still only a 1 line window - unless you know a trick I don't (I (and my team) try to write several lines even though we do rely on citing issues.) i just keep on typing... http://fossil.wanderinghorse.net/repos/cwal/index.cgi/info/ce97684b46927bae3090ac06b7ac09340f51005f http://fossil.wanderinghorse.net/repos/cwal/index.cgi/info/1648e371e7db611c46b0a12c4fab7bec7ca42a84 http://fossil.wanderinghorse.net/repos/cwal/index.cgi/info/af8b1fba5a5904b5b43feef5665ee71bbfbe513c i've never felt compelled to format commit messages to some management-friendly form. It takes me less time to type such a message from the CLI than it does to either (A) wait on emacs (my preferred editor) to start up or (B) fight with vi in doing the little things my fingers do intuitively in emacs. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Tags in comment document
On 7 September 2014 14:00, Stephan Beal sgb...@googlemail.com wrote: It takes me less time to type such a message from the CLI than it does to either (A) wait on emacs (my preferred editor) to start up or (B) fight with vi in doing the little things my fingers do intuitively in emacs. emacsclient ? ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Tags in comment document
emacsclient just so i can type formatted commit messages more quickly? Have simply never felt the need to use an editor for commit messages. -m... Works just fine. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Tags in comment document
Stephan Beal wrote: --===1015663013== Content-Type: multipart/alternative; boundary=f46d04388df3ee3c0605027d793b --f46d04388df3ee3c0605027d793b Content-Type: text/plain; charset=UTF-8 On Sun, Sep 7, 2014 at 7:55 PM, Ron W ronw.m...@gmail.com wrote: It's still only a 1 line window - unless you know a trick I don't (I (and my team) try to write several lines even though we do rely on citing issues.) i just keep on typing... http://fossil.wanderinghorse.net/repos/cwal/index.cgi/info/ce97684b46927bae3090ac06b7ac09340f51005f http://fossil.wanderinghorse.net/repos/cwal/index.cgi/info/1648e371e7db611c46b0a12c4fab7bec7ca42a84 http://fossil.wanderinghorse.net/repos/cwal/index.cgi/info/af8b1fba5a5904b5b43feef5665ee71bbfbe513c i've never felt compelled to format commit messages to some management-friendly form. I have to admit that I *hate* to mistype a commit message and have it frozen for all time. Using an editor just seems so much easier... It takes me less time to type such a message from the CLI than it does to either (A) wait on emacs (my preferred editor) to start up or (B) fight with vi in doing the little things my fingers do intuitively in emacs. I use Emacs too, and I don't have any problem with startup time. (Maybe I have a lighter ~/.emacs ?) -- Will ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Tags in comment document
On Fri, Sep 5, 2014 at 10:07 PM, Philip Bennefall phi...@blastbay.com wrote: whether it should really say branch rather than tags. Is this a bug, or is it really meant to be branch rather than tags? It's probably just an oversight. IIRC, the --tag option to commit was added relative recently (within the past year), and in my experience most people provide the message on the command line, so they never see that. i honestly can't remember the last time i let an scm start up an editor to type in my commit message (several years, at the very least). -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Tags in comment document
Stephan Beal wrote: It's probably just an oversight. IIRC, the --tag option to commit was added relative recently (within the past year), and in my experience most people provide the message on the command line, so they never see that. i honestly can't remember the last time i let an scm start up an editor to type in my commit message (several years, at the very least). I'm really surprised by that. I've always used an editor to type in comments, not only in Fossil, but in Bazaar and Mercurial also (and RCS, though RCS doesn't provide for using an external editor). Why wouldn't you? It's so much easier to compose the message and correct typing mistakes if one is doing it in an editor rather than on the command line. The only situation where I would pass the comment on the command line is if it part of script of some sort. -- Will ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Tags in comment document
On Sep 6, 2014 11:11 AM, Stephan Beal sgb...@googlemail.com wrote: On Fri, Sep 5, 2014 at 10:07 PM, Philip Bennefall phi...@blastbay.com wrote: whether it should really say branch rather than tags. Is this a bug, or is it really meant to be branch rather than tags? It's probably just an oversight. IIRC, the --tag option to commit was added relative recently (within the past year), and in my experience most people provide the message on the command line, so they never see that. i honestly can't remember the last time i let an scm start up an editor to type in my commit message (several years, at the very least). I do occasionally, and the rational came from an article I read on git commits. Roughly: put the briefest 80-col description on one line, next para expands on that as necessary, and longer description follows (if necessary). Our current default commit descriptions don't do anything useful with this type of formatting, but it's easy to imagine spinning up tooling that would. Facilities that used this (or similar) style of formatting would encourage more people to adopt the style, which would not be a bad thing. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
