{"thread":{"id":"3272","subject":"What's in git.git","startedAt":"2006-02-09T06:47:54Z","lastAt":"2006-02-10T15:02:50Z","messageCount":16,"participants":["Junio C Hamano","sean","Andreas Ericsson","Johannes Schindelin","Tony Luck","Ryan Anderson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"15769","messageId":"7vslqtf2p1.fsf@assigned-by-dhcp.cox.net","threadId":"3272","inReplyTo":null,"subject":"What's in git.git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-09T06:47:54Z","receivedAt":"2006-02-09T06:47:54Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"I haven't heard major breakage around the new features scheduled\nfor 1.2.0 so far, except for the two-tree \"diff-tree --cc\" Linus\nhas already fixed, so the previous \"What's new\" is pretty much\nunchanged.\n\nOne *major* change I am thinking about doing is to change my\nworkflow a bit. So far, the proposed updates branch \"pu\" was\nalmost impossible to follow unless you are really a devoted git\ndeveloper, because it is always rebased to the latest master and\nthen topic branches are merged onto it. While that keeps the\nnumber of unnecessary merge nodes between master and pu to the\nminimum, it actively discouraged for the branch to be followed\nby developers.\n\nI would like to rectify that.\n\nSo I have created another branch, \"next\". This is managed quite\ndifferently from \"pu\". I'd promise these things:\n\n * It is to contain planned updates and merge from topic\n branches, just like \"pu\" currently does. However, the topics\n merged there will not contain majorly whacky / unproven ones\n like bind commits and shallow clones, until the basic part\n proves sound during the list discussion.\n\n * I will not rewind or rebase the \"next\" branch. Also I will\n not rebase the topic branches that are merged into it.\n\n * It would occasionally merge from \"master\" if only to prevent\n conflicts.\n\n * If there are patches sent to improve a topic branch in it,\n they will be applied to the topic branch, and then the topic\n branch is merged into \"next\", without any funny rewinding or\n rebasing of \"next\". This will make the \"next\" branch\n cluttered with repeated merges from the same topic branch,\n but that is OK. \"next\" will not be merged into \"master\",\n ever.\n\n * Once a topic is fully cooked, the topic branch will be merged\n into \"master\".\n\nWhat this means is that \"next\" should be as easy to follow as\n\"master\", but still is slightly ahead of \"master\" with not so\nwildly experimental features.\n\nAlthough there theoretically is no reason not to follow the\nabove principles I set for \"next\" to manage \"pu\", it will stay\nwild for now until I get more comfortable with this workflow.\n\nNow, what's in \"next\"? Currently I have two topic branches\nmerged to it.\n\n * jc/nostat:\n ls-files: debugging aid for CE_VALID changes.\n \"Assume unchanged\" git: do not set CE_VALID with --refresh\n \"Assume unchanged\" git\n\n * jc/empty-commit:\n t6000: fix a careless test library add-on.\n Do not allow empty name or email.\n"},{"id":"15771","messageId":"BAYC1-PASMTP1142DA49F5BC7B7B42B22FAE030@CEZ.ICE","threadId":"3272","inReplyTo":"7vslqtf2p1.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git","fromName":"sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-02-09T08:09:05Z","receivedAt":"2006-02-09T08:09:05Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Wed, 08 Feb 2006 22:47:54 -0800\nJunio C Hamano wrote:\n\n\n> One *major* change I am thinking about doing is to change my\n> workflow a bit. So far, the proposed updates branch \"pu\" was\n> almost impossible to follow unless you are really a devoted git\n> developer, because it is always rebased to the latest master and\n> then topic branches are merged onto it. While that keeps the\n> number of unnecessary merge nodes between master and pu to the\n> minimum, it actively discouraged for the branch to be followed\n> by developers.\n\nI've always followed it okay by just using \"git branch -d pu\" each time \nbefore pulling from you. Your \"next\" branch does sound like an \nimprovement though.\n\nSean\n"},{"id":"15772","messageId":"43EB05B5.20307@op5.se","threadId":"3272","inReplyTo":"BAYC1-PASMTP1142DA49F5BC7B7B42B22FAE030@CEZ.ICE","subject":"Re: What's in git.git","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-02-09T09:04:53Z","receivedAt":"2006-02-09T09:04:53Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"sean wrote:\n> On Wed, 08 Feb 2006 22:47:54 -0800\n> Junio C Hamano wrote:\n> \n> \n> \n>>One *major* change I am thinking about doing is to change my\n>>workflow a bit. So far, the proposed updates branch \"pu\" was\n>>almost impossible to follow unless you are really a devoted git\n>>developer, because it is always rebased to the latest master and\n>>then topic branches are merged onto it. While that keeps the\n>>number of unnecessary merge nodes between master and pu to the\n>>minimum, it actively discouraged for the branch to be followed\n>>by developers.\n> \n> \n> I've always followed it okay by just using \"git branch -d pu\" each time \n> before pulling from you. Your \"next\" branch does sound like an \n> improvement though.\n> \n\nI thought\n\n\tPull: +pu:pu\n\nwas supposed to handle such things automatically. It has always pulled \nproperly for me anyways.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"15774","messageId":"BAYC1-PASMTP02D0738F3BA0E42EB66C94AE030@CEZ.ICE","threadId":"3272","inReplyTo":"43EB05B5.20307@op5.se","subject":"Re: What's in git.git","fromName":"sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-02-09T09:40:39Z","receivedAt":"2006-02-09T09:40:39Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Thu, 09 Feb 2006 10:04:53 +0100\nAndreas Ericsson wrote:\n\n> I thought\n> \n> \tPull: +pu:pu\n> \n> was supposed to handle such things automatically. It has always pulled \n> properly for me anyways.\n> \n\nThe only problem with that is that Junio rebases and discards commits\nperiodically that will still be in your local pu branch. The fetch/merge \nlogic doesn't notice that commits have disappeared from Junio's pu branch.\nSo you'll end up with a union of all the pu branches in your local repo \nwith commits that were dropped and never merged into mainline by Junio.\n\nUnless you add changes to the pu branch locally you should never need\nanything but a fast forward when pulling from Junio. Except it breaks\nwhen he rebases things. The easy hackish \"fix\" is just to delete and repull\nthe branch which is always small anyway.\n\nSean\n"},{"id":"15775","messageId":"7vk6c4etzy.fsf@assigned-by-dhcp.cox.net","threadId":"3272","inReplyTo":"43EB05B5.20307@op5.se","subject":"Re: What's in git.git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-09T09:55:45Z","receivedAt":"2006-02-09T09:55:45Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andreas Ericsson writes:\n\n> sean wrote:\n>> I've always followed it okay by just using \"git branch -d pu\" each\n>> time before pulling from you. Your \"next\" branch does sound like\n>> an improvement though.\n>\n> I thought\n>\n> \tPull: +pu:pu\n>\n> was supposed to handle such things automatically. It has always pulled\n> properly for me anyways.\n\nYes, fetching to look at is no problem, but what I wanted to\nsolve is that you cannot easily _touch_ it. The point of this\nis to make improving on top of what is still _not_ in master\neasier for the contributors.\n\nIf you want to improve upon what is in the current \"pu\", the\nnatural thing for you to do would be:\n\n\t$ git fetch git://git.kernel.org/pub/scm/git/git +pu:pu\n\t$ git checkout -b my-pu pu ;# initial\n $ hack on it and git commit many times\n $ git format-patch --stdout pu..my-pu |\n git send-email --to junkio@cox.net --cc git@vger.kernel.org\n\n(Side note: I do not know git-send-email would work like the\nabove, but if it did that might be handy. Ryan?)\n\nBut sometimes you may take more time than how my \"pu\"\nprogresses, and you would want to sync your work to my updated\n\"pu\". A natural thing you would want to do is this:\n\n $ git pull git://git.kernel.org/pub/scm/git/git +pu:pu\n\nUnfortunately, this would _not_ work very well, because by the\ntime you pull from my \"pu\" again, it would have rewound and\nrebased. You would end up seeing unnecessary merge conflicts.\n\nAnother possibility would be:\n\n $ git fetch git://git.kernel.org/pub/scm/git/git +pu:pu\n $ git rebase pu\n\nThis helps somewhat because \"git rebase\" uses \"git cherry\" to\ndetect the same patch with different commit ID in \"pu\" that you\nalready have in \"my-pu\". But my topic branches have been\nsometimes rewound and even rewritten to fix minor points (using\n\"reset --soft HEAD^\" followed by \"commit -a -c ORIG_HEAD\"), and\nwhen that happens \"git rebase\" would not be of much help.\n\nThe updated workflow on my part is trying to reduce these\nproblems by (1) not rewinding nor rebasing \"next\" and (2) not\nrewinding nor rebasing the topic branches merged into \"next\".\n\nStrictly speaking, the latter is not necessary (I would need to\nresolve conflicts when merging the rewound/rebased topic\nbranches into \"next\", but after that is done, contributors who\npulled \"next\" do not have to deal with that, as long as \"next\"\nitself is not rewound/rebased), but that way you could disect\ncomponent topic branches more easily out of \"next\".\n\nFor example, as of this writhing, my \"master\" and \"next\" look\nlike this:\n\n $ git show-branch --topo-order master next\n * [master] .gitignore git-rerere and config.mak\n ! [next] Merge branch 'jc/nostat'\n --\n - [next] Merge branch 'jc/nostat'\n + [next^2] \"Assume unchanged\" git: --really-refresh fix.\n - [next^] Merge branch 'jc/ls-files-o'\n + [next^^2] ls-files: honour per-directory ignore file ...\n - [next~2] Merge branches 'jc/nostat' and 'jc/empty-commit'\n + [next~2^3] t6000: fix a careless test library add-on.\n + [next~2^3^] Do not allow empty name or email.\n + [next^2^] ls-files: debugging aid for CE_VALID changes.\n + [next^2~2] \"Assume unchanged\" git: do not set CE_VALID...\n + [next^2~3] \"Assume unchanged\" git\n *+ [master] .gitignore git-rerere and config.mak\n\nIf you want to help fixing my thinko in jc/nostat branch, you\ncould:\n\n\t$ git checkout -b jc/nostat next^2\n $ fix fix fix; git commit\n\nBy convention, merge records what was the tip of the branch as\nthe first parent, and the second parent (and subsequent ones if\nit is an Octopus) is the tip of the branch that was merged in,\nso you can tell \"next^2\" is what was merged into the branch to\nadvance \"next\"; in other words, that is the tip of the jc/nostat\nbranch. Similarly, you can tell the tip of jc/empty-commit was\nmerged to next~2 in an Octopus as the second merged-in branch,\nso you can tell that its tip is next~2^3.\n\nYou could even publish your jc/nostat branch after you built on\nit and tell me to pull from it to fix my stupidity.\n"},{"id":"15777","messageId":"Pine.LNX.4.63.0602091055540.24701@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"3272","inReplyTo":"7vslqtf2p1.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-02-09T09:58:13Z","receivedAt":"2006-02-09T09:58:13Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 8 Feb 2006, Junio C Hamano wrote:\n\n> So I have created another branch, \"next\".\n\nI never quite understood why you not just publish your topic branches. \nIMHO what you intend to put into \"next\" should be put into \"master\" \nanyway: everyone interested in git development should try the new features \nas early as possible. If there is a \"whacky\" feature, you can put it into \n\"whacky/archexport\" or something along the lines.\n\nCiao,\nDscho\n"},{"id":"15779","messageId":"43EB1984.3040602@op5.se","threadId":"3272","inReplyTo":"7vk6c4etzy.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-02-09T10:29:24Z","receivedAt":"2006-02-09T10:29:24Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> Andreas Ericsson writes:\n> \n> \n>>sean wrote:\n>>\n>>>I've always followed it okay by just using \"git branch -d pu\" each\n>>>time before pulling from you. Your \"next\" branch does sound like\n>>>an improvement though.\n>>\n>>I thought\n>>\n>>\tPull: +pu:pu\n>>\n>>was supposed to handle such things automatically. It has always pulled\n>>properly for me anyways.\n> \n> \n> Yes, fetching to look at is no problem, but what I wanted to\n> solve is that you cannot easily _touch_ it. The point of this\n> is to make improving on top of what is still _not_ in master\n> easier for the contributors.\n> \n> If you want to improve upon what is in the current \"pu\", the\n> natural thing for you to do would be:\n> \n> \t$ git fetch git://git.kernel.org/pub/scm/git/git +pu:pu\n> \t$ git checkout -b my-pu pu ;# initial\n> $ hack on it and git commit many times\n> $ git format-patch --stdout pu..my-pu |\n> git send-email --to junkio@cox.net --cc git@vger.kernel.org\n> \n\nThis is exactly what I do when I improve upon things in master, and \naccording to numerous emails this is the recommended workflow.\n\n> (Side note: I do not know git-send-email would work like the\n> above, but if it did that might be handy. Ryan?)\n> \n\nWith my (still un-published) git-send-patch you could do\n\n\t$ work, work, work\n\t$ git send-patch -s \"Some subject for a prelude message\" pu\n\nand it would do the right thing.\n\nI guess I'll have to get around to sending that thing in sooner or later.\n\n> But sometimes you may take more time than how my \"pu\"\n> progresses, and you would want to sync your work to my updated\n> \"pu\". A natural thing you would want to do is this:\n> \n> $ git pull git://git.kernel.org/pub/scm/git/git +pu:pu\n> \n\nDo you mean\n\t$ git pull git://git.kernel.org/pub/scm/git/git +pu:my-pu\n\n? Otherwise, I don't see how I can end up with merge-conflicts.\n\n> Unfortunately, this would _not_ work very well, because by the\n> time you pull from my \"pu\" again, it would have rewound and\n> rebased. You would end up seeing unnecessary merge conflicts.\n> \n> Another possibility would be:\n> \n> $ git fetch git://git.kernel.org/pub/scm/git/git +pu:pu\n> $ git rebase pu\n> \n\nUsing my own topic-branch, this is what I always do. Conflicts that \noccur that way are always in my patches, so they would have to be \nreworked anyway. The new rerere tool should help if I dally too long.\n\nPerhaps I'm just weird, but I never touch published branches.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"15780","messageId":"7vfymsddqo.fsf@assigned-by-dhcp.cox.net","threadId":"3272","inReplyTo":"Pine.LNX.4.63.0602091055540.24701@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: What's in git.git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-09T10:32:15Z","receivedAt":"2006-02-09T10:32:15Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> IMHO what you intend to put into \"next\" should be put into \"master\" \n> anyway: everyone interested in git development should try the new features \n> as early as possible.\n\nYes, but I've been trying to be _very_ conservative to keep\n\"master\" clean and stable, as I said in my inauguration speech.\n\nSince git is still young and we are building features that are\nneeded in the field every day, it is very beneficial for users\nto keep up-to-date with \"master\", and I would really like to\nencourage that. It saddens me to see git patches posted to the\nkernel list marked with 0.99.9.GIT by prominent kernel people.\n\nHowever, I do not want to see their time wasted on getting\nbitten by stupid bugs I carelessly place on the \"master\" branch.\nSo I'd like to keep \"master\" conservative, stable and boring, at\nleast for now.\n\nInstead of introducing \"next\", I could treat \"pu\" the way I said\nI would do \"next\". But even if I rid of its constant rewinding\nnature, \"pu\" tends to have intrusive stuff near its tip and is\nvery hard to build on top of it. Patches against the tip of\n\"pu\" to fix things unrelated to the whacky ones often would be\ninapplicable to \"master\". This is especially true with what are\ncurrently pending near the tip of \"pu\" (bind commits and shallow\nclones). I do not forsee them to graduate to \"master\" any time\nsoon. Not in their current shape.\n\nThe promised \"next\" should be much easier to build on top of,\nwithout disecting it into component topic branches, and it would\nbe the branch to track for people interested in git development\nif you want to stay closer to the edge without touching bleeding\nor even broken edge. Making it easier to participate in git\ndevelopment by people interested is what I am aiming at here.\n\nI've considered publishing the topic branches individually.\nBranches are cheap from the storage point of view (not really,\none inode and a filesystem block wasted to store only 41-bytes\n;-)), but it needs management time and care (I will need to\nremember to go to the repository and remove stale ones once they\nare merged up). Since branches in \"next\" are meant to be\nshort-lived, I am hoping it is easier for me to bundle them up\nlike I am planning.\n\nOn the other hand, long-lived whacky intrusive ones might be\nbetter published as individual branches. \n"},{"id":"15781","messageId":"7vr76cby2v.fsf@assigned-by-dhcp.cox.net","threadId":"3272","inReplyTo":"43EB1984.3040602@op5.se","subject":"Re: What's in git.git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-09T10:55:52Z","receivedAt":"2006-02-09T10:55:52Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andreas Ericsson writes:\n\n> This is exactly what I do when I improve upon things in master, and\n> according to numerous emails this is the recommended workflow.\n\nYes.\n\n> Do you mean\n> \t$ git pull git://git.kernel.org/pub/scm/git/git +pu:my-pu\n\nI do mean \"+pu:pu\". In my illustration, \"pu\" is used in your\nrepository to track \"pu\" retrieved from me, and \"my-pu\" is a\nfork you created from it and you build your changes upon.\n\n\t$ git pull $URL +pu:my-pu\n\nis a shorthand for:\n\n\t$ git fetch $URL +pu:my-pu\n $ git merge \"auto merge message\" HEAD my-pu\n\nand you definitely do not want to _fetch_ into my-pu when you\nare on my-pu.\n\n> ? Otherwise, I don't see how I can end up with merge-conflicts.\n\nThe problem is exactly why you need the plus sign when you fetch,\ni.e. \"+pu:pu\". My \"pu\" rebases.\n\nSuppose I had this:\n\n o--o--o\n / \"pu\"\n\to--o\n \"master\" \n\nYou do fetch +pu:pu, branch my-pu, and build on top of it:\n\n o--o--o--o--o--o--o\n / \"my-pu\"\n o--o--o\n / \"pu\"\n\to--o\n \"master\"\n\nI add some to my \"master\" and rebuild \"pu\", maybe while adding\nanother commit on \"pu\". You fetch +pu:pu again:\n\n o--o--o--o--o--o--o\n / \"my-pu\"\n o--o--o o--o--o--o\n / / \"pu\" \n\to--o--o--o--o--o--o\n \"master\"\n\nNow, what happens when you merge \"pu\" into \"my-pu\"? The three\ncommits I had on my previous \"pu\" are not part of the history of\nthe updated \"pu\" anymore, but is considered to be part of your\ndevelopment trail. If these had an addition of a file, and if\nyour development on top of the previous \"pu\" modified it, the\nmerge would result in:\n\n * originally the file did not exist.\n * \"pu\" adds it one way.\n * \"my-pu\" adds it in another way.\n\nThis requires a hand merge. What should be done is for me to\ninstead of rebasing \"pu\", merge the updated master to \"pu\".\n\n o--o--o--o--o--o--o\n / \"my-pu\"\n o--o--o--------*--o\n / / \"pu\" \n\to--o--o--o--o--o--o\n \"master\"\n\nThen merge between \"my-pu\" and \"pu\" become easier. You do not\nhave to worry about the earlier three commits, because the point\nyou forked from the previous \"pu\" becomes the merge base.\n\nThe reason I have not done it that way so far is primarily I am\nlazy and also I do not like to see too many merges in the log.\nAlso \"pu\" tends to have really wacky stuff, so separating out\nonly usable bits, excluding wacky ones is slightly easier if I\nrebuild it from scratch.\n\nThe new \"next\" aka \"not too close to bleeding or broken edge\"\nbranch will be managed like the last picture above, in order to\nmake working with it easier to manage. This is only usable if I\ndo not include too bleeding-edge topic branch in it.\n"},{"id":"15784","messageId":"Pine.LNX.4.63.0602091224080.24971@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"3272","inReplyTo":"7vfymsddqo.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-02-09T11:24:59Z","receivedAt":"2006-02-09T11:24:59Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 9 Feb 2006, Junio C Hamano wrote:\n\n> Branches are cheap from the storage point of view (not really,\n> one inode and a filesystem block wasted to store only 41-bytes\n> ;-)), [...]\n\nNot really. I use reiserfs which is quite efficient on these small files.\n\nHth,\nDscho\n"},{"id":"15785","messageId":"43EB290A.6060407@op5.se","threadId":"3272","inReplyTo":"7vr76cby2v.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-02-09T11:35:38Z","receivedAt":"2006-02-09T11:35:38Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> \n> The problem is exactly why you need the plus sign when you fetch,\n> i.e. \"+pu:pu\". My \"pu\" rebases.\n> \n> Suppose I had this:\n> \n> o--o--o\n> / \"pu\"\n> \to--o\n> \"master\" \n> \n> You do fetch +pu:pu, branch my-pu, and build on top of it:\n> \n> o--o--o--o--o--o--o\n> / \"my-pu\"\n> o--o--o\n> / \"pu\"\n> \to--o\n> \"master\"\n> \n> I add some to my \"master\" and rebuild \"pu\", maybe while adding\n> another commit on \"pu\". You fetch +pu:pu again:\n> \n> o--o--o--o--o--o--o\n> / \"my-pu\"\n> o--o--o o--o--o--o\n> / / \"pu\" \n> \to--o--o--o--o--o--o\n> \"master\"\n> \n\nBut wouldn't rebase detect the commits as being the same, unless you've \nmade changes to them? If it doesn't, can we teach it to discard parent \ninfo and re-hash the commits if they conflict? That should solve most \nsuch merge-conflicts, really.\n\n\n> Now, what happens when you merge \"pu\" into \"my-pu\"? The three\n> commits I had on my previous \"pu\" are not part of the history of\n> the updated \"pu\" anymore, but is considered to be part of your\n> development trail. If these had an addition of a file, and if\n> your development on top of the previous \"pu\" modified it, the\n> merge would result in:\n> \n> * originally the file did not exist.\n> * \"pu\" adds it one way.\n> * \"my-pu\" adds it in another way.\n> \n> This requires a hand merge. What should be done is for me to\n> instead of rebasing \"pu\", merge the updated master to \"pu\".\n> \n> o--o--o--o--o--o--o\n> / \"my-pu\"\n> o--o--o--------*--o\n> / / \"pu\" \n> \to--o--o--o--o--o--o\n> \"master\"\n> \n> Then merge between \"my-pu\" and \"pu\" become easier. You do not\n> have to worry about the earlier three commits, because the point\n> you forked from the previous \"pu\" becomes the merge base.\n> \n> The reason I have not done it that way so far is primarily I am\n> lazy and also I do not like to see too many merges in the log.\n> Also \"pu\" tends to have really wacky stuff, so separating out\n> only usable bits, excluding wacky ones is slightly easier if I\n> rebuild it from scratch.\n> \n> The new \"next\" aka \"not too close to bleeding or broken edge\"\n> branch will be managed like the last picture above, in order to\n> make working with it easier to manage. This is only usable if I\n> do not include too bleeding-edge topic branch in it.\n> \n> \n\nGood thinking. You're a marvel at explaining things.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"15814","messageId":"12c511ca0602091514p35c3904bha8d5d406e5472969@mail.gmail.com","threadId":"3272","inReplyTo":"7vslqtf2p1.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git","fromName":"Tony Luck","fromEmail":"tony.luck@intel.com","sentAt":"2006-02-09T23:14:59Z","receivedAt":"2006-02-09T23:14:59Z","isPatch":false,"sender":{"key":"tony.luck@intel.com","avatar":"https://avatars.githubusercontent.com/u/5446021?v=4"},"body":"On 2/8/06, Junio C Hamano wrote:\n> * If there are patches sent to improve a topic branch in it,\n> they will be applied to the topic branch, and then the topic\n> branch is merged into \"next\", without any funny rewinding or\n> rebasing of \"next\". This will make the \"next\" branch\n> cluttered with repeated merges from the same topic branch,\n> but that is OK. \"next\" will not be merged into \"master\",\n> ever.\n>\n> * Once a topic is fully cooked, the topic branch will be merged\n> into \"master\".\n\nThis is pretty much the workflow in my test/release branches (mostly\ndocumented in Documentation/howto/using-topic-branches.txt).\n\nI've sometimes wondered about re-creating the topic branches in\nthe case where there have been a series of follow-on commits\nbefore pulling them into the release branch. The goal would be\nto present history not as it was, but as it should have been if we\ndidn't have all the dumb mistakes and typos.\n\nSo is there an easy way in git to take the series of commits\nfrom a topic branch, make a new branch with all those commits\nas just one commit ... with an open editor on the concatenated\ncommit comments (If there were just typo fixes the comment\nfrom the first commit would apply, but sometimes the follow-on\ncommits would have substantive changes).\n\n-Tony\n"},{"id":"15815","messageId":"20060209233059.GH20880@mythryan2.michonline.com","threadId":"3272","inReplyTo":"12c511ca0602091514p35c3904bha8d5d406e5472969@mail.gmail.com","subject":"Re: What's in git.git","fromName":"Ryan Anderson","fromEmail":"ryan@michonline.com","sentAt":"2006-02-09T23:30:59Z","receivedAt":"2006-02-09T23:30:59Z","isPatch":false,"sender":{"key":"ryan@michonline.com","avatar":null},"body":"On Thu, Feb 09, 2006 at 03:14:59PM -0800, Tony Luck wrote:\n> On 2/8/06, Junio C Hamano wrote:\n> > * If there are patches sent to improve a topic branch in it,\n> > they will be applied to the topic branch, and then the topic\n> > branch is merged into \"next\", without any funny rewinding or\n> > rebasing of \"next\". This will make the \"next\" branch\n> > cluttered with repeated merges from the same topic branch,\n> > but that is OK. \"next\" will not be merged into \"master\",\n> > ever.\n> >\n> > * Once a topic is fully cooked, the topic branch will be merged\n> > into \"master\".\n> \n> This is pretty much the workflow in my test/release branches (mostly\n> documented in Documentation/howto/using-topic-branches.txt).\n> \n> I've sometimes wondered about re-creating the topic branches in\n> the case where there have been a series of follow-on commits\n> before pulling them into the release branch. The goal would be\n> to present history not as it was, but as it should have been if we\n> didn't have all the dumb mistakes and typos.\n> \n> So is there an easy way in git to take the series of commits\n> from a topic branch, make a new branch with all those commits\n> as just one commit ... with an open editor on the concatenated\n> commit comments (If there were just typo fixes the comment\n> from the first commit would apply, but sometimes the follow-on\n> commits would have substantive changes).\n\ngit checkout topic\ngit format-patch --stdout origin > topic-diff\n$VISUAL topic-diff\n# Fix comments\ngit checkout master\ngit checkout -b new-topic master\ngit-am topic-diff\n\n.. done?\n\n(I typically do something akin to this before sending patches to Junio,\nby looking at the output of format-patch in a directory, editing,\ncombining a few changes if necessary, then re-committing, re-running\nformat-patch, and sending the output upstream.)\n\n-- \n\nRyan Anderson\n sometimes Pug Majere\n"},{"id":"15817","messageId":"7virro6qt4.fsf@assigned-by-dhcp.cox.net","threadId":"3272","inReplyTo":"12c511ca0602091514p35c3904bha8d5d406e5472969@mail.gmail.com","subject":"Re: What's in git.git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-09T23:44:07Z","receivedAt":"2006-02-09T23:44:07Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Tony Luck writes:\n\n> So is there an easy way in git to take the series of commits\n> from a topic branch, make a new branch with all those commits\n> as just one commit ... with an open editor on the concatenated\n> commit comments (If there were just typo fixes the comment\n> from the first commit would apply, but sometimes the follow-on\n> commits would have substantive changes).\n\nI do not have a script to do so but my guess is that would be a\n20-30 line shell script. Use cherry to find which ones to pick,\nrun diff-tree on them to extract patches, run apply --index on\neach of them in turn, and dump \"git log master..topic\" to your\neditor and you are done. The editor would have the commit log\nto be edited while working tree and the index would have a\nready-to-commit tree with all the changes applied.\n"},{"id":"15827","messageId":"7vpslw3uqg.fsf@assigned-by-dhcp.cox.net","threadId":"3272","inReplyTo":"43EB290A.6060407@op5.se","subject":"Re: What's in git.git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-10T00:47:35Z","receivedAt":"2006-02-10T00:47:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andreas Ericsson writes:\n\n> But wouldn't rebase detect the commits as being the same, unless\n> you've made changes to them? If it doesn't, can we teach it to discard\n> parent info and re-hash the commits if they conflict? That should\n> solve most such merge-conflicts, really.\n\nYes, rebase would help somewhat (I said that didn't I?). But\nthe thing is, with the \"pu\" workflow of mine so far, I _did_\nrewrite/replace commits on my topic branches, especially when\nthey are young and not in a good shape.\n\nFor example, the topic branch jc/nostat (\"Assume unchanged\" git)\nhas four commits since it forked from the mainline:\n\n + [jc/nostat] \"Assume unchanged\" git: --really-refresh fix.\n + [jc/nostat^] ls-files: debugging aid for CE_VALID changes.\n + [jc/nostat~2] \"Assume unchanged\" git: do not set CE_VALID with --refresh\n + [jc/nostat~3] \"Assume unchanged\" git\n\nWith the \"pu\" workflow, I would have merged the \"do not set\nCE_VALID\" commit and \"--really-refresh fix\" commit into the\nfirst \"Assume unchanged\" commit after I found out about these\ntwo small mistakes. So one day \"pu\" would have contained what\nis there right now as \"jc/nostat~3\", but the next day it would\nhave a commit, perhaps with slightly modified log message from\nwhat is there as \"jc/nostat~3\" to contain fixes jc/nostat~2 and\njc/nostat have right now (the ls-files one is a debugging aid so\nI would have left it separate even with the rewriting-history\nworkflow).\n\nThat kind of rewriting history is not being honest, but the end\nresult is that people do not have to see intermediate states and\nearlier mistakes when things are fully cooked and ready to be\nmerged into the mainline. By promising not to rewind \"next\" and\ntopic branches that go to \"next\", I am closing the door for me\nto do this kind of history rewrite freely. I can still rewrite\nthings I have not pushed out yet, though.\n\nBTW, it is always a judgement call if it is a good thing to\nsquash commits into one like this. Being too honest hurts the\nusability of the history. Especially if you have a trivial \"Oh,\nwhat I checked in does not even compile\" kind of mistakes left\nin the development trail, that would inconvenience bisection.\nBeing too sanitized OTOH tends to drop a single big ball of wax\ninto the history, and makes correcting things harder if it is\nfound later that only parts of that change are desired and the\nother parts are not.\n"},{"id":"15891","messageId":"7vpslvw92d.fsf@assigned-by-dhcp.cox.net","threadId":"3272","inReplyTo":"12c511ca0602091514p35c3904bha8d5d406e5472969@mail.gmail.com","subject":"Re: What's in git.git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-10T15:02:50Z","receivedAt":"2006-02-10T15:02:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Tony Luck writes:\n\n> On 2/8/06, Junio C Hamano wrote:\n> [ ... about the \"next\" branch ... ]\n>\n> This is pretty much the workflow in my test/release branches (mostly\n> documented in Documentation/howto/using-topic-branches.txt).\n\nYup. Sorry I did not make that clear. You deserve the credit.\n\nI am beginning to feel this workflow might benefit from some\ntool support, but I haven't had enough experience to talk about\nexactly what they are yet.\n\nFor example, listing topics that have ever been merged into a\nparticular branch, listing topics that have not been fully\nmerged into a particular branch, etc. are things I find myself\ndoing frequently. I vaguely recall seeing your post that has\nthese things.\n"}]}