{"thread":{"id":"5623","subject":"git pull for update of netdev fails.","startedAt":"2006-09-20T15:03:08Z","lastAt":"2006-09-25T12:47:38Z","messageCount":43,"participants":["Stephen Hemminger","Linus Torvalds","Petr Baudis","Johannes Schindelin","Junio C Hamano","Shawn Pearce","Jeff Garzik","Jakub Narebski","Krzysztof Halasa","Catalin Marinas"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"27232","messageId":"20060920080308.673a1e93@localhost.localdomain","threadId":"5623","inReplyTo":null,"subject":"git pull for update of netdev fails.","fromName":"Stephen Hemminger","fromEmail":"shemminger@osdl.org","sentAt":"2006-09-20T15:03:08Z","receivedAt":"2006-09-20T15:03:08Z","isPatch":false,"sender":{"key":"shemminger@osdl.org","avatar":null},"body":"Jeff, you use branches on the netdev tree, but GIT doesn't seem to like\nto sync these up properly. My normal method is to keep a clone'd version\nof the netdev tree and use pull to resync it. I don't do any changes\nto that tree.\n\nThis doesn't work with all the branches for some reason. Is this a git\nbug?\n\n\n$ git pull\nGenerating pack...\nDone counting 666 objects.\nResult has 400 objects.\nDeltifying 400 objects.\n 100% (400/400) done\nUnpacking 400 objects\nTotal 400, written 400 (delta 324), reused 0 (delta 0)\n 100% (400/400) done\n* refs/heads/origin: fast forward to branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6\n from f04b92e97d21b1921c91ec1d6d5e8bbf8606b77a to e478bec0ba0a83a48a0f6982934b6de079e7e6b3\n* refs/heads/e100-sbit: does not fast forward to branch 'e100-sbit' of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6;\n not updating.\n\nA temporary workaround is to prune the offending branches locally\nfirst, but that seems like a hack.\n"},{"id":"27235","messageId":"Pine.LNX.4.64.0609200816400.4388@g5.osdl.org","threadId":"5623","inReplyTo":"20060920080308.673a1e93@localhost.localdomain","subject":"Re: git pull for update of netdev fails.","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-09-20T15:28:08Z","receivedAt":"2006-09-20T15:28:08Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 20 Sep 2006, Stephen Hemminger wrote:\n> \n> This doesn't work with all the branches for some reason. Is this a git\n> bug?\n\nIt's a \"Jeff bug\". He rebases some of his branches, and git by default \nrefuses to throw away the old data (so if the new branch is not a fast \nforward, it will _not_ just silently throw away the old state).\n\nHowever, you can tell git that Jeff is being difficult by marking such \nbranches individually as being rebased.\n\nThe git archive itself has one such branch: Junio re-writes the \"pu\" \nbranch all the time, and so it seldom fast-forwards nicely (the thing \nabout a fast forward is that you do _not_ lose any old history, you only \nappend to it, while a rebase will throw the old history away and generate \nnew history in its place).\n\nSo for example, for git itself, you might have a \"remotes\" file like mine:\n\n\t[torvalds@g5 git]$ cat .git/remotes/parent \n\tURL: master.kernel.org:/pub/scm/git/git\n\tPull: master:parent\n\tPull: next:next\n\tPull: +pu:pu\n\nwhich just says that the \"parent\" repo is the master repo for git, and \nnotice how the \"Pull: +pu:pu\" line has that extra \"+\" at the head. That's \na marker that the remote \"pu\" branch (which is fetched into the _local_ \n\"pu\" branch) should be updated even if it doesn't fast-forward.\n\nSo you could either mark _all_ the remote branches with the extra \"+\" (to \nsay that you always want to fetch that exact state for whatever branch \nyou're tracking), or you can ask Jeff which branches he expects to do \nstrange things and just mark those individual ones.\n\n> A temporary workaround is to prune the offending branches locally\n> first, but that seems like a hack.\n\nSo there's a non-hack version of this as per above, and it's even \ndocumented, although hard to find (see Documentation/pull-fetch-param.txt)\n\n\t\tLinus\n"},{"id":"27238","messageId":"20060920155431.GO8259@pasky.or.cz","threadId":"5623","inReplyTo":"Pine.LNX.4.64.0609200816400.4388@g5.osdl.org","subject":"Re: git pull for update of netdev fails.","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-09-20T15:54:31Z","receivedAt":"2006-09-20T15:54:31Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Wed, Sep 20, 2006 at 05:28:08PM CEST, I got a letter\nwhere Linus Torvalds said that...\n> However, you can tell git that Jeff is being difficult by marking such \n> branches individually as being rebased.\n\nThis is really a wrong way of describing the problem - I'd say that Git\nis being difficult here. The point is, the subsystem maintainers need to\nmaintain stacks of patches and rebase against the main kernel branch\nregularily, and they want to still publish their current state. So it's\nnot really any of them being strange or difficult, but Git being so\nbecause it has no seamless support for tracking those branches.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nSnow falling on Perl. White noise covering line noise.\nHides all the bugs too. -- J. Putnam\n"},{"id":"27239","messageId":"Pine.LNX.4.63.0609201801110.19042@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"5623","inReplyTo":"20060920155431.GO8259@pasky.or.cz","subject":"Re: git pull for update of netdev fails.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-09-20T16:02:43Z","receivedAt":"2006-09-20T16:02:43Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 20 Sep 2006, Petr Baudis wrote:\n\n> Dear diary, on Wed, Sep 20, 2006 at 05:28:08PM CEST, I got a letter\n> where Linus Torvalds said that...\n> > However, you can tell git that Jeff is being difficult by marking such \n> > branches individually as being rebased.\n> \n> This is really a wrong way of describing the problem - I'd say that Git\n> is being difficult here. The point is, the subsystem maintainers need to\n> maintain stacks of patches and rebase against the main kernel branch\n> regularily, and they want to still publish their current state. So it's\n> not really any of them being strange or difficult, but Git being so\n> because it has no seamless support for tracking those branches.\n\nSo, what exactly do you propose? I do not see any way to help this \nproblem, since you really throw away history. So, the \ngit-is-being-difficult has to be taken with a pound of salt here.\n\nCiao,\nDscho\n"},{"id":"27240","messageId":"7vhcz2jzfd.fsf@assigned-by-dhcp.cox.net","threadId":"5623","inReplyTo":"20060920155431.GO8259@pasky.or.cz","subject":"Re: git pull for update of netdev fails.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-09-20T16:05:58Z","receivedAt":"2006-09-20T16:05:58Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis writes:\n\n> Dear diary, on Wed, Sep 20, 2006 at 05:28:08PM CEST, I got a letter\n> where Linus Torvalds said that...\n>> However, you can tell git that Jeff is being difficult by marking such \n>> branches individually as being rebased.\n>\n> This is really a wrong way of describing the problem - I'd say that Git\n> is being difficult here. The point is, the subsystem maintainers need to\n> maintain stacks of patches and rebase against the main kernel branch\n> regularily, and they want to still publish their current state. So it's\n> not really any of them being strange or difficult, but Git being so\n> because it has no seamless support for tracking those branches.\n\nSeamless support is there and Linus described how without\nbreaking the usual \"if not fast forward you may lose some\npatches so be extra careful\" safety valve.\n\nI do not see what your problem is.\n"},{"id":"27242","messageId":"20060920160756.GP8259@pasky.or.cz","threadId":"5623","inReplyTo":"Pine.LNX.4.63.0609201801110.19042@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: git pull for update of netdev fails.","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-09-20T16:07:56Z","receivedAt":"2006-09-20T16:07:56Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":" Hi,\n\nDear diary, on Wed, Sep 20, 2006 at 06:02:43PM CEST, I got a letter\nwhere Johannes Schindelin said that...\n> On Wed, 20 Sep 2006, Petr Baudis wrote:\n> \n> > Dear diary, on Wed, Sep 20, 2006 at 05:28:08PM CEST, I got a letter\n> > where Linus Torvalds said that...\n> > > However, you can tell git that Jeff is being difficult by marking such \n> > > branches individually as being rebased.\n> > \n> > This is really a wrong way of describing the problem - I'd say that Git\n> > is being difficult here. The point is, the subsystem maintainers need to\n> > maintain stacks of patches and rebase against the main kernel branch\n> > regularily, and they want to still publish their current state. So it's\n> > not really any of them being strange or difficult, but Git being so\n> > because it has no seamless support for tracking those branches.\n> \n> So, what exactly do you propose? I do not see any way to help this \n> problem, since you really throw away history. So, the \n> git-is-being-difficult has to be taken with a pound of salt here.\n\n I personally don't think \"throwing away\" history is an issue. You can\nprint the old sha1 and it is still in the database so you can recover\nit. And if you are really paranoid about it (in what scenario do you\nactually care?), enable reflog and you will have the old sha1s recorded\nthere.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nSnow falling on Perl. White noise covering line noise.\nHides all the bugs too. -- J. Putnam\n"},{"id":"27250","messageId":"Pine.LNX.4.64.0609200902190.4388@g5.osdl.org","threadId":"5623","inReplyTo":"20060920155431.GO8259@pasky.or.cz","subject":"Re: git pull for update of netdev fails.","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-09-20T16:15:04Z","receivedAt":"2006-09-20T16:15:04Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 20 Sep 2006, Petr Baudis wrote:\n> \n> This is really a wrong way of describing the problem - I'd say that Git\n> is being difficult here.\n\nI'm sorry, but no.\n\nGit has been designed from the ground up for safety and security. \nPerformance was one big issue, but at every turn, _integrity_ of the \narchive has always been a much more important one.\n\nI realize that a lot of people don't think \"integrity\" matters. I'm sorry, \nbut those people are simply wrong. In an SCM, \"integrity\" is the _only_ \nthing that matters. Everything else is just fluff.\n\n> The point is, the subsystem maintainers need to maintain stacks of \n> patches and rebase against the main kernel branch regularily, and they \n> want to still publish their current state.\n\nAnd git supports that.\n\n> So it's not really any of them being strange or difficult, but Git being \n> so because it has no seamless support for tracking those branches.\n\nIt _does_ have seamless support for tracking those branches, but git had \nDAMN WELL BETTER MAKE SURE THAT NO INFORMATION GETS LOST!\n\nThat's the one and _only_ thing a SCM had better always guarantee.\n\nThe fact that very few systems guarantee it, and that you can mess around \nany which way you damn well want in most other systems, without the user \nbeing any wiser is a BUG in those systems. The fact that you can edit \n(and/or move around) the raw CVS files after-the-fact, and nobody will \never know is _bad_. That other systems allow it even today is just a \ndisgrace.\n\nWe may have some bugs in git, but modulo those, I hope the design is \nactually very reliable. If you pull from some other repository, you're \nguaranteed that you won't suddenly have lost your old state just because \nthe other end had a mistake.\n\nPeople had better understand that git does support rebasing, but also \nunderstand that THAT DESTROYS HISTORY. If you don't understand that, then \nyou shouldn't be told about it. Which is exactly what git does.\n\nThe thing is, if you don't understand how rebasing etc destroys history, \nyou may do things like do a \"git pull\" or a \"git merge\" of a branch that \nthe other side WILL THROW AWAY! That will later result in major pain, \nbecause when you then try to merge it later, you will get all kinds of \nnasty behaviour, because the history you merged earlier no longer matches \nthe history you're now trying to merge again, and the work you merged \nearlier is simply not there any more.\n\nSee? A \"git rebase\" has _major_ implications for the receiving end. If git \njust silently rebased on the receiving end too, THAT WOULD BE A BUG!\n\nOnce you understand this, and you understand what it _means_, you can then \nadd a \"+\" in your local .git/remotes/xyzzy file. But git should sure as \nhell not allow it by default. \n\nYou may think git is being difficult, but the fact is, git is protecting \nyour data integrity, and protecting your sanity. And if you don't \nunderstand that, then git _should_ refuse to update a branch that you may \nhave depended on the old contents for, and inform you that something \nstrange has happened.\n\nAll of git depends on history being append-only. The fact that you -can- \nrebase does not change that. A rebase is really \"create a totally new \nbranch, delete the old one, and call the new one the same name as you did \nthe old one\".\n\nSo it's really no different from you renaming an unrelated branch to a \nname that you already used earlier. The recipient really _should_ be told \nthat the old branch is gone, and replaced with something totally \nunrelated.\n\n\t\t\tLinus\n"},{"id":"27247","messageId":"20060920161825.GR8259@pasky.or.cz","threadId":"5623","inReplyTo":"7vhcz2jzfd.fsf@assigned-by-dhcp.cox.net","subject":"Re: git pull for update of netdev fails.","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-09-20T16:18:25Z","receivedAt":"2006-09-20T16:18:25Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Wed, Sep 20, 2006 at 06:05:58PM CEST, I got a letter\nwhere Junio C Hamano said that...\n> Petr Baudis writes:\n> \n> > Dear diary, on Wed, Sep 20, 2006 at 05:28:08PM CEST, I got a letter\n> > where Linus Torvalds said that...\n> >> However, you can tell git that Jeff is being difficult by marking such \n> >> branches individually as being rebased.\n> >\n> > This is really a wrong way of describing the problem - I'd say that Git\n> > is being difficult here. The point is, the subsystem maintainers need to\n> > maintain stacks of patches and rebase against the main kernel branch\n> > regularily, and they want to still publish their current state. So it's\n> > not really any of them being strange or difficult, but Git being so\n> > because it has no seamless support for tracking those branches.\n> \n> Seamless support is there and Linus described how without\n> breaking the usual \"if not fast forward you may lose some\n> patches so be extra careful\" safety valve.\n\n I argue that this safety valve is useless for most people (and\nactually I have hard time imagining a plausible scenario in which it\nactually _is_ useful). The support is not really seamless since you have\nto make manual changes to refspecs, while most people probably don't\nunderstand them (and shouldn't be required to if they are just tracking\nsomeone else anyway).\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nSnow falling on Perl. White noise covering line noise.\nHides all the bugs too. -- J. Putnam\n"},{"id":"27248","messageId":"Pine.LNX.4.64.0609200915550.4388@g5.osdl.org","threadId":"5623","inReplyTo":"20060920160756.GP8259@pasky.or.cz","subject":"Re: git pull for update of netdev fails.","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-09-20T16:19:39Z","receivedAt":"2006-09-20T16:19:39Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 20 Sep 2006, Petr Baudis wrote:\n> \n> I personally don't think \"throwing away\" history is an issue. You can\n> print the old sha1 and it is still in the database so you can recover\n> it.\n\nNo it isn't. Once you've lost the reference, you can't really depend on it \nany more in the long run.\n\nA lot of people do things like \"git repack -a -d\" by hand, and we've tried \nto encourage people to do so in cron-jobs etc. We've even had patches \nfloating around that do it automatically after a pull.\n\nIn other words, once a ref is gone, you are easily going to loose the \nhistory to it too. Also, regardless, you should be told about it, UNLESS \nYOU HAVE EXPLICITLY STATED THAT YOU DON'T CARE ABOUT HISTORY!\n\nThat's a really important point. You can trivially say \"I don't care\". \nIt's literally one extra character. But it should be the _user_ that says \nso, not the SCM.\n\nThe whole point of the SCM is to care.\n\n\t\tLinus\n"},{"id":"27251","messageId":"Pine.LNX.4.64.0609200920290.4388@g5.osdl.org","threadId":"5623","inReplyTo":"Pine.LNX.4.64.0609200915550.4388@g5.osdl.org","subject":"Re: git pull for update of netdev fails.","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-09-20T16:26:32Z","receivedAt":"2006-09-20T16:26:32Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 20 Sep 2006, Linus Torvalds wrote:\n> \n> That's a really important point. You can trivially say \"I don't care\". \n> It's literally one extra character. But it should be the _user_ that says \n> so, not the SCM.\n> \n> The whole point of the SCM is to care.\n\nBtw, the \"+\" also protects you from local errors.\n\nLet's say that you've committed some work of your own onto a branch that \nyou happen to follow. Guess what? By default, git refuses to throw your \nhard work away.\n\nThis is not just a random thing. It is in fact one of the very core issues \nof having multiple people work together on the same remote repo. We don't \ndo it very much (because it's often easier for everybody to have their \nown), but the \"CVS workflow\" with one common repository is another example \nwhy WE MUST NOT JUST RESET THE HEADS!\n\nThink about it. You and somebody else works on a common branch, using a \ncommon source repo. When you \"fetch\", you want to get all the work that \nthe other person has done. But you sure as hell don't want that work to \noverwrite your own work.\n\nSo what does git do? It notices if you have a local commit on that shared \nbranch (because it no longer fast-forwards to the other end), and it tells \nyou exactly that: it says that branch so-and-so doesn't fast-forward, and \nrefuses to overwrite it.\n\nWhat would you do? You should in that case switch to the offending branch, \nAND DO A MERGE of your work and the work you shared with another person, \nand then push out the result. \n\nSo the _last_ thing you want to happen is for your work to be silently \njust overwritten.\n\nTrust me, git does the right thing here. No ifs, buts or maybes about it.\n\n\t\t\tLinus\n"},{"id":"27252","messageId":"20060920162810.GB23260@spearce.org","threadId":"5623","inReplyTo":"Pine.LNX.4.64.0609200915550.4388@g5.osdl.org","subject":"Re: git pull for update of netdev fails.","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-09-20T16:28:10Z","receivedAt":"2006-09-20T16:28:10Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Linus Torvalds wrote:\n> On Wed, 20 Sep 2006, Petr Baudis wrote:\n> > \n> > I personally don't think \"throwing away\" history is an issue. You can\n> > print the old sha1 and it is still in the database so you can recover\n> > it.\n> \n> No it isn't. Once you've lost the reference, you can't really depend on it \n> any more in the long run.\n> \n> A lot of people do things like \"git repack -a -d\" by hand, and we've tried \n> to encourage people to do so in cron-jobs etc. We've even had patches \n> floating around that do it automatically after a pull.\n\nOuch. That's really bad.\n\nI knew it but didn't realize it until just now.\n\n\tgit repack -a -d\n\tgit branch -D foo\n\tgit repack -a -d\n\nand *poof* no foo. Even if you somehow have its SHA1 and haven't\nused `git prune` you still have just pruned the thing away and\ncan't look it up anymore.\n\ngit branch -D is just the obvious way of doing it. git rebase is\nslightly less obvious for some people (perhaps more so for others).\ngit fetch with a '+' in a Pull: line is even less obvious, especially\nif you have reflog enabled for exactly that reason.\n\n\nSo we've managed to encourage people to run prune without actually\nrunning prune. Should we just integrate prune and repack -a -d with\nthe 'rm -rf /' command? Perhaps a kernel module at the VFS layer\nwould do the trick? I hear we have some kernel folks nearby. :-)\n\n-- \nShawn.\n"},{"id":"27255","messageId":"Pine.LNX.4.64.0609200927260.4388@g5.osdl.org","threadId":"5623","inReplyTo":"20060920161825.GR8259@pasky.or.cz","subject":"Re: git pull for update of netdev fails.","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-09-20T16:33:42Z","receivedAt":"2006-09-20T16:33:42Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 20 Sep 2006, Petr Baudis wrote:\n>\n> I argue that this safety valve is useless for most people (and\n> actually I have hard time imagining a plausible scenario in which it\n> actually _is_ useful).\n\nIt is only useless for people who use git ass a read-only \"anonymous CVS\" \nkind of thing.\n\nAnd yes, that may be \"most people\", but dammit, it's not the group git has \nbeen designed for. \n\nI would be ok with a \"anonymous read-only\" approach IF GIT ACTUALLY \nENFORCED IT. In other words, we could easily have a read-only clone that \nadded the \"+\" to all branches, but then we should also make sure that \nnobody ever commits _anything_ in such a repo.\n\nNo merges (because you can not rely on the merge result being meaningful: \nthe sources of the merge may be \"ephemeral\"), no local commits (because \nyou can never \"pull\" any more after that, since that now becomes a merge \nwith something you can't trust any more).\n\nIn other words, if you default to the \"+\" behaviour, you basically can do \n_nothing_ in that repository except just track the other end.\n\nIs that useful? Potentially. But it's so clearly inferior to what we have \nnow that you should definitely realize that we're not talking about a full \ngit repository any more, we're really talking about just a \"git tracker\".\n\n\t\tLinus\n"},{"id":"27254","messageId":"20060920163437.GC23260@spearce.org","threadId":"5623","inReplyTo":"Pine.LNX.4.64.0609200920290.4388@g5.osdl.org","subject":"Re: git pull for update of netdev fails.","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-09-20T16:34:37Z","receivedAt":"2006-09-20T16:34:37Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Linus Torvalds wrote:\n> On Wed, 20 Sep 2006, Linus Torvalds wrote:\n> > \n> > That's a really important point. You can trivially say \"I don't care\". \n> > It's literally one extra character. But it should be the _user_ that says \n> > so, not the SCM.\n> > \n> > The whole point of the SCM is to care.\n> \n> Btw, the \"+\" also protects you from local errors.\n> \n> Let's say that you've committed some work of your own onto a branch that \n> you happen to follow. Guess what? By default, git refuses to throw your \n> hard work away.\n> \n> This is not just a random thing. It is in fact one of the very core issues \n> of having multiple people work together on the same remote repo. We don't \n> do it very much (because it's often easier for everybody to have their \n> own), but the \"CVS workflow\" with one common repository is another example \n> why WE MUST NOT JUST RESET THE HEADS!\n\nBTW `git push --force` works just great to reset the remote head.\n\nI worked on a project not to long ago in which a user tried `git\npush`, received a \"not a fast-forward\" error, didn't know what it\nmeant, tried `git push --force`, found that worked, and proceeded\nto force every push he did from then on. To much gnashing of teeth\nfrom everyone else.\n\nOf course an update hook finally took care of the problem, but having\nnon fast-forward pushs be permitted on a shared, bare repository\nby default is interesting to say the least. :-)\n \n-- \nShawn.\n"},{"id":"27257","messageId":"Pine.LNX.4.64.0609200934140.4388@g5.osdl.org","threadId":"5623","inReplyTo":"20060920162810.GB23260@spearce.org","subject":"Re: git pull for update of netdev fails.","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-09-20T16:38:25Z","receivedAt":"2006-09-20T16:38:25Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 20 Sep 2006, Shawn Pearce wrote:\n> > \n> > A lot of people do things like \"git repack -a -d\" by hand, and we've tried \n> > to encourage people to do so in cron-jobs etc. We've even had patches \n> > floating around that do it automatically after a pull.\n> \n> Ouch. That's really bad.\n\nWell, what did you think the \"-d\" stood for?\n\nIt stands for \"delete old packs\".\n\nThere are exactly two operations that delete git objects: \"git prune\" and \n\"git repack -d\". Nothing else should ever do it, but those two definitely \ndo. They're designed to.\n\nI wouldn't call it \"really bad\" - it's part of the design. It's only bad \nif you didn't realize what \"-d\" means.\n\n> I knew it but didn't realize it until just now.\n> \n> \tgit repack -a -d\n> \tgit branch -D foo\n> \tgit repack -a -d\n> \n> and *poof* no foo.\n\nExactly. \n\nI thought people realized this, but apparently sometimes it's just an \nintellectual understanding of what something does, without realizing what \nthat thing actually _means_ in a deeper way.\n\n\t\t\tLinus\n"},{"id":"27261","messageId":"Pine.LNX.4.64.0609200942550.4388@g5.osdl.org","threadId":"5623","inReplyTo":"20060920163437.GC23260@spearce.org","subject":"Re: git pull for update of netdev fails.","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-09-20T16:49:52Z","receivedAt":"2006-09-20T16:49:52Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 20 Sep 2006, Shawn Pearce wrote:\n> > \n> > This is not just a random thing. It is in fact one of the very core issues \n> > of having multiple people work together on the same remote repo. We don't \n> > do it very much (because it's often easier for everybody to have their \n> > own), but the \"CVS workflow\" with one common repository is another example \n> > why WE MUST NOT JUST RESET THE HEADS!\n> \n> BTW `git push --force` works just great to reset the remote head.\n\nYes. That's why \"--force\" exists - it's a way of saying \"the other end is \nwrong, and I really do want to force this update\".\n\n> I worked on a project not to long ago in which a user tried `git\n> push`, received a \"not a fast-forward\" error, didn't know what it\n> meant, tried `git push --force`, found that worked, and proceeded\n> to force every push he did from then on. To much gnashing of teeth\n> from everyone else.\n\nOuch. That implies that we made it a bit too easy to force things, or that \nwe have an insufficiently clear error message.\n\nI think the current error message is fairly good: it says\n\n\t\"remote '%s' is not a strict subset of local ref '%s'. maybe you \n\t are not up-to-date and need to pull first?\"\n\nwhich should be clear enough, but I'm hoping this was a long time ago when \nwe weren't as clear (we added the \"maybe you're not up-to-date ..\" \nlanguage later)\n\n> Of course an update hook finally took care of the problem, but having\n> non fast-forward pushs be permitted on a shared, bare repository\n> by default is interesting to say the least. :-)\n\nYeah, well, it's not permitted \"by default\", but obviously \"--force\" ends \nup being a client-side decision, so with clueless clients, the default \nbehaviour may not be enough to save you.\n\n\t\t\tLinus\n"},{"id":"27263","messageId":"20060920165931.GE23260@spearce.org","threadId":"5623","inReplyTo":"Pine.LNX.4.64.0609200902190.4388@g5.osdl.org","subject":"Re: git pull for update of netdev fails.","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-09-20T16:59:31Z","receivedAt":"2006-09-20T16:59:31Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Linus Torvalds wrote:\n> The thing is, if you don't understand how rebasing etc destroys history, \n> you may do things like do a \"git pull\" or a \"git merge\" of a branch that \n> the other side WILL THROW AWAY! That will later result in major pain, \n> because when you then try to merge it later, you will get all kinds of \n> nasty behaviour, because the history you merged earlier no longer matches \n> the history you're now trying to merge again, and the work you merged \n> earlier is simply not there any more.\n\nYet people (typically those new to Git) will still pull or merge\nthe wrong branch in, work on top of that merge, publish it, others\nwill build on that... and wham; that topic branch head which you\nwanted to rebase prior to merging is now wedged 50 commits deep in\nyour history.\n\nJust yesterday I found such a case in a shared repository. Now I\nhave a branch wedged in our shared mainline that I can't get out\nand shouldn't have been there in the first place.\n\n\nIf only the shared repository had a way of advising clients that\ncommits stored in ref 'BAAAD' may not survive and thus shouldn't\nbe merged. So that git-merge wouldn't let you merge them in.\nUnfortunately there isn't a way to do this that's sane so I'm not\neven going to try.\n\n\nProbably what I should have done (now that I think about it) was to\nput a check into our update hook on the shared repository to look for\na rebaseable branch (which are listed in some info file) being pushed\ninto a non-rebaseable one. If that happens then abort the update.\n\nUnfortunately our current Git client (1.4.2)/Git server version(1.3.1)\ncombinations means we get no output from our update hook when it\nfails, so I can't tell the newbie what they did wrong.\n\n-- \nShawn.\n"},{"id":"27265","messageId":"20060920171012.GF23260@spearce.org","threadId":"5623","inReplyTo":"Pine.LNX.4.64.0609200942550.4388@g5.osdl.org","subject":"Re: git pull for update of netdev fails.","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-09-20T17:10:12Z","receivedAt":"2006-09-20T17:10:12Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Linus Torvalds wrote:\n> On Wed, 20 Sep 2006, Shawn Pearce wrote:\n> > I worked on a project not to long ago in which a user tried `git\n> > push`, received a \"not a fast-forward\" error, didn't know what it\n> > meant, tried `git push --force`, found that worked, and proceeded\n> > to force every push he did from then on. To much gnashing of teeth\n> > from everyone else.\n> \n> Ouch. That implies that we made it a bit too easy to force things, or that \n> we have an insufficiently clear error message.\n\nI've been lucky that I've only run into two people in my life that\nwhen faced with an error message they don't understand immediately\ntry adding \"-f\" and \"--force\" to the command line until something\nhappens. Its entertaining to read their terminal scrollback and\nsee what they did in response to errors; its less so when they've\ndone mildy destructive things that you now must cleanup.\n\nSometimes I wonder if they've managed to reformat their root\nfilesystem while they had it mounted. Never asked. Not sure I\nwant to hear the answer.\n \n> I think the current error message is fairly good: it says\n> \n> \t\"remote '%s' is not a strict subset of local ref '%s'. maybe you \n> \t are not up-to-date and need to pull first?\"\n> \n> which should be clear enough, but I'm hoping this was a long time ago when \n> we weren't as clear (we added the \"maybe you're not up-to-date ..\" \n> language later)\n\nYes; this problem was back with Git 1.2 so the newer language is\nmuch better and should help new users better.\n \n> > Of course an update hook finally took care of the problem, but having\n> > non fast-forward pushs be permitted on a shared, bare repository\n> > by default is interesting to say the least. :-)\n> \n> Yeah, well, it's not permitted \"by default\", but obviously \"--force\" ends \n> up being a client-side decision, so with clueless clients, the default \n> behaviour may not be enough to save you.\n\nI'm wondering if maybe git-receive-pack should deny forcing an\nupdate in a shared repository unless there's either an update hook\nthat its going to run (which would get to vote yea or neigh) or\nthere's a configuration setting enabled which isn't set by default.\n\nI'd think most users of a shared repository wouldn't want to allow\nforcing an update except in some very special cases. For those\nthey could install an update hook or just push a new temporary\nbranch name and then use git-update-ref or git-branch directly on\nthe remote repository.\n\n-- \nShawn.\n"},{"id":"27270","messageId":"Pine.LNX.4.64.0609201032000.4388@g5.osdl.org","threadId":"5623","inReplyTo":"20060920165931.GE23260@spearce.org","subject":"Re: git pull for update of netdev fails.","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-09-20T17:34:33Z","receivedAt":"2006-09-20T17:34:33Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 20 Sep 2006, Shawn Pearce wrote:\n> \n> Yet people (typically those new to Git) will still pull or merge\n> the wrong branch in, work on top of that merge, publish it, others\n> will build on that... and wham; that topic branch head which you\n> wanted to rebase prior to merging is now wedged 50 commits deep in\n> your history.\n\nYes. It might well be a good idea to mark temporary branches some way on \nthe sending side, and have \"git pull\" honor that marking by default.\n\nThe only really good marking we'd have (unless we extended the protocol a \nlot) is name-based, ie we could have a separate directory for \"temporary \nbranches\". \n\nOf course, nothing will ever really avoid outright mistakes, which is \nprobably the bulk of things. I think a lot of those go away when you get \nused to the flow, but especially in the beginning, people _will_ make \nmistakes.\n\nSo maybe trying to avoid them too much is just futile.\n\n\t\tLinus\n"},{"id":"27279","messageId":"45119560.7060102@pobox.com","threadId":"5623","inReplyTo":"Pine.LNX.4.64.0609200816400.4388@g5.osdl.org","subject":"Re: git pull for update of netdev fails.","fromName":"Jeff Garzik","fromEmail":"jgarzik@pobox.com","sentAt":"2006-09-20T19:24:16Z","receivedAt":"2006-09-20T19:24:16Z","isPatch":false,"sender":{"key":"jgarzik@pobox.com","avatar":null},"body":"Linus Torvalds wrote:\n> So you could either mark _all_ the remote branches with the extra \"+\" (to \n> say that you always want to fetch that exact state for whatever branch \n> you're tracking), or you can ask Jeff which branches he expects to do \n> strange things and just mark those individual ones.\n\n\nActually, I only rebase rarely, because it's a pain for downstream people.\n\nStephen just caught one of the rare occasions where I rebased \n'e100-sbit'. Note that other branches did not get rebased.\n\nSorry about that Stephen, I should have posted to netdev.\n\n\tJeff\n"},{"id":"27280","messageId":"ees6hl$jdv$1@sea.gmane.org","threadId":"5623","inReplyTo":"20060920155431.GO8259@pasky.or.cz","subject":"Re: git pull for update of netdev fails.","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-09-20T19:58:48Z","receivedAt":"2006-09-20T19:58:48Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Petr Baudis wrote:\n\n> Dear diary, on Wed, Sep 20, 2006 at 05:28:08PM CEST, I got a letter\n> where Linus Torvalds said that...\n\n>> However, you can tell git that Jeff is being difficult by marking such \n>> branches individually as being rebased.\n> \n> This is really a wrong way of describing the problem - I'd say that Git\n> is being difficult here. The point is, the subsystem maintainers need to\n> maintain stacks of patches and rebase against the main kernel branch\n> regularily, and they want to still publish their current state. So it's\n> not really any of them being strange or difficult, but Git being so\n> because it has no seamless support for tracking those branches.\n\nThere was idea around moving remotes configuration to config file to have\nsome per branch configureation, including readonly for protecting tracking\nbranches, marking default branch for merge with (and which tracking\nbranch(es) to merge)...\n\n...and that included marking branch _on the server side_ as being rebased,\ni.e. without preserved history. Unfortunately, the discussion petered out\nwithout changes to git. Branch marked as pu-like would either get '+'\nin appropriate Pull line in remotes file generated during clone, or they\nwouldn't need '+'.\n\nBy the way, there is '--force' option to git-pull/git-fetch...\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"27281","messageId":"ees6n9$jdv$2@sea.gmane.org","threadId":"5623","inReplyTo":"20060920161825.GR8259@pasky.or.cz","subject":"Re: git pull for update of netdev fails.","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-09-20T20:01:48Z","receivedAt":"2006-09-20T20:01:48Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Petr Baudis wrote:\n \n>> Seamless support is there and Linus described how without\n>> breaking the usual \"if not fast forward you may lose some\n>> patches so be extra careful\" safety valve.\n> \n>   I argue that this safety valve is useless for most people (and\n> actually I have hard time imagining a plausible scenario in which it\n> actually _is_ useful). The support is not really seamless since you have\n> to make manual changes to refspecs, while most people probably don't\n> understand them (and shouldn't be required to if they are just tracking\n> someone else anyway).\n\nOr you can always pull with the --force option...\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"27285","messageId":"Pine.LNX.4.63.0609202304270.19042@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"5623","inReplyTo":"Pine.LNX.4.64.0609200915550.4388@g5.osdl.org","subject":"Re: git pull for update of netdev fails.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-09-20T21:14:25Z","receivedAt":"2006-09-20T21:14:25Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 20 Sep 2006, Linus Torvalds wrote:\n\n> On Wed, 20 Sep 2006, Petr Baudis wrote:\n> > \n> > I personally don't think \"throwing away\" history is an issue. You can\n> > print the old sha1 and it is still in the database so you can recover\n> > it.\n> \n> No it isn't. Once you've lost the reference, you can't really depend on it \n> any more in the long run.\n\nExactly. And to add to that: you can lose the reference just by being not \nfast enough. Example:\n\nSome time ago, Junio was playing with colour in the output of git. He was \ndoing so in some branch he pulled into 'pu'. A few days later, he dropped \nit. Now, I was lucky enough to have fetched pu within the short time span \nwhere colour was part of 'pu', and some days (or weeks, don't remember) \nlater, I found some more time to play with the thing again, and \neventually submitted a patch reintroducing the colour thing.\n\nSo, you can lose things you actually never had!\n\nAnother, even more serious problems with rebasing: You can introduce a bug \nby rebasing. Meaning: git-rebase can succeed, even compilation is fine, \nbut the sum of your patches, and the patches you are rebasing on, is \nbuggy. And there is _no_ way to bisect this, since the \"good\" version can \nbe gone for good.\n\nThese two problems, combined with my love of history, make me never use \nrebased branches myself, especially since I basically use git for projects \nwhich I work on alone, just to synchronise between different sites.\n\nAs for the problem git-rebase tries to solve: you can get a clean branch \nby cherry-picking what you have into a temporary branch, for the sole \npurpose of being history clean.\n\nCiao,\nDscho\n"},{"id":"27286","messageId":"20060920212101.GA24415@spearce.org","threadId":"5623","inReplyTo":"Pine.LNX.4.63.0609202304270.19042@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: git pull for update of netdev fails.","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-09-20T21:21:01Z","receivedAt":"2006-09-20T21:21:01Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Johannes Schindelin wrote:\n> Another, even more serious problems with rebasing: You can introduce a bug \n> by rebasing. Meaning: git-rebase can succeed, even compilation is fine, \n> but the sum of your patches, and the patches you are rebasing on, is \n> buggy. And there is _no_ way to bisect this, since the \"good\" version can \n> be gone for good.\n\nTrue, however one would hope that you tested the commit before you\nrebased it and found it to working. And bisect should point at the\nnew version of that commit as the break. And then you can debug\nit there.\n\nI've seen this happen very rarely, and usually its an initialization\nor calling order type of bug and its usually has more to do with \nother changes in the branch you are rebasing onto that aren't at the\nside your patch affects.\n\nYes its something annoying to track down but certainly easy enough\nwith bisect, especially if you have relatively fine-grained commits\nand a reasonably good test suite.\n\n-- \nShawn.\n"},{"id":"27287","messageId":"Pine.LNX.4.63.0609202321390.19042@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"5623","inReplyTo":"20060920163437.GC23260@spearce.org","subject":"Re: git pull for update of netdev fails.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-09-20T21:23:11Z","receivedAt":"2006-09-20T21:23:11Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 20 Sep 2006, Shawn Pearce wrote:\n\n> Of course an update hook finally took care of the problem, but having\n> non fast-forward pushs be permitted on a shared, bare repository\n> by default is interesting to say the least. :-)\n\nUnfortunately, it is send-pack making the decision on the client side, not \nreceive-pack on the server side, the latter of which knows if the server \nside is shared or not.\n\nCiao,\nDscho\n"},{"id":"27290","messageId":"Pine.LNX.4.63.0609202325510.19042@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"5623","inReplyTo":"20060920212101.GA24415@spearce.org","subject":"Re: git pull for update of netdev fails.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-09-20T21:27:09Z","receivedAt":"2006-09-20T21:27:09Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 20 Sep 2006, Shawn Pearce wrote:\n\n> Johannes Schindelin wrote:\n> > Another, even more serious problems with rebasing: You can introduce a bug \n> > by rebasing. Meaning: git-rebase can succeed, even compilation is fine, \n> > but the sum of your patches, and the patches you are rebasing on, is \n> > buggy. And there is _no_ way to bisect this, since the \"good\" version can \n> > be gone for good.\n> \n> True, however one would hope that you tested the commit before you\n> rebased it and found it to working. And bisect should point at the\n> new version of that commit as the break. And then you can debug\n> it there.\n\nYou misunderstood me. You can _introduce_ a bug by rebasing. _After_ \ntesting that everything is fine. You can even test the rebased branch and \nmiss the bug, since your original tests were more thorough.\n\nCiao,\nDscho\n"},{"id":"27291","messageId":"20060920212747.GB24415@spearce.org","threadId":"5623","inReplyTo":"Pine.LNX.4.63.0609202321390.19042@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: git pull for update of netdev fails.","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-09-20T21:27:47Z","receivedAt":"2006-09-20T21:27:47Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Johannes Schindelin wrote:\n> On Wed, 20 Sep 2006, Shawn Pearce wrote:\n> \n> > Of course an update hook finally took care of the problem, but having\n> > non fast-forward pushs be permitted on a shared, bare repository\n> > by default is interesting to say the least. :-)\n> \n> Unfortunately, it is send-pack making the decision on the client side, not \n> receive-pack on the server side, the latter of which knows if the server \n> side is shared or not.\n\nHuh?\n\nThe server side update hook is given the old and new value of\nthe ref by receive-pack; if it exists with a non-zero status the\nupdate fails.\n\nThe server side could also check if the current value in the ref\n(if it exists) is contained within the new value of the ref. Yes,\nI know it doesn't today, but the point is it could. And I was\nsaying maybe it should when there is no update hook present.\n\n-- \nShawn.\n"},{"id":"27295","messageId":"Pine.LNX.4.63.0609202333320.19042@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"5623","inReplyTo":"20060920212747.GB24415@spearce.org","subject":"Re: git pull for update of netdev fails.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-09-20T21:37:12Z","receivedAt":"2006-09-20T21:37:12Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 20 Sep 2006, Shawn Pearce wrote:\n\n> Johannes Schindelin wrote:\n> > On Wed, 20 Sep 2006, Shawn Pearce wrote:\n> > \n> > > Of course an update hook finally took care of the problem, but having\n> > > non fast-forward pushs be permitted on a shared, bare repository\n> > > by default is interesting to say the least. :-)\n> > \n> > Unfortunately, it is send-pack making the decision on the client side, not \n> > receive-pack on the server side, the latter of which knows if the server \n> > side is shared or not.\n> \n> Huh?\n> \n> The server side update hook is given the old and new value of\n> the ref by receive-pack; if it exists with a non-zero status the\n> update fails.\n> \n> The server side could also check if the current value in the ref\n> (if it exists) is contained within the new value of the ref. Yes,\n> I know it doesn't today, but the point is it could. And I was\n> saying maybe it should when there is no update hook present.\n\nThe point being that this check is not necessarily inexpensive. But you \nare right, we could introduce this as a security measure. But is it really \nintuitive to skip this test when an update hook is added?\n\nI'd rather set another config variable with --shared, which tells git to \nrefuse receiving non-fast-forwards. This could be a sensible setting in \nother setups than shared ones after all. Thoughts?\n\nCiao,\nDscho\n"},{"id":"27296","messageId":"20060920214001.GD24415@spearce.org","threadId":"5623","inReplyTo":"Pine.LNX.4.63.0609202325510.19042@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: git pull for update of netdev fails.","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-09-20T21:40:01Z","receivedAt":"2006-09-20T21:40:01Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Johannes Schindelin wrote:\n> On Wed, 20 Sep 2006, Shawn Pearce wrote:\n> \n> > Johannes Schindelin wrote:\n> > > Another, even more serious problems with rebasing: You can introduce a bug \n> > > by rebasing. Meaning: git-rebase can succeed, even compilation is fine, \n> > > but the sum of your patches, and the patches you are rebasing on, is \n> > > buggy. And there is _no_ way to bisect this, since the \"good\" version can \n> > > be gone for good.\n> > \n> > True, however one would hope that you tested the commit before you\n> > rebased it and found it to working. And bisect should point at the\n> > new version of that commit as the break. And then you can debug\n> > it there.\n> \n> You misunderstood me. You can _introduce_ a bug by rebasing. _After_ \n> testing that everything is fine. You can even test the rebased branch and \n> miss the bug, since your original tests were more thorough.\n\nWhy were your original tests more thorough and your rebased testing\nwas less so? Hmm? Perhaps the test suite needs to be extended as\npart of the rebased commit(s).\n\nOf course a rebase-introduced bug could also be in the test suite,\nsuch that you miss the true bug. I've had bugs in the test suite\nmask real bug, but never a bug both in the feature and in the test\ndue to a rebase or mad merge. I guess I've just been lucky there.\n\n\nWhen rebasing and even when doing a non-fast forward merge one\nneeds to keep in mind that your code is being edited on your behalf.\nNot much different then if you open it in your favorite editor and\nwhack away at a keyboard for a while. Sure these auto-edits work\nmost of the time, on their own and without user intervention, but\nevery once in while things get messed up. Heck, I've seen editors\nmess up source files such that they won't compile anymore.\n\nSo moral of the story is you probably should be testing even after\nrebasing or cherry picking, and the testing shouldn't be any less\nextensive than before you did the rebase/cherry-pick. Which is one\nreason why automated test suites can be useful, despite the risks\nthey also bring...\n\n-- \nShawn.\n"},{"id":"27298","messageId":"7vodtafc4g.fsf@assigned-by-dhcp.cox.net","threadId":"5623","inReplyTo":"Pine.LNX.4.63.0609202333320.19042@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: git pull for update of netdev fails.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-09-20T21:42:55Z","receivedAt":"2006-09-20T21:42:55Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> I'd rather set another config variable with --shared, which tells git to \n> refuse receiving non-fast-forwards. This could be a sensible setting in \n> other setups than shared ones after all. Thoughts?\n\nIf this option is meant to forbid fixing up an screw-up by doing\n\"git-push --force\", I do not quite like it.\n\nIt sounds as if arguing that \"rm -fr\" is dangerous so presence\nof -f and -r at the same time should imply -i option. I think\nthe right answer is not making -i implied, but train the user to\nunderstand what -fr means before using it.\n"},{"id":"27299","messageId":"20060920214903.GF24415@spearce.org","threadId":"5623","inReplyTo":"Pine.LNX.4.63.0609202333320.19042@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: git pull for update of netdev fails.","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-09-20T21:49:03Z","receivedAt":"2006-09-20T21:49:03Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Johannes Schindelin wrote:\n> On Wed, 20 Sep 2006, Shawn Pearce wrote:\n> > The server side could also check if the current value in the ref\n> > (if it exists) is contained within the new value of the ref. Yes,\n> > I know it doesn't today, but the point is it could. And I was\n> > saying maybe it should when there is no update hook present.\n> \n> The point being that this check is not necessarily inexpensive.\n\nBut its not _that_ expensive. If the option is set to refuse\nnon-fast forwards then you take the hit and do the check; if its\nset to allow them then you can bypass the check entirely and let\nthe client direct it (like it does today). Speed vs. safety.\n\nI currently use \"git rev-list $2..$1\" in my update hooks to make sure\nthe update is strictly a fast-foward type update for all branches.\nEnabling this option and having the check run in receive-pack would\nbe faster than what I'm doing now (one less fork).\n\n> But you \n> are right, we could introduce this as a security measure. But is it really \n> intuitive to skip this test when an update hook is added?\n\nNow that you say it, no. These two things (update hook and non-fast\nforward update) are unrelated. If the update hook wants to make\nthe decision on a per branch basis then the option to allow a\nnon-fast forward push must be enabled in the config file.\n \n> I'd rather set another config variable with --shared, which tells git to \n> refuse receiving non-fast-forwards. This could be a sensible setting in \n> other setups than shared ones after all. Thoughts?\n\nAgree completely.\n\n-- \nShawn.\n"},{"id":"27300","messageId":"Pine.LNX.4.63.0609202350160.19042@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"5623","inReplyTo":"7vodtafc4g.fsf@assigned-by-dhcp.cox.net","subject":"Re: git pull for update of netdev fails.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-09-20T21:53:15Z","receivedAt":"2006-09-20T21:53:15Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 20 Sep 2006, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > I'd rather set another config variable with --shared, which tells git to \n> > refuse receiving non-fast-forwards. This could be a sensible setting in \n> > other setups than shared ones after all. Thoughts?\n> \n> If this option is meant to forbid fixing up an screw-up by doing\n> \"git-push --force\", I do not quite like it.\n> \n> It sounds as if arguing that \"rm -fr\" is dangerous so presence\n> of -f and -r at the same time should imply -i option. I think\n> the right answer is not making -i implied, but train the user to\n> understand what -fr means before using it.\n\nI think it is more like being nice, and disallowing \"rm -rf\" via FTP, \nforcing the user to do it locally.\n\nIn a shared repository I really, really, I mean: really, do not want to \nmess a branch up that others pull from. And if I have to fix something, I \n_can_ do it locally. (Plus the hassle reminds me of giving the pullers a \nheads-up.)\n\nCiao,\nDscho\n"},{"id":"27301","messageId":"20060920215318.GG24415@spearce.org","threadId":"5623","inReplyTo":"7vodtafc4g.fsf@assigned-by-dhcp.cox.net","subject":"Re: git pull for update of netdev fails.","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-09-20T21:53:18Z","receivedAt":"2006-09-20T21:53:18Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano wrote:\n> Johannes Schindelin writes:\n> \n> > I'd rather set another config variable with --shared, which tells git to \n> > refuse receiving non-fast-forwards. This could be a sensible setting in \n> > other setups than shared ones after all. Thoughts?\n> \n> If this option is meant to forbid fixing up an screw-up by doing\n> \"git-push --force\", I do not quite like it.\n\nYes, it is meant for stopping exactly that.\n\nAs the repository owner with direct access to the repository I\ndon't want anyone to be able to use --force to reset a branch.\nIf a branch reset needs to happen I want to do it directly on\nthe repository. Its a rather destructive operation, as we have\nbeen saying. I don't want a user slamming in \"--force\" just because.\n\nOn the other hand you can also configure the option to allow\n`git push --force` and craft a smart update hook which looks at\nwho is doing the push and if that is permissible to the ref in\nquestion; exit'ing non-zero if not.\n\nBasically I don't see why an update hook should be necessary to\ndisallow all non-fast forward pushes.\n\n> It sounds as if arguing that \"rm -fr\" is dangerous so presence\n> of -f and -r at the same time should imply -i option. I think\n> the right answer is not making -i implied, but train the user to\n> understand what -fr means before using it.\n\nSome people cannot be trained. No matter how hard you may try.\n\n-- \nShawn.\n"},{"id":"27303","messageId":"eesfm3$h2o$1@sea.gmane.org","threadId":"5623","inReplyTo":"Pine.LNX.4.63.0609202304270.19042@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: git pull for update of netdev fails.","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-09-20T22:34:47Z","receivedAt":"2006-09-20T22:34:47Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Johannes Schindelin wrote:\n\n> Another, even more serious problems with rebasing: You can introduce a bug \n> by rebasing. Meaning: git-rebase can succeed, even compilation is fine, \n> but the sum of your patches, and the patches you are rebasing on, is \n> buggy. And there is _no_ way to bisect this, since the \"good\" version can \n> be gone for good.\n\nWell, you can always tag tip of branch before rebasing, and remove the tag\nwhen rebased branch is tested.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"27310","messageId":"m37izy6skg.fsf@defiant.localdomain","threadId":"5623","inReplyTo":"20060920165931.GE23260@spearce.org","subject":"Re: git pull for update of netdev fails.","fromName":"Krzysztof Halasa","fromEmail":"khc@pm.waw.pl","sentAt":"2006-09-20T23:12:31Z","receivedAt":"2006-09-20T23:12:31Z","isPatch":false,"sender":{"key":"khc@pm.waw.pl","avatar":null},"body":"Shawn Pearce writes:\n\n> If only the shared repository had a way of advising clients that\n> commits stored in ref 'BAAAD' may not survive and thus shouldn't\n> be merged.\n\nThey could be merged for some temporary purposes, though (such\nas compile/run tests). Merging isn't a problem, doing real\ndevelopment on such material wouldn't be the best idea.\n-- \nKrzysztof Halasa\n"},{"id":"27354","messageId":"Pine.LNX.4.63.0609211111540.19042@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"5623","inReplyTo":"ees6hl$jdv$1@sea.gmane.org","subject":"Re: git pull for update of netdev fails.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-09-21T09:14:28Z","receivedAt":"2006-09-21T09:14:28Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 20 Sep 2006, Jakub Narebski wrote:\n\n> Petr Baudis wrote:\n> \n> > Dear diary, on Wed, Sep 20, 2006 at 05:28:08PM CEST, I got a letter\n> > where Linus Torvalds said that...\n> \n> >> However, you can tell git that Jeff is being difficult by marking such \n> >> branches individually as being rebased.\n> > \n> > This is really a wrong way of describing the problem - I'd say that Git\n> > is being difficult here. The point is, the subsystem maintainers need to\n> > maintain stacks of patches and rebase against the main kernel branch\n> > regularily, and they want to still publish their current state. So it's\n> > not really any of them being strange or difficult, but Git being so\n> > because it has no seamless support for tracking those branches.\n> \n> There was idea around moving remotes configuration to config file to have\n> some per branch configureation, including readonly for protecting tracking\n> branches, marking default branch for merge with (and which tracking\n> branch(es) to merge)...\n\nIf you want it, go ahead, propose something.\n\n> ...and that included marking branch _on the server side_ as being rebased,\n> i.e. without preserved history. Unfortunately, the discussion petered out\n> without changes to git.\n\nNot true. We have the [branch \"StrangeCase Sensitive/Name\"] syntax as a \nconsequence.\n\nBut I agree, nothing came out of the discussion about per-branch settings, \nmaybe because nobody cared enough?\n\nCiao,\nDscho\n"},{"id":"27441","messageId":"20060923034407.GF8259@pasky.or.cz","threadId":"5623","inReplyTo":"Pine.LNX.4.63.0609202304270.19042@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: git pull for update of netdev fails.","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-09-23T03:44:07Z","receivedAt":"2006-09-23T03:44:07Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Wed, Sep 20, 2006 at 11:14:25PM CEST, I got a letter\nwhere Johannes Schindelin said that...\n> Another, even more serious problems with rebasing: You can introduce a bug \n> by rebasing. Meaning: git-rebase can succeed, even compilation is fine, \n> but the sum of your patches, and the patches you are rebasing on, is \n> buggy. And there is _no_ way to bisect this, since the \"good\" version can \n> be gone for good.\n\nYes, I agree that this really is a problem, but that's a fundamental\nlimitation. At least for StGIT-maintained floating branches the latest\nbleeding edge StGIT could fix that. (Except that the problem outlined by\nLinus is present here as well, first prune will wipe your older patch\nversions and your patch log will be useless - Catalin? Can we store the\nolder patch versions references in something like\n.git/refs/patches-old/?) And except that it does that only for you -\nthere should be a way to conveniently mirror (clone+pull) the patch\nstack setup.\n\n> As for the problem git-rebase tries to solve: you can get a clean branch \n> by cherry-picking what you have into a temporary branch, for the sole \n> purpose of being history clean.\n\nThat's not really a reliable option because after getting your patches\nthrough Christopher Hellwig you _will_ need to go back and poke some\npatches in that history.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i wrote:\n> Yes, I agree that this really is a problem, but that's a fundamental\n> limitation. At least for StGIT-maintained floating branches the latest\n> bleeding edge StGIT could fix that. (Except that the problem outlined by\n> Linus is present here as well, first prune will wipe your older patch\n> versions and your patch log will be useless - Catalin? Can we store the\n> older patch versions references in something like\n> .git/refs/patches-old/?) And except that it does that only for you -\n> there should be a way to conveniently mirror (clone+pull) the patch\n> stack setup.\n\nWhy not change reflog to store the last n values or the last n days\n(obtained from .git/config file) as refs under refs/prior-heads ?\n\nI can see the same concept of ref history being useful even for\ncore git-rebase and doing it this way would also give it to StGIT\nwithout Catalin needing to change code.\n\nBut it doesn't help git bisect.\n\n\nOf course a looooong time ago when I first implemented reflog support\nthis was suggested but not implemented at the time due to the high\ncost per ref. Now that we have Linus' packed refs available this\nmay not be nearly as much of a problem.\n\n-- \nShawn.\n"},{"id":"27443","messageId":"20060923040942.GG8259@pasky.or.cz","threadId":"5623","inReplyTo":"20060923040035.GB18105@spearce.org","subject":"Re: git pull for update of netdev fails.","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-09-23T04:09:42Z","receivedAt":"2006-09-23T04:09:42Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Sat, Sep 23, 2006 at 06:00:35AM CEST, I got a letter\nwhere Shawn Pearce said that...\n> I can see the same concept of ref history being useful even for\n> core git-rebase and doing it this way would also give it to StGIT\n> without Catalin needing to change code.\n\nIn my StGIT tree, I don't want to have arbitrary N-days cutoff point,\nI want all the patches history preserved at least as long as I carry\nthe patch, because it's just as valuable as the \"regular\" project\nhistory to me.\n\n> But it doesn't help git bisect.\n\nIt's not really all that clear how should bisect work in case of\nmulti-dimensional history. To do it sensibly, I guess you would have to\nhave another command like \"stg commitseries\" which declares \"right now I\nhave the series (patches, their applied/unapplied state and their\nordering) in a clearly defined state\" and then bisect between those.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i said that...\n> Think about it. You and somebody else works on a common branch, using a \n> common source repo. When you \"fetch\", you want to get all the work that \n> the other person has done. But you sure as hell don't want that work to \n> overwrite your own work.\n> \n> So what does git do? It notices if you have a local commit on that shared \n> branch (because it no longer fast-forwards to the other end), and it tells \n> you exactly that: it says that branch so-and-so doesn't fast-forward, and \n> refuses to overwrite it.\n\nI'd bite here that if you commit to a branch that you also simultanously\nfetch from somewhere else, you're asking for it - but I've never really\nused [plain Git]'s branches so perhaps it is a blessed workflow there.\n(Cogito won't let you do it.)\n\n\nDear diary, on Wed, Sep 20, 2006 at 06:33:42PM CEST, I got a letter\nwhere Linus Torvalds said that...\n> I would be ok with a \"anonymous read-only\" approach IF GIT ACTUALLY \n> ENFORCED IT. In other words, we could easily have a read-only clone that \n> added the \"+\" to all branches, but then we should also make sure that \n> nobody ever commits _anything_ in such a repo.\n> \n> No merges (because you can not rely on the merge result being meaningful: \n> the sources of the merge may be \"ephemeral\"), no local commits (because \n> you can never \"pull\" any more after that, since that now becomes a merge \n> with something you can't trust any more).\n\nWell, yes, it gets bad if you just prepend + to all branches:\n\nDear diary, on Wed, Sep 20, 2006 at 06:15:04PM CEST, I got a letter\nwhere Linus Torvalds said that...\n> The thing is, if you don't understand how rebasing etc destroys history, \n> you may do things like do a \"git pull\" or a \"git merge\" of a branch that \n> the other side WILL THROW AWAY! That will later result in major pain, \n> because when you then try to merge it later, you will get all kinds of \n> nasty behaviour, because the history you merged earlier no longer matches \n> the history you're now trying to merge again, and the work you merged \n> earlier is simply not there any more.\n\nThis is a very good point.\n\nBut this just means that, as others in the thread noted, there needs to\nbe a reliable way for marking floating branches in the public\nrepositories and enforcing the implications of that locally (not letting\nthe user to merge with those).\n\nWhen I've said \"seamless support for floating branches\", generally what\nI've had on my mind was that it's seamless for the user, that his the\none who pulls them - the developer can be required to do something small\nextra to mark those as such.\n\n\nWhen you have that, you can just:\n\n (i) Disallow three-way merges with +branches\n\n (ii) Fast-forward of +branches makes you follow the branch' rebase if\nthe original commit in the branch before fetching equaled your HEAD\ncommit, and taints your branch against committing unless you switch to\na non-+ branch (or manually untaint your branch)\n\n (iii) Of course enforce the fast-forward restriction for non-+\nbranches\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i wrote:\n> Dear diary, on Wed, Sep 20, 2006 at 11:14:25PM CEST, I got a letter\n> where Johannes Schindelin said that...\n> > Another, even more serious problems with rebasing: You can introduce a bug\n> > by rebasing. Meaning: git-rebase can succeed, even compilation is fine,\n> > but the sum of your patches, and the patches you are rebasing on, is\n> > buggy. And there is _no_ way to bisect this, since the \"good\" version can\n> > be gone for good.\n>\n> Yes, I agree that this really is a problem, but that's a fundamental\n> limitation. At least for StGIT-maintained floating branches the latest\n> bleeding edge StGIT could fix that. (Except that the problem outlined by\n> Linus is present here as well, first prune will wipe your older patch\n> versions and your patch log will be useless - Catalin? Can we store the\n> older patch versions references in something like\n> .git/refs/patches-old/?) And except that it does that only for you -\n> there should be a way to conveniently mirror (clone+pull) the patch\n> stack setup.\n\nI wasn't following this thread (well, any thread in the last days) but\nthe current patch history implementation in StGIT is prune-safe as it\ngenerates additional commits to keep the history. If you undo an\noperation (push, refresh), the undo will be recorded in the patch\nhistory (that's really immutable). However, deleting a patch would\ndelete the corresponding history log as well.\n\n-- \nCatalin\n"},{"id":"27472","messageId":"b0943d9e0609230615t60e6d573r4abe043c079a2367@mail.gmail.com","threadId":"5623","inReplyTo":"20060923040942.GG8259@pasky.or.cz","subject":"Re: git pull for update of netdev fails.","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2006-09-23T13:15:01Z","receivedAt":"2006-09-23T13:15:01Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"On 23/09/06, Petr Baudis wrote:\n> Dear diary, on Sat, Sep 23, 2006 at 06:00:35AM CEST, I got a letter\n> where Shawn Pearce said that...\n> > I can see the same concept of ref history being useful even for\n> > core git-rebase and doing it this way would also give it to StGIT\n> > without Catalin needing to change code.\n>\n> In my StGIT tree, I don't want to have arbitrary N-days cutoff point,\n> I want all the patches history preserved at least as long as I carry\n> the patch, because it's just as valuable as the \"regular\" project\n> history to me.\n\nThat's how it currently works (the top of the log is in\nrefs/patches//.log). I gave up the idea of using\nreflogs for patch history.\n\n-- \nCatalin\n"},{"id":"27580","messageId":"20060924205455.GA20017@pasky.or.cz","threadId":"5623","inReplyTo":"b0943d9e0609230610h46ffb995gb25ebda8332570e8@mail.gmail.com","subject":"Re: git pull for update of netdev fails.","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-09-24T20:54:55Z","receivedAt":"2006-09-24T20:54:55Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Sat, Sep 23, 2006 at 03:10:17PM CEST, I got a letter\nwhere Catalin Marinas said that...\n> (I'm slow at replying and even slower at implementing anything over\n> the next 2-3 weeks - paternity leave :-))\n\nCongratulations! :-)\n\n> I wasn't following this thread (well, any thread in the last days) but\n> the current patch history implementation in StGIT is prune-safe as it\n> generates additional commits to keep the history. If you undo an\n> operation (push, refresh), the undo will be recorded in the patch\n> history (that's really immutable)\n\nIt does not directly reference the history in the additional commits\nthough, it just mentions the sha1 in the log message - that is not\nprune-safe:\n\n$ cg-log -r patches/master/configchanges.log\n...pick one at random...\ncommit 4e1ad4b1bfb9488636f1a43b3f3d4b8c3b4b2927\ntree 4ba8253dff8190e75ad0f46deaef54747c4ad76d\nparent 3d5f3a87134a056a52dc21bcc4b1c64a4eef9443\nauthor pasky Tue, 19 Sep 2006 16:47:42 +0200\ncommitter pasky Tue, 19 Sep 2006 16:47:42 +0200\n\n * Makefile:\n\n refresh 4852cc3fe638b332f4106b31a7abfafb2c6c3dfc\n$ git-fsck-objects --unreachable | grep\n4852cc3fe638b332f4106b31a7abfafb2c6c3dfc\nunreachable commit 4852cc3fe638b332f4106b31a7abfafb2c6c3dfc\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i wrote:\n> Dear diary, on Sat, Sep 23, 2006 at 03:10:17PM CEST, I got a letter\n> where Catalin Marinas said that...\n> > I wasn't following this thread (well, any thread in the last days) but\n> > the current patch history implementation in StGIT is prune-safe as it\n> > generates additional commits to keep the history. If you undo an\n> > operation (push, refresh), the undo will be recorded in the patch\n> > history (that's really immutable)\n>\n> It does not directly reference the history in the additional commits\n> though, it just mentions the sha1 in the log message - that is not\n> prune-safe:\n\nYes, indeed (I'm still tired :-)). The patch changes are safe and one\ncould probably generate the patch from them but it's a bit more\ncomplicated. The quick solution is to add another parent to the\nchangelog commit so that it points to the patch. However, this\nwouldn't look as nice with gitk as it sees them as merges and doesn't\ndisplay the diff (is there an option I missed?).\n\n-- \nCatalin\n"}]}