>>> "KK" == Konstantin Khomoutov <kos...@bswap.ru> writes:
> On Thu, Oct 07, 2021 at 05:51:02PM +0200, Uwe Brauer wrote:
> [...]
>>> What command are you currently using to push "all main branches" or had you
>>> also implicitly asked how to do that?
>> No, I thought either
>>
>> git push
>>
>> Or
>>
>> git push --all
>>
>> Does this
>>
>>> The full form of the `git push` command is
>>
>>> $ git push <remote> <refspec> [<refspec> ...]
> [...]
>> > $ git push origin 'refs/heads/pub/*:refs/heads/*'
> [...]
>>> The inconvenience is that you need to remember to create your local branches
>>> using that convention (and rename current branches - which is easy to do by
>>> using the `git branch -M` command).
>> I admit I am confused: I thought I should use the same name as in
>> remote, so master should be master and not pub_master
>>
>> Most likely there is something fundamental I don't understand.
> I think it's just your mindset: to assume the names of the branches should
> match is a thought which comes naturally, I would admit. But in reality Git
> maintans a rather asymmetrical model when it comes to communicating with
> remote repositories, and this requires certain getting into. I'll try to put
> things into som perspective for you.
> First, in this age and time we're really accustomed to the workflow when you
> clone some centrally-hosted repository and start pushing your work to it and
> fetching the work done by others from it. Moreover, when it comes to creating
> a repository for brand new object, people sort of automatically reach for one
> or another Git hosting solution - it could be Github, Bitbucket etc for F/OSS
> or private projects or, say, an on-premises corporate GitLab instance - to
> first create an empty (or pre-populated from some template) repository
> through the UI offerred by that solution, and that repository is - again -
> subsequently cloned locally by those who intend to work on the project. In
> other words, typically you end up cloning some repo in any case, and this
> instills some warped mindset which makes you think that there is always some
> main, reference, blueprint, master repository everyone sends their work to -
> just like there was at the times of centralized VCS systems such as
> Subversion, VSS etc.
Well this of course is true, I noted that with collaborators of me having this
problem. However, as I have to admit, I am a regular mercurial user, which is a
distributed VC as well and in some sense with an orthogonal approach towards
implementation
(for example git log shows the current branch, and git log --all shows all
branches, while hg log shows all branches and hg log -b certain branches etc
etc).
However as things are I have to pull and push to git repositories from time to
time, which I usually do with the hg-git plugin, however as good as the plugin
is, it has its limitation, for example
merging (git allows you to merge branches explicitly with the non-fast-forward
option, which I prefer) of course hg itself has this feature but the hg-git
plugin, still, does not convert that well, and that is why that from time to
time I have to use git itself.
Now almost all the features you describe below work in mercurial, I mean having
configured pull and push to a bunch of different repositories, however,
although I do this, I am extremely cautious with such operation since it easily
can mess up things.
> But this is not really the case. Any Git repository is completely
> self-sufficient (modulo some advanced black-magic facilities such as
[Snip]...
> OK, so all this brings us to the model implemented by Git, and it has the
> following properties:
> * Your local branches are truly yours, they are never updated automatically >
> when you fetch from remote repositories. > Your local repository is
> completely free-standing and self-sufficient.
> * If you have named remotes - such as that well-known "origin", - fetching
> from such remote will automatically create and maintain so-called "remote
> branches" (the terminology is not too good, I know) which are "namespaced" to
> separate them from your local branches.
> This makes it possible to properly manage such branches - for instance,
> "master" fetched from "origin" ends up being remotes/origin/master in your
> local repo and "master" fetched from "joes" becomes remotes/joes/master. Note
> that this still have nothing to do with your local branch "master".
> * Only you decide what local branches you update with which data fetched
> from the remotes, and which local branches you push to which remote branches.
> Git sometimes helps you with setting such relations in a sensible way - for
> instance, when you `git clone` a repository, a configuration entry is added
> to the clone making plain `git clone origin` force-update all the remoteer
> branches tracking that remote repository in your local repo. But this setting
> can be removed or changed at will.
> So all this leads us to what I have described in my first mail to this
> thread: you can name your local branches in any way you see fit. This will
> rob you of certain shorthands such as
> $ git push origin HEAD
Thanks again for this very detailed answer, I am not sure, whether I dare to do
this, I mean use this «advanced» features I am not sure I really understand, so
maybe what I do is the following.
1. I git clone the repository,
2. I hg clone (with the hg-git pluging) that repository and push locally
(using the phase concept of mercurial) to the git repository the branches I
wish, do the sophisticated merging or anything else there and push then with
git to the repository.
Regards
Uwe Brauer
--
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/87o87ymzvq.fsf%40mat.ucm.es.
smime.p7s
Description: S/MIME cryptographic signature
