please avoid "merge" commits!!

[Matthias Welwarsky-2]

Hello,

99f28d0 Merge branches 'master' and 'master' of git://anongit.kde.org/digikam

and

2ea3bd8 Merge branch 'master' of git://anongit.kde.org/digikam

Please avoid that. The history becomes unreadable and if you merge a feature
branch with a lot of commits it becomes very difficult to find regressions
with git bisect, because it cannot descent into the branch that was merged.

Therefore:
- always use "git pull --rebase" when you update from origin,
- if you accitendally forgot, use "git rebase origin/<branchname>" before "git
push origin <branchname>" to clean up.

regards,
matthias

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Francesco Riosa]

In data venerdì 17 febbraio 2012 21:56:03, Matthias Welwarsky ha scritto:

> Hello,
>
> 99f28d0 Merge branches 'master' and 'master' of
> git://anongit.kde.org/digikam
>
> and
>
> 2ea3bd8 Merge branch 'master' of git://anongit.kde.org/digikam
>
> Please avoid that. The history becomes unreadable and if you merge a
> feature branch with a lot of commits it becomes very difficult to find
> regressions with git bisect, because it cannot descent into the branch
> that was merged.
>
> Therefore:
> - always use "git pull --rebase" when you update from origin,
> - if you accitendally forgot, use "git rebase origin/<branchname>" before
> "git push origin <branchname>" to clean up.
>
> regards,
> matthias

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]

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 [hidden email]:digikam sql/2.0
git pull -a
git status


[1]
       --rebase
           Rebase the current branch on top of the upstream branch after
fetching. If there is a remote-tracking branch corresponding to the
           upstream branch and the upstream branch was rebased since last
fetched, the rebase uses that information to avoid rebasing
           non-local changes.

           See branch.<name>.rebase and branch.autosetuprebase in git-
config(1) if you want to make git pull always use --rebase instead of
           merging.

               Note
               This is a potentially dangerous mode of operation. It rewrites
history, which does not bode well when you published that
               history already. Do not use this option unless you have read
git-rebase(1) carefully.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Matthias Welwarsky-2]

Hi,

despite the warning in the manual page regarding the --rebase option, the
standard flow when working with git should be as follows:

First check out the remote branch you want to base your work on:
 
$ git checkout -t <remote>/<branch>
 
the local branch will be called <branch> and it is set up to track the remote
branch of the same name

Then, develop, add new files, etc.

After you have changes ready to push to the remote, commit them in your local
branch. Either commit everything, or commit only the files you think are ready
for publishing and "stash" the rest:

$ git commit ...
[maybe] $ git stash

I can only encourage everybody to use "git gui" to commit, you can see the
changes you will commit and it also allows you to only commit parts of files,
single hunks, or even single lines. This allows to create meaningful commits
with clear to understand commit message explaining exactly what the change
does.

Then, update from the remote branch:

$ git pull --rebase

This command will reset your local branch to the head of the remote branch
(after fetching all updates) and then replay all the changes that you have
commited in your local branch on top of it. If there are conflicts you need to
fix them, just like you would with svn or cvs. This fixing of merge conflicts
are done inside a "rebase" bracket, so the workflow is: fix conflict, "git
add" the fixed files, then "git rebase --continue". Repeat until all you
patches are correctly replayed. Again, use "git gui" to make your life easier.

Finally, push the changes to the remote server.

$ git push <remote> <branch>

Since you have rebased your patches on top of the remote branch before, it
will go smoothly, unless of course somebody else has pushed something to the
remote branch before you, in which case your push will fail again. In that
case, go back to the "git pull --rebase" step.

Once you have successfully pushed your changes, continue to develop, add new
files, etc.

If you have only committed part of your work and used "git stash" to stash
away the remaining changes, you will definitely want to have these changes
back in your workspace. Do this with the following command:

$ git stash pop

This will merge the stashed changes back into your workspace. Merge conflicts
may happen here, because maybe a change in the remote branch has affected
files that you changed yourself. In that case you need of course to resolve
these conflicts, too.

As a final hint: become familiar with "git rebase". Especially with "git
rebase -i" which is a very, very powerful tool to clean up your local changes
before you push them to the remote branch. It allows to fix commit messages,
reorder patches or even merge them together. A rebase also allows you to "fix"
merge commits that you have accidentially created by forgetting the "--rebase"
option to git pull. Just try a "git rebase -i <remote>/<branch>" before you
push, you will understand what it does.

best regards,
matthias


On Friday 17 February 2012 23:59:33 Francesco R. wrote:

> 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]
>
> 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 [hidden email]:digikam sql/2.0
> git pull -a
> git status
>
>
> [1]
>        --rebase
>            Rebase the current branch on top of the upstream branch after
> fetching. If there is a remote-tracking branch corresponding to the
>            upstream branch and the upstream branch was rebased since last
> fetched, the rebase uses that information to avoid rebasing
>            non-local changes.
>
>            See branch.<name>.rebase and branch.autosetuprebase in git-
> config(1) if you want to make git pull always use --rebase instead of
>            merging.
>
>                Note
>                This is a potentially dangerous mode of operation. It
> rewrites history, which does not bode well when you published that
>                history already. Do not use this option unless you have read
> git-rebase(1) carefully.

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[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 [hidden email]: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
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel