-2

We are in the progress of migrating our old CVS server towards git but I am getting some pushback from one of the main developers that has been working with CVS for the last 30 years. I think he has some difficulties coming to grips with git. He gave me his opinion and I was wondering how I can challenge or solve some of them:

  1. "Is not possible to merge commits to different branches, for small projects I see that is working but for our project we still need to create separate branches to move the specific fixes." Context: Currently he creates a special release-branch every time we create a release (every quarter). Some customers upgrade to the new releases but a lot of them are still on older versions that receive frequent fixes. When he implements a fix in one of the older branches and wants to include this fix into other release-branches he is getting a lot of merge conflicts. I think the main problem stems from the fact that you cannot just merge branches with wildly different histories.

  2. "Creating new branches and moving fixes from specific branches, not working, in CVS you can just tag certain commits and then move those ones to the one that you want, the option doesn't exits in Git" Context: Same problem as the first one.

  3. "There is no history tree per file like in CVS (we usually check all the changes on certain files per branch) or if we want to see a list of all the files and order them per update date, the option doesn't exits in Git" Context: He apparently wants to see the evolution of a particular file in git, across different branches, not only in the current active branch.

  4. "In general it takes quite some time to commit files, comparing with CVS, we even spend more time in Git to just commit files." Context: I think this is mainly because his merges are getting a lot of conflicts.

Vincent Smit
  • 1

2 Answers2

1

I find the best way to convince someone that a new system is good is to get good at using it and then show them what you can do with it.

I seldom see arguing as a successful way to convince someone to adopt a new technology (language, OS, Source Control System, etc.)

The question "Show me how to make this new system act exactly like my old system" just means they want to keep the old system.

The question "How do I convince my colleague that git is good?" is way beyond what can be answered in a stack Exchange post, but I reiterate, "Show the advantages".

That being said, here are a couple of thoughts that might help address the specific issues you brought up.

  1. New fixes on old branches. You might find that you can use cherry-pick to get the new fixes applied to old branches without having to merge all the changes from the new branch into the old branch. Bear in mind of course that the new fixes may depend on other changes in the new branch, but that applies no matter what source control system you are using.

  2. Seems a lot like (1.). See answer for (1).

  3. History for file. The following line will show the commit history for a file.

git log -- path-to-file

If the file has been renamed along the way, the --follow option will still track it.

git log --follow -- path-to-file (NOTE: --follow has no space. the next -- has spaces around it)

If you want to see a diff of the changes made by each commit, add the -p option

git log --follow -p -- path-to-file

Note that the path-to-file is the path to the file from the top of your git repo, and also should include the filename.

The real nutshell is: People don't like things that they don't know how to use. If you and your colleague both learn all the things git has to offer you will probably become big fans.

Randy Leberknight
  • 1,363
  • 9
  • 17
0

1 - Each fix/ticket (which I assume is on a feature branch) could get backported by rebasing only the revisions related to the fix (that doesn't mean you won't get conflicts... conflicts will come up, of course, if git is not able to rebase correctly, just as expected).

2 - is it different from #1? It doesnt sound like it.

3 - What does that mean? You can do a git log --all some-random-file and you will get its history. You might even add --graph and git will even try to create a tree from the different branches (at least gitk does, so i would assume git does too).

4 - I bet git takes a lot less time to commit locally than cvs on a central server. Does cvs allow you to commit stuff when there are conflicts around?

In general I would say: git has very different workflows and it takes time to get used to it but I would be hard-pressed to find a single person who after using DVCSs decided to go back to centralized.

Welcome to SO.

eftshift0
  • 26,375
  • 3
  • 36
  • 60
  • Was just remembering how it works with CVS. Having the files work as separate entities is actually not a pro... it's a _con_ because changes to multiple files _should_ be atomic if they make up a single change.... if you modify 5 files in order to make a single change (which is what svn and git do when you create a new revision), it would be plain _wrong_ if you just move the changes from a single file. – eftshift0 May 26 '21 at 16:30
  • as a side note: Did you make him watch the presentation linus did at google like 14 years ago to talk about git? He will love it, I am sure. XD – eftshift0 May 26 '21 at 16:30
  • Thanks for the reminder about CVS making commits file-by-file in a non-atomic way. I am now remembering what a horror show it was to revert a multi-file commit in CVS. Especially if other commits had happened on top of those. At this point I would turn down a job if CVS was the only source control option. P.S. If you choose that policy for git, you will probably be unemployable... – Randy Leberknight May 26 '21 at 16:59
  • Regarding your comment/question "Does CVS allow you to commit stuff when there are conflicts around?" In a nutshell - YES. I used to work at a big company with lots of programmers and once in a while they would do a big merge, which would go into the repo, but would list lots of conflicts. Then an email would go around saying something like "This merge produced 120 conflicts, and the following 50 programmers touched code relating to these conflicts, so everybody go in and fix your conflicts." – Randy Leberknight May 26 '21 at 17:13
  • This is obviously a recipe for an intractable conflict death-spiral. I eventually left to go to a sane company. There I learned git and helped convert 100 or so programmers to git. Nobody ever looked back. – Randy Leberknight May 26 '21 at 17:13
  • Right.... and so you would just commit the files with the conflicts in, right? – eftshift0 May 26 '21 at 17:18
  • I personally did not practice commiting files with conflicts. Their process was to perform automatic merges which produced conflicts and commited them anyway, as far as I can recall. – Randy Leberknight May 26 '21 at 18:19