{"thread":{"id":"18652","subject":"nomad workflow -- dont pull ... more like... snatch ...or.. tear!","startedAt":"2009-03-31T00:59:44Z","lastAt":"2009-03-31T00:59:44Z","messageCount":1,"participants":["Florian Mickler"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"109954","messageId":"20090331025944.51be8509@schatten","threadId":"18652","inReplyTo":null,"subject":"nomad workflow -- dont pull ... more like... snatch ...or.. tear!","fromName":"Florian Mickler","fromEmail":"florian@mickler.org","sentAt":"2009-03-31T00:59:44Z","receivedAt":"2009-03-31T00:59:44Z","isPatch":false,"sender":{"key":"florian@mickler.org","avatar":null},"body":"Hi!\n\nI'm working on many different work stations during the week and have\none central repo, where i interface with an svn upstream. \n\nbecause of (but not only because of) git svn's metadata-changes i have\nthe following workflow, which is currently not well supported with git.\n\n<summary>  (for the busy reader)\n    i want to be able to drop my local tracking branches in favor of\n    the remote ones, but keep backup-refs and have the opportunity to\n    abort if something looks funny.\n   \ni have a script which does this, which i could submit for starters...\n\n</summary>\n\nmy workflow:\n\ni have a remote git repository following an svn upstream. (via git svn) \n\nthere are 2 svn branches i do work on and some topic-branches in\nwhich i prepare features to integrate into the svn branches. \n\nWhen i come to work (to any random workstation), i do basically the\nfollowing:\n\nfirsy i run git-svn-rebase on my central git repo.\n\nthen i run my script, which does:\n\na) run git-fetch origin in my workstations git-repo.\n\nb) for all the branches i currently work on: (eg\norigin/svnStableBranch) \n\n\t1. git cherry origin/svnStableBranch svnStableBranch\n\n\t2. if everything is contained it skips the next 2 steps\n\n\t3. else it shows the not contained commits and waits for\n\tuserinput (strg-c, f for full commit descriptions, or anykey to\n\tcontinue) \n\n\t4. it creates backup branch (named tmp_[unixtimestamp])  \n\n\t5. it drops local branch and creates a new tracking branch with\n\tthe same name\n\nat the end of my workday, i run svn rebase on origin and run my script\nagain.\n\nif smth got committed before i could push my changes to the svn, i\ndecide if i create a new branch on origin for my work, so i can\nintegrate it next time, or just merge / rebase my commits now.\n(recovering them from the backup-branch)\n\nwhatever i do i somehow sync my repo onto origin and dcommit\nthere ...maybe...\n\nthe next day i go to any workstation (probably with a working state\nfrom a week ago), run my script to drop the local refs, and continue\nworking. \n\nif i have rebased one of my working branches during the week,\ni see the refactored log vs the old log and can happily drop the backup\nbranches. if i see some piece of work which i forgot to push to origin,\nand which is worth saving i can do it now.\n\nif not ... good.\n\nDo you see my point? Is smth like this deemed useful? is this\nan acceptable workflow? (dropping local refs in favor of remote ones) \n\nit saves me the hazle of doublecheking the state of my\ncurrent workstation every time i change it and if i forgot to push\nsomething a week ago or yesterday, nothing is lost.\n\nis there any possibility that if i submitted a cleaned up version for\nthis called ''git snatch'' or something like this, it would be\nintegrated into mainline?\n\n(because of its disruptive nature, maybe git tear would be a better\nname?)\n\n\nSincerely,\nFlorian\n"}]}