Jean-Christophe PLAGNIOL-VILLARD wrote:
> When you rebase you do not known against which commit the current
> pull request was tested
I think there may be a little bit of confusion.
As I understood it, Øyvind asked which of the following two flows we
should use:
a. "rebase"
1. developer makes a branch locally
2. git commit locally
3. does git pull --rebase to ensure the local changes apply cleanly
on top of public master
4. git send-email
5. maintainer does git pull, which will always be a fast-forward
merge, no matter if git pull is used with or without --rebase is
used, because the developer has already done a rebase in (3) onto
the latest commit
b. "merge"
identical to above, except that (3) is skipped.
Flow a. will generate a single linear history in the main repo. Flow
b. will create a merge commit whenever a merge is not fast-forward,
ie. when commits have been made in the public repo after the branch
was created in (1).
Flow a. loses information about where the branch was created, but
results in a simple linear history.
Flow b. keeps information about where the branch was created, but
results in merge commits.
> If a pul conflit we try to resolve it but if it's too complex at that
> time we ask the one that send the pull request to rebase it's patches
> against the current tree
I think it's very reasonable to require any pull request to apply
cleanly to current tree.
//Peter
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
