|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
ttomecek commented 3 years ago | ||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
jpopelka commented 3 years ago The same as Tomas's comment above - I'd explicitly state that this means source-git, because it took me quite a while to realize that distribution != dist-git | ||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
ttomecek commented 3 years ago I'd say that having a branch for (every) upstream release is crucial here and that's how teams already work who use source-git style of work. Just wondering what customization we want to enable because I presume the naming and branch hygiene would differ between projects. I'd personally vote to make the naming completely up to users while providing best practices: basically enabling people to shoot themselves in their feet while giving them manual how not to do that :) | ||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
zbyszek commented 3 years ago
| ||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
zbyszek commented 3 years ago
That seems very wrong. "History rewriting" is generally only OK when it stays in a local repo, Then there's the problem that people who are not git experts (i.e. most people) tend Instead, a solution that preserves history should be found. git switch f34 git merge --strategy=theirs f34-0000001-2.23.4.g1233 -m 'Update to 2.23.4.g1233' i.e. we generate a commit where the contents are taken exactly from their branch, Sadly, there is https://blog.holisticon.de/2021/03/git-merge-strategy-theirs/ suggests the following: our=f34 their=f34-0000001-2.23.4.g1233 version=2.23.4.g1233 git checkout $our COMMIT_ID=$(git commit-tree -p HEAD -p $their -m "Update to $version" $their^{tree}) git merge --ff-only $COMMIT_ID Maybe we could convince git folks to add With this, you can look at history and it is meaningful: $ git diff HEAD~ '**.spec' and so on. Once that's in place, the whole procedure with accepting force-pushes when (conditions) | ||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
There are still many things to figure out, but I'll just put it up here for visibility.
I'd appreciate if 1, 2 and 3 explicitly stated the operations are happening in the source-git repository which may not be obvious to casual reader.