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,173
  • 1
  • 11
  • 23
  • "this seems to be a safer (but annoying) " - so, in other words, Git is less annoying, but less safe? – user253751 Jun 09 '15 at 11:47
  • 4
    You're running into the very old 'locking vs. merging' debate. The advantage of 'locking' is that you can know no one else is going to mess with stuff you are changing. The disadvantage is that everyone else is hosed while you are working. And if you take a long time to do something, everyone else is stuck for that whole period. With 'merging', you hold up no one but yourself - everyone else is free to get on with their work and you'll merge when you're good and ready. – Michael Kohne Jun 09 '15 at 11:53
  • Note that the 'locking vs. merging' debate goes back at least as far as the introduction of CVS, and you might be able to find other discussions on the subject if you look around. – Michael Kohne Jun 09 '15 at 11:56
  • 4
    By default, Git does [optimistic locking](https://en.wikipedia.org/wiki/Optimistic_concurrency_control). Git will warn and block your push if the push is not a fast-forward merge. This can be disabled by adding the --force flag, if you **really** want to discard the existing branch head. – Lie Ryan Jun 09 '15 at 12:01
  • 1
    @MichaelKohne Clearcase does not prevent you working on a file someone else has locked - it just warns you, so you can liaise with the person who has it locked (ie is working on it) to minimise merge conflicts later. It does not prevent you from going ahead and making changes regardless. Take a moment to read the question's 2nd para. – gbjbaanb Jun 09 '15 at 12:23
  • @gbjbaanb - How it implements the function is irrelevant. The basic question is whether to lock files that are being worked on or merge after editing. Clearcase isn't a bad implementation of the locking paradigm, but it's still taking the locking approach. – Michael Kohne Jun 09 '15 at 12:28
  • @MichaelKohne its not. Locking is not a exclusive lock, you can [still work in parallel and merge later](http://techpubs.sgi.com/library/dynaweb_docs/0530/SGI_EndUser/books/ClrC_UG/sgi_html/ch06.html), the locking system allows you to inform others what files you are working on, not exclude them from [editing them on their own branches](http://stackoverflow.com/questions/5740826/clearcase-working-offline-hijacking-files-then-checking-out-merging) – gbjbaanb Jun 09 '15 at 12:34

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
  • 199,015
  • 33
  • 367
  • 565
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,484
  • 2
  • 20
  • 19
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
  • 146,727
  • 38
  • 279
  • 479
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
  • 42,090
  • 4
  • 59
  • 119