[gits] Git Workflow

[eeide at cs.utah.edu (Eric Eide)]

	Kirk> So Dan came by asking how best to get some of the work in his
	Kirk> personal emulab-devel repo into the mainline emulab-devel repo.
	Kirk> He's been working via the 'master' branch in his personal repo,
	Kirk> so I recommended the following steps:
	Kirk> 
	Kirk> git checkout master
	Kirk> git fetch central  # central is the 'remote' name in his repo for the
	Kirk> mainline emulab-devel repo.
	Kirk> git rebase central/master
	Kirk> <If necessary, fix any merge conflicts and resume rebase.>
	Kirk> git diff central/master
	Kirk> <Look carefully to make sure only the changes he intends are going in.>
	Kirk> git push -f origin master
	Kirk> git push central master

This seems reasonable.

	Kirk> However, there is a fly in the ointment - he doesn't want to push
	Kirk> all of the stuff in his personal repo to emulab central just yet.
	Kirk> So, I suggested:
	Kirk> 
	Kirk> git checkout master
	Kirk> git checkout -b <some_new_branch_name>

You can replace that with "git branch newname", so that you don't have to
immediately checkout master again...

	Kirk> git checkout master
	Kirk> git rm <files_to_leave_out_of_emulab_central_commit>
	Kirk> git fetch central
	Kirk> git rebase central/master
	Kirk> <If necessary, fix any merge conflicts and resume rebase.>
	Kirk> git diff central/master
	Kirk> <Look carefully to make sure only the changes he intends are going in.>
	Kirk> git push -f origin master
	Kirk> git push central master

This sort-of-does what is wanted, but not really.  If I follow your script,
this is the "push a file and also push its removal" technique.  This is not
really the same as not pushing the file at all.

(BTW, note that you have to commit the results of "git rm".)

To give better advice, I think that more details are required.  That's because
there are lots of ways in which one might resolve the problem.

If there are files that need to be wiped out from history, you need more
serious medicine, something like "git filter-branch".  This is tricky.  It is
made more tricky by the fact that you'd (presumably) want to keep the histories
of those not-yet-ready files on a separate branch so you need two runs of
filter-branch.

Depending on how the changes are staged into commits, one might also be able to
sort things out by cherry-picking non-ready-to-push commits onto a separate
branch.

Another alternative: squash the changes into a single commit, then remove the
files that aren't ready to be pushed (saving them elsewhere), then "git commit
--amend".

Ultimately, I think that more details are needed to improve the advice.

	Kirk> I also suggested he look at the view of his repo with 'gitk' to
	Kirk> spot any squirrelly-looking stuff before pushing to
	Kirk> central/master.

Yes; I do this regularly before pushing big stuff.

Eric.

-- 
-------------------------------------------------------------------------------
Eric Eide <eeide at cs.utah.edu>  .         University of Utah School of Computing
http://www.cs.utah.edu/~eeide/ . +1 (801) 585-5512 voice, +1 (801) 581-5843 FAX