On Tue, Sep 01, 2009 at 05:18:40PM -0700, Junio C Hamano wrote: > The "keeping related things together" argument does mean your v1 is better > than this patch, as you had "unmerged" next to "changed but not updated". > I personally think the "keep related things together" argument makes much > more sense than the "close to the bottom is easier to cut and paste" > argument, as I tend to focus at the top of the output when looking at the > status output and almost never cut & paste using mouse (screen for > rectangular cutting and pasting works wonderfully), but it probably is > just me. And remember that I am only just one of the users, nothing more. > > Sadly, "keep related things together" and "as close to the bottom as > possible" are not quite compatible, and we can pick one or the other, but > not both. Just my two cents (and I think I have as good a track record at UI design as Junio... ;) ): I think "related things together" trumps "close to the bottom". Because the former is something that _always_ applies to your output, while the latter is catering to a particular use case and a particular screen setup. In other words, why is the _bottom_ reserved for more important things instead of the _top_? If I have a tall terminal that is long enough to see the output, are you potentially making the important thing less obvious (because I tend to read the the output from top to bottom)? If I use a pager (either manually, because I have seen that the output is too long, or automatically via the pager.status config variable)? What about reading status output into an interface wrapper like "tig status"? So while you may be helping some users, I tend to think you may be hurting others. -Peff PS I am also not entirely convinced that unmerged entries are somehow more important to call attention to in the list than other entries. But the above argues that even _if_ you think they are more important, it is still not necessarily a good thing to move them to the bottom. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html