Re: git commit guidelines for gnulib

[Bruno Haible]

Hi Jim,

Thanks for reminding us how git works; it's indeed 8 months since I last
used it.

Three questions though:

I) About merge commits.

> However, I have one strong preference that I haven't yet mentioned:
> =====================================
> Be careful not to push merge commits.
> =====================================
> 
> What that means is when using git, we should see a single string of
> change sets on the trunk, just as we did in CVS.  Each "commit" should
> have exactly one predecessor and one successor.
> 
> How can that go wrong?
> If you update (pull/fetch/whatever), make a change,
> and commit (locally), but don't push right away...
> Then, someone else makes a change, commits, and pushes theirs.
> After that, you pull (using cvs model), and that induces a merge,
> but there were no conflicts, so you then push the result.
> However, if you look at the resulting graph with e.g., gitk, you'll see
> that the change set before yours now has two successors:
> 
>        Next
>        / \
>   other   yours
>        \ /
>        Prev
> 
> That's unnecessary and ugly.

Why do you consider this "unnecessary" and "ugly"? I thought that this non-
linear merge situation was one of the situations that distinguish a
distributed version control system from a centralized version control system.

When I make a change to my tree, commit it locally to distinguish it from
subsequent changes, and then, after a week of testing with other changes,
decide to commit it into "master", isn't such a "merge commit"/diamond commit
unavoidable? If not, what is the procedure that you recommend when I want
to make some changes that work like this:
  - change 1
  - change 2
  - fix to change 1
  - fix to change 2
  - change 3
  - another fix to change 1
  - now commit change1 with its two fixes ?

When I work with other people in a versioning system, I have only two
requirements:

  1) People should try to proofread and test their changes before committing.

  2) When something doesn't work, it should be clear who is to blame.

Ad 1): we should encourage testing before commit. I have the feeling that
the wish to avoid diamond commits creates a race to commit as soon as
possible. And as I know from earlier experience, the habit to commit
without testing or even without thinking leads to bad quality.

Ad 2): Isn't is clear, even in a diamond commit, who is the latest committer?
Namely, the one who did the diamond commit. Or are the records missing in this
case, preventing clear determination of responsibility?

II) What's the recommended way to make short-lived changes? Is a developer
    forced to create a topic branch just for creating a typo in a comment?

III) git-checkout.
>    ################################################################
>    # A word of caution:
>    # Changing from one branch to another is so easy, quick, and
>    # quiet (especially if you're used to CVS or svn) that it's easy
>    # to forget that a simple "git-checkout master" or "git-checkout BR"
>    # can make massive changes to your working directory -- it all
>    # depends solely on how many files differ between your BR and
>    # the trunk.

I would like to avoid using "git checkout" to switch from one branch to
another in the same directory. Simply, I'm more comfortable working in
different directories. I assume it makes it easier to remember what is where,
and to avoid doing mistakes. Right now, I use 5 checkouts of gnulib:
  gnulib-cvs
  gnulib-work
  gnulib-unistring
  gnulib-modified
  gnulib-manytests
and more on demand. But I obviously don't want to have 5 copies of the large
git repository, only 5 checkouts. I heard somewhere that it would work to
make symbolic links
  gnulib-xxx/.git -> gnulib-cvs/.git
But this is probably wrong: The .git/HEAD file must *not* be symlinked.
- What other files must not be symlinked?
- Does someone have a tutorial how to work with git in this setting?

Bruno