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.
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
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,
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
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
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.
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
> >
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]'
>
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
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
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
"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
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
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
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
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
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
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
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
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
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.
>
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
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
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
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
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
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
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
28 matches
Mail list logo
