{"thread":{"id":"3365","subject":"Why can't git-rebase back up?","startedAt":"2006-02-17T13:59:38Z","lastAt":"2006-02-18T14:53:01Z","messageCount":10,"participants":["linux@horizon.com","Andreas Ericsson","Junio C Hamano","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"16315","messageId":"20060217135938.7412.qmail@science.horizon.com","threadId":"3365","inReplyTo":null,"subject":"Why can't git-rebase back up?","fromName":"","fromEmail":"linux@horizon.com","sentAt":"2006-02-17T13:59:38Z","receivedAt":"2006-02-17T13:59:38Z","isPatch":false,"sender":{"key":"linux@horizon.com","avatar":null},"body":"Newbie question...  In what I assume is a usual technique, I maintain a\n\"build\" branch off of the linux-2.6 history which is what I check out\nto build a kernel.  I usually keep it at an official tagged releas,\nsuch as v2.6.16-rc2.\n\n[[ This is because core git won't allow the checked-out HEAD to point\nto anything but a branch, and checking out something without having\nHEAD point to it is fragile and delicate.  Cogito lets you do this with\ncg-seek. ]]\n\nNow, if I want to migrate to a newer base version, I can always use\ngit-reset --hard v2.6.16-rc3, but that's a bit dangerous.\nPreferable is to use git-rebase v2.6.16-rc3, which will preserve\nany local edits.\n\n(I could also do it as a merge, but that seems like unnecessary history\nclutter.  It's not like local edits are common, anyway.)\n\nBut suppose discover a nasty bug in -rc3 and want to move my build branch\nback to -rc2.  \"git-rebase v2.6.16-rc2\" does nothing.  After a bit\nof thought, I realize why, but sometime I do want to back up.\n\nWhat's the best way to do that?  Should git-rebase take an optional\nthird argument which is the branch head we are moving away from?\nE.g. what I want to do would be\n\n\tgit-rebase v2.6.16-rc2 build v2.6.16-rc3\n\nOr is there some other tool already suited to the job?\n\n(Yes, I'm aware the operations cannot be exact inverses, because if\nI applied a local patch that was also included in -rc3, git-rebase\nwill delete the redundant copy from the build branch, and the backing\nup will have no way to know to put it back.  If I wanted to do that,\nI would use a merge.)\n\n\nOn a completely unrelated note, how do I find out what git thinks of a\nparticular file, such as linux-2.6/.config?  It isn't listed in the\noutput of git-status or git-ls-files, but git-ls-files -i produces an error.\nVery confusingly,\ngit-ls-files -i --exclude-per-directory=.gitignore -X .git/info/exclude .config\nalso produces no output, even though .* is listed in .gitignore.\n"},{"id":"16323","messageId":"43F5DF8B.6050307@op5.se","threadId":"3365","inReplyTo":"20060217135938.7412.qmail@science.horizon.com","subject":"Re: Why can't git-rebase back up?","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-02-17T14:36:59Z","receivedAt":"2006-02-17T14:36:59Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"linux@horizon.com wrote:\n> Newbie question...  In what I assume is a usual technique, I maintain a\n> \"build\" branch off of the linux-2.6 history which is what I check out\n> to build a kernel.  I usually keep it at an official tagged releas,\n> such as v2.6.16-rc2.\n> \n> [[ This is because core git won't allow the checked-out HEAD to point\n> to anything but a branch,\n\n\nYes it will. That's how \"git reset\" works (i.e. pointing HEAD to some \nrandom object). Think of branches and tags as short and humanly \nunderstandable names for certain points in the history. You can visit \nany point in history without having a special short name for it.\n\n> and checking out something without having\n> HEAD point to it is fragile and delicate.  Cogito lets you do this with\n> cg-seek. ]]\n> \n\nIt's more than delicate. It's impossible (even for Cogito). You can take \nsnapshots of how the tree looked at a certain state and export that \nusing git-tar-tree if you wish, but other than that it's impossible to \nvisit a certain point in history without pointing HEAD to it (that's how \nvisiting that point is done, actually).\n\n> Now, if I want to migrate to a newer base version, I can always use\n> git-reset --hard v2.6.16-rc3, but that's a bit dangerous.\n> Preferable is to use git-rebase v2.6.16-rc3, which will preserve\n> any local edits.\n> \n> (I could also do it as a merge, but that seems like unnecessary history\n> clutter.  It's not like local edits are common, anyway.)\n> \n> But suppose discover a nasty bug in -rc3 and want to move my build branch\n> back to -rc2.  \"git-rebase v2.6.16-rc2\" does nothing.  After a bit\n> of thought, I realize why, but sometime I do want to back up.\n> \n\nI'd suggest doing something like this when changing base version (of any \nproject, really). Let's say you start, for the first time, with \nv2.6.16-rc2. The workflow would look something like this:\n\n$ git checkout -b mod-2.6.16-rc2 v2.6.16-rc2; # create a branch at the \ndesired point in history\n$ apply your changes\n\n2.6.16-rc3 is out, and you want to use that instead.\n$ git checkout -b mod-2.6.16-rc3 v2.6.16-rc3; # new branch for new trial\n$ git rebase mod-2.6.16-rc2; # apply patches you've already made\n\nNow a couple of different things can happen:\n1. The rebase works fine. Oh, joy of joy!\n2. The rebase doesn't work, but a merge does:\n$ git pull . mod-2.6.16-rc2\n3. Neither merge or rebase works, but you can manually apply your \npatches, drop the offending ones or resolve the conflicts.\n4. There's a bug so you want to regress. Just do:\n$ git checkout mod-2.6.16-rc2\n\nIn this scenario, only option 3 means trouble and that's inevitable no \nmatter how you work since your patches no longer apply.\n\n\n> What's the best way to do that?  Should git-rebase take an optional\n> third argument which is the branch head we are moving away from?\n> E.g. what I want to do would be\n> \n> \tgit-rebase v2.6.16-rc2 build v2.6.16-rc3\n> \n> Or is there some other tool already suited to the job?\n> \n> (Yes, I'm aware the operations cannot be exact inverses, because if\n> I applied a local patch that was also included in -rc3, git-rebase\n> will delete the redundant copy from the build branch, and the backing\n> up will have no way to know to put it back.  If I wanted to do that,\n> I would use a merge.)\n> \n\nIf you merge a branch based on top of a later head you'd end up with the \nsame commits in your history anyways, since it would have to merge all \ncommits up to the merge-base. In essence, you'd do a complicated \nfast-forward, but with reverse history to what I think you think (i.e. \nyou'd be pulling 2.6.16-rc3 in on top of your patches).\n\nOne way to accomplish this would be to do:\n$ git checkout mod-2.6.16-rc3; # get to that point, one way or another\n$ git format-patch -k --stdout v2.6.16-rc3 > 2.6.16-rc3.patches.mbox\n$ git reset --hard v2.6.16-rc2; # get to that point, one way or another\n$ git am -k 2.6.16-rc3.patches.mbox\n\nHowever, branches and tags are cheap to create, efficient to use, easy \nto remove once you're done with them. They make life easier. Use them. \nYou'll be glad you did.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n"},{"id":"16327","messageId":"20060217153434.26359.qmail@science.horizon.com","threadId":"3365","inReplyTo":"43F5DF8B.6050307@op5.se","subject":"Re: Why can't git-rebase back up?","fromName":"","fromEmail":"linux@horizon.com","sentAt":"2006-02-17T15:34:34Z","receivedAt":"2006-02-17T15:34:34Z","isPatch":false,"sender":{"key":"linux@horizon.com","avatar":null},"body":">> [[ This is because core git won't allow the checked-out HEAD to point\n>> to anything but a branch,\n\n> Yes it will. That's how \"git reset\" works (i.e. pointing HEAD to some \n> random object). Think of branches and tags as short and humanly \n> understandable names for certain points in the history. You can visit \n> any point in history without having a special short name for it.\n\nEr... say again?  git reset doesn't touch the .git/HEAD symlink;\nit overwrites the file that .git/HEAD points to.\n\nIf you know a way to make the core git tools produce a .git/HEAD that\nis either not a symlink or does NOT begin with \"refs/heads/\", I'm quite\ncurious.\n\n>> and checking out something without having\n>> HEAD point to it is fragile and delicate.  Cogito lets you do this with\n>> cg-seek. ]]\n\n> It's more than delicate. It's impossible (even for Cogito). You can take \n> snapshots of how the tree looked at a certain state and export that \n> using git-tar-tree if you wish, but other than that it's impossible to \n> visit a certain point in history without pointing HEAD to it (that's how \n> visiting that point is done, actually).\n\nActually, you're right... Cogito uses refs/heads/cg-seek-point.\nBut you can do it by hand with git-read-tree and git-checkout-index.\n(Very little in git is impossible; some things are just a Really Bad\nIdea.)\n\n> Now, if I want to migrate to a newer base version, I can always use\n> git-reset --hard v2.6.16-rc3, but that's a bit dangerous.\n> Preferable is to use git-rebase v2.6.16-rc3, which will preserve\n> any local edits.\n> \n> (I could also do it as a merge, but that seems like unnecessary history\n> clutter.  It's not like local edits are common, anyway.)\n> \n> But suppose discover a nasty bug in -rc3 and want to move my build branch\n> back to -rc2.  \"git-rebase v2.6.16-rc2\" does nothing.  After a bit\n> of thought, I realize why, but sometime I do want to back up.\n> \n\n> I'd suggest doing something like this when changing base version (of any \n> project, really).\n\n[Use separate branch names for the two build versions.]\n\nThat's certainly a possibility, but kind of annoying to remember what\nthe \"current\" version is.  Typically, there are no local changes,\nand I'm just using \"build\" as a conventional name to let me check\nout the version.  Just like cg-seek-point.\n\n> However, branches and tags are cheap to create, efficient to use, easy \n> to remove once you're done with them. They make life easier. Use them. \n> You'll be glad you did.\n\nI don't really *want* a branch at all.  I just want to export the\nright source tree and compile it.  Local changes are more likely a\nmistake than anything else, but core git doesn't have Cogito's \"blocked\"\nflag.  I'm just trying to avoid getting\ninto the habit of typing \"git reset --hard\" a lot because that's\ndangerous.\n\nIt's sort of along the lines of \"any workflow that makes you type\n'rm -rf *' on a regular basis is a recipe for disaster\".\n\nThe usual solution, of course, is to write a shell script wrapper with\nsome safety checking.  For example, I could see if git-name-rev --tags\ncan come up with a name for the branch head before unleashing git-reset\non it.\n\nBut I thought I'd check if the tool already existed.\n"},{"id":"16330","messageId":"43F5FA10.5020605@op5.se","threadId":"3365","inReplyTo":"20060217153434.26359.qmail@science.horizon.com","subject":"Re: Why can't git-rebase back up?","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-02-17T16:30:08Z","receivedAt":"2006-02-17T16:30:08Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"linux@horizon.com wrote:\n>>>[[ This is because core git won't allow the checked-out HEAD to point\n>>>to anything but a branch,\n> \n> \n>>Yes it will. That's how \"git reset\" works (i.e. pointing HEAD to some \n>>random object). Think of branches and tags as short and humanly \n>>understandable names for certain points in the history. You can visit \n>>any point in history without having a special short name for it.\n> \n> \n> Er... say again?  git reset doesn't touch the .git/HEAD symlink;\n> it overwrites the file that .git/HEAD points to.\n> \n\nMy bad. You're right.\n\n> If you know a way to make the core git tools produce a .git/HEAD that\n> is either not a symlink or does NOT begin with \"refs/heads/\", I'm quite\n> curious.\n> \n\nThe order of precedence works as such:\n.git/<anchor-name>\n.git/refs/<anchor-name>\n.git/refs/tags/<tag-name>\n.git/refs/heads/<branch-name>\nsha1, with git magic to allow abbreviations\n\nThis is why you can't sanely have a branch named HEAD.\n\n> \n>>>and checking out something without having\n>>>HEAD point to it is fragile and delicate.  Cogito lets you do this with\n>>>cg-seek. ]]\n> \n> \n>>It's more than delicate. It's impossible (even for Cogito). You can take \n>>snapshots of how the tree looked at a certain state and export that \n>>using git-tar-tree if you wish, but other than that it's impossible to \n>>visit a certain point in history without pointing HEAD to it (that's how \n>>visiting that point is done, actually).\n> \n> \n> Actually, you're right... Cogito uses refs/heads/cg-seek-point.\n> But you can do it by hand with git-read-tree and git-checkout-index.\n> (Very little in git is impossible; some things are just a Really Bad\n> Idea.)\n> \n> \n>>Now, if I want to migrate to a newer base version, I can always use\n>>git-reset --hard v2.6.16-rc3, but that's a bit dangerous.\n>>Preferable is to use git-rebase v2.6.16-rc3, which will preserve\n>>any local edits.\n>>\n>>(I could also do it as a merge, but that seems like unnecessary history\n>>clutter.  It's not like local edits are common, anyway.)\n>>\n>>But suppose discover a nasty bug in -rc3 and want to move my build branch\n>>back to -rc2.  \"git-rebase v2.6.16-rc2\" does nothing.  After a bit\n>>of thought, I realize why, but sometime I do want to back up.\n>>\n> \n> \n>>I'd suggest doing something like this when changing base version (of any \n>>project, really).\n> \n> \n> [Use separate branch names for the two build versions.]\n> \n> That's certainly a possibility, but kind of annoying to remember what\n> the \"current\" version is.  Typically, there are no local changes,\n> and I'm just using \"build\" as a conventional name to let me check\n> out the version.  Just like cg-seek-point.\n> \n\nThen make the current production be 'build', the \"soon-to-become \nproduction\" to be 'devel' and tag the ones you're finished with so you \ncan revert to them easily if it becomes necessary. That's more or less \nhow all projects work, AFAIK.\n\n> \n>>However, branches and tags are cheap to create, efficient to use, easy \n>>to remove once you're done with them. They make life easier. Use them. \n>>You'll be glad you did.\n> \n> \n> I don't really *want* a branch at all.  I just want to export the\n> right source tree and compile it.\n\n\n$ git tar-tree v2.6.16-rc3 linux-2.6.16-rc3\n\nOTOH, you could just download the released sources and patches from ftp.\n\n>  Local changes are more likely a\n> mistake than anything else, but core git doesn't have Cogito's \"blocked\"\n> flag.  I'm just trying to avoid getting\n> into the habit of typing \"git reset --hard\" a lot because that's\n> dangerous.\n> \n\nI don't see why you should have to, even if you don't use a topic-branch \nfor fiddling with things. You can still do\n\n\t$ git tar-tree <tag> linux-<tag>\n\nto get the snapshot no matter how much you reset and muck about with the \nworking tree copy of the current HEAD.\n\nIf you're unsure about this, try\n\n$ git checkout -b foo 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2\n$ gitk; # behold the dawn of time\n$ git tar-tree v2.6.16-rc3 foo | gzip -9 > foo.tar.gz\n\nNote that the first operation takes quite a while, as it has to update \nall the files in the working tree.\n\n> It's sort of along the lines of \"any workflow that makes you type\n> 'rm -rf *' on a regular basis is a recipe for disaster\".\n> \n> The usual solution, of course, is to write a shell script wrapper with\n> some safety checking.  For example, I could see if git-name-rev --tags\n> can come up with a name for the branch head before unleashing git-reset\n> on it.\n> \n> But I thought I'd check if the tool already existed.\n> \n\nIt does, and it doesn't. git checkout -b <name> <commit-ish> does what \nyou want, although it creates a branch. \"git seek\" isn't needed, since \ncreating branches is so cheap and far better than having to protect \ncertain branch- and tag-names for the sake of creating tools that offer \nless power and flexibility than those already there.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n"},{"id":"16370","messageId":"7vmzgpru8m.fsf@assigned-by-dhcp.cox.net","threadId":"3365","inReplyTo":"20060217135938.7412.qmail@science.horizon.com","subject":"Re: Why can't git-rebase back up?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-18T07:39:21Z","receivedAt":"2006-02-18T07:39:21Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"linux@horizon.com writes:\n\n> But suppose discover a nasty bug in -rc3 and want to move my build branch\n> back to -rc2.  \"git-rebase v2.6.16-rc2\" does nothing.  After a bit\n> of thought, I realize why, but sometime I do want to back up.\n>\n> What's the best way to do that?  Should git-rebase take an optional\n> third argument which is the branch head we are moving away from?\n> E.g. what I want to do would be\n>\n> \tgit-rebase v2.6.16-rc2 build v2.6.16-rc3\n\nThe one in \"next\" has a topic branch change which lets you say:\n\n\t$ git rebase --onto v2.6.16-rc2 v2.6.16-rc3 build\n\nwhich is a shorthand for\n\n\t$ git checkout build\n\t$ git rebase --onto v2.6.16-rc2 v2.6.16-rc3\n\nThat is, tear out my changes that forked from the development\ntrail that led to v2.6.16-rc3, and graft them on top of\nv2.6.16-rc2.\n"},{"id":"16369","messageId":"7vhd6xru8h.fsf@assigned-by-dhcp.cox.net","threadId":"3365","inReplyTo":"43F5FA10.5020605@op5.se","subject":"Re: Why can't git-rebase back up?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-18T07:39:26Z","receivedAt":"2006-02-18T07:39:26Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andreas Ericsson <ae@op5.se> writes:\n\n> The order of precedence works as such:\n> .git/<anchor-name>\n> .git/refs/<anchor-name>\n> .git/refs/tags/<tag-name>\n> .git/refs/heads/<branch-name>\n> sha1, with git magic to allow abbreviations\n>\n> This is why you can't sanely have a branch named HEAD.\n\nActually, you should be able to sanely have a branch named HEAD.\n\nWhen git barebone Porcelain tools _expect_ branch name from the\nuser (not just a random committish), they _ought_ to prefix\n\"refs/heads\" in front of it, exactly in order to help\ndisambiguate things.\n\nOtherwise you have spotted a bug, so please send in a fix.\n\nIt is however a different story if you can keep your sanity if\nyou created a branch called HEAD.  You have to remember to\nexplicitly say refs/heads/HEAD, where a command wants any\ncommittish or treeish.\n"},{"id":"16374","messageId":"20060218085608.30325.qmail@science.horizon.com","threadId":"3365","inReplyTo":"7vmzgpru8m.fsf@assigned-by-dhcp.cox.net","subject":"Re: Why can't git-rebase back up?","fromName":"","fromEmail":"linux@horizon.com","sentAt":"2006-02-18T08:56:08Z","receivedAt":"2006-02-18T08:56:08Z","isPatch":false,"sender":{"key":"linux@horizon.com","avatar":null},"body":"> The one in \"next\" has a topic branch change which lets you say:\n> \n>\t$ git rebase --onto v2.6.16-rc2 v2.6.16-rc3 build\n>\n> which is a shorthand for\n>\n>\t$ git checkout build\n>\t$ git rebase --onto v2.6.16-rc2 v2.6.16-rc3\n>\n> That is, tear out my changes that forked from the development\n> trail that led to v2.6.16-rc3, and graft them on top of\n> v2.6.16-rc2.\n\nAh, exactly what I was looking for!\nHowever, why did you decide to make the *destination* the option?\n\nJust giving a naive user's perspective, the argument to git-rebase\nis the *destination*, and it \"magically\" figures out the source.\n\nIt would seem more natural to me to have an option to explicltly\nspecify the \"from\" and leave the positional argument as the \"to\".\n\nThat also lets you do something about the rebasing-a-merged-branch\nproblem.  If you have:\n      g-->h-->i-->j topic\n     /       /\na-->b-->c-->d-->e-->f master\n\nThen I'd expect \"git-rebase master topic\" to fail with\nan error message like:\n\n\tError: \"topic\" and \"master\" do not have a unique common\n\t\tancestor.  Possible common ancestors:\n\t\tb (master~4)\n\t\td (master~2)\n\tRebasing a branch with merges is generally not recommended,\n\tbut if you want to do it, you need to specify where to cut\n\toff the branch to move.  You probably want one of the above.\n\nAnd you have to use \"git-rebase --from b master\" or --from d.\nH'm... is that unique?  What if you have a bizarre merge pattern\nline\n\n\n     k--->l---->m\n    /            \\\n    | g-->h-->i-->j topic\n    |/        \na-->b-->c-->d-->e-->f master\n\nor \n\n      g-->h-->i-->j topic\n     /       /\na-->b---------->c-->d master\n\nis \"--from b\" well-defined?  I'll have to play with the existing\ncode to see what it does.\n"},{"id":"16376","messageId":"7vpsllowo2.fsf@assigned-by-dhcp.cox.net","threadId":"3365","inReplyTo":"20060218085608.30325.qmail@science.horizon.com","subject":"Re: Why can't git-rebase back up?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-18T09:15:09Z","receivedAt":"2006-02-18T09:15:09Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"linux@horizon.com writes:\n\n> That also lets you do something about the rebasing-a-merged-branch\n> problem.  If you have:\n>\n>       g-->h-->i-->j topic\n>      /       /\n> a-->b-->c-->d-->e-->f master\n\nIdeally, you should be able to come up with:\n\n                        g'->h'->j' topic\n                       /\n  a-->b-->c-->d-->e-->f master\n\nBut it should not matter.  You should not be merging master (or\nany other branches that might have interaction with the topic)\ninto your topic branches to begin with.\n\nInstead, use a separate test branch and merge both topic and\nmaster into it:\n\n             g-->h-->j topic\n            /         \\       \n           /---o---o---o test\n          /       / \n     a-->b-->c-->d-->e-->f master\n\nOnce your topic is fully cooked, you would merge it into\nmaster.  If the area topic and master touch overlaps, you might\nhave to resolve the same conflict you would have already\nresolved when you merged (j) commit into test in the above\npicture, but that is why we have \"git rerere\" ;-).\n\nBTW, why are we suddenly having many nameless people on this\nlist, I wonder...\n"},{"id":"16383","messageId":"20060218130056.14228.qmail@science.horizon.com","threadId":"3365","inReplyTo":"7vpsllowo2.fsf@assigned-by-dhcp.cox.net","subject":"Re: Why can't git-rebase back up?","fromName":"","fromEmail":"linux@horizon.com","sentAt":"2006-02-18T13:00:56Z","receivedAt":"2006-02-18T13:00:56Z","isPatch":false,"sender":{"key":"linux@horizon.com","avatar":null},"body":"> BTW, why are we suddenly having many nameless people on this\n> list, I wonder...\n\nOh, you know, possibilities like:\n\n- I'm sick of being googled and quizzed about every off-the-cuff\n  remark I've ever made.\n- My real name is not pronouncable by earthlings.\n- My embittered ex joe-jobs me with porn spam whenever he finds a new\n  e-mail address for me.\n- My day job has licensed BitKeeper and I don't want hassles from\n  His Larryness.\n- I'm am illegal immigrant and I don't want to get noticed by la Migra.\n- My name is Jamal Al-Gashey and it's *so* not worth it.\n\nAnd I'm never sure if it's politer to use an obvious pseudonym or a\nsubtle one.\n-- \n\t-Michael Baldwin <bruce5@wallamaloo.edu.au>\n"},{"id":"16386","messageId":"Pine.LNX.4.63.0602181545450.3483@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"3365","inReplyTo":"20060218130056.14228.qmail@science.horizon.com","subject":"Re: Why can't git-rebase back up?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-02-18T14:53:01Z","receivedAt":"2006-02-18T14:53:01Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 18 Feb 2006, linux@horizon.com wrote:\n\n> > BTW, why are we suddenly having many nameless people on this\n> > list, I wonder...\n> \n> Oh, you know, possibilities like:\n> \n> - I'm sick of being googled and quizzed about every off-the-cuff\n>   remark I've ever made.\n> - My real name is not pronouncable by earthlings.\n> - My embittered ex joe-jobs me with porn spam whenever he finds a new\n>   e-mail address for me.\n> - My day job has licensed BitKeeper and I don't want hassles from\n>   His Larryness.\n> - I'm am illegal immigrant and I don't want to get noticed by la Migra.\n> - My name is Jamal Al-Gashey and it's *so* not worth it.\n\n- I'm working for NSA, and my name is classified.\n- If people knew who I am, they would fault me for my starting a war, \n  instead of commenting on my patches.\n- I could use a pseudonym, but that would be a lie, and since you cannot \n  tell if it is a pseudonym to begin with, it is an even bigger lie, and \n  if I did not use a pseudonym, you could mistake it for one, and I could\n  not live with that lie at all. (Recurse ad infinitum.)\n\nHaving said all that, I think it is important to provide a real and \ntraceable name with patches (at least patches which do not do obvious \nthings, like fix typos). If only for the reason that incompetent and \nmalign people like to sue not only each other.\n\nCiao,\nDscho\n"}]}