Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I was thinking of bringing up a git service on an Ubuntu server. However, the way me and another programmer operate -- we really want to try and stick to one person working on a project at a time.

How would I make a Bash script to create a check in and check out with git? We want to prevent anyone from checking in code that hasn't already been checked in, and it should error out with the name of the person who has the code checked out.

EDIT: I'm not really interested in using Git with its fantastic diff features. I move 100mph and don't have time to play diff games with the other developers. That's why we're using Git. If the other developers want to play the diff game, they can still do so. But when I check something out, I want it locked to everyone until I check it back in again.

share|improve this question
add comment

4 Answers

up vote 4 down vote accepted

But when I check something out, I want it locked to everyone until I check it back in again.

Errr... sorry, this isn't how a DVCS (with a D as "Distributed") works at all.

a/ you don't "checkout" a file (like you would in ClearCase for instance). You just start modifying it, and Git will detect the change as a candidate for indexing (git add) and for committing (git commit, the "checking" part)

b/ When you "checkout" (i.e. modify) or checking a file, the other developers, with their associated other repos, don't know anything about that.
You "locking" everybody in that everybody can't access your repo and modify your files.

But when you publish (i.e push those changes), then you need to solve any concurrent modification. In a DVCS, there is no central referential able to detect a concurrent change and/or to record a "lock".

share|improve this answer
    
Thank you for your kind answer. See, I'm pretty new to Git. I heard that everyone likes it better than SVN or something, and I saw this Github as well and used that on a project. I think you've convinced me that I need to use SVN for my strategy. –  ServerChecker Jun 26 '11 at 4:09
1  
@ServerChecker: for a good comparison between a CVCS (like ClearCase) and Git, see stackoverflow.com/questions/645008/…. For a general difference between DVCS and CVCS, see stackoverflow.com/questions/2704996/… –  VonC Jun 26 '11 at 10:13
add comment

That's not exactly the way git was designed to work. That is, it isn't the typical git workflow. If you really want that workflow, consider using something built around that kind of workflow like SubVersion. Locked files result in notifications if someone else wants the file, but you own the file:

http://svnbook.red-bean.com/en/1.5/svn-book.html#svn.advanced.locking

I don't know if the git-svnserver gateway supports locking but it might. If it does, then you can have the best of both worlds.

Git is very flexible, however. If you want to be mean it will support that. Git lets you blindly wipe away anyone else's changes that may have occurred while you were using the file. Every time you want to push to the main repository just do:

git pull --strategy ours ; git push

No need for that merge feature.

That pair of commands will push your changes to the server ignoring any changes other people have made since your last sync.

Another option to consider is "git pull --strategy recursive -Xours".

share|improve this answer
add comment

Is communication with the other programmer an option? For a small team that's almost certainly a better way than relying on locking.

If you insist on locking, Git's distributed model is not really a good fit. Instead of Git you should probably look at using a centralised version control system, like SVN. This allows you to put a lock on files in the repository. Your fellow programmer will receive a warning when he/she tries to commit to the repo.

share|improve this answer
add comment

You really don't need this. Git and other good source control systems handle merges well enough that you don't need to lock files on checkout. Instead, make sure you both make frequent commits and regularly push your changes upstream.

As for writing a bash script to checkin and out, you could always write a bash script like anything else ... just a series of commands like you would run them on the command line, but again you don't need this. You only need one command to update your local repository, one command to commit, and one command to push upstream. It would behove you to learn git first, then consider scripting later when you find a task that is tedious to run as individual commands yourself.

share|improve this answer
    
I don't want to be stuck in 'diff' Hades. That's for the other programmers to do if they want to go there. Instead, I want this Bash script so that I use Git in this manner. –  ServerChecker Jun 25 '11 at 18:59
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.