On Fri, 3 Jul 2015 06:15:23 -0700 (PDT)
p...@greenlogix.eu wrote:

> hello,
> I cloned a rep I installed on a ubuntu machine (empty rep)
> as I add files to that empty working copy, I can commit them (I use 
> SourceTree)
> but once I do the push, I get an error, 
> master -> master (branch is currently checked out)

I think that's how the tool you're using tells you about the problem
dealed with in [1] and detailed in [2] (I suspect, plain Git would tell
you a lot more information had you used it insteas of SoureTree).

Basically (if I'm correct with the diagnosis) the problem is like here:

* You have a "normal", non-bare repository on your target ("server")

* This means that repository has a work tree -- where the checked out
  files are kept, and where you modify them and from where you then
  stage these changes to be included into the next commit, and then

  It seems, you have the branch "master" checked out there in the
  remote repo.

* Now you're trying to *update* that branch "master" in the remote repo
  by your push from your local repo.

It seems a logical thing to you until you try to imagine what would
happen if Git allowed to do such a thing by default (it doesn't).

What would happen is that suddenly the index (the staging area in which
commits are prepared) is no more linked to the tip commit of the
"master" branch it used to before you pushed.  That's quite a nasty
situation: for a start, you'll be unable to commit your changes, and
`git diff --staged` will give weird results.  That is, by this push
you would "pull the rug from under the feet" of your work tree in the
remote repository.

What to do about this depends on what solution you're more comfortable
with.  I, for one, prefer pushing to a throw-away branch with a
meaningless name such as "temp" -- then when I'm back at the remote repo
I just do

  git merge temp

and may be

  git branch -d temp

afterwards to get rid of that branch.

A corollary to this, is that if you're able to reach this local repo
from your remote repo, just *fetch* your data from the local repo
when you're back at your remote repo.  That is, fetch instead of pushing.

Another approach, quite often suggested, is to have a separate *bare*
repository somewhere which is used for exchange by both regular repos.
In this scheme, you would push to that shared reposory and then when
back at the remote repository you'd fetch from that shared one and
merge your changes into appropriate branch(es).

IMO for one-man projects this approach is an overkill unless you have
troubles pushing/fetching directly between all your workplaces (and if
you have, you would typically use some public Git hosting such as
Bitbucket or Github or others).

Yet another approach is to tweak a special configuration parameter in
the remote repo to allow pushes to the currently checked out branch.
Given the situation -- you're doing your first baby steps with Git --
I'd strongly advise against this because after the first such push you
will be scratching your head about what to do next.

My bit of advice: push to a temporary branch(es) in the remote repo
and when back at it, merge from that branch/those branches into the
corresponding local branch(es).  You can then get rid of those temporary
branches or keep them around for the next push etc.
Or fetch, if possible/more convenient.

1. http://stackoverflow.com/q/3191400/720999
2. http://gitready.com/advanced/2009/02/01/push-to-only-bare-repositories.html

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to