Re: git methodology

[Bruno Haible]

Paul Eggert wrote:
> > Then the two "git stash" commands were unnecessary; all that's needed is
> >
> >       $ git pull
> >       # fix conflicts then  "git commit"  of the merged files
> 
> I vaguely recall that when I've done that in the past, I installed
> unnecessary gunk into the savannah repositories.  I never had time to
> track it down.

That happens if you have already done "git commit" and in the meantime someone
else has pushed another commit. In this situation, git will tell you upon
"git push" that it cannot push because the top of the 'master' branch is
different in your repository and in the remote one. In this situation,
you can either use "git rebase master" (this is a bit complex) or create
a fresh git repository, copy your modifications to there and commit&push
them there, then throw away the git repository that contains the conflict
(this is conceptually more simple, but only applicable if the repo has no
other interesting stuff).

When someone else committed and pushed something, but you did not do a
"git commit" so far, the
  $ git stash
  $ git pull
  $ git stash apply
  # Fix conflicts then go "git add" of the merged files.
sequence is the simplest way to merge.

> Anyway, thanks for the tutorial on how you use git.

Here is something more complete:


Simple Use of Git without Branches
==================================

This is a way to use Git for people who do not like to remember many
commands, and who prefer modified state to lie explicitly around in the
file system rather than to be hidden in branches. It's also quite similar
to the way one works with CVS. While the basic concept in Git in general
is the commit (= formally approved patch), here the basic entity is the
modified file (as in CVS).

You will have several git repositories locally, each for a distinct
development topic. In one git repository, you may overhaul the documentation.
In another git repository, you may introduce new facilities for I/O. In
another git repository, you may accumulate all the minor changes that you
wanted to submit but never had time to, etc.

So, when starting a new topic, while advanced Git users create a branch,
you will create a new repository. For this purpose, you can have a
"gnulib-clean" reposity that only ever contains unmodified gnulib; copying
this repository (with "cp -a") is faster than doing a "gnulib clone" across
the network.

You use "git status" frequently to check the status of your work.

The normal way to update from the central gnulib repository is
  - if "git status" tells you that you have no modifications, just do
      $ git pull
  - otherwise, do
      $ git stash
      $ git pull
      $ git stash apply
    Here, if you have conflicts, resolve them and do "git add" of the
    resolved files.

The normal way to publish a change is:
  1. do a "git diff" to review the patch; at the same time, write the
     ChangeLog entry into a scratch editor buffer.
When you are done with that,
  2. Pull, as explained above.
  3. Copy the ChangeLog entry into the ChangeLog file.
  4. git commit <modified files> ChangeLog
  5. git push

Normally the time window left for other people's commits to interfere with
yours is minimized by this technique. If it still happens, i.e. if "git push"
tells you that it cannot push because the master branch is different in the
remote repository, then the following is in order:
  $ git stash
  $ git rebase master
  # fix conflicts with your commits, then do "git commit -i <merged-files>"
  $ git stash apply

I remember one day when you, Eric, Ralf, and I were all committing at the same
time; I had to go through this procedure 3 times until my "git push" was
accepted.

When working with several changes in parallel, you can avoid different
repositories if only separate file sets are affected. You leave all files
modified until you decide about the topic of the next commit. Then you
collect the list of modified files ("git status" and "git diff" are your
friends here), and do the commit.

While working with a larger change that affects many files, after proofreading
some changes, you can use
  $ git add <modified-files>
to say "these modified files are ok". This allows you to concentrate on the
other modifications that are not yet done or not yet proofread. The command
  $ git diff
will then omit the files marked with "git add". You can use the command
  $ git diff --cached
to view these changes. When you are ready to commit, you can do
  $ git commit <modified-files>
as you learned before; but you can also do
  $ git commit
to commit the changes that you marked as proofread before (i.e. those that
you see through "git diff --cached").


OK, Paul, I hope this gets you more confident about using git with the old
CVS like methodology.

Bruno