On Tuesday 30 March 2010 23:38:00 David ?Bombe? Roden wrote: > On Tuesday 30 March 2010 12:35:00 Ximin Luo wrote: > > > > No, it will not. If work on the branch continues (which is unlikely > > > because it has been merged so further work would happen on the master > > > branch) I would just merge master again. Simple and beautiful. > > > > What I meant by weird was it'll look like this: > > > > -o---o o---o <- master > > \ / > > \ / > > \ / > > -o---o---o---o---o <- identicon > > > > which looks like master was pulled into identicon then branched off again. > > Which is basically what has happened here without --no-ff. > > No, it doesn?t. The situation looked kind of like this: > > -o-o-o-------o <- master > \ \ > o-o-o---o <- bombe/identicon > > After merging the identicon branch into master it looks like: > > -o-o-o-------o > \ \ > o-o-o---o <- master / bombe/identicon > > With --no-ff you would get: > > -o-o-o-------o---o <- master > \ \ / > o-o-o---o <- bombe/identicon > > This looks more confusing IMHO. > > > > But it should really look like this: > > > > -o---o---o---o---o <- master > > / > > / > > / > > -o---o---o---o <- identicon > > No, it shouldn?t. There are no commits in the identicon branch that are not > merged into master. > > > > If you are going to have a merge-and-push workflow then it makes sense to > > do this consistently, and generate a merge commit whenever you pull from a > > repo that you are not tracking. > > We are not aiming for a workflow containing a push. What (I think) we want to > utilize is the workflow that is used by e.g. the Linux team and the Git team, > where only a few persons have access to the official repository, pulling > changes from various other people that are doing the ?hard work.? In that > workflow fast-forward commits are actually preferable because they do not > cause a merge and are thus less likely to cause conflicts and grieve. :)
So did we lose a bunch of commits from master or didn't we, as originally complained? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20100401/5548d5de/attachment.pgp>