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. :)
> X
Bombe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20100331/ca9256ce/attachment.pgp>
