{"thread":{"id":"6397","subject":"[RFC] Replace rebase with filtering","startedAt":"2007-01-16T02:41:33Z","lastAt":"2007-01-17T22:21:19Z","messageCount":16,"participants":["Steven Grimm","Johannes Schindelin","Jakub Narebski","Shawn O. Pearce","Brian Gernhardt","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"31793","messageId":"45AC3B5D.6080700@midwinter.com","threadId":"6397","inReplyTo":null,"subject":"[RFC] Replace rebase with filtering","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2007-01-16T02:41:33Z","receivedAt":"2007-01-16T02:41:33Z","isPatch":false,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"Blanket request, so I don't have to keep repeating it: Please correct me \nif I'm wrong about anything below. I'm more familiar with git than I was \na month ago, but still not an expert, so I could be totally off (re)base \nhere. With that note of confidence...\n\nWe have a setup like this:\n\n    (external)\n        |\n   local master\n        |\n   integration\n  /     |     \\\ndev1   dev2  dev3\n\nWe pull changes from the external repository (actually a Subversion \nrepo) into a local master. The integration repo is a clone of that. \nThat's our local setup, but the particulars don't matter here -- I'm \njust using it as an example.\n\nIdeally, we'd rebase the integration area against changes pulled from \nmaster, then each dev repository would rebase against the changes from \nthe integration area. That would keep our histories nice and clean as we \npull changes down from the external repository.\n\nBut of course rebase will get confused and we'll end up re-applying \nchanges in the dev sandboxes as soon as there are any existing change in \nthe integration repo when we pull changes from master, because rebase \nwill turn those existing changes into new revisions that don't match any \npreviously known ones in the dev repositories.\n\nSo at the moment, as far as I can see, the only option is to use merge \nrather than rebase everywhere but the leaf nodes of our repository tree, \nand just live with the cluttered history. The developers will at least \nhave clean *local* histories, but they'll be rebasing onto a cluttered \nhistory from the integration repo.\n\nHowever, they may not want to, even if they can: as soon as I rebase, \nunless everyone is very careful, I have just prevented other developers \nfrom pulling my local commits into their local repositories before I've \npushed my stuff up to the integration area. Sibling-to-sibling pulls  -- \nwhich I hope we all agree are a very useful feature of systems like git \n-- have exactly the same rebase problem as parent-to-child pulls: you'll \nend up re-applying the same changes if the target repo had an earlier \nversion of a newly-rebased chain of commits. So even in our development \nrepos, I suspect we'll want to avoid rebasing unless we're certain we \nwon't ever need to share changes directly with each other, and just live \nwith the clutter.\n\nAll of which made me think, gee, it'd sure be nice if there was a way to \nfilter out those excess merges when we view our branch history. I think \nall it would take would be to mark a merge commit as a rebase-ish update \n(rather than an actual integration where the merge itself is an event \nthat's important to us) and you could, if the user chose, discard those \nmerges from views of the branch history.\n\nAnd then it occurred to me: if we had that, would we actually need \nrebase at all? As far as I know, rebase is all about aesthetics, not \nfunctionality; the reason you rebase instead of merge is that you don't \nwant to wade through zillions of irrelevant merges when you browse your \nproject's history. But if those merges are simply not shown to you, it \nshouldn't matter that they exist. Yes, you will have more objects in \nyour index, but with git's delta compression, you might not even notice \nthe difference.\n\nRebase has an interesting undesirable property aside from messing up \ndownstream clones when they try to pull your latest changes. Since \nrebase preserves the timestamps on your local commits, you almost always \nend up with a situation where the history says almost all your local \ncommits happened before the commit they claim to have been branched \nfrom. That's not too big a problem in most cases, but it sure isn't very \nclean. The underlying problem is that when you rebase you lose not only \nthe history of your intermediate updates, but also the history of your \noriginal branch creation.\n\nFiltering rather than rewriting history would fix all of that. We could \neasily report that branch XYZ was forked from branch ABC on 01/03/2006 \nand is up to date with all of ABC's changes up to 01/18/2006 (i.e., \ndisplay information about the initial branch and the most recent update \nmerge, but none of the ones in between.) The timestamps all make sense \nbecause you haven't lost the history. And if someone has cloned your \nrepository, they can keep pulling updates without anything breaking.\n\nIt might also, be possible to implement an after-the-fact rebase to \nreduce the number of excess commits: a command that rebases all the \nupdate merges older than a certain age, on the theory that you can \nusually put an upper bound on how out-of-date someone's clone of your \nrepo is allowed to get. That would rewrite just the ancient history, not \ntouching anything recent, and would mark the newly-created revisions \nsuch that pull could skip fetching them if the target already has the \nmore recent revisions. (The revision at which you stop rebasing should \nend up with the same revision ID as the one in the actual history, since \nthe contents should match.) If that's not clear I can draw a picture. \nHaven't thought that bit through too much so it might not be feasible in \nthe end, but it seems like in theory we have all the information we need \nto resolve conflicts, etc.\n\nComments? Am I fundamentally misunderstanding how rebase works and/or \nwhy the documentation warns people away from using it in repos that \nmight be pulled from?\n\n-Steve\n"},{"id":"31812","messageId":"Pine.LNX.4.63.0701161216440.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6397","inReplyTo":"45AC3B5D.6080700@midwinter.com","subject":"Re: [RFC] Replace rebase with filtering","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-16T11:18:18Z","receivedAt":"2007-01-16T11:18:18Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 15 Jan 2007, Steven Grimm wrote:\n\n> Ideally, we'd rebase the integration area against changes pulled from \n> master, then each dev repository would rebase against the changes from \n> the integration area. That would keep our histories nice and clean as we \n> pull changes down from the external repository.\n> \n> But of course rebase will get confused and we'll end up re-applying \n> changes in the dev sandboxes as soon as there are any existing change in \n> the integration repo when we pull changes from master, because rebase \n> will turn those existing changes into new revisions that don't match any \n> previously known ones in the dev repositories.\n\nI had the impression that the use of \"--ignore-if-in-upstream\" in \ngit-rebase avoids exactly this case: re-applying changes which are already \nin upstream.\n\nDoesn't it work that way?\n\nCiao,\nDscho\n"},{"id":"31836","messageId":"45AD2568.4040408@midwinter.com","threadId":"6397","inReplyTo":"Pine.LNX.4.63.0701161216440.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [RFC] Replace rebase with filtering","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2007-01-16T19:20:08Z","receivedAt":"2007-01-16T19:20:08Z","isPatch":false,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"Johannes Schindelin wrote:\n> I had the impression that the use of \"--ignore-if-in-upstream\" in \n> git-rebase avoids exactly this case: re-applying changes which are already \n> in upstream.\n>\n> Doesn't it work that way?\n>   \n\nWhere's that option documented? The manpage makes no mention of it at all.\n\n-Steve\n"},{"id":"31837","messageId":"45AD2AE7.2010908@midwinter.com","threadId":"6397","inReplyTo":"45AD2568.4040408@midwinter.com","subject":"Re: [RFC] Replace rebase with filtering","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2007-01-16T19:43:35Z","receivedAt":"2007-01-16T19:43:35Z","isPatch":false,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"Steven Grimm wrote:\n> Johannes Schindelin wrote:\n>> I had the impression that the use of \"--ignore-if-in-upstream\" in \n>> git-rebase avoids exactly this case: re-applying changes which are \n>> already in upstream.  \n> Where's that option documented? The manpage makes no mention of it at \n> all.\n\nAh, okay, poking around in the git-rebase source, I see you mean that \ngit-format-patch is called with that option. Gotcha. The problem is that \nafter a rebase, the revisions in question *aren't* in the upstream. \nHere's my understanding of why. Say I have this in my integration \nrepository:\n\na---b---c---d (master)\n \\\n  e---f---g   (integration)\n\nNow, I rebase the integration branch onto master:\n\na---b---c---d\n             \\\n              e'---f'---g'\n\nThe problem is that, since e' contains all the changes in e *and* in \nb/c/d, it does not have the same SHA1 as the original e revision, nor in \nfact the same hash as any of the revisions in the pre-rebase tree. And \nafter rebase succeeds, it wipes the original e, f, and g from the \nhistory of the integration branch.\n\nWhen a clone fetches e', f', and g' from this repo and tries to rebase \nonto the integration branch, git-format-patch will think b, c, and d are \nnew (correct) but also that e', f', and g' are new. Since they have \npreviously unknown hashes and there's no record of the original e, f, \nand g or their relation to the new revisions -- at least, no record that \ngets pulled down to the clone when it fetches -- there's no way for \ngit-format-patch to know that it has already applied those changes.\n\nAs always, correct me if I'm wrong -- that's my understanding of the \nproblem with rebasing in a parent repository.\n\n-Steve\n"},{"id":"31844","messageId":"Pine.LNX.4.63.0701162131130.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6397","inReplyTo":"45AD2AE7.2010908@midwinter.com","subject":"Re: [RFC] Replace rebase with filtering","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-16T20:35:25Z","receivedAt":"2007-01-16T20:35:25Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 16 Jan 2007, Steven Grimm wrote:\n\n> Steven Grimm wrote:\n> > Johannes Schindelin wrote:\n> > > I had the impression that the use of \"--ignore-if-in-upstream\" in\n> > > git-rebase avoids exactly this case: re-applying changes which are already\n> > > in upstream.  \n> > Where's that option documented? The manpage makes no mention of it at all.\n> \n> Ah, okay, poking around in the git-rebase source, I see you mean that\n> git-format-patch is called with that option. Gotcha. The problem is that after\n> a rebase, the revisions in question *aren't* in the upstream. Here's my\n> understanding of why. Say I have this in my integration repository:\n> \n> a---b---c---d (master)\n> \\\n>  e---f---g   (integration)\n> \n> Now, I rebase the integration branch onto master:\n> \n> a---b---c---d\n>             \\\n>              e'---f'---g'\n> \n> The problem is that, since e' contains all the changes in e *and* in \n> b/c/d, it does not have the same SHA1 as the original e revision, nor in \n> fact the same hash as any of the revisions in the pre-rebase tree. And \n> after rebase succeeds, it wipes the original e, f, and g from the \n> history of the integration branch.\n\nThat is correct, but --ignore-if-in-upstream actually tests the hash of \nthe _diff_, not of the commit. So, if c really introduces the same change \nas f (i.e. the diffs are identical), git-rebase will ignore f:\n\na---b---c---d\n             \\\n              e'---g'\n\nTotally untested, of course. But this is what --ignore-if-in-upstream was \nwritten for.\n\nCiao,\nDscho\n"},{"id":"31845","messageId":"45AD383E.50105@midwinter.com","threadId":"6397","inReplyTo":"Pine.LNX.4.63.0701162131130.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [RFC] Replace rebase with filtering","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2007-01-16T20:40:30Z","receivedAt":"2007-01-16T20:40:30Z","isPatch":false,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"Johannes Schindelin wrote:\n> That is correct, but --ignore-if-in-upstream actually tests the hash of \n> the _diff_, not of the commit. So, if c really introduces the same change \n> as f (i.e. the diffs are identical), git-rebase will ignore f:\n>\n> a---b---c---d\n>              \\\n>               e'---g'\n>\n> Totally untested, of course. But this is what --ignore-if-in-upstream was \n> written for.\n>   \n\nOkay, great, that is certainly an improvement over what I thought was \nhappening. But it won't work if you had to manually resolve a conflict \nduring the rebase, yes? In that case the diffs would presumably not match.\n\n-Steve\n"},{"id":"31847","messageId":"eojf73$1f4$1@sea.gmane.org","threadId":"6397","inReplyTo":"45AD383E.50105@midwinter.com","subject":"Re: [RFC] Replace rebase with filtering","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-01-16T21:14:42Z","receivedAt":"2007-01-16T21:14:42Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Steven Grimm wrote:\n\n> Johannes Schindelin wrote:\n>> That is correct, but --ignore-if-in-upstream actually tests the hash of \n>> the _diff_, not of the commit. So, if c really introduces the same change \n>> as f (i.e. the diffs are identical), git-rebase will ignore f:\n>>\n>> a---b---c---d\n>>              \\\n>>               e'---g'\n>>\n>> Totally untested, of course. But this is what --ignore-if-in-upstream was \n>> written for.\n>>   \n> \n> Okay, great, that is certainly an improvement over what I thought was \n> happening. But it won't work if you had to manually resolve a conflict \n> during the rebase, yes? In that case the diffs would presumably not match.\n\nThen git-rerere would help, I think.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"31848","messageId":"Pine.LNX.4.63.0701162218070.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6397","inReplyTo":"45AD383E.50105@midwinter.com","subject":"Re: [RFC] Replace rebase with filtering","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-16T21:20:31Z","receivedAt":"2007-01-16T21:20:31Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 16 Jan 2007, Steven Grimm wrote:\n\n> Johannes Schindelin wrote:\n> > That is correct, but --ignore-if-in-upstream actually tests the hash of the\n> > _diff_, not of the commit. So, if c really introduces the same change as f\n> > (i.e. the diffs are identical), git-rebase will ignore f:\n> > \n> > a---b---c---d\n> >              \\\n> >               e'---g'\n> > \n> > Totally untested, of course. But this is what --ignore-if-in-upstream was\n> > written for.\n> >   \n> \n> Okay, great, that is certainly an improvement over what I thought was\n> happening. But it won't work if you had to manually resolve a conflict during\n> the rebase, yes? In that case the diffs would presumably not match.\n\nCorrect. There is no automatic way any program could verify that such a \npatch is indeed what is already in upstream.\n\nUsually, however, this results in a conflict which you have to resolve. \nAnd _you_ do not have a hard time verifying that the patch already went \nin, and you just say \"git rebase --skip\" and the rebasing will continue \n_without_ having committed the now obsolete patch.\n\nCiao,\nDscho\n"},{"id":"31850","messageId":"20070116212219.GA29434@spearce.org","threadId":"6397","inReplyTo":"eojf73$1f4$1@sea.gmane.org","subject":"Re: [RFC] Replace rebase with filtering","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-01-16T21:22:19Z","receivedAt":"2007-01-16T21:22:19Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Jakub Narebski <jnareb@gmail.com> wrote:\n> Steven Grimm wrote:\n> > Okay, great, that is certainly an improvement over what I thought was \n> > happening. But it won't work if you had to manually resolve a conflict \n> > during the rebase, yes? In that case the diffs would presumably not match.\n> \n> Then git-rerere would help, I think.\n\nNo, because rerere only helps to recall a prior conflict resolution.\nHere Steven is talking about having rebase intelligently realize that\nthe upstream has accepted a patch, but did so by modifying it first.\nThere really isn't a solution to the problem.\n\npg tried to do this by applying several patches at once until\nsomething matched.  If the upstream fixed a line like \"a=b\" to\nbe \"a = b\" then this would *never* match, and pg would abort.\nStGIT runs the patches backwards.  A much smarter approach then\nwhat pg tried to do, but again, \"a = b\" would never match.\n\n-- \nShawn.\n"},{"id":"31849","messageId":"Pine.LNX.4.63.0701162220460.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6397","inReplyTo":"eojf73$1f4$1@sea.gmane.org","subject":"Re: [RFC] Replace rebase with filtering","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-16T21:23:12Z","receivedAt":"2007-01-16T21:23:12Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 16 Jan 2007, Jakub Narebski wrote:\n\n> Steven Grimm wrote:\n> \n> > Johannes Schindelin wrote:\n> >> That is correct, but --ignore-if-in-upstream actually tests the hash of \n> >> the _diff_, not of the commit. So, if c really introduces the same change \n> >> as f (i.e. the diffs are identical), git-rebase will ignore f:\n> >>\n> >> a---b---c---d\n> >>              \\\n> >>               e'---g'\n> >>\n> >> Totally untested, of course. But this is what --ignore-if-in-upstream was \n> >> written for.\n> >>   \n> > \n> > Okay, great, that is certainly an improvement over what I thought was \n> > happening. But it won't work if you had to manually resolve a conflict \n> > during the rebase, yes? In that case the diffs would presumably not match.\n> \n> Then git-rerere would help, I think.\n\nAFAICT no. First, git-rerere can only resolve conflicts for which it has \nseen a conflict resolution. Unlikely here.\n\nWorse, the way git-rerere would _have_ to resolve the conflict, a commit \nwould _fail_ (since no change should be committed if a munged version of \nit was already applied).\n\nCiao,\nDscho\n"},{"id":"31853","messageId":"eojh8r$9e6$1@sea.gmane.org","threadId":"6397","inReplyTo":"Pine.LNX.4.63.0701162218070.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [RFC] Replace rebase with filtering","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-01-16T21:49:45Z","receivedAt":"2007-01-16T21:49:45Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Johannes Schindelin wrote:\n\n> Usually, however, this results in a conflict which you have to resolve. \n> And _you_ do not have a hard time verifying that the patch already went \n> in, and you just say \"git rebase --skip\" and the rebasing will continue \n> _without_ having committed the now obsolete patch.\n\nUnfortunately, at least with git 1.4.4.x, not quite. You have to have\nindex clean to do \"git rebase --skip\", while usually there would be\nconflict when applying patch that is already present some deeper.\n\nI think that is a bug in git-rebase.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"31855","messageId":"2696299C-A54D-4A7E-BA3B-029C8E4B278D@silverinsanity.com","threadId":"6397","inReplyTo":"eojh8r$9e6$1@sea.gmane.org","subject":"Re: [RFC] Replace rebase with filtering","fromName":"Brian Gernhardt","fromEmail":"benji@silverinsanity.com","sentAt":"2007-01-16T22:31:15Z","receivedAt":"2007-01-16T22:31:15Z","isPatch":false,"sender":{"key":"benji@silverinsanity.com","avatar":"https://gravatar.com/avatar/e06c101dbc25c68114d859b4a9ec7cf8a2c52fd2b0270ef0eac0e2e63ff22311?d=mp&s=160"},"body":"\nOn Jan 16, 2007, at 4:49 PM, Jakub Narebski wrote:\n\n> Johannes Schindelin wrote:\n>\n>> Usually, however, this results in a conflict which you have to  \n>> resolve.\n>> And _you_ do not have a hard time verifying that the patch already  \n>> went\n>> in, and you just say \"git rebase --skip\" and the rebasing will  \n>> continue\n>> _without_ having committed the now obsolete patch.\n>\n> Unfortunately, at least with git 1.4.4.x, not quite. You have to have\n> index clean to do \"git rebase --skip\", while usually there would be\n> conflict when applying patch that is already present some deeper.\n>\n> I think that is a bug in git-rebase.\n\nAgreed.  I tend to \"git checkout HEAD -- files\" before a \"git rebase  \n--skip\" to fix that, although I guess \"git reset --hard\" would work  \njust the same.  But by saying \"--skip\" means \"these changes are  \nirrelevant\", so it should clean up after itself.  It's a definite  \nusability snafu.\n\nI'd put a simple patch to add the reset to git-merge.sh, but I'm not  \nsure I understand what --skip is doing in there with a 30 second  \npeek.  Maybe if I get more tuits, I'll do it, but someone more  \nfamiliar with it can probably do it much faster (and be more certain  \nit's the right thing to do).\n\n~~ Brian\n"},{"id":"31859","messageId":"Pine.LNX.4.63.0701162350150.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6397","inReplyTo":"2696299C-A54D-4A7E-BA3B-029C8E4B278D@silverinsanity.com","subject":"Re: [RFC] Replace rebase with filtering","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-16T22:51:36Z","receivedAt":"2007-01-16T22:51:36Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 16 Jan 2007, Brian Gernhardt wrote:\n\n> I'd put a simple patch to add the reset to git-merge.sh, but I'm not sure I\n> understand what --skip is doing in there with a 30 second peek.\n\nBetter put \"git reset --hard\" into git-rebase.sh... Just search for \n\"--skip\" and you will find where it has to go.\n\n> Maybe if I get more tuits, I'll do it, but someone more familiar with it \n> can probably do it much faster (and be more certain it's the right thing \n> to do).\n\nBut if _you_ do it, you gain knowledge about git!\n\nCiao,\nDscho\n"},{"id":"31860","messageId":"7vwt3mwpll.fsf@assigned-by-dhcp.cox.net","threadId":"6397","inReplyTo":"Pine.LNX.4.63.0701162350150.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [RFC] Replace rebase with filtering","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-16T22:53:26Z","receivedAt":"2007-01-16T22:53:26Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n>> I'd put a simple patch to add the reset to git-merge.sh, but I'm not sure I\n>> understand what --skip is doing in there with a 30 second peek.\n>\n> Better put \"git reset --hard\" into git-rebase.sh... Just search for \n> \"--skip\" and you will find where it has to go.\n\nI'd later want to allow starting rebase from a dirty working\ntree as long as the rebasing of the entire series would not\nconflict with the local changes, so I would seriously prefer a\nsolution without \"reset --hard\".\n"},{"id":"31862","messageId":"Pine.LNX.4.63.0701162357270.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6397","inReplyTo":"7vwt3mwpll.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC] Replace rebase with filtering","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-16T22:57:38Z","receivedAt":"2007-01-16T22:57:38Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 16 Jan 2007, Junio C Hamano wrote:\n\n> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n> \n> >> I'd put a simple patch to add the reset to git-merge.sh, but I'm not sure I\n> >> understand what --skip is doing in there with a 30 second peek.\n> >\n> > Better put \"git reset --hard\" into git-rebase.sh... Just search for \n> > \"--skip\" and you will find where it has to go.\n> \n> I'd later want to allow starting rebase from a dirty working\n> tree as long as the rebasing of the entire series would not\n> conflict with the local changes, so I would seriously prefer a\n> solution without \"reset --hard\".\n\nFair enough.\n\nCiao,\nDscho\n"},{"id":"31926","messageId":"45AEA15F.70001@midwinter.com","threadId":"6397","inReplyTo":"Pine.LNX.4.63.0701162218070.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [RFC] Replace rebase with filtering","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2007-01-17T22:21:19Z","receivedAt":"2007-01-17T22:21:19Z","isPatch":false,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"  Johannes Schindelin wrote:\n>> Okay, great, that is certainly an improvement over what I thought was\n>> happening. But it won't work if you had to manually resolve a conflict during\n>> the rebase, yes? In that case the diffs would presumably not match.\n>>     \n> Correct. There is no automatic way any program could verify that such a \n> patch is indeed what is already in upstream.\n>   \n\nWell, yes there is, in fact: don't forget the existing history like \nrebase currently does. Merge doesn't have the same problem. That's kind \nof the crux of what I'm proposing here: if you change the implementation \nof git's \"Don't clutter my history with meaningless merges\" feature from \na history-lossy operation (rebase as it stands today) to a display-time \nfilter (regular merge with an added \"I'm just an update\" marker) then \nthis problem evaporates and it becomes safe to clone *any* repository \nand pull updates from it, not just ones where the owner is being careful \nnever to run rebase when there are pending changes.\n\nI think filtering is consistent with the way git does other things. \nRenames would be the big example; they are detected after the fact and \ndealt with at the point where they're actually relevant to what the user \nis doing (merging, etc.) rather than appearing as an explicit part of \nthe repository's history. Why shouldn't no-op \"sync with upstream\" \nchanges work the same way?\n\n> Usually, however, this results in a conflict which you have to resolve. \n> And _you_ do not have a hard time verifying that the patch already went \n> in, and you just say \"git rebase --skip\" and the rebasing will continue \n> _without_ having committed the now obsolete patch.\n>   \n\nTrue enough, but if the computer can retain the information it needs to \ndo that for me (which it does if I merge instead of rebase) then why \nshouldn't it?\n\n-Steve\n"}]}