{"thread":{"id":"9444","subject":"Workflow question: A case for git-rebase?","startedAt":"2007-08-08T21:11:22Z","lastAt":"2007-08-09T20:30:56Z","messageCount":4,"participants":["Thomas Adam","Johannes Schindelin","Jan Hudec"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"50238","messageId":"18071eea0708081411p41eaa44ai105adaef0e4b10a5@mail.gmail.com","threadId":"9444","inReplyTo":null,"subject":"Workflow question: A case for git-rebase?","fromName":"Thomas Adam","fromEmail":"thomas.adam22@gmail.com","sentAt":"2007-08-08T21:11:22Z","receivedAt":"2007-08-08T21:11:22Z","isPatch":false,"sender":{"key":"thomas.adam22@gmail.com","avatar":"https://gravatar.com/avatar/137f9858bc6bfd5b2f743aefd988c81ce0cbd306248889df80e269519cfc8741?d=mp&s=160"},"body":"Hello all,\n\nSo we've (as in my place of work) have switched from SVN to GIT\nalthough I do have a few questions -- hopefully they're not too\nobvious. :)\n\nWe have our master branch which is where all the latest changes are\nadded to as a \"remote shared repository which everyone pushes and\npulls to. That's emulating pretty much what SVN did -- which is\nfine.\n\nAs for myself, I maintain _locally_ a few branches (branchX, branchY)\nwhich dictate some bits and pieces I'm working on. Periodically, I\nwill tend to merge either merge to master and then push those changes\nout. So far so good...\n\nBut, I've now come up against a case whereby if one of my colleagues\nchanges a file (call it fileA) in branch master, and, in the course of\nmy working in branchX means i modify fileA also, when I come to merge\nbranchX into master I find the original change in master (as submitted\nby my colleague) being reverted by my changes in branchX. Luckily I\ndon't commit that since I do a git-diff beforehand. :)\n\nOne suggest solution to this is to merge master into branchX/branchY\nperiodically, although this has the same problems as described when I\ntry to merge -- if I'm going to make branchX the same as master, I\nmight as well just work in master and be done with it, right?\n\nSo I was wondering if it's fine to branch from master at any given\npoint and perhaps use git-rebasse when I come to merge? Is this even\nthe correct mode of working? Indeed, there might be times when\ngit-rebase isn't necessary if a merge to master from branchX or\nbranchY won't revert a commit in master because that file had been\nedited, so how do I determine when to use git-rebase in this case? Or\nis that the correct indicator?\n\nI do hope that makes sense.\n\nKindly,\n\nThomas Adam\n"},{"id":"50246","messageId":"Pine.LNX.4.64.0708082246370.21857@racer.site","threadId":"9444","inReplyTo":"18071eea0708081411p41eaa44ai105adaef0e4b10a5@mail.gmail.com","subject":"Re: Workflow question: A case for git-rebase?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-08-08T21:47:50Z","receivedAt":"2007-08-08T21:47:50Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 8 Aug 2007, Thomas Adam wrote:\n\n> As for myself, I maintain _locally_ a few branches (branchX, branchY)\n> which dictate some bits and pieces I'm working on. Periodically, I\n> will tend to merge either merge to master and then push those changes\n> out. So far so good...\n> \n> But, I've now come up against a case whereby if one of my colleagues\n> changes a file (call it fileA) in branch master, and, in the course of\n> my working in branchX means i modify fileA also, when I come to merge\n> branchX into master I find the original change in master (as submitted\n> by my colleague) being reverted by my changes in branchX.\n\nI have a hard time seeing that. If you touch the same code, \nunidentically, merge-recursive will not be nice to you: it will show \nconflicts, and you have to resolve them.\n\nOr do you use \"-s ours\"?\n\nCiao,\nDscho\n"},{"id":"50248","messageId":"18071eea0708081456l2ff1b73dy90ef33c1b5058c77@mail.gmail.com","threadId":"9444","inReplyTo":"Pine.LNX.4.64.0708082246370.21857@racer.site","subject":"Re: Workflow question: A case for git-rebase?","fromName":"Thomas Adam","fromEmail":"thomas.adam22@gmail.com","sentAt":"2007-08-08T21:56:33Z","receivedAt":"2007-08-08T21:56:33Z","isPatch":false,"sender":{"key":"thomas.adam22@gmail.com","avatar":"https://gravatar.com/avatar/137f9858bc6bfd5b2f743aefd988c81ce0cbd306248889df80e269519cfc8741?d=mp&s=160"},"body":"On 08/08/07, Johannes Schindelin wrote:\n> Hi,\n>\n> On Wed, 8 Aug 2007, Thomas Adam wrote:\n>\n> > As for myself, I maintain _locally_ a few branches (branchX, branchY)\n> > which dictate some bits and pieces I'm working on. Periodically, I\n> > will tend to merge either merge to master and then push those changes\n> > out. So far so good...\n> >\n> > But, I've now come up against a case whereby if one of my colleagues\n> > changes a file (call it fileA) in branch master, and, in the course of\n> > my working in branchX means i modify fileA also, when I come to merge\n> > branchX into master I find the original change in master (as submitted\n> > by my colleague) being reverted by my changes in branchX.\n>\n> I have a hard time seeing that. If you touch the same code,\n> unidentically, merge-recursive will not be nice to you: it will show\n> conflicts, and you have to resolve them.\n>\n> Or do you use \"-s ours\"?\n\nNo, nothing like that. I have had a situation where by a merge from\nbranchX to master has resulted in master's changes to fileA being\nreverted based on what was in the contents of fileA in branchX -- this\nis of course wrong though -- master hsa the most recent copy. My\nsolution therefore was to cherry pick the commit into branchX and\nremerge into master. This is why I was forced to ask about whether or\nnot git-rebase was the correct way to go.\n\nAlthough I suppose this leads me to the ancillory question of: At the\npoint I merged master into branchX did this cause any problems for any\nfuture merges of branchX into master? I cannot recall if this\n\"revert scenario\" I describe to master happened pre or past my merge\nof master into branchX, but I suspect it was after I had merged master\ninto branchX.\n\n-- Thomas Adam\n"},{"id":"50341","messageId":"20070809203056.GB4567@efreet.light.src","threadId":"9444","inReplyTo":"18071eea0708081456l2ff1b73dy90ef33c1b5058c77@mail.gmail.com","subject":"Re: Workflow question: A case for git-rebase?","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2007-08-09T20:30:56Z","receivedAt":"2007-08-09T20:30:56Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Wed, Aug 08, 2007 at 22:56:33 +0100, Thomas Adam wrote:\n> On 08/08/07, Johannes Schindelin wrote:\n> > Hi,\n> >\n> > On Wed, 8 Aug 2007, Thomas Adam wrote:\n> >\n> > > As for myself, I maintain _locally_ a few branches (branchX, branchY)\n> > > which dictate some bits and pieces I'm working on. Periodically, I\n> > > will tend to merge either merge to master and then push those changes\n> > > out. So far so good...\n> > >\n> > > But, I've now come up against a case whereby if one of my colleagues\n> > > changes a file (call it fileA) in branch master, and, in the course of\n> > > my working in branchX means i modify fileA also, when I come to merge\n> > > branchX into master I find the original change in master (as submitted\n> > > by my colleague) being reverted by my changes in branchX.\n> >\n> > I have a hard time seeing that. If you touch the same code,\n> > unidentically, merge-recursive will not be nice to you: it will show\n> > conflicts, and you have to resolve them.\n> >\n> > Or do you use \"-s ours\"?\n> \n> No, nothing like that. I have had a situation where by a merge from\n> branchX to master has resulted in master's changes to fileA being\n> reverted based on what was in the contents of fileA in branchX -- this\n> is of course wrong though -- master hsa the most recent copy. My\n> solution therefore was to cherry pick the commit into branchX and\n> remerge into master. This is why I was forced to ask about whether or\n> not git-rebase was the correct way to go.\n\nGit rebase is a correct way to go, with advantage of resulting in simpler\nhistory and disadvantage of slightly harder conflict resolution (since you\nmerge commit-at-a-time rather than in one big block). However merge is\nequally correct way to go.\n\nEither there is a bug in merge -- which I would consider rather unlikely,\nthough not impossible -- or you actually did, probably unintentionally, undo\nthe master's changes. This might happen if:\n\n - You try to merge, either in --no-commit mode, or have a conflict, so it's\n not commited.\n - Then decide you don't want to resolve now and undo the\n changes by checking out the files, but don't clean the information about\n merge in progress.\n - Commit some changes in such state. This records a merge, that revers all\n changes from master.\n\nSimilarly attempt to merge just part of files would result in a problem like\nyou describe -- merging is only supported on whole trees.\n\n> Although I suppose this leads me to the ancillory question of: At the\n> point I merged master into branchX did this cause any problems for any\n> future merges of branchX into master? I cannot recall if this\n> \"revert scenario\" I describe to master happened pre or past my merge\n> of master into branchX, but I suspect it was after I had merged master\n> into branchX.\n\nMerge is completely symetrical operation in git. Merging branchX into master\nand merging master into branchX is the same for all purposes whatsoever\n(though you can tell how you did it by order of the parsent in the commit\nobjecT).\n\nRepeated merges between two branches are allowed and always correct thing to do.\nHowever, you should be aware, that attempt to reject a change will be\nrecorded as a reversal and merged as such. You can try visualizing the\nsituation before the merge with:\n gitk master-before-merge...branchX-before-merge\n (or equivalently: gitk merge-result^...merge-result^2)\nprint the base revision with:\n git merge-base master-before-merge...branchX-before-merge\n (or equivalently: git merge-base merge-result^...merge-result^2)\nlook it up the graph and contemplate at what could have caused the reversal.\nI expect you can't disclose the code to ask anybody help you with that.\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec \n"}]}