that's not actually what rebase is doing. Rebase is rewriting the commit
history so it looks nice. It doesn't have anything to do with keeping
changes merged
You right, "Rebase is rewriting the commit history so it looks nice" and so,
if you have a local merged commit, it will be erased [1] by this operation.
Okay, although honestly, that seems a little bit like running before we
walk. All we are saving is, at most an extra commit to indicate the merge
and forcing people to understand rebase. Understand what I mean?
If conflicts occurs, the only way to not create an useless extra commit in
more than the merge commit, it to use the command set "pull --rebase" +
"git merge --no-ff" + "push" [2], if for some reasons, the committer has to
wait between the merge and the push and that the reason why I added this one
step, it can successfully update/resolve conficts using "git rebase -p" and
then push [3].
Okay, although honestly, that seems a little bit like running before we
walk. All we are saving is, at most an extra commit to indicate the merge
and forcing people to understand rebase. Understand what I mean?
As I said before, at least at the beginning, I wouldn't like committers new
in git have a chance to run into problems and in the same time I wouldn't
like they have to think to much about what should he use in that situation,
that's the reason why I created this workflow and for sure if there is a
better way to achieve this, amen.
-Fred
[1]
Clone 1:
1- I checkout a new branch test1
2- I created a file test1.txt
3- I add/commit test1.txt
4- I checkout master
5- I merged --no-ff test1
Clone 2:
1- I created a file file1.txt
2- I add/commit file1.txt
3- git push
Clone 1:
1- I pull --rebase
[2]
Clone 1:
1- I checkout a new branch test1
2- echo "file1 edited by clone 1" > file1.txt
2- I created a file test1.txt
3- I add/commit test1.txt
Clone 2:
1- echo "file1 edited by clone 2" > file1.txt
2- I add/commit file1.txt
3- I push
Clone 1:
1- git pull --rebase
2- resole the conflicts creating an extra commit that's going to be included
in the same dev line than the all dev.
5- I checkout master
6- git push
[3]
Clone 1:
1- I checkout a new branch test1
2- echo "file1 edited by clone 1" > file1.txt
2- I created a file test1.txt
3- I add/commit test1.txt
5- I checkout master
6- I merged --no-ff test1
Clone 2:
1- echo "file1 edited by clone 2" > file1.txt
2- I add/commit file1.txt
3- I push
Clone 1:
1- git pull --rebase
2- resole the conflicts creating an extra commit in more than the one of the
merged commit.
3- git push
-----Message d'origine-----
From: Michael A. Labriola
Sent: Sunday, March 24, 2013 12:14 AM
To: [email protected]
Subject: RE: [Git/Wiki] please review the proposed workflow and comment
First of all, I use pull with the rebasing option to keep my work on top of
what the others already pushed until there's no issues for my local merges.
that's not actually what rebase is doing. Rebase is rewriting the commit
history so it looks nice. It doesn't have anything to do with keeping
changes merged
Yes, it might have been an option but I preferred to rebase to make people
to get the habit of getting the others' commits before starting a working
session, making the eventual conflicts resolved first.
That was my point too... I am just saying that's not really what rebase is
doing
How would you have write it so ?
I will write up something and post
I generaly do a "pull --rebase" + "git merge --no-ff" + "push" in the same
stream to avoid "git rebase -p", which, in case of conflict would make me
create an extra commit in more than the merge commit for the >same
feature/bugfix, with "rebasing first" solution, I can resolve the conflict,
rebase again and then have a merge up to date relative to the main stream.
Okay, although honestly, that seems a little bit like running before we
walk. All we are saving is, at most an extra commit to indicate the merge
and forcing people to understand rebase. Understand what I mean?
