Re: [fossil-users] Visual indication of cherrypick and backout merges
Thus said Andy Goth on Thu, 10 Jul 2014 15:14:07 -0500: Not all cherrypicks and backouts are done by [fossil merge]. Around here, lots of things are done by hand. I see what you mean. You're looking for a way to tag something as ``merged'' by copy-paste and not using merge --cherrypick and for the UI to understand this and use an arrow in the timeline to link it up. What do the Q cards accomplish for cherrypicks and backouts? First off, am I right in assuming that Q + and Q - correspond to cherrypick and backout? Okay, so does this information get used for anything? It doesn't seem to be displayed anywhere outside the manifest. As far as I know it just records the predecessor. It isn't currently used by the UI for anything, though I think it could be used to inform the arrow rendering portion of the timeline to draw associations. Tags and comments are editable, and this does not confuse Fossil. It knows not only the original tags and comments but also all edits, and it displays the accumulation of edits without losing track of the originals. So I don't see why Q cards can't be edited in the same way. I see, I think I've misunderstood your proposal. You aren't suggesting that the Q-card stored in the manifest be changed, but that it be allowed to be superceded by another manifest that has different information than the original (this is how propagating tags and edits work). That's a fair question, not one that I think I can address. :-) Andy -- TAI64 timestamp: 400053beff3d ___ 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] Visual indication of cherrypick and backout merges
On Thu, Jul 10, 2014 at 11:01 PM, Andy Bradford amb-fos...@bradfords.org wrote: I see, I think I've misunderstood your proposal. You aren't suggesting that the Q-card stored in the manifest be changed, but that it be allowed to be superceded by another manifest that has different information than the original (this is how propagating tags and edits work). That's a fair question, not one that I think I can address. :-) 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. -- - 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] Visual indication of cherrypick and backout merges
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: 400053bf2587 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
