[Monotone-devel] Re: OpenEmbedded looking to jump ship

[Holger Freyther]

Justin Patrin <papercrane <at> gmail.com> writes:


> It looks like the original discussion is here:
> http://projects.linuxtogo.org/pipermail/openembedded-devel/2008-March/004642.html
> I haven't been reading my mail very carefully lately.
> 
> The majority of complaints seem to be that "merge is broken". I
> honestly can't understand this argument. Merge in monotone has always
> been the part that makes the most sense to me. It seems likely that
> the people who say that mtn's merge is broken are not paying
> sufficient attention to what they're doing (such as fragmenting
> history by copying files, then renaming back to the original name).
> Most people seem to be having non-content conflicts, which, I must
> agree, is a part of monotone that is lacking in UI. Being able to
> suture 2 technically different files/nodes into one in a merge would
> help a lot here.
> 
> There also seems to be a want for cherry-picking, although I'm not
> sure how this works in practice in other SCMs. Using pluck can
> cherry-pick revisions just fine but it's just more likely to cause
> non-content conflicts down the line.
> 
> Still others appear to want to be able to merge local revisions into
> one before pushing....although it sounds to me like this is more a
> side-effect of how git works.
> 


What is getting in my way:
    - Non Content Conflicts. Within the 6 weeks of working at Openmoko Inc.,
I have seen three manual merges (mtn dropping files on one side like proposed
in the manual) and in all cases I had to clean up the mess because the wrong
files were dropped. What is more annoying is that git will do this merge just
fine, if not git-mergetool is helpful to resolve it. The reality is that I have
changes in org.openmoko.dev which would be good for org.openembedded.dev but
I do not tell anyone because if someone would pick the change I would have
NCCs. With git it would be a matter of git-cherry-pick, and I would just pull
on the Openmoko site and everything would be fine. Just naming the filename
and not the path for NCCs is funny as well, spepcially if the filename is not
unique within your repository.

I'm feeling blind with monotone:
     - git-rev-list origin/qtwebkit.. (to show what I would push now) is
       missing
     - gitk is almost instantly working on the OE tree
     - git-fetch will tell me what was updated, which branches created,
       mtn doesn't have this. 


I feel forced in a work flow:
     - git-commit --amend is missing
     - git-add -i is missing
     - git-revert is missing (disapprove does not work on merges... which
       voids the whole concept)
     - git-rebase -i is missing
     - git-merge-tool (okay we don't have an index with mtn, you can not use
       disapprove on a merge and kill_rev_locally will mess up your working
       on a merge...)
     - git-format-patch (my version with mtn diff -r .. -r breaks on merges)
     - git-show (my version with mtn diff -r p:rev -r rev breaks with merges)


If you have questions regarding my workflow and use-cases feel free to ask.


PS: Sorry this is rather short, gmane ate my first reply to this...