llvm dev - Jun 2016 - Switching to git (Windows experience) (was re:[cfe-dev] GitHub anyone?)

On Fri, Jun 3, 2016 at 5:29 AM, Renato Golin via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> On 3 June 2016 at 10:03, George Rimar via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>> +1. I am also bit concerned here. Never used git, but it is fine, I am
ready to learn,
>> but now when I am using TortoiseSVN the only command line I am using is
for creating the
>> final patch (though I think that is also available in GUI).
>> And what I heard in this threads that almost all using only command
line for working with git. That
>> is really different workflow approach.
>
> This is not true. There are a lot of GUIs for git, even more so than
> for SVN. If an outdated tool like TortoiseSVN is enough for LLVM's
> purposes, I'm sure there will be some Git GUI that will be good
> enough.
I get the opposite from the responses on this thread. What I've been
taking away is that there are a lot of choices, but none of them are
particularly mature. (That's not to say none of them are plausibly
workable.) By the way, I very much appreciate all of the suggestions
people have chimed in with, so thank you for making those options
known!
> I am reading a few people using TortoiseSVN afraid of the change. I
> understand the feeling, but now we're looking for technical arguments,
> not personal ones. So, what I recommend is for people to try out other
> GUIs on LLVM's Git and see how it goes.
Breaking people's functioning workflows *is* a technical argument.
> I'm also not asking anyone to move to a console based approach, nor
> I've seen anyone doing that. What people did was to show their
> workflow, which most of it happens to be on the console. And, since
> GUIs are just wrappers to command-line tools, if it is possible on the
> command-line, it's possible that some GUI tool will be able to do it.
> And the reverse is also true, if we can't do it on console, GUIs
won't
> do it either, and we can't move to Git only.
>
> That's all there is to it.
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.
>
>
>> I guess people here can be divided on those who using/used both svn and
git and
>> familar with both. Or a minor part, but still some group that are
familar with svn only.
>
> Why do you assume that everyone should be familiar with SVN?
Because everyone currently contributing to LLVM has to be at least
passingly familiar with fetch and commit (and nothing else)?
> Using Git-SVN doesn't automatically make someone familiar with SVN, as
> much as using GitHub doesn't make you familiar with Git. You can use
> GitHub for years and have no idea how to do anything else in Git, and
> still be a perfectly good developer. That's the power of those tools.
>
>
>> I think latter group just reads this thread and do not leave comments,
just because unfamilar with git
>> enough to do that.
>
> I seriously encourage those people to step forward and try out Git
> tools, command-line and GUIs, as well as GitHub, GitLab, BitBucket, or
> anything else for that matter.
>
> The workflow will change under Git, of course it will. But that
> doesn't mean you'll be unable to work or understand what you're
doing.
>
> As a thought experiment, let's suppose we moved from SVN/Git to only
> SVN. Do you think the workflow would be identical to everybody else
> that uses Git-SVN?
>
> It's not because people use Git-SVN that they work like SVN. All Git
> users use Git-SVN because they work like Git, and only the final
> commit goes to SVN because *legacy*.
>
>
>
>> Tanya Lattner and Anton Korobeynikov wrote about some kind of survey
that can bring on top
>> the real distribution of opinions, I think this idea was good, if that
is a point of interest.
>
> They were actually being proactive in trying to understand how the
> final move decision would happen, not trying to force people to take
> decisions before all the technical issues are solved. These threads
> are not about personal opinions any more, they're about technical
> issues.
>
> As I loosely collected from the previous (opinion) thread, there were
> about 80% of the people strongly in favour, with some 10% undecided
> and 10% against. If we were *only* to take those odds, the fairest
> thing to do would be to move unconditionally to Git.
>
> But we can't ignore the technical details. All Git supporters are
> doing now, is to find a workflow that is sane under Git-only. If we
> can't find one, there's no point in moving. If we can, *then*
we'll do
> the poll.
>
> As someone said earlier, this is not about Git vs. SVN. It's about the
> current workflow vs. some future unknown one. Until we know what the
> future workflow looks like, I will personally not vote to move to
> Git-Only.
>
> Makes sense?
Makes sense to me and I very much appreciate the discussions to see if
such a migration is plausible.

Btw, if we do poll the community, I hope there's a distinction made
between "let's move to git and drop all support for svn",
"let's move
to git with a requirement for at least basic svn support", and
"let's
stick with svn".

~Aaron
>
> cheers,
> --renato
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

On 3 Jun 2016, at 15:01, Aaron Ballman via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> 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.
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

On 6/3/2016 9:31 AM, David Chisnall via llvm-dev wrote:
> On 3 Jun 2016, at 15:01, Aaron Ballman via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
>> 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.
> 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
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.

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.

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160603/efd65a4b/attachment.html>