Fred,
As the Gitflow model this project agreed to follow says to always (and
only) work on feature branches, we will never work directly on the
(local) develop branch... Does this mean that the only case where
'rebase' might cause an irreversible problem doesn't exist for us? I
think it does, but stating this explicitly here and on the wiki will
take away much of the trouble people seem to be having with the
suggested workflow.
EdB
On Fri, Mar 22, 2013 at 10:48 AM, Frédéric THOMAS
<webdoubl...@hotmail.com> wrote:
>> Rebasing is the operation to get the others work rewriting YOUR commits on
>> top of them, it means you will never rewrite their history.
>
>
> That deserves a better explanation, actually, visually, it doesn't look like
> to be rewritten but it is, and in the natural historical order.
> Note, everything already pushed will be the exact same as it is on the
> remote repo and your work will be re-writen on top, so the only risks is if
> YOU have an unpushed merge, in this case YOUR merge will be flaten but if
> you follow the guideline I explained in the previous post, it will never
> happen.
>
> Thanks,
> -Fred
>
> -----Message d'origine----- From: Frédéric THOMAS
> Sent: Friday, March 22, 2013 10:12 AM
>
> To: dev@flex.apache.org
> Subject: Re: [OT] Log history
>
> Hi,
>
> I'm happy you gone into this and less because I thought you already
> understood why and when it is better and cleaner while it is safe to use
> rebasing instead of merging but no problem, I'm going to try to explain it
> again later.
>
>
>
> 1- Branching:
>
> The point, in the example I provided was to illustrate how you should work
> from a branch as branching and merging are cheap and are considered as a
> standard developement workflow on Git, even if you work only on local
> branches, the reason behind that is that you might discover another bug,
> nothing relative to the one you're working on (but that impact the same
> file(s)) and this new bug has a higher priority and then has to be fixed
> now, making you stoping the dev of your current bug.
> It's then better to fix it on another branch, doing do, it will be
> availlable for the others as well as for you if you rebase your branch on it
> (again, I will tell you later why it is safe to do so at this point).
> If you have been working on the develop branch directly or on the branch
> dedicated to the bug you was working on before, it would have not been clear
> later in the paralelle history line of your bugfix why there's something not
> relative to it, I made an example of this you can look at [1], as you will
> see, there's nothing destructive using pull --rebase as soon as you
> understand when, where and why to use it.
>
> I hope with the last paragraph, I made clearer why working on a
> feature/bugfix branch is better than on the develop branch.
> Indeed, if you work with someone else, it makes the thing more obvious.
>
> Note: If you apply a quick patch or the dev is only one line of code to
> change and there are no tests to do, etc..., in this case, it's ok to do it
> directly on the develop branch, taking the precaution of rebasing before
> committing however.
>
>
>
>
> 2- Rebasing, merging, what, when, where and why :
>
> Know something once and for ever: rebasing preserve a good history and is
> not destructive until you didn't merge the branch you are working on and
> didn't pushed it yet.
> (and for the latter, you can always avoid it as soon as you follow the good
> practices, see the conclusion).
>
> Note, I explain with my words and my poor English :P
>
> Let's start:
>
> A- Rebasing:
>
> a- What is rebasing:
>
> Rebasing is the operation to get the others work rewriting YOUR commits on
> top of them, it means you will never rewrite their history.
>
> b- When rebasing:
>
> Each time you know or you thing the branch you're based on changed or even
> only when there is a significant amount of time you didn't do it.
>
> c- Where and from where to rebase:
>
> From a branch: it means everywhere.
> The From Where is depending if you are working on a local branch or a
> tracked branch.
>
> From a local branch, you will like to rebase onto the branch your branch is
> based from.
> From a tracked branch, same as before plus the same remote branch to track
> what your mates did.
>
> d- Finaly, WHY it works and it is not descrutive unless you don't follow the
> good practice i'm explaining in this doc :
>
> Because until you didn't merge and not pushed, there are no cases where
> rebase will not preserve yours and the others history, it will put your work
> on top of the others, if you/they did a merge and pushed it, this merge
> still will be preserved.
>
>
>
> B- Merging:
>
> a- What is merging:
>
> Merging is the operation to of joining 2 or more developement lines,
> basicly, this operation will write your commits ahead of the current HEAD,
> you can use the --no-ff flag to indicate you want an extra commit, the merge
> commit, which will make your work easily reversed and will identify clearly
> this work on the remote branch it will be pushed.
>
> b- When merging:
>
> Just before pushing, like that, you are preversed from the mad reads I see
> on internet talking about the rebase risks.
>
> c- Where merging:
>
> From the branch you want your feature/bugfix branch be merge.
>
> d- Why merging :
>
> I mean, the anwser is in the What.
>
>
> C- Conclusion:
>
> Reabase all the time, until you don't have a pending merge that is not
> pushed.
> But if you follow my guideline relative to the When merging, you should not
> encounter this situation.
>
> I hope those explanations anwser all of your questions, except maybe this
> one:
>
>> U:\gitLab\work\asf\flex\testWorkFlow\justin>git reset --hard 54072f3
>
>
> How do I know I need to do this? Would I need to do this every time?
> I really don't want to have to work though obscure git options and issue a
> dozen git commands just to check in a single fix to a single file. If we
> have to do that then I think we are using the tools incorrectly or it's the
> wrong tool for the job. IMO we need to make it as easy or easier than SVN to
> use and add yet more complexity.
>
> In the context of the demo I did, it was to revert the timeline just before
> the merge operation which did a no fast forward merge with the --no-ff flag,
> causing the creation of a merge commit, I wanted to show you how to remove
> it in case you decided you wanted a flat history at the end.
>
> Thanks,
> -Fred
>
> [1]
> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (develop)
> $ git checkout -b bug2fix1
> Switched to a new branch 'bug2fix1'
>
> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
> $ ls bug2fixDir/
> bug2FixFile1 bug2FixFile2
>
> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
> $ cat bug2fixDir/bug2FixFile1
> This is the 1rst line
> this is the 2nd line
>
> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
> $ echo Bug2fix1 should fix the line1 writing first instead of 1rst > null
>
> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
> $ cat bug2fixDir/bug2FixFile1
> This is the first line
> this is the 2nd line
> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
> $ git commit -m "bug2fix1: Fixed bub2fixFile1" bug2fixDir/bug2FixFile1
> [bug2fix1 51af745] bug2fix1: Fixed bub2fixFile1
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
> $ echo As you can see, there is the second line to fix as well but not plan
> for this bug, so I open an other jira and f
> ix it > nul
>
> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
> $ git checkout develop
> Switched to branch 'develop'
> Your branch is ahead of 'origin/develop' by 2 commits.
>
> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (develop)
> $ git checkout -b bug2fix2
> Switched to a new branch 'bug2fix2'
>
> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix2)
> $ cat bug2fixDir/bug2FixFile1
> This is the 1rst line
> this is the 2nd line
>
> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix2)
> $ echo Fix the line 2 > nul
>
> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix2)
> $ cat bug2fixDir/bug2FixFile1
> This is the 1rst line
> this is the second line
>
> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix2)
> $ git commit -m "bug2fix2: Fixed bug2fixFile1" bug2fixDir/bug2FixFile1
> [bug2fix2 46f7fe0] bug2fix2: Fixed bug2fixFile1
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix2)
> $ git checkout develop
> Switched to branch 'develop'
> Your branch is ahead of 'origin/develop' by 2 commits.
>
> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (develop)
> $ git merge --no-ff bug2fix2
> Merge made by the 'recursive' strategy.
> bug2fixDir/bug2FixFile1 | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (develop)
> $ git branch -d bug2fix2
> Deleted branch bug2fix2 (was 46f7fe0).
>
> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (develop)
> $ git push
> Counting objects: 14, done.
> Delta compression using up to 8 threads.
> Compressing objects: 100% (10/10), done.
> Writing objects: 100% (13/13), 1.16 KiB, done.
> Total 13 (delta 3), reused 0 (delta 0)
> To U:/gitLab/work/asf/flex/testWorkFlow/..\flex-sdk.git
> 3cbafc4..3830e37 develop -> develop
>
> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (develop)
> $ git checkout bug2fix1
> Switched to branch 'bug2fix1'
>
> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
> $ git pull --rebase origin develop
> From U:/gitLab/work/asf/flex/testWorkFlow/..\flex-sdk
> * branch develop -> FETCH_HEAD
> First, rewinding head to replay your work on top of it...
> Applying: bug2fix1: Fixed bub2fixFile1
> Using index info to reconstruct a base tree...
> M bug2fixDir/bug2FixFile1
> Falling back to patching base and 3-way merge...
> Auto-merging bug2fixDir/bug2FixFile1
> CONFLICT (content): Merge conflict in bug2fixDir/bug2FixFile1
> Failed to merge in the changes.
> Patch failed at 0001 bug2fix1: Fixed bub2fixFile1
> The copy of the patch that failed is found in:
> u:/gitLab/work/asf/flex/testWorkFlow/justin/.git/rebase-apply/patch
>
> When you have resolved this problem, run "git rebase --continue".
> If you prefer to skip this patch, run "git rebase --skip" instead.
> To check out the original branch and stop rebasing, run "git
> rebase --abort".
>
>
> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin
> ((3830e37...)|REBASE)
> $ git mergetool bug2fixDir/bug2FixFile1
> Merging:
> bug2fixDir/bug2FixFile1
>
> Normal merge conflict for 'bug2fixDir/bug2FixFile1':
> {local}: modified file
> {remote}: modified file
> Hit return to start merge resolution tool (p4merge):
>
> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin
> ((3830e37...)|REBASE)
> $ cat bug2fixDir/bug2FixFile1
> This is the first line
> this is the second line
>
> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin
> ((3830e37...)|REBASE)
> $ echo it was a normal confict, I resolved it now, I am going to fix the
> last file > nul
>
> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin
> ((3830e37...)|REBASE)
> $ git rebase --continue
> Applying: bug2fix1: Fixed bub2fixFile1
>
> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
> $ echo Fixed this file > bug2fixDir/bug2FixFile2
>
> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
> $ cat bug2fixDir/bug2FixFile2
> Fixed this file
>
> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
> $ git status
> # On branch bug2fix1
> # Changes not staged for commit:
> # (use "git add <file>..." to update what will be committed)
> # (use "git checkout -- <file>..." to discard changes in working
> directory)
> #
> # modified: bug2fixDir/bug2FixFile2
> #
> # Untracked files:
> # (use "git add <file>..." to include in what will be committed)
> #
> # bug2fixDir/bug2FixFile1.orig
> no changes added to commit (use "git add" and/or "git commit -a")
>
> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
> $ rm bug2fixDir/bug2FixFile1.orig
>
> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
> $ git status
> # On branch bug2fix1
> # Changes not staged for commit:
> # (use "git add <file>..." to update what will be committed)
> # (use "git checkout -- <file>..." to discard changes in working
> directory)
> #
> # modified: bug2fixDir/bug2FixFile2
> #
> no changes added to commit (use "git add" and/or "git commit -a")
>
> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
> $ git commit -m "bug2fix1: Fixed bug2fixFile2" bug2fixDir/bug2FixFile2
> 1 file changed, 1 insertion(+)
>
> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
> $ git checkout develop
> Switched to branch 'develop'
>
> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (develop)
> $ git merge --no-ff bug2fix1
> Merge made by the 'recursive' strategy.
> bug2fixDir/bug2FixFile1 | 4 ++--
> bug2fixDir/bug2FixFile2 | 1 +
> 2 files changed, 3 insertions(+), 2 deletions(-)
>
> AsusFred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (develop)
> $ git branch -d bug2fix1
> Deleted branch bug2fix1 (was 96c462c).
>
> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (develop)
> $ git push
> Counting objects: 13, done.
> Delta compression using up to 8 threads.
> Compressing objects: 100% (7/7), done.
> Writing objects: 100% (9/9), 857 bytes, done.
> Total 9 (delta 3), reused 0 (delta 0)
> To U:/gitLab/work/asf/flex/testWorkFlow/..\flex-sdk.git
> 3830e37..aa030f4 develop -> develop
>
> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (develop)
> $ git hist
> * aa030f4 2013-03-22 | Merge branch 'bug2fix1' into develop (HEAD,
> origin/develop, develop) [Justin Mclean]
> |\
> | * 96c462c 2013-03-22 | bug2fix1: Fixed bug2fixFile2 (bug2fix1) [Justin
> Mclean]
> | * b931b4e 2013-03-22 | bug2fix1: Fixed bub2fixFile1 [Justin Mclean]
> |/
> * 3830e37 2013-03-22 | Merge branch 'bug2fix2' into develop [Justin
> Mclean]
> |\
> | * 46f7fe0 2013-03-22 | bug2fix2: Fixed bug2fixFile1 [Justin Mclean]
> |/
> * fcb51d5 2013-03-22 | Renamed the file [Justin Mclean]
> * 868fa15 2013-03-22 | prepared the bug2fix demo1 [Justin Mclean]
> * 3cbafc4 2013-03-21 | Added fr_FR [Justin]
> * c3058e9 2013-03-21 | Updated the README again [Frédéric THOMAS]
> * 54072f3 2013-03-21 | Added pt_PT [Justin Mclean]
> * f43029d 2013-03-21 | Updated the README [Frédéric THOMAS]
> * 1032fa2 2013-03-21 | Added README (origin/release, origin/master,
> origin/HEAD, master) [Frédéric THOMAS]
>
> -- NOTHING DESTRUCTIVE, both of the bug histories have been preserved and
> are clearly visible, for this demo, I didn't flaten the bug2fix2 to the
> develop branch even though it has one commit, I would have done it in the
> real live.
>
> -----Message d'origine----- From: Justin Mclean
> Sent: Friday, March 22, 2013 2:56 AM
> To: dev@flex.apache.org
> Subject: Re: [OT] Log history
>
> Hi,
>
> Thanks for going though that.
>
>> ---------------------------------
>> You add locales
>> ---------------------------------
>> U:\gitLab\work\asf\flex\testWorkFlow\justin>git checkout -b
>> test_Rebased_Hotfix_Without_Conflic
>> Switched to a new branch 'test_Rebased_Hotfix_Without_Conflic'
>
>
> etc etc
>
> Actually it wasn't quite like that in that as files and directories already
> existed. It does seem a bit excessive to make a branch just to change a
> single file and it also assumes I have no other changes and a perfectly
> clean tree (not the case). As the branch is local and not shared with anyone
> else do you really need a branch for a simple change to a singe file?
>
>> U:\gitLab\work\asf\flex\testWorkFlow\justin>git pull --rebase origin
>> develop
>
>
> This is the bit I'm confused about why would I use --rebase when all
> documentation I've read say it dangerous to use and it hard to undo (unlike
> merge) and it difficult to see what it's going to do (no --dry-run) - I know
> both of this situations have work arounds (mostly) but they are complex. It
> seems to me that knowing what about to happen and being able to back out of
> it if things go wrong is far more important than having a totally "clean"
> history. It's not like the history produced was incorrect or even confusing.
>
>> U:\gitLab\work\asf\flex\testWorkFlow\justin>git merge --no-ff
>> test_Rebased_Hotfix_Without_Conflic
>
>
> Why is --no-ff required? What would happen if this option wasn't used in
> this case? And if I didn't make the branch in the first place there would be
> no need for this merge or the hard reset below right?
>
>> U:\gitLab\work\asf\flex\testWorkFlow\justin>git reset --hard 54072f3
>
>
> How do I know I need to do this? Would I need to do this every time?
>
> I really don't want to have to work though obscure git options and issue a
> dozen git commands just to check in a single fix to a single file. If we
> have to do that then I think we are using the tools incorrectly or it's the
> wrong tool for the job. IMO we need to make it as easy or easier than SVN to
> use and add yet more complexity.
>
> Thanks,
> Justin
>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
