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>

Reply via email to