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

I think we should start two other threads: one about git tooling on Windows
and one about infrastructure problems migrating to git.

Some developers on Windows prefer to use GUI tools like TortoiseSVN to
command line tools for version control. The last time I tried
TortoiseGit on Windows (which was over a year ago), it did not feel
ready for production use on a complex project to me (I had crashes on
simple operations, and it seems I was not alone in seeing flaky
behavior: Windows 8 Explorer Crashing (#1738) · Issues · TortoiseGit / TortoiseGit · GitLab and
Windows 7 explorer crashes (#2494) · Issues · TortoiseGit / TortoiseGit · GitLab as examples).

Are there suitable GUI tools for git on Windows for projects as
complex as LLVM? I believe MSVC has some integration, but I've not
used it before. Perhaps other tools exist that match the integration
and stability that TortoiseSVN has with Explorer?

I bring this up as a possible minor concern because asking people to
switch from one set of command line commands to another set of command
line commands is a different beast than asking people to switch from
Explorer-integrated menus and dialogs to the command line (that's a
drastically different workflow to achieve the same end result of
source code version control).

+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.

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.
I think latter group just reads this thread and do not leave comments, just because unfamilar with git
enough to do that.

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.

+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 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.

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?

cheers,
--renato

+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 :slight_smile:

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.

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. :slight_smile:

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. :slight_smile:

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 :slight_smile:

You did. :slight_smile:

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

cheers,
-renato

+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

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.

So, we just have to make sure that we don't add any crazy workflow on Git.

That's why I like the idea of having llvm-projs as being an automated
sub-module hook-driven repo that no one uses, and let everyone else
use Git as it was intended, in a way that most GUIs can handle.

That's the workflow I'm looking for... I *really* don't want a
convoluted workflow "just because it's Git".

I'd rather use Git-SVN than have to write tons of bash scripts and
break my workflow. In that sense, we're on the exact same predicament.
GUI or not, makes no difference.

cheers,
--renato

My experience with git on windows over the last several years has been very positive. I use TortoiseGIT for the bulk of my tasks. I like the fact that I can perform most operations directly from the log window. I also use git-gui (which is part of the base git installation) to do commits on subsets of changes in a file, or a large number of separate commits in quick succession. I find that I rarely need to use the command line as tortoise git covers all the common commands, and a large number of the uncommon ones. For LLVM I have used the unofficial, and now official git mirrors for quite some time without issue (though I don’t do very much with it as I am not a regular contributor).

George Rimar via llvm-dev <llvm-dev@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.

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://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

I second that! This book is amazing. That's how I learnt git.

--renato

Quick comments about the GUI tools. LLVM repo is truly a stress test for tools with its 200000 commits. Some simple tools usually cannot handle a log view.

  • SmartGit is great and cross-platform. But is not free.
  • SourceTree was ok too, but I had to switch as it does not support Linux.
  • GitKraken looks promising, but lacks advanced features and in general a bit sluggish. I’ve just opened LLVM repo with it and log browsing is fine.
  • GitHub app is very simple (as I remember it) and not Linux support. Not sure it allows any history rewrite and that might be needed if you want to keep linear history in LLVM.