git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* {Spam?} push pull not working
@ 2012-01-24 19:00 Rick Bragg
  2012-01-24 19:41 ` Jeff King
  0 siblings, 1 reply; 6+ messages in thread
From: Rick Bragg @ 2012-01-24 19:00 UTC (permalink / raw)
  To: GIT Mailing-list

Hi,

I cloned a repo from /home/me/repo1 to /home/me/repo2.  Then made
changes and a new commit on repo1, then from repo1 did "git
push /home/me/repo2 and it says Everything is up-to-date.  How could
this be?

Thanks
Rick

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: {Spam?} push pull not working
  2012-01-24 19:00 {Spam?} push pull not working Rick Bragg
@ 2012-01-24 19:41 ` Jeff King
  2012-01-24 20:05   ` {Spam?} " Rick Bragg
  2012-01-24 20:12   ` {Spam?} " Junio C Hamano
  0 siblings, 2 replies; 6+ messages in thread
From: Jeff King @ 2012-01-24 19:41 UTC (permalink / raw)
  To: Rick Bragg; +Cc: GIT Mailing-list

On Tue, Jan 24, 2012 at 02:00:31PM -0500, Rick Bragg wrote:

> I cloned a repo from /home/me/repo1 to /home/me/repo2.  Then made
> changes and a new commit on repo1, then from repo1 did "git
> push /home/me/repo2 and it says Everything is up-to-date.  How could
> this be?

It's hard to say, since you didn't show us the exact commands you ran.

One possible cause is that you made your commit on a detached HEAD, not
on a branch, and therefore pushing branches will have no effect. You can
check this by running "git status", which will report either your
current branch or "not currently on any branch".

Another possible cause is that git is not trying to push the branches
that you think it is.

For example, imagine repo1 has two branches, "master" and "foo", and the
"master" branch is checked out. When you clone it, the resulting repo2
will have remote-tracking branches for both "master" and "foo", but will
only checkout the "master" branch. Now imagine you make commits on
"foo" in repo1, and then try to push. Git's default behavior is to push
only branches which match (by name) a branch on the destination. So we
would attempt to push "master" (which is up to date), but not "foo".

You can see which branches are being considered in the push with "git
push -vv". If you want to push all branches, you can use "git push
--all", or read up on refspecs in "git help push". If you want to change
git-push's default behavior, read up on "push.default" in "git help
config".

-Peff

^ permalink raw reply	[flat|nested] 6+ messages in thread

* {Spam?} Re: push pull not working
  2012-01-24 19:41 ` Jeff King
@ 2012-01-24 20:05   ` Rick Bragg
  2012-01-24 20:12   ` {Spam?} " Junio C Hamano
  1 sibling, 0 replies; 6+ messages in thread
From: Rick Bragg @ 2012-01-24 20:05 UTC (permalink / raw)
  To: Jeff King; +Cc: GIT Mailing-list

On Tue, 2012-01-24 at 14:41 -0500, Jeff King wrote:
> On Tue, Jan 24, 2012 at 02:00:31PM -0500, Rick Bragg wrote:
> 
> > I cloned a repo from /home/me/repo1 to /home/me/repo2.  Then made
> > changes and a new commit on repo1, then from repo1 did "git
> > push /home/me/repo2 and it says Everything is up-to-date.  How could
> > this be?
> 
> It's hard to say, since you didn't show us the exact commands you ran.
> 
> One possible cause is that you made your commit on a detached HEAD, not
> on a branch, and therefore pushing branches will have no effect. You can
> check this by running "git status", which will report either your
> current branch or "not currently on any branch".
> 
> Another possible cause is that git is not trying to push the branches
> that you think it is.
> 
> For example, imagine repo1 has two branches, "master" and "foo", and the
> "master" branch is checked out. When you clone it, the resulting repo2
> will have remote-tracking branches for both "master" and "foo", but will
> only checkout the "master" branch. Now imagine you make commits on
> "foo" in repo1, and then try to push. Git's default behavior is to push
> only branches which match (by name) a branch on the destination. So we
> would attempt to push "master" (which is up to date), but not "foo".
> 
> You can see which branches are being considered in the push with "git
> push -vv". If you want to push all branches, you can use "git push
> --all", or read up on refspecs in "git help push". If you want to change
> git-push's default behavior, read up on "push.default" in "git help
> config".
> 
> -Peff
> 

Thanks, I went back a few commits and tried again and it works.  I'm not
sure what it was, I will have allot of reading to do.

Thanks again!
Rick

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: {Spam?} push pull not working
  2012-01-24 19:41 ` Jeff King
  2012-01-24 20:05   ` {Spam?} " Rick Bragg
@ 2012-01-24 20:12   ` Junio C Hamano
  2012-01-24 20:18     ` Jeff King
  1 sibling, 1 reply; 6+ messages in thread
From: Junio C Hamano @ 2012-01-24 20:12 UTC (permalink / raw)
  To: Jeff King; +Cc: Rick Bragg, GIT Mailing-list

Jeff King <peff@peff.net> writes:

> For example, imagine repo1 has two branches, "master" and "foo", and the
> "master" branch is checked out. When you clone it, the resulting repo2
> will have remote-tracking branches for both "master" and "foo", but will
> only checkout the "master" branch. Now imagine you make commits on
> "foo" in repo1, and then try to push. Git's default behavior is to push
> only branches which match (by name) a branch on the destination. So we
> would attempt to push "master" (which is up to date), but not "foo".

Technically you are not saying anything incorrect, but the above is not an
appropriate paragraph to give to a total newbie, I would have to say.

It does not make it clear that it is insane to push to repo2 with matching
push (or "current" or "upstream" for that matter), after cloning from a
repository repo1 with a working tree to repo2 with an working tree, and
making changes at the original repo1 repository. Instead, you are giving a
false impression that pushing both "master" and "foo" explicitly would
solve the problem OP is having, which is not true.

If repo1 and repo2 with working trees want to criss-cross-exchange their
histories, both should "git pull" from the other, not "git push", and if
one side cannot initiate a connection to the other, "git push" that goes
in the other direction should be pushing into remote tracking refs of the
other in order to emulate a "git pull" that goes in the other direction.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: {Spam?} push pull not working
  2012-01-24 20:12   ` {Spam?} " Junio C Hamano
@ 2012-01-24 20:18     ` Jeff King
  2012-01-24 20:28       ` Junio C Hamano
  0 siblings, 1 reply; 6+ messages in thread
From: Jeff King @ 2012-01-24 20:18 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Rick Bragg, GIT Mailing-list

On Tue, Jan 24, 2012 at 12:12:54PM -0800, Junio C Hamano wrote:

> > For example, imagine repo1 has two branches, "master" and "foo", and the
> > "master" branch is checked out. When you clone it, the resulting repo2
> > will have remote-tracking branches for both "master" and "foo", but will
> > only checkout the "master" branch. Now imagine you make commits on
> > "foo" in repo1, and then try to push. Git's default behavior is to push
> > only branches which match (by name) a branch on the destination. So we
> > would attempt to push "master" (which is up to date), but not "foo".
> 
> Technically you are not saying anything incorrect, but the above is not an
> appropriate paragraph to give to a total newbie, I would have to say.
> [...]

Yeah, I agree with all of this. I was trying not to go into too much
detail because we knew so little about the situation (e.g., we don't
even know if repo2 in the example is bare or not!), but perhaps my
terseness made things even more confusing.

This might have been a better example (it exhibits the problem, but is
not an example of a terrible thing to be doing):

  1. repo1 has a "master" branch

  2. clone repo1 with "git clone --bare repo1 repo2". Repo2 now has a
     master branch.

  3. create a new "foo" branch in repo and commit on it

  4. "git push ../repo2" from repo1. This is a sane thing to be doing,
     but will not push the newly-created "foo" branch, as some users
     might expect.

-Peff

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: {Spam?} push pull not working
  2012-01-24 20:18     ` Jeff King
@ 2012-01-24 20:28       ` Junio C Hamano
  0 siblings, 0 replies; 6+ messages in thread
From: Junio C Hamano @ 2012-01-24 20:28 UTC (permalink / raw)
  To: Jeff King; +Cc: Rick Bragg, GIT Mailing-list

Jeff King <peff@peff.net> writes:

> This might have been a better example (it exhibits the problem, but is
> not an example of a terrible thing to be doing):
>
>   1. repo1 has a "master" branch
>
>   2. clone repo1 with "git clone --bare repo1 repo2". Repo2 now has a
>      master branch.
>
>   3. create a new "foo" branch in repo and commit on it
>
>   4. "git push ../repo2" from repo1. This is a sane thing to be doing,
>      but will not push the newly-created "foo" branch, as some users
>      might expect.

Yeah, that is pretty much the standard thing people would do, at least
before GitHub era ;-), to start a project in repo1, and then to publish
for others to fetch at repo2.

Thanks for clarification.

P.S. Did you have chance to take a look at the "grep" thing? I thought
"grep --textconv" would make sense, but I may be missing some large
pitfalls.

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2012-01-24 20:28 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-01-24 19:00 {Spam?} push pull not working Rick Bragg
2012-01-24 19:41 ` Jeff King
2012-01-24 20:05   ` {Spam?} " Rick Bragg
2012-01-24 20:12   ` {Spam?} " Junio C Hamano
2012-01-24 20:18     ` Jeff King
2012-01-24 20:28       ` Junio C Hamano

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).