On Mon, Mar 16, 2009 at 6:33 PM, John Dlugosz <JDlugosz@xxxxxxxxxxxxxxxx> wrote:
> I think the difference is because you mail in your changes to master,
> and I'm having developers cooperate in advancing that branch. The only
> thing I need a local copy of dev for is to checkout during the "work
> completed" phase, in which case the topic's result is added to the top
> of dev for all to see, either as a single amalgamated checkin or a
> non-ff merge.
Why is the topic a non-ff merge? Here's a normal non-email workflow:
$ git clone git://central/repo.git
$ cd repo
$ edit, commit, edit, commit, looks good
$ git fetch origin
$ git log -p master..origin/master # (1)
$ git merge origin/master
$ compile, test, etc
$ git push origin master # (2)
(1) inspect changes in origin/master, make sure you want to merge
(2) this fast-forwards git://central/repo.git/refs/heads/master from
local master
Or, if you prefer topic branches:
$ git clone git://central/repo.git
$ cd repo
$ git checkout -b topic origin/master
$ edit, commit, edit, commit, looks good
$ git checkout master
$ git pull # (1)
$ git merge topic
$ compile, test, etc
$ git push origin master (2)
$ git branch -d topic
(1) this fast-forwards local master since local development is
on topic.
(2) as above, this fast-forwards
git://central/repo.git/refs/heads/master from local master
So this way git://central/repo.git/refs/heads/master is never reset.
But, if you do have a valid reason for resetting, then what I said in
my previous message still applies.
j.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
