On Wednesday, 5 September 2012 07:21:14 UTC+1, Mauro Sanna wrote:
>
> On 5 September 2012 00:49, Antony Male <anton...@gmail.com <javascript:>> 
> wrote: 
> > On Tuesday, 4 September 2012 21:42:29 UTC+1, Mauro Sanna wrote: 
> >> 
> >> On 4 September 2012 14:44, Antony Male <anton...@gmail.com> wrote: 
> >> > On Monday, 3 September 2012 21:53:28 UTC+1, Mauro Sanna wrote: 
> >> >> 
> >> >> On 3 September 2012 19:45, Antony Male <anton...@gmail.com> wrote: 
> >> >> > On Monday, 3 September 2012 18:33:03 UTC+1, Mauro Sanna wrote: 
> >> >> >> 
> >> >> >> On 3 September 2012 18:56, Antony Male <anton...@gmail.com> 
> wrote: 
> >> >> >> > On Monday, 3 September 2012 17:32:46 UTC+1, Mauro Sanna wrote: 
> >> >> >> >> 
> >> >> >> >> On 3 September 2012 18:13, Antony Male <anton...@gmail.com> 
> >> >> >> >> wrote: 
> >> >> >> >> > On Monday, 3 September 2012 12:19:11 UTC+1, Mauro Sanna 
> wrote: 
> >> >> >> >> >> 
> >> >> >> >> >> Then I do a git checkout master, git merge devel and push 
> and 
> >> >> >> >> >> all 
> >> >> >> >> >> done. 
> >> >> >> >> >> I always have done this but now, in a new application, when 
> I 
> >> >> >> >> >> do 
> >> >> >> >> >> git 
> >> >> >> >> >> merge 
> >> >> >> >> >> devel into master it asks me for a commit message. 
> >> >> >> >> > 
> >> >> >> >> > 
> >> >> >> >> > In version 1.7.10, git started prompting for a commit 
> message 
> >> >> >> >> > after 
> >> >> >> >> > every 
> >> >> >> >> > merge. The rationale behind this is explained in Junio's 
> (the 
> >> >> >> >> > maintainer's) 
> >> >> >> >> > blog post [1] 
> >> >> >> >> 
> >> >> >> >> Ok but, why it don't ask for a commit message when used in 
> some 
> >> >> >> >> other 
> >> >> >> >> projects? 
> >> >> >> >> .git/config is the same. 
> >> >> >> >> Perhaps because I've set the repository using git before 
> 1.7.10? 
> >> >> >> > 
> >> >> >> > 
> >> >> >> > Maybe in one project the merges you're doing are 
> non-fast-forward 
> >> >> >> > (as 
> >> >> >> > you 
> >> >> >> > stated), whereas in the others they're fast-forward? Maybe 
> there's 
> >> >> >> > a 
> >> >> >> > configuration difference? (I didn't think there was a config 
> key 
> >> >> >> > to 
> >> >> >> > disable 
> >> >> >> > this behaviour, but it's worth a check). 
> >> >> >> 
> >> >> >> 
> >> >> >> Here the config for two of my projects. 
> >> >> >> The first is not fast-forward while in the second the merge is 
> >> >> >> fast-forward. 
> >> >> > 
> >> >> > 
> >> >> > There we go! Read up on the differences between fast-forward and 
> >> >> > non-fast-forward merges. [1] is a helpful resource. 
> >> >> > 
> >> >> > Now, as you can see, fast-forward merges don't involve an actual 
> >> >> > merge 
> >> >> > commit. No merge commit = no commit message. Which is why you're 
> not 
> >> >> > being 
> >> >> > prompted for a message for the fast-forward merge.n 
> >> >> 
> >> >> Yes I know, but I want my merges to be fast-forward. 
> >> >> Because git configuration is the same for the two projects I don't 
> >> >> know why the merge for first project go fast-forward while the 
> second 
> >> >> one not. 
> >> >> What's the differerence between the two configurations? There is no 
> >> >> difference, so why I have a merge with fast-forward and a merge with 
> >> >> no fast-forward? 
> >> > 
> >> > 
> >> >  'git merge' will (by default) do a fast-forward merge if it can, 
> >> > otherwise 
> >> > it will do a recursive merge. 
> >> > 
> >> > As shown by the PDF I linked to a few posts back, if you're merging 
> >> > develop 
> >> > into master (git checkout master; git merge develop), a fast-forward 
> >> > merge 
> >> > can happen if and only if develop is a direct descendant of master. 
> That 
> >> > is, 
> >> > if the master branch contains only commits which are also contained 
> by 
> >> > the 
> >> > develop branch. If master has commits which develop does not have, 
> then 
> >> > a 
> >> > fast-forward merge cannot occur, and a recursive merge must be used 
> >> > instead. 
> >> > 
> >> > Graphically: (Use a fixed-width font to view: I know google groups 
> uses 
> >> > a 
> >> > variable-width font by default) 
> >> > 
> >> > A fast-forward merge *can* occur: 
> >> > 
> >> >         O--O--O 
> >> >        /      ^ 
> >> > O--O--O    develop 
> >> >       ^ 
> >> >     master 
> >> > 
> >> > which will result in: 
> >> > 
> >> >             develop 
> >> >                v 
> >> > O--O--O--O--O--O 
> >> >                ^ 
> >> >              master 
> >> > 
> >> > A fast-forward merge *cannot* occur (as master contains commits which 
> >> > aren't 
> >> > present on develop): 
> >> > 
> >> >            develop 
> >> >               v 
> >> >         O--O--O 
> >> >        / 
> >> > O--O--O--O 
> >> >          ^ 
> >> >       master 
> >> > 
> >> > where a recursive merge will result in (M being the merge commit): 
> >> > 
> >> >            develop 
> >> >               v 
> >> >         O--O--O 
> >> >        /       \ 
> >> > O--O--O--O------M 
> >> >                 ^ 
> >> >               master 
> >> > 
> >> > 
> >> > If you're having trouble visualising your branch structure, use `gitk 
> >> > master 
> >> > develop` (if gitk is available), otherwise `git log --graph --oneline 
> >> > --decorate master develop`. You should see that, in the repository 
> where 
> >> > fast-forward merges are occuring, there are no commits present on 
> master 
> >> > which aren't also present on develop. In the other repository (where 
> >> > fast-forward merges are not occuring), you will see that there is at 
> >> > least 
> >> > one commit on master which is not also present on develop (you may 
> have 
> >> > to 
> >> > look back a bit, to slightly before the first recursive merge 
> occurred). 
> >> > 
> >> > Hope that helps clarify the situation. If you're still not getting 
> it, 
> >> > paste 
> >> > (or pastebin) the output of `git log --graph --oneline --decorate 
> master 
> >> > develop`, and I can point out the critical difference. 
> >> 
> >> Here is: 
> >> http://pastebin.com/dmxtS8ZB 
> > 
> > 
> > If you look right down, you'll see commit ba4c51. That commit was made 
> on 
> > the master branch. Therefore every time you ask git to merge develop 
> into 
> > master, there's history present in master which isn't in the develop 
> branch, 
> > making a fast-forward merge impossible. 
> > 
> > Is that clear? I don't know what else to say. 
>
> Right, it's clear. 
> There is a way now to make a fast-forward merge? 
> Or I must delete brand devel and recreate? 
> Thanks for your answers and your patience.
>

You can `git checkout master && git merge develop && git checkout develop 
&& git reset --hard master`. Note that this is rewriting public history. To 
steal a notice from the #git IRC channel:

"Rewriting public history is a very bad idea.  Anyone else who may have 
pulled the old history will have to `git pull --rebase` and even worse 
things if they have tagged or branched, so you must publish your 
humiliation so they know what to do.  You will need to `git push -f` to 
force the push.  The server may not allow this.  See 
receive.denyNonFastForwards (git-config)"

So you can only (reasonably) do this if you're the only person who has 
access to any of your project's repos. Similarly, if you're working on your 
project from multiple computers, make sure you *do not* run `git pull` from 
the non-rewritten repo, as this will merge together the two versions of 
history of the develop branch, and result in a right mess.

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/git-users/-/fa8TVCuI9rMJ.
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to 
git-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/git-users?hl=en.

Reply via email to