Re: fetch and pull

Re: fetch and pull

[John Dlugosz]

=== Re: ===
> So, after inspecting the changes, how do you fast-forward your local
dev
> to sync up with origin/dev?

$ git push . origin/dev dev
=== end ===

That did not work.  It just reports "everything up to date".  If I
understand the point of what it does correctly, I think

	$ git push . +origin/dev:dev

is correct.



TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.
  If you received this in error, please contact the sender and delete the material from any computer.

Re: fetch and pull

[Jay Soffian]

On Mon, Mar 16, 2009 at 3:00 PM, John Dlugosz <JDlugosz@tradestation.com> wrote:
> === Re: ===
>> So, after inspecting the changes, how do you fast-forward your local
> dev
>> to sync up with origin/dev?
>
> $ git push . origin/dev dev
> === end ===
>
> That did not work.  It just reports "everything up to date".  If I
> understand the point of what it does correctly, I think
>
>        $ git push . +origin/dev:dev
>
> is correct.

You very likely do not want the '+' at the start:

$ git push . origin/dev:dev

j.

RE: fetch and pull

[John Dlugosz]

=== Re: ===
You very likely do not want the '+' at the start:

$ git push . origin/dev:dev

j.

=== end ===

Yes, I do.  If the central repository changed dev in some way other than a fast-forward, or if you really messed up your local dev, it still needs to be repointed.

Remember the overall flow:  first fetch (not pull) and then inspect the difference between your dev and origin/dev.  Then, change your dev to match.

--John

TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.

Re: fetch and pull

[Sverre Rabbelier]

Heya,

On Mon, Mar 16, 2009 at 21:39, John Dlugosz <JDlugosz@tradestation.com> wrote:
> PT09IFJlOiA9PT0NCllvdSB2ZXJ5IGxpa2VseSBkbyBub3Qgd2FudCB0aGUg

Forgot to turn off encryption?

-- 
Cheers,

Sverre Rabbelier

Re: fetch and pull

[Jay Soffian]

On Mon, Mar 16, 2009 at 4:39 PM, John Dlugosz <JDlugosz@tradestation.com> wrote:
> Yes, I do.  If the central repository changed dev in some way other than a fast-forward, or if you really messed up your local dev, it still needs to be repointed.
>
> Remember the overall flow:  first fetch (not pull) and then inspect the difference between your dev and origin/dev.  Then, change your dev to match.

Let me illustrate why this is still probably wrong. I have a clone of
git://git.kernel.org/pub/scm/git/git.git. It has the following remote
tracking branches:

$ git branch -r
  origin/html
  origin/maint
  origin/man
  origin/master
  origin/next
  origin/pu
  origin/todo

origin/master is never reset. origin/pu resets often. When I want to
work on git, I typically create a branch from origin/master. In this
case, I would almost never want to reset that branch. So I'd typically
do:

$ git checkout -b topic origin/master
$ edit, commit, edit, commit...
$ git fetch
$ git log origin/master..topic
$ git rebase origin/master

Rarely, I'll base a topic on origin/pu. And origin/pu might get reset.
But even if it were, I wouldn't want to blindly reset my local branch
to match, thus losing my local changes. Instead I'd do this:

$ git checkout -b pu-topic origin/pu
$ git tag pu-topic-base # handy when origin/pu is reset
$ edit, commit, edit, commit
$ git fetch
drat, origin/pu was reset
$ git rebase --onto origin/pu pu-topic-base

And in the rare circumstance that I really do want to reset a local
branch, I'd do this:

$ git checkout dev
examine, make sure I really want to reset
$ git reset --hard origin/dev

I can't really think of a good reason I'd want to reset a local branch
which I haven't checked out.

j.

RE: fetch and pull

[John Dlugosz]

> I can't really think of a good reason I'd want to reset a local branch
> which I haven't checked out.
> 
> j.

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.

Can you suggest a better way of doing that, where "better" means minimizing the number of cookbook incantations to learn?

If, during that procedure, the instruction to
	git checkout dev
were replaced by one that checks out the remote and creates the local at that time (what is the argument?), then after pushing the result, delete the local dev.  

Keeping the local dev around has the advantage of being able to see what changes have taken place without having to be implicit by eyeballing where your topics branch off from, and makes it clear what you've read/understood already even if you are not going to rebase your topic.

--John

TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.

Re: fetch and pull

[Jay Soffian]

On Mon, Mar 16, 2009 at 6:33 PM, John Dlugosz <JDlugosz@tradestation.com> 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.

Re: fetch and pull

[Jeff King]

On Mon, Mar 16, 2009 at 09:43:47PM +0100, Sverre Rabbelier wrote:

> On Mon, Mar 16, 2009 at 21:39, John Dlugosz <JDlugosz@tradestation.com> wrote:
> > PT09IFJlOiA9PT0NCllvdSB2ZXJ5IGxpa2VseSBkbyBub3Qgd2FudCB0aGUg
> 
> Forgot to turn off encryption?

Erny zra rapelcg va gurve urnqf.

-Peff

Re: fetch and pull

[Sverre Rabbelier]

Heya,

On Tue, Mar 17, 2009 at 09:34, Jeff King <peff@peff.net> wrote:
> On Mon, Mar 16, 2009 at 09:43:47PM +0100, Sverre Rabbelier wrote:
> Erny zra rapelcg va gurve urnqf.

I always encrypt my messages with two-round ROT-13.

-- 
Cheers,

Sverre Rabbelier

RE: fetch and pull

[John Dlugosz]

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

You checkout master before updating it?

> $ git merge topic
> $ compile, test, etc
> $ git push origin master (2)
> $ git branch -d topic

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


The developers may not non-ff the dev when they push it.  But the repository maintainer may reset dev for some reason, and since topic branches are pushed, he can see that it either doesn't bother anyone that way or knows who to help out.  But, it means that in general the pull _could_ be arbitrary and not a ff from his last pull.

For example, developer A checks in a finished topic, then B checks in a finished topic.  But A doesn't use a spell checker even though he *really* should, and doesn't proof read even though he **really** should let a native English speaker look at it first.  So the repository maintainer rewrites the tip of the dev branch.  Next morning, everyone pulls, and both A and B are non-ff even though they have not branched anything from the old A or B.

> Rarely, I'll base a topic on origin/pu. And origin/pu might get reset.
> But even if it were, I wouldn't want to blindly reset my local branch
> to match, thus losing my local changes. Instead I'd do this:

The local changes are all on a topic.  Daily routine is to fetch and probably rebase topics each morning.   Nobody checks out dev except to post a completed topic.

--John

TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.

Re: fetch and pull

[Jay Soffian]

On Tue, Mar 17, 2009 at 10:58 AM, John Dlugosz
<JDlugosz@tradestation.com> wrote:
>> $ 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
>
> You checkout master before updating it?

You cannot merge/rebase a branch unless it is checked out.

> The developers may not non-ff the dev when they push it.  But the repository maintainer may reset dev for some reason, and since topic branches are pushed, he can see that it either doesn't bother anyone that way or knows who to help out.  But, it means that in general the pull _could_ be arbitrary and not a ff from his last pull.
>
> For example, developer A checks in a finished topic, then B checks in a finished topic.  But A doesn't use a spell checker even though he *really* should, and doesn't proof read even though he **really** should let a native English speaker look at it first.  So the repository maintainer rewrites the tip of the dev branch.  Next morning, everyone pulls, and both A and B are non-ff even though they have not branched anything from the old A or B.

We seem to not be understanding each other, and I apologize, but I
cannot invest any more time in this thread. Perhaps others better
understand what you are trying to do and can jump in.

j.

RE: fetch and pull

[John Dlugosz]

> On Tue, Mar 17, 2009 at 10:58 AM, John Dlugosz
> <JDlugosz@tradestation.com> wrote:
> >> $ 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
> >
> > You checkout master before updating it?
> 
> You cannot merge/rebase a branch unless it is checked out.
> 

Sure you can.
	git rebase upstream topic

But I think I see the point:  the implicit merge done by pull uses the current HEAD and config branch.<name>.merge.

My concern is that you establish your working state based on the local 'master', only to immediately change it again when the pull updates master.  But that's the way it's supposed to work?

I think the documentation for git-pull might also be garbled from text being of different eras.  "Normally the branch merged is the HEAD of the remote"?  That will be basically random since the last thing the upstream repo user did will control what his HEAD is.

But, the intention here is
  1) direct attention to the desired branch
  2) do what is appropriate for the current branch

The key to avoiding massive confusion is making sure that (2) is set up properly.  I never know what's going to happen with a pull, and I suppose that's because nothing was set up properly.

--John (still confused)



TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.

Re: fetch and pull

[Nanako Shiraishi]

Quoting John Dlugosz <JDlugosz@TradeStation.com>:

> My concern is that you establish your working state based on the local 'master', only to immediately change it again when the pull updates master.  But that's the way it's supposed to work?
>
> I think the documentation for git-pull might also be garbled from text being of different eras.  "Normally the branch merged is the HEAD of the remote"?  That will be basically random since the last thing the upstream repo user did will control what his HEAD is.

That's how it's supposed to work, and the documentation isn't from a different era, either. Majority of users clone from a central repository and keep pulling to update their clones, and in that kind of setting, HEAD will never change. A HEAD in a bare repository tells people which branch is the primary branch of the project.

I think you are confused because you are thinking that it's typical to pull from a live repository that has a working tree somebody else uses to grow his history, and you are correct that you can't predict which branch HEAD points at at any given moment. But that isn't how a typical workflow uses pull and push between repositories.

-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/

Re: fetch and pull

[Jeff King]

On Tue, Mar 17, 2009 at 12:44:31PM -0400, John Dlugosz wrote:

> > > You checkout master before updating it?
> > 
> > You cannot merge/rebase a branch unless it is checked out.
> > 
> Sure you can.
> 	git rebase upstream topic

This literally does a "checkout" behind the scenes, so it is still
manipulating your working tree. It is basically the equivalent of:

  git checkout topic && git rebase upstream

The actual rebasing happens on a detached HEAD, but you will find at the
end of such a rebase that you are now on the branch "topic".

-Peff

Re: fetch and pull

[Björn Steinbrink]

On 2009.03.18 06:31:03 +0900, Nanako Shiraishi wrote:
> Quoting John Dlugosz <JDlugosz@TradeStation.com>:
> > I think the documentation for git-pull might also be garbled from
> > text being of different eras.  "Normally the branch merged is the
> > HEAD of the remote"?  That will be basically random since the last
> > thing the upstream repo user did will control what his HEAD is.
> 
> That's how it's supposed to work, and the documentation isn't from a
> different era, either. Majority of users clone from a central
> repository and keep pulling to update their clones, and in that kind
> of setting, HEAD will never change. A HEAD in a bare repository tells
> people which branch is the primary branch of the project.

But _if_ HEAD changes in the remote repo, that has normally no effect on
the behaviour of pull. Especially since the examples in the man page are
"git pull" and "git pull origin".

AFAICT the remote's HEAD affects the pull behaviour when:

1) You do "git pull git://host/repo.git" or similar, i.e. you don't use
a remote. Because then, no refspec is given to fetch, and it defaults to
fetching HEAD.

2) You do "git pull origin" and there's no remote.origin.fetch set, same
as above then.

3) You do "git pull" and either is branch.<name>.remote set to an url
(same as 1) then) or to a remote that has no default fetch refspec set
(same as 2) then).


1) probably isn't that common for most users, and even if, it's not
one of the commands given as examples to which the paragraph applies.

2) I don't think that's a common setup, and it's not a default setup, so
that hardly qualifies for "normally".

3) I've actually seen cases of the first form of this setup (remote set
to an url), but usually that was paired with a confused user.


So while it's true that the remote's HEAD might be what you merge, it's
not quite what happens "normally". Of course it's true that the most
common setup is probably that HEAD references master and that
branch.<name>.merge is also set to refs/heads/master, but while the
outcome is basically the same, I'd rather say that that is a coincidence
rather than what the text means to the reader.


I'm unsure about how to improve that section though. Basically, the last
paragraph ("When no refspec was given ...") above the EXAMPLES section
needs to be repeated, but that feels wrong. Anyone got a better idea?

Well, at least I finally realised that pull _might_ default to the
remote's HEAD, and for that part, I'll send a patch.

Björn

Re: fetch and pull

[Junio C Hamano]

Björn Steinbrink <B.Steinbrink@gmx.de> writes:

> 1) You do "git pull git://host/repo.git" or similar, i.e. you don't use
> a remote. Because then, no refspec is given to fetch, and it defaults to
> fetching HEAD.
> ...
> 1) probably isn't that common for most users, and even if, it's not
> one of the commands given as examples to which the paragraph applies.

I think "a maintainer responds to a pull request" is the only case that
happens often in practice for a fetch+merge of HEAD from a remote
repository.

Even in that case, we strongly encourage people to say not just "which
repository location" but also "which branch", i.e.

	Linus, please pull from:

		git://git.or.cz/alt-git.git for-linus

	to obtain the following commits.

When Linus cuts and pastes that to his shell, the command will become:

	$ git pull git://git.or.cz/alt-git.git for-linus

and HEAD is not involved in such a use case.

RE: fetch and pull

[John Dlugosz]

> 2) I don't think that's a common setup, and it's not a default setup,
> so
> that hardly qualifies for "normally".

How many users of git on a team have it set up by someone who already knows what he's doing?  I think bad or broken setups might be more common.  For example, I didn't have any "fetch" setting under remote until I started reading this list and digging in more.  And the upstream repository is not bare.  




TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.
  If you received this in error, please contact the sender and delete the material from any computer.

Re: fetch and pull

[Björn Steinbrink]

On 2009.03.18 11:18:41 -0400, John Dlugosz wrote:
> > 2) I don't think that's a common setup, and it's not a default
> > setup, so that hardly qualifies for "normally".
> 
> How many users of git on a team have it set up by someone who already
> knows what he's doing? I think bad or broken setups might be more
> common. For example, I didn't have any "fetch" setting under remote
> until I started reading this list and digging in more.

Hm? Both clone and "remote add" setup the fetch line by default. So you
manually adjusted the config to add the remote as just an url alias? I'm
not convinced that such manual config changes are "normal" either. At
least you're most likely the first user from which I've heard that he
did that.

Björn

RE: fetch and pull

[John Dlugosz]

> Hm? Both clone and "remote add" setup the fetch line by default. So you
> manually adjusted the config to add the remote as just an url alias?
> I'm
> not convinced that such manual config changes are "normal" either. At
> least you're most likely the first user from which I've heard that he
> did that.

No, he manually added
	[remote "pub"]
	url = //...

only.

I'm sure he wouldn't know "clone" if it bit him.  I assume the entire repository and working tree was simply copied from his machine.

This is the same guy who insists on rebasing the dev branch.  As soon as I learned to use "git log" I tried to convince him that he should merge, not rebase, but he won't listen.  So I got control and did the merge (not rebase) and am trying to device a work-flow and matching cook book for the team.

Nobody thought to post to this mailing list either.  So you have a selection bias in your sample.  I speculate that there is a larger population of people who use git poorly, and that includes not participating in the community to learn better.

Just like you can write Fortran in any language, git happily lets you treat it like SourceSafe, with a dash of "just enough knowledge to be dangerous" use of other features.

--John
(sorry about the footer)

TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.
  If you received this in error, please contact the sender and delete the material from any computer.

RE: fetch and pull

[John Dlugosz]

Thanks for your thoughts.  I'm still trying to figure out not just the
basic meaning of the tools but what can be done with them.

=== Re: ===
With git that is not ancient (i.e. v1.5.0 or newer), there is no reason
to
have local "dev" that purely track the remote anymore.  If you only want
to go-look-and-see, you can check out the remote tracking branch
directly
on a detached HEAD with "git checkout origin/dev".
=== end ===

Yes, I figured out that since gitk shows the remote, there is no reason
to have local copies of any master (upstream) refs that I don't plan on
modifying.  After setting it to track remotes, I deleted all my unneeded
copies.

=== Re: ===
Which means that the only cases we need to make it convenient for users
are to handle these local branches that "track" remote ones when you do
have local changes, or when you plan to have some.
=== end ===

I also realized recently that, with the use of topic branches, the user
doesn't need to see the "old" (local copy of) dev to understand what
changed since he last looked.  The visible branch point with the topic
will serve as that marker.

The only time the local dev is used is when the developer is going to
add a commit for the completed topic.  But, dealing with it (only) then
would be more steps when doing that.  And the local dev would still be
visible and out-dated from day-to-day, and when keeping the topic
up-to-date with dev changes he would need to use origin/dev not just dev
in his commands to rebase or merge.

=== Re: ===
I'd actually say we should give users a convenient way to remove the
local
branches that are marked to track remote tracking branches but do not
have
anything interesting on their own (iow when they can fast-forward to
their
corresponding remote tracking branches), if the true motive behind this
thread is "'git push' will notice 'dev' that is left behind and gives
clutter".
=== end ===

I found that using the GUI was easy enough, when "converting" my local
to track remote branches.  If you mean make a way to have a local
version of a tracking branch transiently, that is, only when it is
interesting, then I think I like that idea.

=== Re: ===
So how about "git branch --prune --remote=<upstream>" that iterates over
local branches, and if

 (1) it is not the current branch; and
 (2) it is marked to track some branch taken from the <upstream>; and
 (3) it does not have any commits on its own;

then remove that branch?  "git remote --prune-local-forks <upstream>" is
also fine; I do not care about which command implements the feature that
much.
=== end ===

Since fetch is the command that does the tracking of remotes, how about
having an option to fetch that does this before proceeding with the
fetch?  That is what people really want if they think they want locals
to auto-track the remotes.

=== Re: ===
But in that case, you shouldn't mark "dev" as tracking the remote's
"dev"
to begin with, so the hypothetical "branch --prune --remote=<upstream>"
would not touch such a "fork to address old issues", and we'd be safe.
=== end ===

Does git now "associate" local branch names with the remotes, other than
by simply having the same name?

--John
(please excuse the footer; it's not my choice)

TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.
  If you received this in error, please contact the sender and delete the material from any computer.

RE: fetch and pull

[John Dlugosz]

=== Re: ===
If the local "dev" is meant to just track the remote, [that is the case]
you really ought to avoid doing anything very involved in it (unless
you're 
planning on merging something into it and pushing the result, that is!).
If
there's no local changes, then you can just pull with impunity, and
let it fast-forward - or use git merge or git rebase if you've already
fetched and don't want to spend the few seconds it takes to ask the
server if there's anything new :)
=== end ===

I thought about that.  But wouldn't that require you to checkout dev
first?  It seems that pull wants to merge into the current branch,
period.  That makes it unsuitable for something that just refreshes the
remote view of things, and is an accident waiting to happen if you run
it while on your topic branch instead.

=== Re: ===
Finally, if you really, truly, definitely want to blow away the
current branch and replace it with another one, you can use git reset
--hard. This will throw away (irretrievably) local uncommitted
changes, and force the current branch to point to the specified one.
=== end ===

"reset" does not change the current branch.  It updates the contents of
the working directory and index to match the node specified, but does
not change what git considers to be the branch you are "on".  I got a
few floating heads and later merge confusion before I finally understood
that.  It appears that "checkout" is the only thing that changes the
"current branch".  In any case, reset does not reposition any refs at
all.

=== Re: ===
Remember, you can undo most things using the reflog if you mess up,
including unwanted merges, git reset --hard (committed changes only)
etc.
=== end ===

Yes, indeed.

--John
(please excuse the footer; it's not my idea)

TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.
  If you received this in error, please contact the sender and delete the material from any computer.

Re: fetch and pull

[Junio C Hamano]

Bryan Donlan <bdonlan@gmail.com> writes:

> If the local "dev" is meant to just track the remote, you really ought
> to avoid doing anything very involved in it (unless you're planning on
> merging something into it and pushing the result, that is!). If
> there's no local changes, then you can just pull with impunity, and
> let it fast-forward - or use git merge or git rebase if you've already
> fetched and don't want to spend the few seconds it takes to ask the
> server if there's anything new :)

With git that is not ancient (i.e. v1.5.0 or newer), there is no reason to
have local "dev" that purely track the remote anymore.  If you only want
to go-look-and-see, you can check out the remote tracking branch directly
on a detached HEAD with "git checkout origin/dev".

Which means that the only cases we need to make it convenient for users
are to handle these local branches that "track" remote ones when you do
have local changes, or when you plan to have some.

If you do have local changes on "dev" that is marked to track the remove
"dev", and if you are on a branch different from "dev", then we should not
do anything after "git feftch" updates the remote tracking "dev".  It
won't fast forward anyway, and we do not need to talk about this case in
this thread.

That leaves only one case.  Your "dev" forked from the remote "dev"
sometime in the past, is marked to "track" the latter, but you haven't
done anything on the branch.  Should we have a convenient way to
fast-forward it after a "git fetch" that updates the remote "dev"?

I'd actually say we should give users a convenient way to remove the local
branches that are marked to track remote tracking branches but do not have
anything interesting on their own (iow when they can fast-forward to their
corresponding remote tracking branches), if the true motive behind this
thread is "'git push' will notice 'dev' that is left behind and gives
clutter".

Yes, you may earlier thought about building on top of the remote branch,
but you haven't done anything other than creating a branch, you left it
without doing anything interesting and kept it behind.

If you later decide to revisit whatever you wanted to work on by forking
from that branch, you can "git checkout -t -b dev origin/dev" at that time
to recreate the branch just as easily as you would do "git checkout dev",
and between the time you notice that you have a stale "dev" that does not
have anything interesting and the time you decide to really work on the
topic again, you may be better off not cluttering "git branch" output with
such useless local branches.

So how about "git branch --prune --remote=<upstream>" that iterates over
local branches, and if

 (1) it is not the current branch; and
 (2) it is marked to track some branch taken from the <upstream>; and
 (3) it does not have any commits on its own;

then remove that branch?  "git remote --prune-local-forks <upstream>" is
also fine; I do not care about which command implements the feature that
much.

The only case I think would be useful to keep a local branch that does not
yet have a commit on its own happens in this workflow:

 (1) You notice a bug sometime in the past (or at the tip) of the "dev"
     branch you see in the remote;

 (2) You bisect, find a faulty commit, and fork your "dev" from that
     commit, so that you can work on fixing that single bug, later to be
     merged back (because you anticipate the fix would be an involved
     series);

 (3) But you haven't had a chance to work on the fix yet.

Your fork point in this workflow has a meaning: this is the broken commit
I fix with my commits immediately after it.  It should not be rebased nor
fast-forwarded.

But in that case, you shouldn't mark "dev" as tracking the remote's "dev"
to begin with, so the hypothetical "branch --prune --remote=<upstream>"
would not touch such a "fork to address old issues", and we'd be safe.

Re: fetch and pull

[Bryan Donlan]

On Fri, Mar 6, 2009 at 5:11 PM, John Dlugosz <JDlugosz@tradestation.com> wrote:
> ===Re:===
>> There was patch series adding support --ff=only, but I think it didn't
>> made into git...  Hmmm...
>
> I do not think it has much to do with the main point of what John wants
> to
> do which is to muck with local branch without checking it out, which is
> only possible when it happens to fast forward to the new tip of the
> corresponding branch obtained from the the remote.
> ===end===
>
> It occurs to me that maybe my concept is off, if it is being so
> difficult.
>
> Here is what I'm "cooking":
>
> ======excerpt======
>
> To keep apprised of other people's work, including updates to the main
> dev branch, start the day with:
>
>        git fetch
>
> This will update your "remote tracking branches", letting you see what
> everyone else is working on, and letting you see the central
> repository's dev (as remotes/origin/dev) compared to your own local dev,
> so you can see what has been added.
>
> This does not change your local dev, or any other branches you are
> using.  As for your own topic branches, you are the only one who changes
> them.  This is a perfectly safe command and can be performed any time to
> update your view of what's happening throughout the team.
> You will, in particular, see your local dev where you last left it, and
> the current remotes/origin/dev pointing ahead of it.  E.g.
>
>        A <== dev
>         \
>          B--C--D <== remotes/origin/dev
>
> In this example, you see plain "dev" still pointing to A, and
> "remotes/origin/dev" pointing to D.  So, you can tell that B, C, D were
> added.  Review the nodes B, C, and D, by reading the comments and seeing
> which files were affected, and look deeper if it seems to affect what
> you are doing.  Finally, issue the command
>
>        ???
>
> And this will update your local dev to match the origin.
>
> ======
>
> Basically, instead of mysterious "can't push" messages, the idea is that
> people can feel good about 'fetch' as refreshing their view of the
> central repo, so gitk can show them how the central dev (and other
> branches) differs from their own.

If the local "dev" is a topic branch, you'd want to either merge or
rebase with the origin's dev branch. Rebasing is probably best if
you've not published the branch yet (unless you'd prefer proper merge
history on it).

If the local "dev" is meant to just track the remote, you really ought
to avoid doing anything very involved in it (unless you're planning on
merging something into it and pushing the result, that is!). If
there's no local changes, then you can just pull with impunity, and
let it fast-forward - or use git merge or git rebase if you've already
fetched and don't want to spend the few seconds it takes to ask the
server if there's anything new :)

Finally, if you really, truly, definitely want to blow away the
current branch and replace it with another one, you can use git reset
--hard. This will throw away (irretrievably) local uncommitted
changes, and force the current branch to point to the specified one.

Remember, you can undo most things using the reflog if you mess up,
including unwanted merges, git reset --hard (committed changes only)
etc.

Re: fetch and pull

[Junio C Hamano]

"John Dlugosz" <JDlugosz@TradeStation.com> writes:

> Here is what I'm "cooking":
>
> ======excerpt======
>
> To keep apprised of other people's work, including updates to the main
> dev branch, start the day with:
>
> 	git fetch
>
> This will update your "remote tracking branches", letting you see what
> everyone else is working on, and letting you see the central
> repository's dev (as remotes/origin/dev) compared to your own local dev,
> so you can see what has been added.
>
> This does not change your local dev, or any other branches you are
> using.  As for your own topic branches, you are the only one who changes
> them.  This is a perfectly safe command and can be performed any time to
> update your view of what's happening throughout the team.
> You will, in particular, see your local dev where you last left it, and
> the current remotes/origin/dev pointing ahead of it.  E.g.
>
> 	A <== dev
> 	 \
> 	  B--C--D <== remotes/origin/dev
>
> In this example, you see plain "dev" still pointing to A, and
> "remotes/origin/dev" pointing to D.  So, you can tell that B, C, D were
> added.  Review the nodes B, C, and D, by reading the comments and seeing
> which files were affected, and look deeper if it seems to affect what
> you are doing.  Finally, issue the command
>
> 	??? 
>
> And this will update your local dev to match the origin.
>
> ======

I already answered that question in a separate message (that is
different from what you are replying to), didn't I?

RE: fetch and pull

[John Dlugosz]

===Re:===
> There was patch series adding support --ff=only, but I think it didn't
> made into git...  Hmmm...

I do not think it has much to do with the main point of what John wants
to
do which is to muck with local branch without checking it out, which is
only possible when it happens to fast forward to the new tip of the
corresponding branch obtained from the the remote.
===end===

It occurs to me that maybe my concept is off, if it is being so
difficult.

Here is what I'm "cooking":

======excerpt======

To keep apprised of other people's work, including updates to the main
dev branch, start the day with:

	git fetch

This will update your "remote tracking branches", letting you see what
everyone else is working on, and letting you see the central
repository's dev (as remotes/origin/dev) compared to your own local dev,
so you can see what has been added.

This does not change your local dev, or any other branches you are
using.  As for your own topic branches, you are the only one who changes
them.  This is a perfectly safe command and can be performed any time to
update your view of what's happening throughout the team.
You will, in particular, see your local dev where you last left it, and
the current remotes/origin/dev pointing ahead of it.  E.g.

	A <== dev
	 \
	  B--C--D <== remotes/origin/dev

In this example, you see plain "dev" still pointing to A, and
"remotes/origin/dev" pointing to D.  So, you can tell that B, C, D were
added.  Review the nodes B, C, and D, by reading the comments and seeing
which files were affected, and look deeper if it seems to affect what
you are doing.  Finally, issue the command

	??? 

And this will update your local dev to match the origin.

======

Basically, instead of mysterious "can't push" messages, the idea is that
people can feel good about 'fetch' as refreshing their view of the
central repo, so gitk can show them how the central dev (and other
branches) differs from their own.  

TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.
  If you received this in error, please contact the sender and delete the material from any computer.

Re: fetch and pull

[Junio C Hamano]

Jakub Narebski <jnareb@gmail.com> writes:

> "John Dlugosz" <JDlugosz@TradeStation.com> writes:
>
>> So, after inspecting the changes, how do you fast-forward your local dev
>> to sync up with origin/dev?
>> 
>> I'm worried that
>> 
>> 	git pull origin dev
>> 
>> will try to merge into the current head.  The documentation indicates
>> "The remote ref that matches <src> is fetched, and if <dst> is not empty
>> string, the local ref that matches it is fast forwarded using <src>."
>> which is what I want, but it does NOT say that the normal behavior of
>> merging origin/dev into the =current= HEAD, if it happens to not be the
>> local dev.
>> 
>> So, does it indeed suppress that behavior if you give it an explicit
>> destination?  Or will I have to checkout dev first before doing the
>> pull, to prevent strange things from happening?  Hmm, or perhaps I
>> should be using merge, not pull?  After all, pull is really just a
>> wrapper around fetch and then merge, right?  So is it OK to call merge
>> when I really want to fast-forward, and is there an option to give an
>> error if it isn't ff?
>
> There was patch series adding support --ff=only, but I think it didn't
> made into git...  Hmmm...

I do not think it has much to do with the main point of what John wants to
do which is to muck with local branch without checking it out, which is
only possible when it happens to fast forward to the new tip of the
corresponding branch obtained from the the remote.

Re: fetch and pull

[Jakub Narebski]

"John Dlugosz" <JDlugosz@TradeStation.com> writes:

> So, after inspecting the changes, how do you fast-forward your local dev
> to sync up with origin/dev?
> 
> I'm worried that
> 
> 	git pull origin dev
> 
> will try to merge into the current head.  The documentation indicates
> "The remote ref that matches <src> is fetched, and if <dst> is not empty
> string, the local ref that matches it is fast forwarded using <src>."
> which is what I want, but it does NOT say that the normal behavior of
> merging origin/dev into the =current= HEAD, if it happens to not be the
> local dev.
> 
> So, does it indeed suppress that behavior if you give it an explicit
> destination?  Or will I have to checkout dev first before doing the
> pull, to prevent strange things from happening?  Hmm, or perhaps I
> should be using merge, not pull?  After all, pull is really just a
> wrapper around fetch and then merge, right?  So is it OK to call merge
> when I really want to fast-forward, and is there an option to give an
> error if it isn't ff?

There was patch series adding support --ff=only, but I think it didn't
made into git...  Hmmm...

-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: fetch and pull

[Junio C Hamano]

"John Dlugosz" <JDlugosz@TradeStation.com> writes:

> I've gotten the hang of git well enough to pretty much bang on it until
> I achieve what I wanted to happen, though maybe trying a few things and
> recovering from mistakes or taking the long way around.
>
> Now I'm putting together a cookbook for our team, to allow use of topic
> branches rather than treating it simply as a faster SourceSafe.
>
> I want to advocate running
>
> 	git fetch
>
> as being a safe thing to do at any time, just to refresh your view of
> the origin and not mess up any of your local labels.  That is, you can
> see the difference between the local dev and the origin/dev.
>
> So, after inspecting the changes, how do you fast-forward your local dev
> to sync up with origin/dev?

$ git push . origin/dev dev

fetch and pull

[John Dlugosz]

I've gotten the hang of git well enough to pretty much bang on it until
I achieve what I wanted to happen, though maybe trying a few things and
recovering from mistakes or taking the long way around.

Now I'm putting together a cookbook for our team, to allow use of topic
branches rather than treating it simply as a faster SourceSafe.

I want to advocate running

	git fetch

as being a safe thing to do at any time, just to refresh your view of
the origin and not mess up any of your local labels.  That is, you can
see the difference between the local dev and the origin/dev.

So, after inspecting the changes, how do you fast-forward your local dev
to sync up with origin/dev?

I'm worried that

	git pull origin dev

will try to merge into the current head.  The documentation indicates
"The remote ref that matches <src> is fetched, and if <dst> is not empty
string, the local ref that matches it is fast forwarded using <src>."
which is what I want, but it does NOT say that the normal behavior of
merging origin/dev into the =current= HEAD, if it happens to not be the
local dev.

So, does it indeed suppress that behavior if you give it an explicit
destination?  Or will I have to checkout dev first before doing the
pull, to prevent strange things from happening?  Hmm, or perhaps I
should be using merge, not pull?  After all, pull is really just a
wrapper around fetch and then merge, right?  So is it OK to call merge
when I really want to fast-forward, and is there an option to give an
error if it isn't ff?

--John
(sorry about the footer; it's not my idea)

TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.
  If you received this in error, please contact the sender and delete the material from any computer.