fetch and pull

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: fetch and pull

Junio C Hamano
"John Dlugosz" <[hidden email]> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: fetch and pull

Jakub Narębski
In reply to this post by John Dlugosz
"John Dlugosz" <[hidden email]> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: fetch and pull

Junio C Hamano
Jakub Narebski <[hidden email]> writes:

> "John Dlugosz" <[hidden email]> 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.

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: fetch and pull

Junio C Hamano
"John Dlugosz" <[hidden email]> 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?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: fetch and pull

Bryan Donlan
In reply to this post by John Dlugosz
On Fri, Mar 6, 2009 at 5:11 PM, John Dlugosz <[hidden email]> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: fetch and pull

Junio C Hamano
Bryan Donlan <[hidden email]> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

RE: fetch and pull

John Dlugosz
In reply to this post by Bryan Donlan
=== 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

RE: fetch and pull

John Dlugosz
In reply to this post by Junio C Hamano
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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html