And David Bryson writes:
One really should not push to a non-bare repo.
WHAT?!?!?!
And Jeff King responds:
It's in master and should be in 1.6.1, but it is a config option that
defaults to "warn" for now, so as not to break existing setups.
WHAT?!?!?!
I do this all the time. I clone from my main working directory
onto some cluster / MPP where the build system is all wonky.
Once I get everything building, I push back to a branch (often
new) in my main working directory. Then I can merge the build
changes whenever I get a chance.
Pushing from these systems often is much, much easier than
pulling from the origin. Sometimes you're working in temporary
space on a back-end node; you can connect out but you cannot
connect in.
I've gotten a few people interested in git for managing these
nearly one-off build problems. git is the first system that has
"just worked" for them. Their having to configure each repo
eliminates the "just works" factor.
It feels like newer gits make more and more decisions about what
I shouldn't do.
Jason
On Mon, Dec 01, 2008 at 07:46:35PM -0500, Jason Riedy wrote:
And David Bryson writes:
quoted
One really should not push to a non-bare repo.
WHAT?!?!?!
To clarify: one should not push to the _current branch_ of a non-bare
repo...
And Jeff King responds:
quoted
It's in master and should be in 1.6.1, but it is a config option that
defaults to "warn" for now, so as not to break existing setups.
WHAT?!?!?!
...and that is what 1.6.1 will warn about.
I do this all the time. I clone from my main working directory
onto some cluster / MPP where the build system is all wonky.
Once I get everything building, I push back to a branch (often
new) in my main working directory. Then I can merge the build
changes whenever I get a chance.
As long as you are not pushing to the currently checked-out branch, then
you will see no change in behavior. If you are pushing to the currently
checked-out branch, then what are you doing to reconcile the resulting
mismatch between the index and HEAD?
Pushing from these systems often is much, much easier than
pulling from the origin. Sometimes you're working in temporary
space on a back-end node; you can connect out but you cannot
connect in.
Of course. The recommended thing to do is:
# on pusher
git push $remote HEAD:some-branch-that-is-not-checked-out
# on $remote
git merge some-branch-that-is-not-checked-out
where an obvious choice for branch name is "incoming/master" or whatever
suits your workflow. You can also do:
# on pusher
git push $remote HEAD:branch-that-is-checked-out
# on $remote
git reset --hard
but that throws away anything else going on in that branch on $remote.
It feels like newer gits make more and more decisions about what
I shouldn't do.
Doing
git push $remote HEAD:branch-that-is-checked-out
has _never_ worked without further action on $remote. Now we're warning
about it.
If you have other specific complaints about new git behavior, I'm sure
the list would be happy to hear about it. Almost every behavior change
is in response to user complaints, and a lot of effort is put into
maintaining backwards compatibility. If we've screwed up somewhere, it
would be good to know.
-Peff
On 12/1/08, Jason Riedy [off-list ref] wrote:
And David Bryson writes:
> One really should not push to a non-bare repo.
WHAT?!?!?!
And Jeff King responds:
quoted
It's in master and should be in 1.6.1, but it is a config option that
> defaults to "warn" for now, so as not to break existing setups.
WHAT?!?!?!
I do this all the time. I clone from my main working directory
onto some cluster / MPP where the build system is all wonky.
Once I get everything building, I push back to a branch (often
new) in my main working directory. Then I can merge the build
changes whenever I get a chance.
Pushing from these systems often is much, much easier than
pulling from the origin. Sometimes you're working in temporary
space on a back-end node; you can connect out but you cannot
connect in.
I've gotten a few people interested in git for managing these
nearly one-off build problems. git is the first system that has
"just worked" for them. Their having to configure each repo
eliminates the "just works" factor.
It feels like newer gits make more and more decisions about what
I shouldn't do.
Jason
I second Jason's opinion. I also frequently push to non-bare
intermediary repos. This functionality is essential for several of my
work flows. Please, please, do not handicap git-push operation!!
--Leo--