<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 6/3/2016 9:31 AM, David Chisnall via llvm-dev wrote:<br>
<blockquote
cite="mid:64A9F2F3-9FE7-4E18-9B23-66F58DCA65E9@cl.cam.ac.uk"
type="cite">
<pre wrap="">On 3 Jun 2016, at 15:01, Aaron Ballman via llvm-dev <a class="moz-txt-link-rfc2396E" href="mailto:llvm-dev@lists.llvm.org"><llvm-dev@lists.llvm.org></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">
The end result is "go use the console". Whether that's because people
recommend it or because it's the only option is immaterial. The fact
remains, we don't have to do that today, we may have to do that
tomorrow, and some people view that as a regression. Let's not be
dismissive of that by claiming it's a personal preference, please.
</pre>
</blockquote>
<pre wrap="">
I don’t disagree, but the flip side of this argument is that git GUIs on *NIX platforms (including OS X) are far better than their svn alternatives, in part because things like committing individual parts of a set of changes independently are standard parts of a git workflow (and, in a large part, because the git CLI is a case study in poor UI design and so people have been far more motivated to write GUIs than for svn).
David
</pre>
</blockquote>
And they almost always leave out big chunks of functionality that
are important for several use cases. Basically, they figure out the
commands needed for a small set of workflows, ensure the best case
works, then stop there.<br>
<br>
Coming from a perforce and SVN background, I think this is
understandable. With perforce and SVN, you just don't have as many
options and possible workflows, so they tend to be a little easier
to learn, and a lot easier to wrap in a UI on the client side.<br>
<pre class="moz-signature" cols="72">--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
</pre>
</body>
</html>