Re: [git-users] what is the most efficient way to mirror a repository

2023-04-16 Thread Uwe Brauer
>>> "FC" == Felipe Contreras  writes:

> On Fri, Apr 14, 2023 at 3:25 PM Uwe Brauer  wrote:
>> >  1. Clone the original repo:
>> 
>> >   git clone --mirror o...@git.code.sf.net/p/matlab-emacs/src
>> 
>> 
>> That worked as I expected (as a mercurial user)
>> I just followed the instructions of the gitlab documentation but did not
>> realize that this instructions were aimed as users you have set up their
>> own local repository but not a mirror.

> Git is a true *distributed* version control system, so everyone's
> repositories can be thought of as forks. I have many repos where my
> master branch is not the upstream master branch, it contains other
> commits, and as such it's a true fork.

> Maybe `git fork` would have been a better name for `git clone`.

Well, yes, but in the case you want to move one repository from one
server to another (and check it first locally and not let the
webinterface do the transfer), then you will need the --mirror option.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/git-users/873550z44i.fsf%40mat.ucm.es.


smime.p7s
Description: S/MIME cryptographic signature


Re: [git-users] what is the most efficient way to mirror a repository

2023-04-15 Thread Felipe Contreras
On Fri, Apr 14, 2023 at 3:25 PM Uwe Brauer  wrote:

> >  1. Clone the original repo:
>
> >   git clone --mirror o...@git.code.sf.net/p/matlab-emacs/src
>
>
> That worked as I expected (as a mercurial user)
> I just followed the instructions of the gitlab documentation but did not
> realize that this instructions were aimed as users you have set up their
> own local repository but not a mirror.

Git is a true *distributed* version control system, so everyone's
repositories can be thought of as forks. I have many repos where my
master branch is not the upstream master branch, it contains other
commits, and as such it's a true fork.

Maybe `git fork` would have been a better name for `git clone`.

Cheers.

-- 
Felipe Contreras

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/git-users/CAMP44s3OMx7JMQTY0nLr2FwLsyQ4k3-EsaXCtoeHLVYp3%3Dx0Zw%40mail.gmail.com.


Re: [git-users] what is the most efficient way to mirror a repository

2023-04-14 Thread Uwe Brauer

> On Fri, Apr 14, 2023 at 04:38:34PM +0200, Uwe Brauer wrote:

> Well, your approach is incorrect. ;-)
> A correct one is going to be quicker, too.

> As I've explained in this list in the past, _by default_ Git implements
> asymmetric approach to handling remote repositories and branches they
> contain - you might want to re-read [1] and may be the whole thread; may be
> this idea will now have greater chances to really sink in as you will be
> able to compare and contrast "normal" clone and "mirror" clone.

> OK, a quick refresher on that asynchronous nature of "normal" Git repos.
> Even if you bring to life some local repository by cloning an already existing
> one, and intend to only communicate with that "origin" repository, Git does
> not really somehow establish such one-to-one relation between these two repos.
> A branch named "foo" in your local repository is still your local "foo", and,
> say, it won't be automatically updated when you fetch from the remote, and it
> won't be deleted if it's deleted on the remote.

> If you need mirroring, you're going to use mirroring, which sets up the clone
> in a way so that local "refs" (branches and tags) are always _replaced_ by the
> changes done on the mirrored remote repo, and then in the cloned repo you add
> another remote - for your GitLab-hosted repository - also instructing Git to
> do "mirror pushes". Here's how:

>  1. Clone the original repo:

>   git clone --mirror o...@git.code.sf.net/p/matlab-emacs/src

> Note that a bare repository is created. That means, it has no work tree
> (no checked out files).

I just realized another issue (for the future):

suppose, I (and all the
other maintainers)

Then it would be sufficient to do 
mkdir .git
mv all the stuff to the .git directory 
run 

git config --local --bool core.bare false

git reset --hard

Right?

I never have really used them. 
But then still of course 
 copyright
  documentation
  fontlockhang
  hairyblocks
  mac_init
* master
  modernize
  shellcomplete
  strings
  usage1
  wisent-parser


So it might be better to clone from gitlab the repository without the
mirror option, looks cleaner.

Ok I broke my promise and did not read the thread again.

Good night

Uwe 

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/git-users/878reui41r.fsf%40mat.ucm.es.


smime.p7s
Description: S/MIME cryptographic signature


Re: [git-users] what is the most efficient way to mirror a repository

2023-04-14 Thread Uwe Brauer

> On Fri, Apr 14, 2023 at 04:38:34PM +0200, Uwe Brauer wrote:

> Well, your approach is incorrect. ;-)
> A correct one is going to be quicker, too.

> As I've explained in this list in the past, _by default_ Git implements
> asymmetric approach to handling remote repositories and branches they
> contain - you might want to re-read [1] and may be the whole thread; may be
> this idea will now have greater chances to really sink in as you will be
> able to compare and contrast "normal" clone and "mirror" clone.


You are right, I am sorry. You dedicated quite some time, but it seemed  so
overwhelming  that I just kept this bit of information in my memory:

I wrote 
,
|  git branch -a
| * main
|   remotes/origin/HEAD -> origin/main
|   remotes/origin/feature
|   remotes/origin/main
`


And you final answer was
,
| 
|   git checkout feature
`


I admit I even forgot that had an extended thread on the topic. That
your answer cannot be the last word on this issue I realized yesterday.
Suppose I have to remotes 


Like 

,
|  git branch -a
| * master
|   remotes/bitbucket/HEAD -> bitbucket/main
|   remotes/bitbucket/feature
|   remotes/bitbucket/master
`

Then 

 git checkout feature 

Can not be the answer. 

But I think it is better before you even answer, that I go over the
thread and try to sort it out for myself (as far as I can get).

Because I need to understand that structure if I want deal with
pull-requests and fork (via the command line and emacs without magit).
For sure tomorrow after some testing I will run into other problems, and
will send another message. 

>  1. Clone the original repo:

>   git clone --mirror o...@git.code.sf.net/p/matlab-emacs/src


That worked as I expected (as a mercurial user)
I just followed the instructions of the gitlab documentation but did not
realize that this instructions were aimed as users you have set up their
own local repository but not a mirror.


> Note that a bare repository is created. That means, it has no work tree
> (no checked out files).

> You can now `cd` to the resulting directory and do `git branch` (note
> the absense of "-a" or "-r") and `git tag` there to see that all the
> branches and all the tags are here.

>  2. Configure a named remote in your clone:

>   git remote add gitlab --mirror=push 
> g...@gitlab.com:kalthad/matlab-emacs.git

Thanks, I for sure would have used.


git remote add gitlab  g...@gitlab.com:kalthad/matlab-emacs.git

Without the mirror option.


Thanks again for you patience.

Regards

Uwe 
-- 
Warning: Content may be disturbing to some audiences
I strongly condemn Putin's war of aggression against the Ukraine.
I support to deliver weapons to Ukraine's military. 
I support the ban of Russia from SWIFT.
I support the EU membership of the Ukraine. 
https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/git-users/87leiui53j.fsf%40mat.ucm.es.


smime.p7s
Description: S/MIME cryptographic signature


Re: [git-users] what is the most efficient way to mirror a repository

2023-04-14 Thread Konstantin Khomoutov
On Fri, Apr 14, 2023 at 04:38:34PM +0200, Uwe Brauer wrote:

> I would like to run a test and have a mirror of 
> matlab-emacs at sourgeforge 
> 
> At gitlab.
> 
> So first step I clone the sourceforge repository
> 
>  git clone o...@git.code.sf.net/p/matlab-emacs/src
> 
> Then 
> 
> git branch -a
> 
> Shows me 
> 
> * master
>   remotes/origin/HEAD -> origin/master
>   remotes/origin/copyright
>   remotes/origin/documentation
>   remotes/origin/fontlockhang
>   remotes/origin/hairyblocks
>   remotes/origin/mac_init
>   remotes/origin/master
>   remotes/origin/modernize
>   remotes/origin/shellcomplete
>   remotes/origin/strings
>   remotes/origin/usage1
>   remotes/origin/wisent-parser
> 
> I create a repository at gitlab (private for the moment) and run 
> 
>  git remote add gitlab g...@gitlab.com:kalthad/matlab-emacs.git
> 
> and then
> 
>  git  push -u gitlab --all
> 
> However despite the option --all 
> 
> only the master branch is pushed.
> 
> Does this mean I have to checkout all the remaining remote branches, 10,
> before run git push -u gitlab --all?
> 
> Is there any quicker way?

Well, your approach is incorrect. ;-)
A correct one is going to be quicker, too.

As I've explained in this list in the past, _by default_ Git implements
asymmetric approach to handling remote repositories and branches they
contain - you might want to re-read [1] and may be the whole thread; may be
this idea will now have greater chances to really sink in as you will be
able to compare and contrast "normal" clone and "mirror" clone.

OK, a quick refresher on that asynchronous nature of "normal" Git repos.
Even if you bring to life some local repository by cloning an already existing
one, and intend to only communicate with that "origin" repository, Git does
not really somehow establish such one-to-one relation between these two repos.
A branch named "foo" in your local repository is still your local "foo", and,
say, it won't be automatically updated when you fetch from the remote, and it
won't be deleted if it's deleted on the remote.

If you need mirroring, you're going to use mirroring, which sets up the clone
in a way so that local "refs" (branches and tags) are always _replaced_ by the
changes done on the mirrored remote repo, and then in the cloned repo you add
another remote - for your GitLab-hosted repository - also instructing Git to
do "mirror pushes". Here's how:

 1. Clone the original repo:

  git clone --mirror o...@git.code.sf.net/p/matlab-emacs/src

Note that a bare repository is created. That means, it has no work tree
(no checked out files).

You can now `cd` to the resulting directory and do `git branch` (note
the absense of "-a" or "-r") and `git tag` there to see that all the
branches and all the tags are here.

 2. Configure a named remote in your clone:

  git remote add gitlab --mirror=push 
g...@gitlab.com:kalthad/matlab-emacs.git

 3. Do the initial push:

  git push gitlab

Observe everything getting pushed up.

 4. Next time, when the original repository has new stuff, you do

  cd cloned_repo
  git fetch origin
  git push gitlab

That is all. It will work because the cloning operation has set the resulting
repository up in a way so that fetches update the local refs directly - as
opposed to manipulating those so-called "remote branches", and the named
remote in the resulting repo has been set up to do "mirroring pushes".

 1. https://groups.google.com/g/git-users/c/IaH4Wlf3Ebo/m/iYffiJmpBgAJ

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/git-users/20230414152623.7wagcebgkipxamvy%40carbon.