nomad workflow -- dont pull ... more like... snatch ...or.. tear!

nomad workflow -- dont pull ... more like... snatch ...or.. tear!

[Florian Mickler]

[-- Attachment #1: Type: text/plain, Size: 2939 bytes --]

Hi!

I'm working on many different work stations during the week and have
one central repo, where i interface with an svn upstream. 

because of (but not only because of) git svn's metadata-changes i have
the following workflow, which is currently not well supported with git.

<summary>  (for the busy reader)
    i want to be able to drop my local tracking branches in favor of
    the remote ones, but keep backup-refs and have the opportunity to
    abort if something looks funny.
   
i have a script which does this, which i could submit for starters...

</summary>

my workflow:

i have a remote git repository following an svn upstream. (via git svn) 

there are 2 svn branches i do work on and some topic-branches in
which i prepare features to integrate into the svn branches. 

When i come to work (to any random workstation), i do basically the
following:

firsy i run git-svn-rebase on my central git repo.

then i run my script, which does:

a) run git-fetch origin in my workstations git-repo.

b) for all the branches i currently work on: (eg
origin/svnStableBranch) 

	1. git cherry origin/svnStableBranch svnStableBranch

	2. if everything is contained it skips the next 2 steps

	3. else it shows the not contained commits and waits for
	userinput (strg-c, f for full commit descriptions, or anykey to
	continue) 

	4. it creates backup branch (named tmp_[unixtimestamp])  

	5. it drops local branch and creates a new tracking branch with
	the same name

at the end of my workday, i run svn rebase on origin and run my script
again.

if smth got committed before i could push my changes to the svn, i
decide if i create a new branch on origin for my work, so i can
integrate it next time, or just merge / rebase my commits now.
(recovering them from the backup-branch)

whatever i do i somehow sync my repo onto origin and dcommit
there ...maybe...

the next day i go to any workstation (probably with a working state
from a week ago), run my script to drop the local refs, and continue
working. 

if i have rebased one of my working branches during the week,
i see the refactored log vs the old log and can happily drop the backup
branches. if i see some piece of work which i forgot to push to origin,
and which is worth saving i can do it now.

if not ... good.

Do you see my point? Is smth like this deemed useful? is this
an acceptable workflow? (dropping local refs in favor of remote ones) 

it saves me the hazle of doublecheking the state of my
current workstation every time i change it and if i forgot to push
something a week ago or yesterday, nothing is lost.

is there any possibility that if i submitted a cleaned up version for
this called ''git snatch'' or something like this, it would be
integrated into mainline?

(because of its disruptive nature, maybe git tear would be a better
name?)


Sincerely,
Florian

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]