Re: git setup
On Fri, 2023-08-25 at 22:36 +, Russell L. Harris wrote: > If pushing from PRODUCTION is more reliable or less trouble-prone than > pulling from BACKUP, kindly explain to me, and I shall change. Another consideration is that to pull from PRODUCTION requires it to be running a service (e.g. ssh) to give BACKUP access. If PRODUCTION is something like a laptop that you use when not at home, then you may not want to have said service exposing itself on strange wifi networks. -- Tixy
Re: git setup
On Sat, Aug 26, 2023 at 08:10:20AM -0300, Eduardo M KALINOWSKI wrote: [...] > The reliability should be the same, but you cannot push to a non-bare > repository. At least not in the standard configuration, but git being git > I'm sure there's a way to override that. Actually, if the push doesn't touch the checked-out branch, you can push to a non-bare repo. Disallowing modifications in the checked-out branch kinda makes sense, too :-) Cheers -- t signature.asc Description: PGP signature
Re: git setup
On 25/08/2023 19:36, Russell L. Harris wrote: But for me, the only purpose of the backup repository is to ensure against data loss due to a catastrophic event such as drive failure on my production host. If pushing from PRODUCTION is more reliable or less trouble-prone than pulling from BACKUP, kindly explain to me, and I shall change. They're equivalent. One small advantage is that you can push directly from your working computer; to pull from the backup computer you have to ssh there first. However, pushing to a central repository is the workflow generally used when multiple people are working on a project. You may be only one using the repository, but if you follow the common procedure, it'll help if you ever find yourself working in a multi-user project. If a bare BACKUP is more reliable or less trouble-prone than a non-bare BACKUP, kindly explain to me, and I shall change. The reliability should be the same, but you cannot push to a non-bare repository. At least not in the standard configuration, but git being git I'm sure there's a way to override that. -- Parents often talk about the younger generation as if they didn't have much of anything to do with it. Eduardo M KALINOWSKI edua...@kalinowski.com.br
Re: git setup
On Fri, Aug 25, 2023 at 09:40:19PM +0100, Tixy wrote: > On Fri, 2023-08-25 at 19:47 +0200, john doe wrote: > > On 8/25/23 13:44, Tixy wrote: > > > On Fri, 2023-08-25 at 10:47 +0200, to...@tuxteam.de wrote: > > > > Yes, I think a bare remote is the way to go in this context > > > > > > You can make a repo bare by editing it's config file (.git/config) to > > > have 'bare = true' instead of 'bare = false' under the '[core]' > > > > > > > Generaly, the '.git' extension symbolises a bare repository! > > The opposite is true, the .git directory is the default location for > git's stuff in non-bare repos. I think that was a misunderstanding: the OP was saying that if the whole repository has a name ending with ".git" (e.g. "foo.git") it is a bare repo, which is, indeed a common convention. What you say is that a non-bare repo contains a subdir called ".git" containing all the git stuff whithin the working dir (and which, by the way, is almost a bare repo itself). Both are true. The OP used this strange term "extension" for the file name ending, which comes from unhappy DOS times ;-) Cheers -- t signature.asc Description: PGP signature
Re: git setup
On Fri, Aug 25, 2023 at 10:36:33PM +, Russell L. Harris wrote: > As best I understand it (and kindly correct me if I am mistaken), a > bare repository is a central repository used by a group of developers. > Each developer has his own repository, and no developer ``owns'' the > central repository. The number of developers in the group may be 1. Ownership is not relevant, really. That's just politics, and is outside of the technical discussion. Even if you "own" both the central repository and the working repository, and if you are the only developer with access to the central repository, then you're still following the same basic technical setup. > But for me, the only purpose of the backup repository is to ensure > against data loss due to a catastrophic event such as drive failure on > my production host. The basic setup that has been described is perfectly suited to this scenario. Arrange it so that when you run "git push" in your working repository, it sends your commits to the central repository. (There may be a prompt for your password or your passphrase, depending on how you've configured ssh to the remote system.) That's basically all you need to do. Everything else is just needless complexity.
Re: git setup
On Fri, Aug 25, 2023 at 09:54:02AM +0200, Loris Bennett wrote: Does a bare remote to which you simply push not already provide you with an adequate backup? One you have made a number of commits, you can just push them to the remote. I am old and my fingers sometimes strike the wrong keys. (In younger days, I was a very skilled typist.) And now and then, I manage to make an entire paragraph or more disappear. So, whether backups are manual or automated, my rule is (1) commit frequently, and (2) backup with each commit. However, I may have missed some of the intricacies of your scenario. You seemed to imply that you don't have a bare remote, which I find surprising. I also have old computers (with old drives). Moreover, I live out in the country where power interruptions are common (thus, I power a computer through a UPS). These two factors are why I wish to have a backup repository on a separate computer. --- As best I understand it (and kindly correct me if I am mistaken), a bare repository is a central repository used by a group of developers. Each developer has his own repository, and no developer ``owns'' the central repository. But for me, the only purpose of the backup repository is to ensure against data loss due to a catastrophic event such as drive failure on my production host. If pushing from PRODUCTION is more reliable or less trouble-prone than pulling from BACKUP, kindly explain to me, and I shall change. If a bare BACKUP is more reliable or less trouble-prone than a non-bare BACKUP, kindly explain to me, and I shall change. RLH
Re: git setup
On Fri, 2023-08-25 at 19:47 +0200, john doe wrote: > On 8/25/23 13:44, Tixy wrote: > > On Fri, 2023-08-25 at 10:47 +0200, to...@tuxteam.de wrote: > > > Yes, I think a bare remote is the way to go in this context > > > > You can make a repo bare by editing it's config file (.git/config) to > > have 'bare = true' instead of 'bare = false' under the '[core]' > > > > Generaly, the '.git' extension symbolises a bare repository! The opposite is true, the .git directory is the default location for git's stuff in non-bare repos. $ git init test # some output omitted Initialized empty Git repository in /home/tixy/test/.git/ $ ls -lA test total 4 drwxr-xr-x 7 tixy tixy 4096 Aug 25 21:28 .git $ cat test/.git/config [core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true For bare repos it doesn't create the .git directory... $rm -rf test $git init --bare test # some output omitted Initialized empty Git repository in /home/tixy/test/ $cat test/config [core] repositoryformatversion = 0 filemode = true bare = true -- Tixy
Re: git setup
On 8/25/23 13:44, Tixy wrote: On Fri, 2023-08-25 at 10:47 +0200, to...@tuxteam.de wrote: Yes, I think a bare remote is the way to go in this context You can make a repo bare by editing it's config file (.git/config) to have 'bare = true' instead of 'bare = false' under the '[core]' > Generaly, the '.git' extension symbolises a bare repository! -- John Doe
Re: git setup
On Fri, 2023-08-25 at 10:47 +0200, to...@tuxteam.de wrote: > Yes, I think a bare remote is the way to go in this context You can make a repo bare by editing it's config file (.git/config) to have 'bare = true' instead of 'bare = false' under the '[core]' section. I do this after copying the .git directory to my remote server when setting up a new repo. Google returns a Stack Overflow answer [1] that says you can do the same with: git config --bool core.bare true [1] https://stackoverflow.com/questions/2199897/how-to-convert-a-normal-git-repository-to-a-bare-one -- Tixy
Re: git setup
On 8/25/23 09:04, Russell L. Harris wrote: On Fri, Aug 25, 2023 at 07:24:59AM +0100, Tixy wrote: On Thu, 2023-08-24 at 22:24 +, Russell L. Harris wrote: I'm also a bit confused about doing it this way. The usual workflow with git is to 'push' to the remote repository, which is in fact what you originally asked how to do. This particular exercise is aimed at automation; the impetus was a change of hosts and a move to Debian 12. I have been opening two terminals, one on the local host and the other (via SSH) on the remote host. Whenever I think it is time to capture the state of the document I am composing, I commit to the local repository, then I pull the update into the remote repository. To me, pull seemed natural, because the remote repository was cloned from the local. But if there is a reason to push, then I shall change. Taking advantage of Git comes to mind!!! ;^) I would strongly suggest you to reconsider your approach and to spend more time getting a correct set up instead of going with what you know!!! :) If lack of time is a constrain for you, please say so and we will not spend time trying to make you go in an other direction. -- John Doe
Re: git setup
On Fri, Aug 25, 2023 at 09:54:02AM +0200, Loris Bennett wrote: [...] > Does a bare remote to which you simply push not already provide you with > an adequate backup? One you have made a number of commits, you can just > push them to the remote. Yes, I think a bare remote is the way to go in this context. Perhaps, but just perhaps, some repository manager around it (e.g. gitolite) can be convenient (that's what I do). Cheers -- t signature.asc Description: PGP signature
Re: git setup
"Russell L. Harris" writes: > On Fri, Aug 25, 2023 at 07:24:59AM +0100, Tixy wrote: >>On Thu, 2023-08-24 at 22:24 +, Russell L. Harris wrote: >>> #!/bin/bash >>> # post-commit >>> # 2023.08.24 2200gmt >>> >>> ssh backup "git pull" >>> exit 0 > >>You could omit the 'exit 0' so it returns the error code from the ssh >>command, that way you'll get some feedback from failures to backup >>which you would probably want to know about. > > Thanks; I'll do it. I have run Debian for over twenty years, but I > have much to learn. > >>I'm also a bit confused about doing it this way. The usual workflow >>with git is to 'push' to the remote repository, which is in fact what >>you originally asked how to do. > > This particular exercise is aimed at automation; the impetus was a > change of hosts and a move to Debian 12. I have been opening two > terminals, one on the local host and the other (via SSH) on the remote > host. Whenever I think it is time to capture the state of the > document I am composing, I commit to the local repository, then I pull > the update into the remote repository. > > To me, pull seemed natural, because the remote repository was cloned > from the local. But if there is a reason to push, then I shall change. > >>As others pointed out, you push with the command 'git push' which you >>could do in the hook script instead of 'ssh backup "git pull"'. But >>whatever works for you I guess. > > Sounds reasonable. > >>Note, if you ever edit commits then having an automated 'pull' or >>'push' command will fail, as by default they will only do a fast- >>forward operation. There are commandline options and config setups to >>change this. > > That's why I wrote the long description. The purpose of the system is > to make backups as effortless as possible, and to allow me to > reconsider a paragraph or a page which I deleted yesterday or last > week. Offhand, I don't know how to edit a commit, or why I would need > to. Does a bare remote to which you simply push not already provide you with an adequate backup? One you have made a number of commits, you can just push them to the remote. However, I may have missed some of the intricacies of your scenario. You seemed to imply that you don't have a bare remote, which I find surprising. Cheers, Loris -- This signature is currently under constuction.
Re: git setup
On Fri, Aug 25, 2023 at 07:24:59AM +0100, Tixy wrote: On Thu, 2023-08-24 at 22:24 +, Russell L. Harris wrote: #!/bin/bash # post-commit # 2023.08.24 2200gmt ssh backup "git pull" exit 0 You could omit the 'exit 0' so it returns the error code from the ssh command, that way you'll get some feedback from failures to backup which you would probably want to know about. Thanks; I'll do it. I have run Debian for over twenty years, but I have much to learn. I'm also a bit confused about doing it this way. The usual workflow with git is to 'push' to the remote repository, which is in fact what you originally asked how to do. This particular exercise is aimed at automation; the impetus was a change of hosts and a move to Debian 12. I have been opening two terminals, one on the local host and the other (via SSH) on the remote host. Whenever I think it is time to capture the state of the document I am composing, I commit to the local repository, then I pull the update into the remote repository. To me, pull seemed natural, because the remote repository was cloned from the local. But if there is a reason to push, then I shall change. As others pointed out, you push with the command 'git push' which you could do in the hook script instead of 'ssh backup "git pull"'. But whatever works for you I guess. Sounds reasonable. Note, if you ever edit commits then having an automated 'pull' or 'push' command will fail, as by default they will only do a fast- forward operation. There are commandline options and config setups to change this. That's why I wrote the long description. The purpose of the system is to make backups as effortless as possible, and to allow me to reconsider a paragraph or a page which I deleted yesterday or last week. Offhand, I don't know how to edit a commit, or why I would need to. RLH
Re: git setup
On Thu, 2023-08-24 at 22:24 +, Russell L. Harris wrote: > #!/bin/bash > # post-commit > # 2023.08.24 2200gmt > > ssh backup "git pull" > exit 0 > You could omit the 'exit 0' so it returns the error code from the ssh command, that way you'll get some feedback from failures to backup which you would probably want to know about. I'm also a bit confused about doing it this way. The usual workflow with git is to 'push' to the remote repository, which is in fact what you originally asked how to do. As sothers pointed out, you push with the command 'git push' which you could do in the hook script instead of 'ssh backup "git pull"'. But whatever works for you I guess. Note, if you ever edit commits then having an automated 'pull' or 'push' command will fail, as by default they will only do a fast- forward operation. There are commandline options and config setups to change this. -- Tixy
Re: git setup
On Tue, Aug 22, 2023 at 12:59:18AM -0400, Karl Vogel wrote: me% cat try #!/bin/sh export PATH=/usr/local/bin:/bin:/usr/bin ssh -q -c aes128-...@openssh.com -i $HOME/.ssh/bkup_ed25519 \ bkup "logger -t autopull git pull whatever" exit 0 I am grateful for the recommendations. The backup works as expected if I keep a terminal window open and logged via SSH into the remote host, and execute ``git pull''. But I still have not managed to get the git hook script running. I decided to document the system and to give the document a title so that it can be found by others trying to put together a similar system. Kindly suggest improvements in the title or the content. --- USE OF GIT POST-COMMIT HOOK TO AUTOMATE SSH PULL OF A GIT REPOSITORY FOR DOCUMENT BACKUP (1) This is a git system running on a pair of Debian computers (LOCAL and REMOTE) and serving a single user. All git activity involves only the MASTER branch; there is no branching or merging. Routine operations consist of COMMITS to the production repository on the local host and PULLS into the backup repository on the remote host. Passwordless SSH is used for data transfer. (2) The primary purpose of the git system is archival and backup of text documents, which are composed in LaTeX markup. As a document takes shape during composition, from time to time it is committed. A secondary purpose of the git system is to allow reference or regression to an earlier stage in the development of a particular document. (3) SSH is configured for passwordless login to the remote host by the local host. (4) The PRODUCTION repository is ``192.168.1.85:/home/rlh/git.production''. (5) The BACKUP repository is ``192.168.1.35:/home/rlh/git.backup''. (6) The backup repository was cloned (non-bare) from the production repository. The git remote was assigned the alias ``backup''. (7) A git hook script on the local host named ``post-commit'' calls SSH on the backup host to pull the latest document version from the production repository. The script, the path of which is, ``.git/hooks/post-commit'', follows. Note that the shebang line specifies ``bash'', which is appropriate for a Debian/GNU Linux system: #!/bin/bash # post-commit # 2023.08.24 2200gmt ssh backup "git pull" exit 0
Re: syncthing, rsync for git; was: git setup
On 23/08/2023 02:27, Michael Kjörling wrote: I know of rsync's shortcomings in the bidirectional-sync use case because I looked for a good while for a way to get it to do that safely, before coming across unison which being designed for that solved that problem with for all intents and purposes no fuss at all. Almost every version control system (besides legacy ones, e.g. RCS) is designed to combine changes from multiple working copies evolving in parallel. Of course, git facilities allows to synchronize multiple repositories with minimal risk to loose changes committed to any copy. The idea has been posted in this thread already, see Sven Joachim. Tue, 22 Aug 2023 17:28:40 +0200. https://lists.debian.org/msgid-search/87h6orf653@turtle.gmx.de setup an "upstream" *bare* repository that may reside on the same machine or accessed through ssh and add it using "git remote" to existing working copies (new ones created by "git clone" will have it). You may need to set tracking for existing branches. Generally you may follow guides for git hosting services, some open source projects have their own introductions for git novices. You may e.g. choose a branch per working copy to be able to combine commits from any of them. Balance of "git merge" and "git rebase" is mater of taste in respect to linear commit history. A policy for a *backup* repository may be different from an "upstream" one. Backup repositories should allow to recover after accidental force push to some old commit. Warning: "git push --mirror" does force push at least by default, use it with care. You may either fetch or push to backup repository depending on current working directory. When used properly, it is safer than general purpose synchronizing tools. A single branch may be pushed to an "upstream" or a "backup" repository without permanently adding it as a remote by specifying path to that repository git push user@host:/path/to/repository.git master I would limit usage of rsync and similar tools to rather specific cases when git repositories are involved: - copy data when you are going to decommission a disk - working copy contains untracked files having some value or temporary branches undesired in upstream and backup repositories.
Re: syncthing, rsync for git; was: git setup
On Tue, 22 Aug 2023 19:27:57 + Michael Kjörling <2695bd53d...@ewoof.net> wrote: > On 22 Aug 2023 14:33 -0400, from cele...@gmail.com (Celejar): > >> Git tends to be very rsync-friendly. > > > > I do something similar - I use syncthing to automatically keep the git > > repositories on two of my machines in sync. rsync may be better, but > > syncthing has more or less worked for me. > > I'm not really familiar with syncthing, but it looks like it and rsync > solve somewhat different problems; rsync being primarily intended to > update one location (the destination) to match another (the source), > whereas syncthing is primarily intended to update both locations such > that they match (but can be run in one-way mode if desired). > > Therefore syncthing would seem to be more analogous to unison than to > rsync. Correct. My use case is two systems both used for development (I work sometimes on a laptop and sometimes on a desktop). I understand that this is not the OP's case and the subject of the thread, and I apologize for the confusion. > I know of rsync's shortcomings in the bidirectional-sync use case > because I looked for a good while for a way to get it to do that > safely, before coming across unison which being designed for that > solved that problem with for all intents and purposes no fuss at all. -- Celejar
Re: syncthing, rsync for git; was: git setup
On 22 Aug 2023 14:33 -0400, from cele...@gmail.com (Celejar): >> Git tends to be very rsync-friendly. > > I do something similar - I use syncthing to automatically keep the git > repositories on two of my machines in sync. rsync may be better, but > syncthing has more or less worked for me. I'm not really familiar with syncthing, but it looks like it and rsync solve somewhat different problems; rsync being primarily intended to update one location (the destination) to match another (the source), whereas syncthing is primarily intended to update both locations such that they match (but can be run in one-way mode if desired). Therefore syncthing would seem to be more analogous to unison than to rsync. I know of rsync's shortcomings in the bidirectional-sync use case because I looked for a good while for a way to get it to do that safely, before coming across unison which being designed for that solved that problem with for all intents and purposes no fuss at all. -- Michael Kjörling https://michael.kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?”
Re: git setup
On Tue, 22 Aug 2023 16:31:58 +0200 wrote: > On Tue, Aug 22, 2023 at 09:16:47AM -0500, John Hasler wrote: > > Christoph writes: > > > I have almost the same setup and use local git repositories. Instead > > > of syncing them by the git tools I use rsync to update the backup from > > > time to time. This is a dumb method but it works. > > > > This is what I do as well. > > Actually... not that dumb. Git tends to be very rsync-friendly. In some > weird way, this is no coincidence. I do something similar - I use syncthing to automatically keep the git repositories on two of my machines in sync. rsync may be better, but syncthing has more or less worked for me. -- Celejar
Re: git setup
On Tue, 22 Aug 2023 09:28:00 +0200 john doe wrote: > To me you only update upstream by pushes and never by pulling! > > So my suggestion in your case would be: > - One repo to work in and to push to upstream > - One upstream bare repo This is essentially what I do. My master repo, which the OP would call BACKUP, is on a headerless machine, so I used gitolite there, and git administration is all over ssh. That gets backed up daily using amanda. I have two laptops, a desktop and a plethora of other machines. Each of those has such repos as are appropriate to that machine. All of them push to and pull from the gitolite machine. The trick is a bit of discipline: When ending a session on any machine, be sure to push it to the gitolite repo. And when starting a session, be sure to pull from the gitolite repo. That keeps things in synch. KISS: Keep It Simple, Stupid! -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
Re: git setup
On Tue, Aug 22, 2023 at 03:00:33AM +, Russell L. Harris wrote: > My needs are simple. I need two git repositories. > > The first is my work space, into which periodically I commit the > article on which I am working. > > The second repository is my backup; it resides on another machine. > Several times a day, I SSH into the backup machine and pull the > working repository. It would be nice to be able to push from WORKING > to BACKUP, eliminating the need to SSH. > > I cloned the WORKING repository from the old host, and the WORKING > repository appears to function correctly. But I do not know how to > configure the BACKUP repository. I tried the BARE option, but I am not > able to push from WORKING to BACKUP. Creating BACKUP as a bare repository, configuring it as a remote in WORKING and pushing WORKING to BACKUP whenever you want is the correct setup for your situation. If you can ssh to the backup machine it's weird that you can't push to it. What happens when you use `git push`? -- Ceppo
Re: git setup
On 2023-08-22 03:00 +, Russell L. Harris wrote: > After much searching and reading, I have not discovered how to set up > a pair of git repositories to work together. > > I write articles for publication. I typically spend anywhere from > several hours to many days on each article. It is frustrating to work > for an hour or two on a paragraph or a page and then accidentally to > erase what I have written. > > In the past, I have found git to be a very good solution. But now I > am moving to a new computer, and I an having difficulty replicating > the previous setup. > > My needs are simple. I need two git repositories. > > The first is my work space, into which periodically I commit the > article on which I am working. > > The second repository is my backup; it resides on another machine. > Several times a day, I SSH into the backup machine and pull the > working repository. It would be nice to be able to push from WORKING > to BACKUP, eliminating the need to SSH. Git supports pushing via the ssh protocol, and since you have already set up the ssh connection, the rest is rather simple. > I cloned the WORKING repository from the old host, and the WORKING > repository appears to function correctly. But I do not know how to > configure the BACKUP repository. I tried the BARE option, but I am not > able to push from WORKING to BACKUP. On the backup machine, create a bare repository: $ mkdir -p /path/to/backup-repo.git $ cd /path/to/backup-repo.git $ git init --bare Then you can push from your work machine: $ git push --all ssh://[user@]/path/to/backup-repo.git $ git push --tags ssh://[user@]/path/to/backup-repo.git where "" is the hostname of your backup machine, and "user" is your login name there (which you can usually omit). You probably also want to add the backup repository as a remote, so that you do not have to write the long URL every time you push. Cheers, Sven
Re: git setup
On Tue, Aug 22, 2023 at 09:16:47AM -0500, John Hasler wrote: > Christoph writes: > > I have almost the same setup and use local git repositories. Instead > > of syncing them by the git tools I use rsync to update the backup from > > time to time. This is a dumb method but it works. > > This is what I do as well. Actually... not that dumb. Git tends to be very rsync-friendly. In some weird way, this is no coincidence. Cheers -- t signature.asc Description: PGP signature
Re: git setup
Christoph writes: > I have almost the same setup and use local git repositories. Instead > of syncing them by the git tools I use rsync to update the backup from > time to time. This is a dumb method but it works. This is what I do as well. -- John Hasler j...@sugarbit.com Elmwood, WI USA
Re: git setup
On 8/22/23 05:00, Russell L. Harris wrote: After much searching and reading, I have not discovered how to set up a pair of git repositories to work together. This makes no sense, that is what Git is for! :) In the past, I have found git to be a very good solution. But now I am moving to a new computer, and I an having difficulty replicating the previous setup. Rethinking your set up, might not be a bad idea! My needs are simple. I need two git repositories. Basically, Git uses non-bare/mirror repository (you work in this one) and an upstream repo which will be 'bare'. The first is my work space, into which periodically I commit the article on which I am working. I'm OK so far! The second repository is my backup; it resides on another machine. Several times a day, I SSH into the backup machine and pull the working repository. To me you only update upstream by pushes and never by pulling! So my suggestion in your case would be: - One repo to work in and to push to upstream - One upstream bare repo If you want a working repo on the same box as the bare repo is located, use the file protocol to pull using a cron job for automation! HTH. -- John Doe
Re: git setup
Am Tue, Aug 22, 2023 at 03:00:33AM + schrieb Russell L. Harris: Hello Russel, I cannot answer your question directly but show what I am doing now. > After much searching and reading, I have not discovered how to set up > a pair of git repositories to work together. > > I write articles for publication. I typically spend anywhere from > several hours to many days on each article. It is frustrating to work > for an hour or two on a paragraph or a page and then accidentally to > erase what I have written. > > In the past, I have found git to be a very good solution. But now I > am moving to a new computer, and I an having difficulty replicating > the previous setup. > > My needs are simple. I need two git repositories. > > The first is my work space, into which periodically I commit the > article on which I am working. > > The second repository is my backup; it resides on another machine. > Several times a day, I SSH into the backup machine and pull the > working repository. It would be nice to be able to push from WORKING > to BACKUP, eliminating the need to SSH. I have almost the same setup and use local git repositories. Instead of syncing them by the git tools I use rsync to update the backup from time to time. This is a dumb method but it works. > I cloned the WORKING repository from the old host, and the WORKING > repository appears to function correctly. But I do not know how to > configure the BACKUP repository. I tried the BARE option, but I am not > able to push from WORKING to BACKUP. To dig that is on my todo list as well. But as an additional backup I would run the dump method in parallel, just in case I manage to screw up the git repository. Kind regards, Christoph -- Ist die Katze gesund schmeckt sie dem Hund. signature.asc Description: PGP signature
Re: git setup
On Mon, Aug 21, 2023 at 11:01:21PM -0400, Russell L. Harris wrote:
> I write articles for publication. I typically spend anywhere from
> several hours to many days on each article. It is frustrating to work
> for an hour or two on a paragraph or a page and then accidentally to
> erase what I have written.
Heard that.
> The second repository is my backup; it resides on another machine.
> Several times a day, I SSH into the backup machine and pull the
> working repository. It would be nice to be able to push from WORKING
> to BACKUP, eliminating the need to SSH.
I'd set up a post-commit hook on the production system. Have it SSH to
your backup system and do a pull automatically whenever you commit a change.
I made an example project to try it:
me% mkdir example
me% cd example
me% git init
Test file:
me% date > testing
me% git add testing
me% git commit -m 'Testing a new file"
me% git log
d5fe2ce 2023-08-22 00:09:21 -0400 vogelke - Testing a new file
Here's a test script to connect from my backup system ("bkup") and simulate
pulling my working repo. I have an SSH public/private key set up for
passwordless login:
me% cat try
#!/bin/sh
export PATH=/usr/local/bin:/bin:/usr/bin
ssh -q -c aes128-...@openssh.com -i $HOME/.ssh/bkup_ed25519 \
bkup "logger -t autopull git pull whatever"
exit 0
Here's the remote system log when I run this from the command line:
me@bkup% tail -1 /var/log/messages
Aug 22 00:24:44 bkup autopull[60592]: git pull whatever
I copied the test script ("try") to .git/hooks/post-commit and ran a commit:
me% git add try
me% date; git commit -m 'Added hook'
Tue Aug 22 00:31:27 EDT 2023
[master 42cb917] Added hook
1 file changed, 6 insertions(+)
create mode 100755 try
me% git log
42cb917 2023-08-22 00:31:27 -0400 vogelke - Added hook
d5fe2ce 2023-08-22 00:09:21 -0400 vogelke - Testing a new file
Here's the system log on the remote system showing my hook ran when the
commit was done:
me@bkup% tail -1 /var/log/messages
Aug 22 00:31:27 bkup autopull[80162]: git pull whatever
Replace the "logger ..." part of post-commit to run "git pull" or whatever.
Hope this helps.
--
Karl Vogel I don't speak for the USAF or my company
There's no kill like overkill.
--Reddit post about using .45 ACP rounds to dispose of old disk drives
git setup
After much searching and reading, I have not discovered how to set up a pair of git repositories to work together. I write articles for publication. I typically spend anywhere from several hours to many days on each article. It is frustrating to work for an hour or two on a paragraph or a page and then accidentally to erase what I have written. In the past, I have found git to be a very good solution. But now I am moving to a new computer, and I an having difficulty replicating the previous setup. My needs are simple. I need two git repositories. The first is my work space, into which periodically I commit the article on which I am working. The second repository is my backup; it resides on another machine. Several times a day, I SSH into the backup machine and pull the working repository. It would be nice to be able to push from WORKING to BACKUP, eliminating the need to SSH. I cloned the WORKING repository from the old host, and the WORKING repository appears to function correctly. But I do not know how to configure the BACKUP repository. I tried the BARE option, but I am not able to push from WORKING to BACKUP. RLH
