On Thu, 23 Oct, Andy Bradford wrote: > I could be wrong, but is it possible that what he's asking for > is a consistency in a fixed output width when %S is being used > in the timeline? Or an option to have fixed width UUIDs in > the timeline? Consider the timeline output here where you > have a nicely fixed width column of UUIDs and then suddenly to > break the flow there is [84871722547960b] in the middle. I can > imaging it getting pretty messy if there are a lot of varying widths > of UUIDs in the output.
Yes, almost. ;-) I'm not interested in interactive usage of fossil. We are using fossil in a completely automated scenario to track and retrieve generated files over time. So, my concern is compatibility and consistency of command line switches and their output. When we have to store the commit UUIDs of files (timeline -showfiles/-v) it just feels weird to store different length UUIDs. But now, calculating the longest UUID in a specific timeline output and then adjusting the length of the shorter UUIDs to be the same length would be even worse in my scenario as then the same commit may show up with different length UUIDs depending on the timeline itself. So, please don't do that. :-) What I propose is a consistent and reliable output which doesn't change when using the same switches specified. I can live with the current state, however it does not "feel" right for automated usage. -- Stefan Bellon _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
