{"thread":{"id":"26577","subject":"libreoffice merge(tool?) issue #3 ...","startedAt":"2011-02-22T15:34:37Z","lastAt":"2011-02-28T15:10:39Z","messageCount":12,"participants":["Michael Meeks","Brian Gernhardt","Michael J Gruber","Andres Freund"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"161885","messageId":"1298388877.32648.171.camel@lenovo-w500","threadId":"26577","inReplyTo":null,"subject":"libreoffice merge(tool?) issue #3 ...","fromName":"Michael Meeks","fromEmail":"michael.meeks@novell.com","sentAt":"2011-02-22T15:34:37Z","receivedAt":"2011-02-22T15:34:37Z","isPatch":false,"sender":{"key":"michael.meeks@novell.com","avatar":null},"body":"Hi there,\n\n        So - yet again, I'm still a completely clueless git user :-)\nbasically the same setup and reproduction issue as last time, still\nusing a stable git: version 1.7.3.4\n\nSetup:\n        git clone git://anongit.freedesktop.org/libreoffice/libs-core\n        git checkout integration/dev300_m98\n        git remote add stage git://anongit.freedesktop.org/libreoffice/staging/libs-core\n        git fetch stage\n\nReproduce:\n\trm -Rf *\n\tgit reset --hard # ie. totally clean tree.\n        git merge stage/dev300\n\n\tI get this output from the merge:\n\nerror: refusing to lose untracked file at 'ucb/source/ucp/ext/makefile.mk'\n\n\tThen when I run:\n\n$ git mergetool ucb/source/ucp/ext/makefile.mk\n..\n\nDeleted merge conflict for 'ucb/source/ucp/ext/makefile.mk':\n  {local}: created\n  {remote}: deleted\nUse (c)reated or (d)eleted file, or (a)bort?\n\n\tIt seems to suggest that the file is deleted somewhere (in the branch I\nam trying to merge in) it seems.\n\n\tInterestingly, though - the file is present in both\nintegration/dev300_m98:\n\n\tgit log -n1 ucb/source/ucp/ext/makefile.mk | tee\ncommit 80b61d9c6762b4f195edd1246b903b11ad3f2252\nAuthor: Thomas Arnhold <thomas@arnhold.org>\nDate:   Fri Jan 21 14:11:55 2011 +0100\n\n    Remove old RCS lines.\n\n\tAnd also present in the branch I'm merging: stage/dev300:\n\ncommit 0c87cb97cf3790fa98bcbb0eef9d174140a4e847\nAuthor: sb <sb@openoffice.org>\nDate:   Fri Sep 10 13:10:07 2010 +0200\n\n    sb129: #i113189# change UNO components to use passive registration\n\n\n\tWhich makes me wonder - why the deleted / untracked file message ?\nprobably something obvious, but I found it rather confusing, and again\nI've seen a number of examples of this.\n\n\tThanks,\n\n\t\tMichael.\n\nPS. of course, perhaps this is 'just me' - for space / time /\nsimplicty / certainty reasons, I do a lot of \"cp -lR foo/.git baa/\" to\nduplicate trees - but AFAIK all git operations are atomic and use\nrenames rather than in-place re-writing: right ?\n-- \n michael.meeks@novell.com  <><, Pseudo Engineer, itinerant idiot\n"},{"id":"161890","messageId":"993F66D7-7659-4AA5-9931-1EB66CAA01DB@silverinsanity.com","threadId":"26577","inReplyTo":"1298388877.32648.171.camel@lenovo-w500","subject":"Re: libreoffice merge(tool?) issue #3 ...","fromName":"Brian Gernhardt","fromEmail":"benji@silverinsanity.com","sentAt":"2011-02-22T15:55:17Z","receivedAt":"2011-02-22T15:55:17Z","isPatch":false,"sender":{"key":"benji@silverinsanity.com","avatar":"https://gravatar.com/avatar/e06c101dbc25c68114d859b4a9ec7cf8a2c52fd2b0270ef0eac0e2e63ff22311?d=mp&s=160"},"body":"\nOn Feb 22, 2011, at 10:34 AM, Michael Meeks wrote:\n\n> PS. of course, perhaps this is 'just me' - for space / time /\n> simplicty / certainty reasons, I do a lot of \"cp -lR foo/.git baa/\" to\n> duplicate trees - but AFAIK all git operations are atomic and use\n> renames rather than in-place re-writing: right ?\n\nFYI: `git clone foo bar` will use hard-links to copy the object files and is both very fast and space efficient.  (See the description of `--local` in git-clone(1), which is used by default for local repositories since git 1.5.3.)  It's also guaranteed to work while the correctness of `cp -lR` depends on implementation details of git.\n\n~~ Brian"},{"id":"161897","messageId":"4D63F2C5.2080505@drmicha.warpmail.net","threadId":"26577","inReplyTo":"1298388877.32648.171.camel@lenovo-w500","subject":"Re: libreoffice merge(tool?) issue #3 ...","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-02-22T17:30:45Z","receivedAt":"2011-02-22T17:30:45Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Michael Meeks venit, vidit, dixit 22.02.2011 16:34:\n> Hi there,\n> \n>         So - yet again, I'm still a completely clueless git user :-)\n> basically the same setup and reproduction issue as last time, still\n> using a stable git: version 1.7.3.4\n<PG>\nI'm sorry you're having reproduction issues. At least your git is stable.\n</PG>\n> \n> Setup:\n>         git clone git://anongit.freedesktop.org/libreoffice/libs-core\ncd libs-core # I assume\n>         git checkout integration/dev300_m98\n>         git remote add stage git://anongit.freedesktop.org/libreoffice/staging/libs-core\n>         git fetch stage\n> \n> Reproduce:\n> \trm -Rf *\n> \tgit reset --hard # ie. totally clean tree.\n# Those two should be no-ops after following the above.\n>         git merge stage/dev300\nIs that stage/ooo/dev300?\n> \n> \tI get this output from the merge:\n\nI get thousands of conflicts. Have the branches moved since your post?\nIt may be better to give us sha1 or stable tags.\n\nAre you doing any builds before merging?\n\n> PS. of course, perhaps this is 'just me' - for space / time /\n> simplicty / certainty reasons, I do a lot of \"cp -lR foo/.git baa/\" to\n> duplicate trees - but AFAIK all git operations are atomic and use\n> renames rather than in-place re-writing: right ?\n\nOuch. See Brian's post :)\n\nMichael\n"},{"id":"161899","messageId":"1298398479.32648.184.camel@lenovo-w500","threadId":"26577","inReplyTo":"4D63F2C5.2080505@drmicha.warpmail.net","subject":"Re: libreoffice merge(tool?) issue #3 ...","fromName":"Michael Meeks","fromEmail":"michael.meeks@novell.com","sentAt":"2011-02-22T18:14:39Z","receivedAt":"2011-02-22T18:14:39Z","isPatch":false,"sender":{"key":"michael.meeks@novell.com","avatar":null},"body":"Hi Michael,\n\nOn Tue, 2011-02-22 at 18:30 +0100, Michael J Gruber wrote:\n> I get thousands of conflicts. Have the branches moved since your post?\n> It may be better to give us sha1 or stable tags.\n\n\tNope; there are thousands of conflicts; a subset of these are (I would\nlike to think ;-) erroneous; but I'm picking out individual files with\nproblems that I can repeat easily and that have (I hope) simple history\nto try to isolate the problems for you.\n\n> Are you doing any builds before merging?\n\n\tBuilds of what ? git - no; LibreOffice - sure, it builds before the\nmerge - and then there is a huge slew of work to do to make it build\nafterwards ;-) but then that is not so suprising.\n\n\tAnyhow - thanks for looking at it; can you replicate the suprising\nresult in that file: ucb/source/ucp/ext/makefile.mk ? what does\n'refusing to loose untracked file' mean in that context ?\n\n\tThanks,\n\n\t\tMichael.\n\n-- \n michael.meeks@novell.com  <><, Pseudo Engineer, itinerant idiot\n"},{"id":"162018","messageId":"4D64ED12.5050802@drmicha.warpmail.net","threadId":"26577","inReplyTo":"1298398479.32648.184.camel@lenovo-w500","subject":"Re: libreoffice merge(tool?) issue #3 ...","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-02-23T11:18:42Z","receivedAt":"2011-02-23T11:18:42Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Michael Meeks venit, vidit, dixit 22.02.2011 19:14:\n> Hi Michael,\n> \n> On Tue, 2011-02-22 at 18:30 +0100, Michael J Gruber wrote:\n>> I get thousands of conflicts. Have the branches moved since your post?\n>> It may be better to give us sha1 or stable tags.\n> \n> \tNope; there are thousands of conflicts; a subset of these are (I would\n> like to think ;-) erroneous; but I'm picking out individual files with\n> problems that I can repeat easily and that have (I hope) simple history\n> to try to isolate the problems for you.\n> \n>> Are you doing any builds before merging?\n> \n> \tBuilds of what ? git - no; LibreOffice - sure, it builds before the\n> merge - and then there is a huge slew of work to do to make it build\n> afterwards ;-) but then that is not so suprising.\n\nBuilds of LO, naturally. The point is that possibly one branch tracks\nsome build products that the other doesn't track - e.g., autogenerated\nmake or autoconf stuff etc. (This happens easily when you change your\nbuild chain.) That would lead to a message like that:\n\n> \tAnyhow - thanks for looking at it; can you replicate the suprising\n> result in that file: ucb/source/ucp/ext/makefile.mk ? what does\n> 'refusing to loose untracked file' mean in that context ?\n\nSay, you build on branch A, that generates an untracked file foo, but\nbranch B (which you want to merge) tracks that. Merges refuses to\noverwrite foo (even though A does not have foo) so that you don't loose\nthe contents of the untracked file.\n\nBut I'm really wondering whether we're merging the same revs. As I\nmentioned, I don't see that branch in \"stage\" that you're merging, only\n\"stage/ooo/dev300\", see below. Also, I'm getting\n\nAA ucb/source/ucp/ext/makefile.mk\n\nwhich has a somewhat surprising markup (the left side introduces no\nchange, the right side does - should have a trivial resolution), without\nbuilding LO before.\n\nNote that you're merging branches which are way off,\n\ngit rev-list --count --left-right\norigin/integration/dev300_m98...stage/ooo/dev300\n3566    3126\n\nand that the merge base is quite old:\n\naf61642 (#i105937# Fixed a few remaining gradient glitches, 2010-01-16)\n\nThe latter explains many of the problems (and the \"surprising\" above):\ncompared to the merge base, both branches add\nucb/source/ucp/ext/makefile.mk as a *new* file with different contents,\nso that the conflict can't be resolved automatically, and that's how it\nis marked up.\n\nIs that merge really what you're after?\n\nMichael\n\nBranches with your recipe:\n\n* integration/dev300_m98\n  master\n  remotes/origin/HEAD -> origin/master\n  remotes/origin/feature/bootstrap-build\n  remotes/origin/feature/currency-64bit\n  remotes/origin/feature/gnumake2.1\n  remotes/origin/feature/helppack\n  remotes/origin/feature/layout\n  remotes/origin/feature/pptx-export-ooxml11\n  remotes/origin/feature/rodatastrings\n  remotes/origin/feature/sqlite\n  remotes/origin/feature/winshrink\n  remotes/origin/integration/dev300_m98\n  remotes/origin/libreoffice-3-3\n  remotes/origin/libreoffice-3-3-0\n  remotes/origin/libreoffice-3-3-1\n  remotes/origin/master\n  remotes/stage/ooo/dev300\n  remotes/stage/ooo/dev300_m100\n  remotes/stage/premerge/dev300_m98\n\n\nMichael\n"},{"id":"162023","messageId":"4D650A03.8030106@drmicha.warpmail.net","threadId":"26577","inReplyTo":"4D64ED12.5050802@drmicha.warpmail.net","subject":"Re: libreoffice merge(tool?) issue #3 ...","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-02-23T13:22:11Z","receivedAt":"2011-02-23T13:22:11Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Michael J Gruber venit, vidit, dixit 23.02.2011 12:18:\n> Note that you're merging branches which are way off,\n> \n> git rev-list --count --left-right\n> origin/integration/dev300_m98...stage/ooo/dev300\n> 3566    3126\n> \n> and that the merge base is quite old:\n> \n> af61642 (#i105937# Fixed a few remaining gradient glitches, 2010-01-16)\n\nFollowing up on this:\n\ngit rev-list --count --left-right\norigin/integration/dev300_m98...stage/ooo/dev300\n3566    3126\n\ngit rev-list --count --left-right --no-merges\norigin/integration/dev300_m98...stage/ooo/dev300\n2794    2180\n\ngit rev-list --count --left-right --no-merges --cherry-pick\norigin/integration/dev300_m98...stage/ooo/dev300\n1136    528\n\nThat is, 2500 of these different commits are patch-equivalent\n(cherry-picks). I don't think \"merge\" is the best tool to combine \"fake\"\nbranches like those. You may be better off with rebase... Although I'm\nwondering what the branch policy was that lead to this.\n\nMichael\n"},{"id":"162172","messageId":"1298565560.32648.258.camel@lenovo-w500","threadId":"26577","inReplyTo":"993F66D7-7659-4AA5-9931-1EB66CAA01DB@silverinsanity.com","subject":"Re: libreoffice merge(tool?) issue #3 ... (bogus)","fromName":"Michael Meeks","fromEmail":"michael.meeks@novell.com","sentAt":"2011-02-24T16:39:20Z","receivedAt":"2011-02-24T16:39:20Z","isPatch":false,"sender":{"key":"michael.meeks@novell.com","avatar":null},"body":"Hi Brian,\n\n\tFirst - it seems that the issue here was entirely bogus, not least\nbecause we had a bug with re-writing these makefiles as we checked them\nin; so hopefully only 2 issues pending ;-)\n\n\tAnyhow - I tried your kind advice:\n\nOn Tue, 2011-02-22 at 10:55 -0500, Brian Gernhardt wrote:\n> FYI: `git clone foo bar` will use hard-links to copy the object\n> files and is both very fast and space efficient.  (See the\n> description of `--local` in git-clone(1), which is used by\n> default for local repositories since git 1.5.3.)  It's also\n> guaranteed to work while the correctness of `cp -lR` depends\n> on implementation details of git.\n\n\tSounds like just what I need. Unfortunately, it didn't clone some of\nthe pieces I needed; eg. other configured remotes, I ended up with just\n'origin' - which was unexpected (and less wonderful than cp -lR ;-).\n\n\tIs that a feature ?\n\n\tThanks,\n\n\t\tMichael.\n\n-- \n michael.meeks@novell.com  <><, Pseudo Engineer, itinerant idiot\n"},{"id":"162227","messageId":"4D677F98.7080502@drmicha.warpmail.net","threadId":"26577","inReplyTo":"1298565560.32648.258.camel@lenovo-w500","subject":"Re: libreoffice merge(tool?) issue #3 ... (bogus)","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-02-25T10:08:24Z","receivedAt":"2011-02-25T10:08:24Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Michael Meeks venit, vidit, dixit 24.02.2011 17:39:\n> Hi Brian,\n> \n> \tFirst - it seems that the issue here was entirely bogus, not least\n> because we had a bug with re-writing these makefiles as we checked them\n> in; so hopefully only 2 issues pending ;-)\n> \n> \tAnyhow - I tried your kind advice:\n> \n> On Tue, 2011-02-22 at 10:55 -0500, Brian Gernhardt wrote:\n>> FYI: `git clone foo bar` will use hard-links to copy the object\n>> files and is both very fast and space efficient.  (See the\n>> description of `--local` in git-clone(1), which is used by\n>> default for local repositories since git 1.5.3.)  It's also\n>> guaranteed to work while the correctness of `cp -lR` depends\n>> on implementation details of git.\n> \n> \tSounds like just what I need. Unfortunately, it didn't clone some of\n> the pieces I needed; eg. other configured remotes, I ended up with just\n> 'origin' - which was unexpected (and less wonderful than cp -lR ;-).\n> \n> \tIs that a feature ?\n\nYes, because by cloning someone else's config they could make you do\nwhat they want (alias...).\n\nI think in your case you can just copy over the .git/config and maybe\nset up \"alternates\" so that you don't have to refetch the remote objects\nwhich are not referenced by local refs. (Alternatively, clone --mirror,\nthen copy over config and turn into non bare.)\n\nMaybe we do need \"clone --copy\" or something as a safe version of \"cp -al\"?\n\nMichael\n"},{"id":"162271","messageId":"201102252155.13466.andres@anarazel.de","threadId":"26577","inReplyTo":"1298565560.32648.258.camel@lenovo-w500","subject":"Re: libreoffice merge(tool?) issue #3 ... (bogus)","fromName":"Andres Freund","fromEmail":"andres@anarazel.de","sentAt":"2011-02-25T20:55:12Z","receivedAt":"2011-02-25T20:55:12Z","isPatch":false,"sender":{"key":"andres@anarazel.de","avatar":null},"body":"Hi,\n\nOn Thursday 24 February 2011 17:39:20 Michael Meeks wrote:\n> \tAnyhow - I tried your kind advice:\n> \n> On Tue, 2011-02-22 at 10:55 -0500, Brian Gernhardt wrote:\n> > FYI: `git clone foo bar` will use hard-links to copy the object\n> > files and is both very fast and space efficient.  (See the\n> > description of `--local` in git-clone(1), which is used by\n> > default for local repositories since git 1.5.3.)  It's also\n> > guaranteed to work while the correctness of `cp -lR` depends\n> > on implementation details of git.\n> \n> \tSounds like just what I need. Unfortunately, it didn't clone some of\n> the pieces I needed; eg. other configured remotes, I ended up with just\n> 'origin' - which was unexpected (and less wonderful than cp -lR ;-).\nSee the --mirror option for clone\n\nPer default only local refs get copied over.\n\nAndres\n"},{"id":"162441","messageId":"1298903102.14697.127.camel@lenovo-w500","threadId":"26577","inReplyTo":"201102252155.13466.andres@anarazel.de","subject":"copying git repositories ...","fromName":"Michael Meeks","fromEmail":"michael.meeks@novell.com","sentAt":"2011-02-28T14:25:02Z","receivedAt":"2011-02-28T14:25:02Z","isPatch":false,"sender":{"key":"michael.meeks@novell.com","avatar":null},"body":"Hi Andres & Brian,\n\n\tThanks for your help;\n\nOn Fri, 2011-02-25 at 21:55 +0100, Andres Freund wrote:\n> > On Tue, 2011-02-22 at 10:55 -0500, Brian Gernhardt wrote:\n> > > FYI: `git clone foo bar` will use hard-links to copy the object\n> > > files and is both very fast and space efficient.  (See the\n> > > description of `--local` in git-clone(1), which is used by\n> > > default for local repositories since git 1.5.3.)  It's also\n> > > guaranteed to work while the correctness of `cp -lR` depends\n> > > on implementation details of git.\n..\n> > \tSounds like just what I need. Unfortunately, it didn't clone some of\n> > the pieces I needed; eg. other configured remotes, I ended up with just\n> > 'origin' - which was unexpected (and less wonderful than cp -lR ;-).\n..\n> See the --mirror option for clone\n\n\tI tried all of this; none of it did what I had hoped :-)\n\n\tgit clone src dest\n\n\tyields a different repository, with a totally different config /\nremotes setup - missing all but a new synthetic origin pointing at the\nlocal files and which can't be git pulled from in the normal way; ie. it\nbehaves extremely differently to the cp -lR result.\n\n\tgit clone --mirror src dest\n\n\tyields a similar problem-repository, which is for extra measure a bare\ncheckout, and thus also not what I need.\n\n\tI'm really looking for an equivalent of 'cp -lR foo baa' that:\n\n\t* uses hard links to save space\n\t* produces precisely-a-duplicate repository\n\n\tFor #2 - I would use the verb 'clone' except of course the 'clone' I'm\ntalking about would be one that is identical, the same, with no\ndifferences (not eg. missing a few limbs ;-) \n\n\tClearly cp -lR is bad & evil and all that; but it yields exactly what I\nneed to effectively manage my local trees, multiple checkouts, and\ndifferent builds without burning the entire disk.\n\n\tIs there a blessed 'cp -lR' wrapper for git that is functionally\nidentical ? [ and I'm happy of course for some slow divergence, and loss\nof efficiency as I pull more changes from time to time into each tree ].\n\n\tSorry for the noise,\n\n\t\tMichael.\n\n-- \n michael.meeks@novell.com  <><, Pseudo Engineer, itinerant idiot\n"},{"id":"162442","messageId":"201102281603.08375.andres@anarazel.de","threadId":"26577","inReplyTo":"1298903102.14697.127.camel@lenovo-w500","subject":"Re: copying git repositories ...","fromName":"Andres Freund","fromEmail":"andres@anarazel.de","sentAt":"2011-02-28T15:03:08Z","receivedAt":"2011-02-28T15:03:08Z","isPatch":false,"sender":{"key":"andres@anarazel.de","avatar":null},"body":"Hi Michael,\n\nOn Monday, February 28, 2011 03:25:02 PM Michael Meeks wrote:\n> Hi Andres & Brian,\n> \tFor #2 - I would use the verb 'clone' except of course the 'clone' I'm\n> talking about would be one that is identical, the same, with no\n> differences (not eg. missing a few limbs ;-)\n> \n> \tClearly cp -lR is bad & evil and all that; but it yields exactly what I\n> need to effectively manage my local trees, multiple checkouts, and\n> different builds without burning the entire disk.\n> \n> \tIs there a blessed 'cp -lR' wrapper for git that is functionally\n> identical ? [ and I'm happy of course for some slow divergence, and loss\n> of efficiency as I pull more changes from time to time into each tree ].\nWhat about git clone --reference=oldrepo ssh://upstream/ ?\n\nAndres\n"},{"id":"162443","messageId":"43737C0D-E1B7-4036-BE39-8DF09751E22D@silverinsanity.com","threadId":"26577","inReplyTo":"1298903102.14697.127.camel@lenovo-w500","subject":"Re: copying git repositories ...","fromName":"Brian Gernhardt","fromEmail":"benji@silverinsanity.com","sentAt":"2011-02-28T15:10:39Z","receivedAt":"2011-02-28T15:10:39Z","isPatch":false,"sender":{"key":"benji@silverinsanity.com","avatar":"https://gravatar.com/avatar/e06c101dbc25c68114d859b4a9ec7cf8a2c52fd2b0270ef0eac0e2e63ff22311?d=mp&s=160"},"body":"\nOn Feb 28, 2011, at 9:25 AM, Michael Meeks wrote:\n\n> \tI'm really looking for an equivalent of 'cp -lR foo baa' that:\n> \n> \t* uses hard links to save space\n> \t* produces precisely-a-duplicate repository\n\nI mostly handle this sort of thing by branch switching in the same checkout, which I assume you're trying not to do because of recompilation time.  Your way, eventually the repositories in question would start to diverge and you'd have to keep them in sync manually, which sounds far less than ideal.  Eventual repacks would break the hard links and you'd even lose the space savings.\n\nWhat you might be interested in is the git-new-workdir script in git.git/contrib/workdir.  It uses symbolic links to create a new working directory backed by the exact same object store and config as the original.\n\n\nThis is not a situation git is well designed for, honestly.  The more \"git-like\" work flow would be to maintain a single central, probably bare, repository on your machine that pulls from everything that all your local repositories need.  Then set up the other repositories to get all the references from the central repo.  Then there's only one that needs to be updated from the remotes.  If you use the --reference option to git-clone, you're not even duplicating the object store and each clone only has the objects it needs.\n\n~~ Brian\n"}]}