{"thread":{"id":"3165","subject":"Two newbie question: \"dead\" branches and merging after cherry-pick.","startedAt":"2006-01-27T17:36:19Z","lastAt":"2006-01-27T20:59:46Z","messageCount":3,"participants":["Romano Giannetti","Alex Riesen","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"15167","messageId":"20060127173619.GA26199@pern.dea.icai.upcomillas.es","threadId":"3165","inReplyTo":null,"subject":"Two newbie question: \"dead\" branches and merging after cherry-pick.","fromName":"Romano Giannetti","fromEmail":"romano@dea.icai.upcomillas.es","sentAt":"2006-01-27T17:36:19Z","receivedAt":"2006-01-27T17:36:19Z","isPatch":false,"sender":{"key":"romano@dea.icai.upcomillas.es","avatar":null},"body":"\nHi,\n\n   this is a \"really-newbie-question\"...  git is the first SCM that I try to\n   use, and I am really fascinated with it. I develop my software on three\n   different PC and git solves all my problems of keeping uptodate with\n   myself in a really nice way. \n\n   I have a couple of doubts that probably are at the very silly level but... \n   Here I go: \n\n        - I use to work on a topic branch to make test, try solutions for\n        bugs, etc. Say I am done with the branch \"test-bill-idea\". I decide\n        it's a dead branch, so that I do not want to see it in day-by-day\n        work (git branch, basically), but I do not want to loose it. If I\n        delete the branch I will loose all its commit at the next prune,\n        correct? There is a way to maintain it as a dead or hidden branch,\n        shown for example just by gitk --all? If I tag the tip of the\n        branch, and then delete .git/refs/head/test-bill-idea, will the\n        \"dead branch commits\" be preserved by next prune(s)? \n\n        - Easier: suppose I cheery-picked \"abababab\" from branch \"testing\"\n        to master branch. What will happen if later I decide to merge\n        all \"testing\" to master branch? I will have a merge conflict (trying\n        to apply two times the same fix) or not? \n\n   Thank you very much for your time! Have a nice week end,\n\n         Romano   \n\n   \n-- \nRomano Giannetti             -  Univ. Pontificia Comillas (Madrid, Spain)\nElectronic Engineer - phone +34 915 422 800 ext 2416  fax +34 915 596 569\nhttp://www.dea.icai.upcomillas.es/romano/\n"},{"id":"15170","messageId":"20060127194730.GB6169@steel.home","threadId":"3165","inReplyTo":"20060127173619.GA26199@pern.dea.icai.upcomillas.es","subject":"Re: Two newbie question: \"dead\" branches and merging after cherry-pick.","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2006-01-27T19:47:30Z","receivedAt":"2006-01-27T19:47:30Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Romano Giannetti, Fri, Jan 27, 2006 18:36:19 +0100:\n> - I use to work on a topic branch to make test, try solutions for\n> bugs, etc. Say I am done with the branch \"test-bill-idea\". I decide\n> it's a dead branch, so that I do not want to see it in day-by-day\n> work (git branch, basically), but I do not want to loose it. If I\n> delete the branch I will loose all its commit at the next prune,\n> correct? There is a way to maintain it as a dead or hidden branch,\n> shown for example just by gitk --all? If I tag the tip of the\n> branch, and then delete .git/refs/head/test-bill-idea, will the\n> \"dead branch commits\" be preserved by next prune(s)? \n\nYes, it will.\n\nYou can actually move the reference file anywhere under .git/refs/,\nand \"git prune\" will never touch it and gitk will show it different\ncolor (looks grey to me). The tags are shown yellow, which can be\nassociated with \"dead for some time\" already.\n\n> - Easier: suppose I cheery-picked \"abababab\" from branch \"testing\"\n> to master branch. What will happen if later I decide to merge\n> all \"testing\" to master branch? I will have a merge conflict (trying\n> to apply two times the same fix) or not? \n\nYes, you probably will have to deal with a conflict (it can match the\nbranch to be merged exactly, which is hardly a conflict).\n"},{"id":"15171","messageId":"7vlkx11j5p.fsf@assigned-by-dhcp.cox.net","threadId":"3165","inReplyTo":"20060127173619.GA26199@pern.dea.icai.upcomillas.es","subject":"Re: Two newbie question: \"dead\" branches and merging after cherry-pick.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-01-27T20:59:46Z","receivedAt":"2006-01-27T20:59:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Romano Giannetti <romano@dea.icai.upcomillas.es> writes:\n\n>         - I use to work on a topic branch to make test, try solutions for\n>         bugs, etc. Say I am done with the branch \"test-bill-idea\". I decide\n>         it's a dead branch, so that I do not want to see it in day-by-day\n>         work (git branch, basically), but I do not want to loose it. ...\n\nFirst let me make sure if I understand you correctly.\n\nYou are done with what you did in the branch for now, but you\nhave not merged the work to your day-to-day development \"master\"\nfor some reason.  In the meantime you would want to switch to\nother topic branches to work on other topics, and while working\non them you do not want to \"git branch\" and \"git show-branch\" to\nshow the topic you are done with but not merged yet.  Later you\nwould want to come back to it to do some interesting stuff with\nit (maybe finally merge into \"master\", or format-patch to send\nupstream).  Is that what is happening here?\n\nIf so, I would have chosen \"postponed\" not \"dead\" to describe\nthe situation but you said \"dead\" and that is why I am wondering\nif I am getting you correctly.\n\n>         ... If I\n>         delete the branch I will loose all its commit at the next prune,\n>         correct? ...\n\nYes.  If you do not have anything under .git/refs pointing at\nthe tip of a development trail, that trail will be lost by the\nnext prune.  Even if you do not prune, it would be cumbersome to\nfind it.  \"git lost-found\" would find it for you but it still is\ncumbersome.\n\n>         ... There is a way to maintain it as a dead or hidden branch,\n>         shown for example just by gitk --all? If I tag the tip of the\n>         branch, and then delete .git/refs/head/test-bill-idea, will the\n>         \"dead branch commits\" be preserved by next prune(s)? \n\nYes.  You have the tag under .git/refs which points at the tip\nof that postponed branch head, so the development trail will not\nbe lost.  When you are done with other topics and would want to\ncome back to that topic again, you could do this:\n\n\t$ git checkout -b test-bill-idea tag-bill-idea-postponed\n\nUntil recently I used to have \"jc/link\" topic branch to play\nwith \"gitlink\"-style subproject support suggested by Linus.  It\nis not finished yet, and in the meantime I have suggested\nanother way to do subproject support, which I've been spending\nmore time on, in \"jc/bind\" topic branch.  I have not abandoned\n\"jc/link\" topic completely, so I am not ready to do throw away\nthat branch with \"git branch -D jc/link\" yet, but at the same\ntime it clutters output from \"git branch\".  So I did exactly\nwhat you outlined [*1*]:\n\n\t$ git tag hold/jc/gitlink jc/link ;# copy it to tags/\n        $ git branch -D jc/link\t\t  ;# delete it from heads/\n\nNow \"git branch\" would not show it, but \"gitk --all\" still would.\n\n>         - Easier: suppose I cheery-picked \"abababab\" from branch \"testing\"\n>         to master branch. What will happen if later I decide to merge\n>         all \"testing\" to master branch? I will have a merge conflict (trying\n>         to apply two times the same fix) or not? \n\nThis is easy to experiment so I'd suggest you to try it and tell\nus what you see, like this:\n\n\t$ git checkout -b test-merge-throwaway master\n        $ git cherry-pick abababab\n        $ ... play with it, maybe making a couple of commits\n        $ git pull . testing\n\nI would not be surprised if this resolves cleanly. If abababab\nis the only thing that touches the set of paths it touches,\nother than what are in \"testing\" and what you did since\n\"testing\" forked from \"master\", it is likely that the merge\nwould resolve cleanly.\n\nOtherwise you would likely to see conflicts --- in which case\nyou may want to suggest if/how we can reduce it.  \"cherry-pick\"\nwithout -r drops a hint of which commit was picked in the commit\nlog so it _might_ be a good idea to teach git to optionally take\nthat information into account while doing the merge.  I dunno.\n\nOnce you are done experimenting, you can come back to master and\ndelete the test-merge-throwaway branch:\n\n\t$ git checkout master\n        $ git branch -D test-merge-throwaway\n\n\n[Footnote]\n\n*1* As my personal convention, each of my topic branches is\nnamed with two-letter name, '/', and a short topic word, and\npostponed tags have names starting with \"hold/\".  Sticking to a\nconvention makes it easy for me to do things like this:\n\n\t$ git show-branch --topo-order master \"heads/??/*\"\n"}]}