Simplified porcelains? [LWN.net]

Simplified porcelains?

Posted Aug 6, 2008 9:52 UTC (Wed) by dpotapov (guest, #46495)
In reply to: Simplified porcelains? by epa
Parent article: Git Magic

epa wrote: "I am worried it is not suitable for stupid people."

I think you should not worry much about stupid people, at least, not as much as about close
minded ones. As practice has shown, learning basic commands is not so difficult if you were
given proper instructions as to what should be learned first.

However, if someone approaches to it with the attitude -- I want to work with Git in the exact
same way as I do with CVS then it is a problem. Git does not try to emulate CVS commands, so
the only emulation it provides is git cvsserver, which enables usual CVS clients to work with
the Git repository.

For everyday work with Git, you do not have to know many more commands than with CVS. In fact,
it may be only one or two commands more. This is because when you commit, you do that locally,
so you need to know the "git push" command to push your changes to the remote server. Thus,
roughly speaking: cvs commit = git commit -a && git push

However, the ability to commit locally is a great advantage of Git (or any other DVCS). It is
not only allow you to work offline, but it allows you to save your intermediate steps that you
may want to re-work or even completely remove later without showing anyone. With CVS or SVN,
you usually do not commit, unless you are satisfied with result of your work and run all tests
on it, as result, you commit a big patch-bomb. Git allows you to save your changes
incrementally in logical steps and rework them if necessary later; and only when you happy
with results of your work, you do "git push".

Finally, someone may ask if for most everyday work, you need to know only 5 or 6 Git commands,
why Git has about 150 commands? My answer is simple: you may need them one day, and it is nice
to have the ready solution for you. Look at it in this way: Notepad has about 5 key bindings,
but you do not use it to write your programs, do you? And your favorite editor is likely to
have by an order or two more key bindings than Notepad. Still, you don't think that Notepad is
easier to use than any more feature-rich editor, right?

(Log in to post comments)

Simplified porcelains?

Posted Aug 6, 2008 14:50 UTC (Wed) by newren (subscriber, #5160) [Link]

You can use 'eg diff' to get the direct equivalent of svn diff, if you install EasyGit (eg). Otherwise, use 'git diff HEAD'. (one caveat: 'git diff HEAD' doesn't make sense in the case of an incomplete merge, because there isn't just one last revision to compare to, but two since you are merging things together. In such a case, you'd use something else; though eg diff works just fine.)

Simplified porcelains?

Posted Aug 6, 2008 16:07 UTC (Wed) by tialaramex (subscriber, #21167) [Link]

I think there's several questions buried in there. One thing you'd probably like if you
haven't seen it already is (type it exactly as shown)

git log origin..

This asks for a log of commits between 'origin' and your present reference which is probably
the HEAD of your local repository or a branch thereof. 'origin' is the remote repository
(either set up manually following the convention, or as a result of using 'git clone')

Thus, anything on this list has been committed locally but not pushed upstream yet and it's
your responsibility to back it up or push it if you don't want to lose the changes when your
5yo nephew throws the laptop into the bird pond.

Of course you also want to look at 'git status' for reassurance that you don't have any
changes that aren't checked in locally. But after a little while using 'git' you get so used
to the speed and convenience of local commits that you use them with the same unconscious ease
that you use the "save" feature in your text editor of choice.

Simplified porcelains?

Posted Aug 6, 2008 17:10 UTC (Wed) by iabervon (subscriber, #722) [Link]

Actually, everybody uses what git calls branches in CVS (although CVS branches are something
different). If you're doing work in your local directory, and someone else makes a commit to
the central server, you don't see that change until you update; these two simultaneous
different states of the same project are what git calls branches. Git just makes this
explicit. Furthermore, everybody uses CVS's basic merging in update, and git is pretty similar
in the same situations.

The main difference between CVS and git in this regard is that CVS requires you to resolve
conflicts before committing, and git requires you to commit before resolving conflicts.
Obviously, if you sometimes fail when trying to resolve conflicts, git is nicer (because you
can get back your version and try again or try merging with only some of the changes at a time
or something).

Simplified porcelains?

Posted Aug 6, 2008 21:14 UTC (Wed) by dpotapov (guest, #46495) [Link]

epa wrote: "99% of people do not use branches in CVS or Subversion"

Of course, they don't, because it is so painful with CVS or Subversion that people go at great
length avoiding them wherever possible. But Git developers use branches not because they are
"cool features", but because their usage significantly simplifies and speeds up development.
And the speed at which Git develops is the best testament to that.


epa: "how the differences between your local directory (whether changes have been committed or
not) and some remote repository"

If you already fetch changes from that remote. Then you can run:
git diff remote-name/branch-name


epa: "With svn, you can commit something and know that it's definitely there on the server,
being backed up every night."

The difference is that with SVN, you CANNOT backup your work in progress, while Git allows you
to that easily. You can backup all your local repo on the server (or even on a few servers if
you are really paranoiac). You can do that automatically on every commit or follow whatever
backup policy you like. Git is fully distributed system and mirroring changes is not a problem
at all!


epa: "You can say 'svn status' for reassurance that you don't have any changes which are not
in a safe place."

And that is how the central CVS and SVN repositories slowly but surely are turning in mess...
Just let any developer to commit without review and proper testing, just because they feel
that they need to save their work at the end of their day, and you are going to have a lot of
mess soon.

BTW, in respectable companies like Google, there is such a thing as code review, which means
that you can wait sometimes for days (happens even for weeks!) before you can check-in...

Even without code review, the full cycle of testing and building on different platforms and
different configurations may take hours. Are you going to wait at the end of your working day
when these tests have finished?

With Git, you are going home knowing that your changes are properly backed and in testing now,
and if results are okay (and you do not have to wait for someone's else approval), you can
push changes to the official repo. (In some workflows, most developers never push to the
official repo. So just send an email to the team lead saying that you have accomplished the
task, and then the team lead will either pull those changes or get back to you saying what
s/he does not like about your changes.)

Simplified porcelains?

Posted Aug 7, 2008 14:45 UTC (Thu) by BenHutchings (subscriber, #37955) [Link]

"Is there a true equivalent of 'svn diff', that is, show the differences between your local
directory (whether changes have been committed or not) and some remote repository?"

'svn diff' doesn't touch the repository either, unless you give it URLs.

Simplified porcelains?

Posted Aug 7, 2008 21:44 UTC (Thu) by magnus (subscriber, #34778) [Link]

> How do you get that same warm fuzzy feeling with git? 

Perhaps you could use git push --dry-run to see that nothing needs to be pushed to the server.

With respect to server backups, it's worth noting that since each developer keeps a full copy
of the repository, this by itself works as a distributed backup.