[Digikam-devel] please avoid "merge" commits!!

[Marcel Wiesweg]

> ack, I've done a change at the same time of someone else and git refused to
> push, so I've done a `git pull -a` `git commit` `git push` cicle, the first
> pull should hve be done with --rebase right? The man page of git pull is a
> bit worrying tough [1]

It is simple, never use "git pull", always use "git pull --rebase".
I have an alias "up = pull --rebase" so I type "git up" as in old SVN days, 
and am not tempted to create mess with a simple pull.


> while we are at it, I'm currently using the following cicle to merge the
> changes to the branch (sql/2.0) I use as a testbed, do you have better
> suggestion for this as well?
> 
> git pull -a
> git merge origin/master
> git push git at git.kde.org:digikam sql/2.0
> git pull -a
> git status

Reading the word "testbed": I assume you are confident that the branch needs 
to be public, i.e., you do development in this branch which will at some time 
become foundation for code in master.

With a local branch, you would simply rebase on current master which creates a 
100% clean history. With a public branch, we should not rewrite history.
Assuming your branch was for private use to you, which it probably is, 
rebasing would be an option, I'm not 100% sure it's allowed for branches by 
sysadmins now.

For a normal public branch though, we indeed need merge commits, what you gave 
should work.

Personally, I would have a separate working directory with the git-new-workdir 
script, then go to my main directory where master is checked out:
git up
Then go to the workdir of the feature branch:
git up
git merge master
git commit -a
merging when I need changes from master, otherwise not more than weekly.

Note: I have probably some options tuned for this to work conveniently, such 
as "push.default tracking".

Marcel