{"thread":{"id":"2800","subject":"Branches merging by only overwrite files","startedAt":"2005-12-11T08:30:49Z","lastAt":"2005-12-11T11:15:44Z","messageCount":3,"participants":["Ben Lau","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"13479","messageId":"439BE3B9.3040308@ust.hk","threadId":"2800","inReplyTo":null,"subject":"Branches merging by only overwrite files","fromName":"Ben Lau","fromEmail":"benlau@ust.hk","sentAt":"2005-12-11T08:30:49Z","receivedAt":"2005-12-11T08:30:49Z","isPatch":false,"sender":{"key":"benlau@ust.hk","avatar":null},"body":"Hi,\n\n    I am looking for a solution to merge two branches but do not perform \nfile level merge. Instead, I wish the result file is the copy from any \none of the branches.\n\n    For example, assumes it has two branches A and B,  some of the files \nare modified in both of them. In this case, `/usr/bin/merge` could not \nbe execated, it just have to choose the revision from branch A and \ndiscards all the changes from B. For the rest of files, it just simply \nchoose the newest copy from A or B.\n\n    How can I perform this action?\n\nThanks in advance.\n"},{"id":"13482","messageId":"7vbqzonfkx.fsf@assigned-by-dhcp.cox.net","threadId":"2800","inReplyTo":"439BE3B9.3040308@ust.hk","subject":"Re: Branches merging by only overwrite files","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-12-11T09:33:18Z","receivedAt":"2005-12-11T09:33:18Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ben Lau <benlau@ust.hk> writes:\n\n>    I am looking for a solution to merge two branches but do not perform \n> file level merge. Instead, I wish the result file is the copy from any \n> one of the branches.\n\nIt might be better to state why you need this first.  It could\nbe that what you really want to solve is not related to merge at\nall.\n\n>    For example, assumes it has two branches A and B,  some of the files \n> are modified in both of them. In this case, `/usr/bin/merge` could not \n> be execated, it just have to choose the revision from branch A and \n> discards all the changes from B. For the rest of files, it just simply \n> choose the newest copy from A or B.\n\nI wonder why you say \"could not be executed\".  I take it to mean\nyou just do not want to even when it could.\n\nNow, it is not clear if you always want copy from branch A and\nnot from branch B when both branches have the same path, or you\nwant to pick one at random between A and B.  If branch A kept\nthe file intact and branch B modified it, what do you want to\nhappen?  The default \"merge\" semantics in git (unless you are\nusing \"ours\" strategy) in such a case is always to take the\nversion from branch B.  Is that consistent with what you want?\n\nWhat do you exactly mean \"newest copy from A or B\"?  What are\nyou basing the \"newest\" determination on?  The commit date of A\nand B commits, or the author date ot two?\n\nAssuming that you can give reasonable and consistent answer to\nthe above question to define the semantics of your \"new merge\nalgorithm\", what you would do is to write a new script\ngit-merge-benlau to implement whatever semantics you picked.\nYou could model it after existing merge strategy, such as\ngit-merge-resolve.sh or git-merge-stupid.sh.  Then you give the\nnew merge strategy to \"git-merge\" or \"git-pull\".\n\nFor example, if you want all the usual \"trivial merges\" to work\njust like the default git merge algorithms, but always take\n\"our\" version instead of running file-level merge when both\nsides modified a file, then you start from a copy of\ngit-merge-stupid.sh, and replace \"git-merge-one-file\" with\n\"git-merge-one-file-benlau'.  Copy \"git-merge-one-file.sh\" to\ncreate another new script, \"git-merge-one-file-benlau\", and\nreplace this line:\n\n\tmerge \"$src1\" \"$orig\" \"$src\"\n\nwith\n\n\tcat \"$orig\" >\"$src1\"\n\nand you are done.\n\nI outlined the above without knowing what you really want to\nachieve, and I do not think the resulting merge strategy makes\nmuch sense, but that is what I get form hacking without knowing\nwhat you are really trying to do ;-).\n"},{"id":"13487","messageId":"439C0A60.6070500@ust.hk","threadId":"2800","inReplyTo":"7vbqzonfkx.fsf@assigned-by-dhcp.cox.net","subject":"Re: Branches merging by only overwrite files","fromName":"Ben Lau","fromEmail":"benlau@ust.hk","sentAt":"2005-12-11T11:15:44Z","receivedAt":"2005-12-11T11:15:44Z","isPatch":false,"sender":{"key":"benlau@ust.hk","avatar":null},"body":"Junio C Hamano wrote:\n\n>Ben Lau <benlau@ust.hk> writes:\n>\n>\n>>   I am looking for a solution to merge two branches but do not perform \n>>file level merge. Instead, I wish the result file is the copy from any \n>>one of the branches.\n>>\n>\n>It might be better to state why you need this first.  It could\n>be that what you really want to solve is not related to merge at\n>all.\n>\n>\nSorry for not giving the reason to require this merge strategy. I just \nafraid it need to write too long and discourge people in reading my email.\n\nRecently, besides to use git for kernel's version control. I used it to \nmanage the change of a content management software called xoops. It is a \nPHP system. I have maintained several websites based on this engine.\n\nThose website's code was maintained by CVS in the past. But CVS's branch \nmanagement is quite terrible and therefore each site have their own \nrepository. And now I am going to merge all the sites into a single git \nrepository with multple branches.\n\nSource layout of xoops:\n\nhtml/class\nhtml/themes\nhtml/include\n[[:snipped:]]\nhtml/modules\n\nAs it is module-based CMS system, after install the core system, users \nmay choose to install any module to enchance their site by placing codes \nunder the path of 'html/modules' .\n\nThat means every user must have their own changes. To simplify the \nupgrade process, users just have to replace the old files by newest \nsource , no matter it is the core system or modules.\n\nConsider the following tree:\n\n        v2.0\n       /    \\\n    tag1    v2.2  \n    /   \\     \\\n site1 site2  tag2\n                \\\n              site3\n\nBranches site1 and site2 are dervated from v2.0 and have installed \nseveral different modules. In the tree, it may have another sites \nrunning v2.2 like site3. Now, I am going to upgrade site2 to tag2(based \non v2.2) by merge the branches the produce the tree as follow:\n\n        v2.0\n       /    \\\n    tag1     v2.2  \n    /   \\     \\\n site1   \\   tag2\n          \\  /  \\\n        site2   site3\n\nBut the merge is not smooth, tag2 may contains some modules that are \nnewer then what site2 has been installed. Replace those conflict files \nfrom tag2 should be the simplest method , and that is why I want this \nmerge strategy.\n\n>>   For example, assumes it has two branches A and B,  some of the files \n>>are modified in both of them. In this case, `/usr/bin/merge` could not \n>>be execated, it just have to choose the revision from branch A and \n>>discards all the changes from B. For the rest of files, it just simply \n>>choose the newest copy from A or B.\n>>\n>\n>I wonder why you say \"could not be executed\".  I take it to mean\n>you just do not want to even when it could.\n>\n>\nwell... a typo mistake, should be \"should not be execated\"\n\n>Now, it is not clear if you always want copy from branch A and\n>not from branch B when both branches have the same path, or you\n>want to pick one at random between A and B.  If branch A kept\n>the file intact and branch B modified it, what do you want to\n>happen?  The default \"merge\" semantics in git (unless you are\n>using \"ours\" strategy) in such a case is always to take the\n>version from branch B.  Is that consistent with what you want?\n>\n>What do you exactly mean \"newest copy from A or B\"?  What are\n>you basing the \"newest\" determination on?  The commit date of A\n>and B commits, or the author date ot two?\n>\n>\nIf the file is modified in branch A, choose the revision from A.\nIf branch A kept the file intact and branch B modified it, It could use \nthe branch B's version.\n\nIn fact, It just copy files from branch A to branch B.\n\n>Assuming that you can give reasonable and consistent answer to\n>the above question to define the semantics of your \"new merge\n>algorithm\", what you would do is to write a new script\n>git-merge-benlau to implement whatever semantics you picked.\n>You could model it after existing merge strategy, such as\n>git-merge-resolve.sh or git-merge-stupid.sh.  Then you give the\n>new merge strategy to \"git-merge\" or \"git-pull\".\n>\n>\nhmmm. Do you think my answer make sense? May be I could call it \n\"git-merge-direct-copy\".  Although it just copy and overwrite files from \na branch to another , it could help to manage web-based CMS like xoops \nwhere add-ons are installed by source  within the source tree.\n\n>For example, if you want all the usual \"trivial merges\" to work\n>just like the default git merge algorithms, but always take\n>\"our\" version instead of running file-level merge when both\n>sides modified a file, then you start from a copy of\n>git-merge-stupid.sh, and replace \"git-merge-one-file\" with\n>\"git-merge-one-file-benlau'.  Copy \"git-merge-one-file.sh\" to\n>create another new script, \"git-merge-one-file-benlau\", and\n>replace this line:\n>\n>\tmerge \"$src1\" \"$orig\" \"$src\"\n>\n>with\n>\n>\tcat \"$orig\" >\"$src1\"\n>\n>and you are done.\n>\n>I outlined the above without knowing what you really want to\n>achieve, and I do not think the resulting merge strategy makes\n>much sense, but that is what I get form hacking without knowing\n>what you are really trying to do ;-).\n>\n>\nSpent some times reading the manual and source code, I found similar way \nto implement. But I don't want to waste the effort in coding , that is \nwhy I sent this email out to see would it have any solutions that don't \nrequire to add a new algorithm and changes the source code. If no such \nmethod, then I will start coding, at least it will be useful to me.\n\nThanks!!\n"}]}