Re: fetch and pull

From: Jay Soffian <jaysoffian@gmail.com>
Date: Mar 17, 2009, 00:09 UTC
Message-ID: <76718490903161709v6d8d09f6k17d2fe1a5e56fb03@mail.gmail.com>
In-Reply-To: <450196A1AAAE4B42A00A8B27A59278E70A2AF0A9@EXCHANGE.trad.tradestation.com>

On Mon, Mar 16, 2009 at 6:33 PM, John Dlugosz <JDlugosz@tradestation.com> wrote:

Show 6 quoted lines

> 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.