Thus said Stephan Beal on Fri, 11 Jul 2014 00:22:52 +0200: > If that summary indeed reflects the goal, i _think_ it's just a matter > of changing the timeline query to do so. Looking at the code now, i > see that graph.c is quite a bit more than a timeline parser, though, > so maybe it's not as straightforward as changing a query.
Yes, back when I discovered Q-cards I too looked at graph.c and wondered why it didn't already handle them, but it turned out not to be so simple. Changing the timeline to include Q-cards is one thing, and I think that would be a nice-to-have, but I'm starting wonder if the Q-card As independent of what is being requested. I think the bigger goal is simply to have a way of associating one checkin with another in the timeline and that it is user alterable. Given that the Q-card is actually a reference to a SHA1 of another Manifest (it's just like the P-card except it is only specific to the named SHA1 hashes, and doesn't imply a merge of all ancestry) I don't think it makes much sense to supercede the Q-card. How could the Q-card ever be wrong? Either you typed ``fossil merge --cherrypick'' or you didn't. If you did, it will merge in just that content and include the Q-card[1]. If you didn't, then there will be no Q-card. I think, however, that a special tag that represents a relationship might make more sense and somehow this would help the UI figure out how to draw more lines. [1] It is possible to type ``fossil merge --cherrypick'' and let Fossil merge in content, but then you can remove all the merged in content, and add different content, and the Q-card will still be present. Not sure if this is a bug or simply a case of ``why would anyone ever do that?'' :-) Andy -- TAI64 timestamp: 4000000053bf2587 _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
