From: John Dlugosz <hidden> Date: 2016-06-15 22:46:24
=== 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.
From: Jay Soffian <hidden> Date: 2016-06-15 22:46:24
On Mon, Mar 16, 2009 at 3:00 PM, John Dlugosz [off-list ref] wrote:
=== Re: ===
quoted
So, after inspecting the changes, how do you fast-forward your local
dev
quoted
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.
From: John Dlugosz <hidden> Date: 2016-06-15 22:46:24
=== 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.
From: Jay Soffian <hidden> Date: 2016-06-15 22:46:24
On Mon, Mar 16, 2009 at 4:39 PM, John Dlugosz [off-list ref] 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.
From: John Dlugosz <hidden> Date: 2016-06-15 22:46:24
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.
From: Jay Soffian <hidden> Date: 2016-06-15 22:46:24
On Mon, Mar 16, 2009 at 6:33 PM, John Dlugosz [off-list ref] 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.
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.
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.
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.
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/
From: Jeff King <hidden> Date: 2016-06-15 22:46:24
On Tue, Mar 17, 2009 at 12:44:31PM -0400, John Dlugosz wrote:
quoted
quoted
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
From: Björn Steinbrink <hidden> Date: 2016-06-15 22:46:24
On 2009.03.18 06:31:03 +0900, Nanako Shiraishi wrote:
Quoting John Dlugosz [off-list ref]:
quoted
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
From: John Dlugosz <hidden> Date: 2016-06-15 22:46:25
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.
From: Björn Steinbrink <hidden> Date: 2016-06-15 22:46:25
On 2009.03.18 11:18:41 -0400, John Dlugosz wrote:
quoted
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
From: John Dlugosz <hidden> Date: 2016-06-15 22:46:25
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.