5

I'm trying to convince colleagues about using Git, and somehow it's hard to explain the advantage of doing a pull before a push, because just before pushing, some other developer has pushed his changes to the server and by the time I pull his changes and merge it, some other developer would've pushed his changes and I'm supposed to merge those too before I can push my changes. Loop infinitely.

In Clearcase, you can lock a file you're working on, so that nobody else can modify it. If they want to modify it, they have to 'hijack' it on their local machine and later merge it. Somehow, this seems to be a safer (but annoying) way of working with the files.

So how exactly is Git's approach an advantage?

Nav
  • 1,191

4 Answers4

5

Pick your choice - do you prefer always getting a warning when there might be a potential conflict in the near future since two people are going to edit the same file (Clearcase)? Or do you prefer to get a warning when the VCS detects there is an actual conflict since the two people edited the same source code lines, or lines very near to each other (Git)?

The first model produces some false positives from time to time, which can be annoying. At a first glance, the second model seems to have a higher risk to introduce bugs. That is because when a merge is formally successful and you get no warning, there is a certain risk of having a "semantic" conflict, only revealed by tests. However, to my experience, in reality the latter is neglectable - I cannot remember ever to have encountered such a situation in the last 10 years. Moreover, the first model has indeed the same risk, since just because you get a warning about a simultaneous edit beforehand does not automatically ensure the two developers will inspect their merge results afterwards more carefully.

Doc Brown
  • 218,378
4

First of all, Git is a decentralized VCS (as opposed to ClearCase, which is very centralized: see "What are the basic clearcase concepts every developer should know?")

That means, there is no central server to keep track of a "locked" file.

Secondly, you generally don't just pull, but you pull --rebase with autostash in order to replay your local (not yet pushed) modification on top of whatever concurrent modifications were published (pushed).

This is the natural workflow to allow concurrent collaboration.
Note that ClearCase allows for concurrent modifications as well, at least in snapshot views (but you cannot easily tell which hijacked file was modified).

Finally, there isn't much going for the old (1985) ClearCase model (See "ClearCase advantages/disadvantages"). Using it in 2015 is an anachronism, as it doesn't scale well with large number of files, unless you are using dynamic views, and even then, any merge is dreadfully slow.
If you have to go on using an IBM tool, consider at least RTC (Rational Team Concert). It does have a locking mechanism.

Community
  • 1
VonC
  • 2,504
2

In one case the person who locks first wins. In the other case the person who is ready to push first wins. Most of the time, the person you want to have precedence is the one who is ready to push. If I have a week left on my new feature, and you are done fixing a bug for today's release, you should have priority on checking in.

This leads to a lot of walking around getting other people to release their non-urgent locks so you can check in your urgent change. Some people like this because it "forces a conversation," but it really doesn't. Those annoying people who make significant changes without communicating properly can still make those changes on hijacked copies and wait for those files to get unlocked. Mostly you end up annoying people for the same end result: whoever is ready to check in first does so, and forces people who check in later to merge.

Karl Bielefeldt
  • 148,830
1

You have changes to commit, but they are based on an old version. That's no good. In any source control system, you can rebase your changes so that they are now based on the current version. That's not automatic, it is work, there might be conflicts, but it's all unavoidable. So far, everything's the same.

But because the process of rebasing and retesting your change took time, by the time you are done you might again have changes based on an old version. Usually this is just bad luck (you rebased your code to include Joe's changes, and just then Jim had to check in his last month's work). With a bigger team, and people sometimes working on the same files, this can be a problem.

With git, your choices are: Either be quick, or ask other developers not to commit anything until you are done. With other systems, you can lock files, so other developers cannot commit, which is really the same, except you don't walk to their desk, and they cannot say no. There isn't really much difference in practice, assuming you are not locking files and then keep them locked for ages. I'd always do a first rebase without telling anyone, to avoid bothering everyone else too much.

gnasher729
  • 49,096