I want to have a git repository accessed via ssh. Just for me, no plans to give anyone else
access.
Below is the transcript of what I did, how do I solve the problem at the end of git refusing
to update a checked out branch?
rjc@linux:/tmp$ mkdir orig
rjc@linux:/tmp$ cd orig
rjc@linux:/tmp/orig$ git init
Initialized empty Git repository in /tmp/orig/.git/
rjc@linux:/tmp/orig$ ls -al > file
rjc@linux:/tmp/orig$ git add file
rjc@linux:/tmp/orig$ git commit file
[...]
1 file changed, 5 insertions(+)
create mode 100644 file
rjc@linux:/tmp/orig$ cd ..
rjc@linux:/tmp$ mkdir copy
rjc@linux:/tmp$ cd copy
rjc@linux:/tmp/copy$ git init
Initialized empty Git repository in /tmp/copy/.git/
rjc@linux:/tmp/copy$ git pull localhost:/tmp/orig
remote: Counting objects: 3, done.
[...]
>From localhost:/tmp/orig
* branch HEAD -> FETCH_HEAD
rjc@linux:/tmp/copy$ git push localhost:/tmp/orig
fatal: The current branch master has no upstream branch.
To push the current branch and set the remote as upstream, use
git push --set-upstream localhost:/tmp/orig master
rjc@linux:/tmp/copy$ git push --set-upstream localhost:/tmp/orig master
rjc@linux:/tmp/copy$ ls -al > file2
rjc@linux:/tmp/copy$ git push
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
It seems that I have to create the master repository with "git init --bare" and then push from the slave after adding a file. Adding a file on the master is also apparently a bad idea. This is annoying, pity git is what all the cool kids use nowadays. On Tuesday, 8 May 2018 6:18:29 PM AEST Russell Coker wrote:
I want to have a git repository accessed via ssh. Just for me, no plans to give anyone else access.
Below is the transcript of what I did, how do I solve the problem at the end of git refusing to update a checked out branch?
rjc@linux:/tmp$ mkdir orig rjc@linux:/tmp$ cd orig rjc@linux:/tmp/orig$ git init Initialized empty Git repository in /tmp/orig/.git/ rjc@linux:/tmp/orig$ ls -al > file rjc@linux:/tmp/orig$ git add file rjc@linux:/tmp/orig$ git commit file [...] 1 file changed, 5 insertions(+) create mode 100644 file rjc@linux:/tmp/orig$ cd .. rjc@linux:/tmp$ mkdir copy rjc@linux:/tmp$ cd copy rjc@linux:/tmp/copy$ git init Initialized empty Git repository in /tmp/copy/.git/ rjc@linux:/tmp/copy$ git pull localhost:/tmp/orig remote: Counting objects: 3, done. [...] From localhost:/tmp/orig * branch HEAD -> FETCH_HEAD rjc@linux:/tmp/copy$ git push localhost:/tmp/orig fatal: The current branch master has no upstream branch. To push the current branch and set the remote as upstream, use
git push --set-upstream localhost:/tmp/orig master rjc@linux:/tmp/copy$ git push --set-upstream localhost:/tmp/orig master rjc@linux:/tmp/copy$ ls -al > file2 rjc@linux:/tmp/copy$ git push
-- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
On 08.05.18 18:35, Russell Coker via luv-main wrote:
This is annoying, pity git is what all the cool kids use nowadays.
On Tuesday, 8 May 2018 6:18:29 PM AEST Russell Coker wrote:
I want to have a git repository accessed via ssh. Just for me, no plans to give anyone else access.
Whatever we're most familiar with is the best VCS for solo use, I figure. Only if desperate to climb the git learning curve would I add unnecessary frustration to the task in hand. (For solo use I just continue to use what I've known for around three decades - CVS. How uncool is that?) Erik
On Tuesday, 8 May 2018 7:29:59 PM AEST Erik Christiansen via luv-main wrote:
Whatever we're most familiar with is the best VCS for solo use, I figure. Only if desperate to climb the git learning curve would I add unnecessary frustration to the task in hand. (For solo use I just continue to use what I've known for around three decades - CVS. How uncool is that?)
I used CVS 20 years ago and found it to work OK. I don't recall what the actual issues were but I recall being relieved when I found Subversion. I seriously considered installing Subversion for this use, not that I think it's particularly great but I became reasonably proficient when I was paid to take over a project that used it a lot. But the ability to check things in while offline will be handy on occasion. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
Russell Coker via luv-main <luv-main@luv.asn.au> writes:
It seems that I have to create the master repository with "git init --bare" and then push from the slave after adding a file. Adding a file on the master is also apparently a bad idea.
Both of these apply equally to subversion. You have to create the repository on the master first before you can even conduct the first checkout. You can't interect directly with the master repository, you have to checkout a version somewhere first. I am not 100% sure what you mean by "Adding a file on the master is also apparently a bad idea." however the master repository is a "bare respository" not a working tree, so you can't see your files here or add to them unless you create a checkout first. -- Brian May <brian@linuxpenguins.xyz> https://linuxpenguins.xyz/brian/
On 9 May 2018 at 08:10, Brian May via luv-main <luv-main@luv.asn.au> wrote:
Russell Coker via luv-main <luv-main@luv.asn.au> writes:
It seems that I have to create the master repository with "git init --bare" and then push from the slave after adding a file. Adding a file on the master is also apparently a bad idea.
I think that a shared repository (where every one commits changes to) is not meant to have local (unchecked in) changes as it makes things messy. There are several styles of managing shared work - if you want several checkouts synching in at different times - one common bare repository makes this simpler to agree on the official version. But you can have multiple trees - then usual style is to have a tracking branch for each tree. Each person can then merge in via their tracking branch and when up to date (like subversion) and then push their changes to that tree. One style is each feature is a separate branch with developers committing to that feature branch. As features stabilise some one will merge that branch into a stable branch for testing / release. git is *much* faster than subversion and handles very large packages like the kernel. It also allows you to re-write your history (unlike subversion) and handles multiple simultaneous threads of history which can be merged together and preserve their separate time lines unlike subversion. I've used both subversion and git and despite some painful learning I much prefer git. It is worth persevering with - but take it in steps. It's really worth understanding that it uses hashes to index the code snapshots - which makes it vastly faster to see if two directories/files are changed. Andrew
On 09.05.18 08:10, Brian May via luv-main wrote:
Russell Coker via luv-main <luv-main@luv.asn.au> writes:
It seems that I have to create the master repository with "git init --bare" and then push from the slave after adding a file. Adding a file on the master is also apparently a bad idea.
Both of these apply equally to subversion. You have to create the repository on the master first before you can even conduct the first checkout. You can't interect directly with the master repository, you have to checkout a version somewhere first.
Heck, that even applies to venerable CVS. The repository remains inviolate, and you check out a copy into a working tree, then check back in, either to the head or a branch.
I am not 100% sure what you mean by "Adding a file on the master is also apparently a bad idea." however the master repository is a "bare respository" not a working tree, so you can't see your files here or add to them unless you create a checkout first.
Yup, and surely remote check-in/out from the repository is standard for them all? Erik
On Wednesday, 9 May 2018 12:54:22 PM AEST Erik Christiansen via luv-main wrote:
On 09.05.18 08:10, Brian May via luv-main wrote:
Russell Coker via luv-main <luv-main@luv.asn.au> writes:
It seems that I have to create the master repository with "git init --bare" and then push from the slave after adding a file. Adding a file on the master is also apparently a bad idea.
Both of these apply equally to subversion. You have to create the repository on the master first before you can even conduct the first checkout. You can't interect directly with the master repository, you have to checkout a version somewhere first.
Heck, that even applies to venerable CVS. The repository remains inviolate, and you check out a copy into a working tree, then check back in, either to the head or a branch.
I am not 100% sure what you mean by "Adding a file on the master is also apparently a bad idea." however the master repository is a "bare respository" not a working tree, so you can't see your files here or add to them unless you create a checkout first.
Yup, and surely remote check-in/out from the repository is standard for them all?
The difference is that systems like CVS and Subversion are explicitely designed to have a single primary repository that's not directly accessible. No-one would ever think of Subversion as allowing people to do independent stuff and merge it later. Git gives you the impression that you can push/pull from anywhere to anywhere when that isn't the case. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
On 15.05.18 10:45, Russell Coker via luv-main wrote:
On Wednesday, 9 May 2018 12:54:22 PM AEST Erik Christiansen via luv-main wrote:
Yup, and surely remote check-in/out from the repository is standard for them all?
The difference is that systems like CVS and Subversion are explicitely designed to have a single primary repository that's not directly accessible. No-one would ever think of Subversion as allowing people to do independent stuff and merge it later. Git gives you the impression that you can push/pull from anywhere to anywhere when that isn't the case.
Ah, I had at one stage thought of modernising from CVS to Subversion, but after decades of using CVS to automatically merge concurrent edits from multiple sources, I'm disappointed to hear that Subversion is a regression in capability. (OK, on rare occasions I had to manually resolve conflicts, but CVS showed both versions of the conflicting lines, and a keystroke selected which survived. Sometimes human adjudication is essential, and > 99% automagic merging is a great productivity aid.) Without more experience with Git than a couple of check-outs for a local compile, I'd still surmise that it is not a lot more distributed than CVS if you can't "push/pull from anywhere to anywhere". (Except that I'd have expected that a push ought to be to everywhere, given my mental model of a development trunk (maybe called "main") with local development on a branch, which may be merged back into the trunk at some stage.) And given that one shared copy of the head of the trunk is an essential resource of a VCS, then it doesn't seem to matter functionally whether that is a networked central copy or distributed copies forced to be identical. Erik
On 15/05/18 12:53, Erik Christiansen via luv-main wrote:
Ah, I had at one stage thought of modernising from CVS to > Subversion, but after decades of using CVS to automatically merge > concurrent edits from multiple sources, I'm disappointed to hear that > Subversion is a regression in capability. I certainly wouldn't say that. I moved from RCS to CVS to Subversion to git and I found Subversion more capable than CVS in every respect.
Without more experience with Git than a couple of check-outs for a > local compile, I'd still surmise that it is not a lot more > distributed than CVS if you can't "push/pull from anywhere to > anywhere". (Except that I'd have expected that a push ought to be to > everywhere, given my mental model of a development trunk (maybe > called "main") with local development on a branch, which may be > merged back into the trunk at some stage.) And given that one shared > copy of the head of the trunk is an essential resource of a VCS, then > it doesn't seem to matter functionally whether that is a networked > central copy or distributed copies forced to be identical. But the distributed copies aren't forced to be identical; that's one of the key features of git.
https://git-scm.com/book/en/v2/Git-Basics-Working-with-Remotes The issue that Russell encountered is that git can also operate centralised servers in addition to distributed repositories, but you can't do both things with a single repository. A normal repository can share with others, but not be a centralised server; a centralised server can't also be used as a local repository. But you can use any number of both in any project. Hope that helps, Andrew
On 15.05.18 13:57, Andrew Pam via luv-main wrote:
But the distributed copies aren't forced to be identical; that's one of the key features of git.
That makes them somewhat like a set of local branches on a conventional VCS, perhaps.
https://git-scm.com/book/en/v2/Git-Basics-Working-with-Remotes
Ah, and there are merge rules to compensate, I see. OH, yes, "upstream". A local repository may base one distro, with only approved patches going to the upstream repository for more general distribution.
The issue that Russell encountered is that git can also operate centralised servers in addition to distributed repositories, but you can't do both things with a single repository. A normal repository can share with others, but not be a centralised server; a centralised server can't also be used as a local repository. But you can use any number of both in any project.
I can see that some rethinking is required when making a VCS transition.
Hope that helps, Andrew
Thanks Andrew, it does. I keep a "git" mail folder for accumulating informative tidbits, and continued exposure eases the transition should that have to move into a higher gear. Erik
Russell Coker via luv-main <luv-main@luv.asn.au> writes:
Git gives you the impression that you can push/pull from anywhere to anywhere when that isn't the case.
Maybe I am confused. What do you mean when you say that this isn't the case? -- Brian May <brian@linuxpenguins.xyz> https://linuxpenguins.xyz/brian/
On 15 May 2018 1:24:29 pm AEST, Brian May <brian@linuxpenguins.xyz> wrote:
Russell Coker via luv-main <luv-main@luv.asn.au> writes:
Git gives you the impression that you can push/pull from anywhere to anywhere when that isn't the case.
Maybe I am confused. What do you mean when you say that this isn't the case?
Well I can't create a repository, check files in, and then pull and push to it from other systems. I need to create an empty repository, push to it from somewhere, and then I can pull and push from anywhere. -- Sent from my Huawei Mate 9 with K-9 Mail.
On 16/05/18 13:09, Russell Coker via luv-main wrote:
Well I can't create a repository, check files in, and then pull and push to it from other systems.
You certainly can.
I need to create an empty repository, push to it from somewhere, and then I can pull and push from anywhere.
That's the way that git is normally used, but not the only possible way. <https://www.quora.com/Whats-the-difference-between-a-bare-and-non-bare-git-repository> Cheers, Andrew
Russell Coker <russell@coker.com.au> writes:
Well I can't create a repository, check files in, and then pull and push to it from other systems. I need to create an empty repository, push to it from somewhere, and then I can pull and push from anywhere.
I suspect what you need to do is adjust things slightly, so you can do what you want. e.g. you can create a bare respository on somewhere. Then you can check out a working tree on the same system. This working tree can push/pull to the bare repository as much as you want. Furthermore you can checkout this bare respository on remote systems. I can't think of any source code revision system that would allow you to push/pull to a remote working respository with a working tree. It is unclear what to do when pushing to a working tree that has changes (should we update the working tree to? Or just the respository?) or worse if the working tree has conflicting changes already. -- Brian May <brian@linuxpenguins.xyz> https://linuxpenguins.xyz/brian/
On Sat, May 19, 2018 at 03:09:35PM +1000, Brian May wrote:
Russell Coker <russell@coker.com.au> writes:
Well I can't create a repository, check files in, and then pull and push to it from other systems. I need to create an empty repository, push to it from somewhere, and then I can pull and push from anywhere.
I suspect what you need to do is adjust things slightly, so you can do what you want.
e.g. you can create a bare respository on somewhere. Then you can check out a working tree on the same system. This working tree can push/pull to the bare repository as much as you want. Furthermore you can checkout this bare respository on remote systems.
and don't forget 'git stash' - no fuss/no drama stashing away of any local changes & revert to HEAD. Then run git pull, and then merge your stashed crap. As a sysadmin who dabbles in programming and also writes documentation and other stuff with either markdown or latex, I love git. I used to use rcs, then cvs, then subversion. Now I use git pretty much exclusively. i've still got some fondness for the simplicity of rcs, but always hated cvs and to a lesser extent, svn - by design, a not-quite-as-awful cvs. IMO & IME for someone who's NOT a full-time developer so doesn't use it every day, git is easier to work with and much harder to fuck-up completely than cvs or even svn. By most accounts that's even more true for those who DO work with it every day. for most stuff I do, i'm using git as a glorified massively over-capable rcs clone with remote push/pull/fork capability (with "remote" mostly meaning "other hosts on my LAN"), but I also use several of its other features, especially when working with other people's code. There's probably less than 5% of what git's capable of that I know really well, but I've been using it long enough now that I'm confident that I can figure out anything else I need to do with it. and etckeeper with git is just awesomely useful. PS: I run a local gitlab ("github clone" is a semi-accurate brief description) in a docker container, and some of my stuff (dlocate and fakecloud) has two origins, so I can push to either or both of my local gitlab or to github. gitlab's overkill for most people (including me) but there are numerous alternatives. git itself includes git-daemon which is very basic, and there are also other options for fancy self-hosted git servers, like gitea and gogs. it's very convenient to have my own local git server with the same kind of features as github (and a few more) for personal stuff that I don't want uploaded to servers controlled by someone else.....and also so that I'm not dependant on some commercial provider and don't really have to GAF if they turn evil. Also convenient to have my own local repo to keep a clone of upstream projects. https://about.gitlab.com/ https://docs.gitea.io/en-US/ https://gogs.io/ BTW, both gitlab and gitea are packaged for debian. Running gitlab in docker is even easier, it was trivially easy to set up...i'd guess the same would be true for gitea. I would expect that for your consulting work, Russell, having git+ssh or https access to your personal git repos from client sites would be very useful. could use, e.g., a different branch for each client to track customisations of common code. craig -- craig sanders <cas@taz.net.au>
On Tue, May 08, 2018 at 06:35:33PM +1000, Russell Coker via luv-main wrote:
It seems that I have to create the master repository with "git init --bare" and then push from the slave after adding a file. Adding a file on the master is also apparently a bad idea.
This is annoying, pity git is what all the cool kids use nowadays.
Yeah, if you need a checked out workspace on the remote, the usual pattern is to use a hook to do it. We have a $GIT_DIR/hooks/post-update and something along the lines of #!/bin/sh # # An example hook script to prepare a packed repository for use over # dumb transports. # # To enable this hook, rename this file to "post-update". echo echo "* Updating devel repository *" echo cd /shared/remote/master || exit unset GIT_DIR git checkout -- . git pull --rebase origin There may be better ways (post-receive, more robust script). It was set up almost a decade ago now :-) K
participants (7)
-
Andrew Pam -
Andrew Worsley -
Brian May -
Craig Sanders -
Erik Christiansen -
Karl Billeter -
Russell Coker