From: Don Zickus on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/995#note_546859655
Only if you set up a mirror is that true. And only select projects are
allowed to be mirrored. Public project and a Silver tier, I think are
the minimum requirements. Which kernel-ark
From: Herton R. Krzesinski on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/995#note_546096447
I'm ok keeping the upstream remote for now (short term solution). We can
think more and do further changes if we find a better way to handle it.
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/995#note_546051611
When you create a fork on gitlab, it should automatically keep it in
sync with the project that you sync from, which means origin/master
doesn't really go out of date any more than
From: Don Zickus on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/995#note_545998171
@hertonrk-rh - see my above answer to @jmflinuxtx. I have pondered
on/off the last few months about how to eliminate the whole 'merge-base'
selection as I don't like it and requires git
From: Herton R. Krzesinski on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/995#note_545205029
I think adding origin/master would help. But it always exists, so may be
it's not the behavior you want here, to show an error/force the
developer to setup an upstream remote or
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/995#note_545178822
@dzickusrh Our documentation has been wrong for a year. Cloning the
project to your own namespace should grab all branches, so origin/master
should still just work. origin/ should point
From: Don Zickus on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/995#note_545176162
@jmflinuxtx @hertonrk-rh - here is the problem as described in issue #35
and #32 and Prarit's MR !588, users are 'forking' the kernel-ark into
the personal space and cloning that. That is
From: Herton R. Krzesinski on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/995#note_544919319
@dzickusrh in line with Justin said, why we care about upstream or
"master" branch here, why not use origin/master since that exists
already for kernel-ark checkout?
There is
From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/995#note_544834861
Yes, for the stable branches, we don't care about master. I use
$UPSTREAM as a variable for the git --log, upstream is passed as an
argument for genspec and defined in
From: Don Zickus on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/995#note_544042283
@jmflinuxtx - this might conflict with a similar change you are making
in the stable branches?
___
kernel mailing list --
From: Don Zickus
Use upstream/master for merge-base with fallback to master
In Makefile.common there is logic that determines what the
merge-base is and is used to generate changelogs correctly.
The logic assumes a 'master' branch exists and is up to date.
However, the documentation recommends
11 matches
Mail list logo
