6

I try to convince my coworkers to leave svn and switch to git. One problem I see coming is: It's complicated and error-prone to have to do git commit and git push separately. So I was thinking about a git ci alias, which commits the changes and pushes it right to the server. I know, how to do that, but:

The problem is, that I want to give arguments like -m "" to git commit. So

git ci -m "Cool change"

should execute

git commit -m "Cool change" && git push

How can I do so?

iGEL
  • 16,540
  • 11
  • 60
  • 74
  • 2
    Cudos for trying to convince your co-workers to take the git route. I do wonder why they'd want to avoid commiting and pushing seperately. What makes you think it's error prone or complicated to do these tasks seperately? Do you really want every commit to be a push also? – Jamie Dixon Jun 28 '11 at 11:22
  • 1
    I agree with Jamie. Being able to commit locally gives a huge liberty in terms of how to organize your work, and in what granularity to commit. You can do many small commits so that each change is recorded and can be reverted, but if they don't make sense to the community separately, you can push them all when they are all finished. – rafalotufo Jun 28 '11 at 11:30
  • plus you are insulated from pesky things like network bandwith or - indeed - availability – sehe Jun 28 '11 at 12:11
  • I love to commit often and to push once. But it's hard to leave a learned workflow, so it should as easy as possible for the start. Also I have to convince our manager, and he wants to have everything committed by the end of the day. They would be free to use git commit and push even with may alias. – iGEL Jun 28 '11 at 13:08
  • I know, it's not very git-like, but you can't change everything at the same time. – iGEL Jun 28 '11 at 13:22
  • 2
    You are doing yourself and your co-workers a disservice by continuing to use git in a svn-style manner. My advice to you is to grab the bull by its horns and teach your co-workers the difference. Otherwise they will never learn git and stay in the comfortable svn zone for all eternity. – rtn Jun 28 '11 at 14:18

2 Answers2

0

For the general problem of adding arguments to one of multiple commands as an alias, the git alias works almost exactly like a normal *nix alias. The only difference it that unless the git alias starts with ! it's assumed that git should be prepended to the command. Any arguments used in combination with an alias is prepended, to insert an argument into a loger string of commands you need some kind of shell command for parsing the arguments. See for instance this question for arguments.

But for this question in particular. I agree with the others that this is a useful thing to do. If you're going to push immediately after committing, I assume each user have their own public private repo (readonly for others) so that the push will "never" fail, which means it works very different from svn anyway; they must pull from different repos etc.

If you're instead are using one public "master repo" that everyone pulls and pushes to, this would be a even worse idea, since when the push inevitably will fail sometime, they are trained not to use "commit" then "push" but use your "ci" alias to commit and push changes; When they try to "re-commit" the changes the second part will not run because the first command does not finish with success status (but prints no changes added to commit (use "git add" and/or "git commit -a") instead).

Community
  • 1
  • 1
Stein G. Strindhaug
  • 5,077
  • 2
  • 28
  • 41
0

you can "hide" git much like the "git achievement" project does. This will enable you to add scripts that look like git commands. Your basic flow should be:

git pull --rebase

so that history is linear like what they are used to in SVN's update. But you must tell them that they may need to get rid of conflicts and tell them about or alias git add -A && git rebase --continue. I suggest turning on rerere and sharing those resolutions across the team with a script attached to the "alias" you're going to make for this.

Next, hide commit with something like this:

git add -A
git commit -m "message"
git pull --rebase
git push origin <current branch> # or set up tracking and omit the last 2 args

These should fail gracefully on conflicts as well.

here is the link to git achievements:

http://benjamin-meyer.blogspot.com/2010/03/git-achievements.html

Although I think this is not helping them in the long run, I hope this helps for now.

Adam Dymitruk
  • 124,556
  • 26
  • 146
  • 141