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

>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 hope so. At this moment I see that TortoiseSVN is like a standart,
and looks like there is no standart GUI for git, what makes me think about
possible
troubles people can face because of low quality of such tools.
Possible low quality I mean, I did not try to use any yet, so I have nothing
more that conserns here.
>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.
>
>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.
>
>
>> 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?
>
>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.
Ok, what I wanted to say here that it is hard to discuss something with
you're not familar.
Like for me to discuss git here. So if there is a discussion about moving to
git, I assume that
people who involved should be familar with both when voting for something.
I think it is not ok to vote just because "I am using it and it is ok for
me".
>> 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.
>
That probably worth to try. My concerns mostly about mandatory of that,
when looks it just possible that soon I`ll have no other choise.
>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.
That were people who was directly involved in this discussion. Probably there
are lots
of other opinions. Probably not.
>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.
It sound like you're trying to find something that is not possible with svn
just to justify
that git is a must. I hope I understood that wrong :)
>
>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?
>
>cheers,
>--renato
Anyways what I need to add that I am not familar with git and so all above just
my conserns.
Hope that possible new workflow you're talking can will be OK for everyone.

George.

On 3 June 2016 at 13:31, George Rimar <grimar at accesssoftek.com>
wrote:
> I hope so. At this moment I see that TortoiseSVN is like a standard,
> and looks like there is no standart GUI for git, what makes me think about
possible
> troubles people can face because of low quality of such tools.
This is true, but in a weird way. :)

TortoiseSVN is the remaining tool from an old era. I've used it
before, as I also used other low quality alternatives. Tortoise is the
only one that survived and no is doing SVN interfaces any more, so it
becomes a standard by default. While I remember to like it, it wasn't
the standard back then, so now I can't say that it's current status is
solely on merit.

Whereas there are lots of interfaces for Git, most of them rubbish
(I've tried them in a way to encourage my son to use Git, he ended up
using the console).

GitHub is one of the solutions that stands out, and that's mostly
based on merit. It's not perfect, but it's been ahead of the
competition for a while now.

> Ok, what I wanted to say here that it is hard to discuss something with
you're not familar.
> Like for me to discuss git here. So if there is a discussion about moving
to git, I assume that
> people who involved should be familar with both when voting for something.
> I think it is not ok to vote just because "I am using it and it is ok
for me".
If we do the vote too early, it can only be based on unfounded opinions.

> That probably worth to try. My concerns mostly about mandatory of that,
> when looks it just possible that soon I`ll have no other choise.
I honestly think you should, regardless of LLVM. :)

> It sound like you're trying to find something that is not possible with
svn just to justify
> that git is a must. I hope I understood that wrong :)
You did. :)

The original email (and many subsequent ones) were clear: this is a
cost saving move. And the savings are huge.

cheers,
-renato

George Rimar via llvm-dev <llvm-dev at lists.llvm.org> writes:
>>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.
>
> Ok, what I wanted to say here that it is hard to discuss something with
you're not familar.
> Like for me to discuss git here. So if there is a discussion about moving
to git, I assume that
> people who involved should be familar with both when voting for something.
> I think it is not ok to vote just because "I am using it and it is ok
for me".
Atlassian has some pretty good documentation about workflows here.  I
encourage perusal.  While git is the technology used for exposition,
they could map pretty well to most other DVCSs and the Centralized
workflow is what SVN supports.

https://www.atlassian.com/git/tutorials/comparing-workflows/

We use a modified gitflow workflow that handles multiple active release
branches.

I also highly, highly, highly recommend reading Scott Chacon's
_Pro_Git_.  It's very well written, easy to understand and provides a
lot of insight.  And it's free online!

https://progit.org/
https://git-scm.com/book/en/v2/

I really can't recommend this enough.  This is the book that helped me
understand git in a very deep way.  It's pragmatic and unlike most other
git tutorials it starts with practical work scenarios, not with the gory
details of git's data model.  The data model is extremely cool but you
don't need to be an expert on it to use git effectively.

Buy the book and support good documentation!

                           -David

On 3 June 2016 at 19:06,  <dag at cray.com> wrote:
> https://progit.org/
> https://git-scm.com/book/en/v2/
I second that! This book is amazing. That's how I learnt git.

--renato