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
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:
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*,
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
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,
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
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 ?
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?
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
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
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
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
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
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,
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.
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
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
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
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
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
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
--
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?
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).
@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.
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
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
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...
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
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
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
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
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
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
33 matches
Mail list logo
