Bug 265630
| Summary: | Push rejected after merge | ||
|---|---|---|---|
| Product: | Services | Reporter: | Mikhail T. <freebsd-2024> |
| Component: | Git Integration | Assignee: | Git Admin <git-admin> |
| Status: | Closed FIXED | ||
| Severity: | Affects Some People | CC: | emaste, imp, lwhsu |
| Priority: | --- | ||
| Version: | unspecified | ||
| Hardware: | Any | ||
| OS: | Any | ||
|
Description
Mikhail T.
2022-08-04 17:43:42 UTC
Presumably your `git pull` has resulted in a merge, which we don't want. You probably need to `git rebase freebsd/main` (You can use `git pull --rebase` as mentioned in the committer's guide, or set git config to rebase by default.) > Presumably your `git pull` has resulted in a merge Yes. > which we don't want No idea, why... If we're discussing "wants" -- I want Subversion... > git rebase freebsd/main fatal: invalid upstream 'freebsd/main' Please, advise. (In reply to Mikhail T. from comment #2) "freebsd" is the remote name as documented in the git primer / committer's guide, it may be "origin" instead if you haven't followed those steps (In reply to Ed Maste from comment #3) I just did "git rebase" (without arguments) and it worked. "git push" succeeded after that. Now, is all this really necessary to push a one-line port-update? Issue resolved per submitter Thanks for the link, but it does not answer my question -- it talks about /how/, rather than /why/. I can see some benefit in formalizing the first line(s) of all commit-messages. I don't see, why "rebase" must be mandatory to push a change, though. Yes, it could be automatic, but why does it matter at all? The commit-message does not change... Is it because the hook-script API is not good enough to check the commit-messages? You closed this ticket after providing the workaround. But the "nonsense" is still there -- there is no fix... (In reply to Mikhail T. from comment #7) >Thanks for the link, but it does not answer my question -- it talks about /how/, >rather than /why/. With a linear history you have well defined bisection and other desirable properties, so we enforce that on src, ports and docs. Merges like the one you tried to push add little to no value to the repo, and often are the cause of other problems. History in other projects have also shown they are also a frequent source of accidental 'silent' reverting of changes. So they are not allowed to make it easier for all developers and users using the repo. > Merges like the one you tried to push add little to no value to the repo,
> and often are the cause of other problems.
I see, thanks... Perhaps, an advice to do "git rebase" should be output then -- instead of the cryptic "ACCESS DENIED" error I got?
Merge commits are disallowed for now (except for vendor branches) so that we have a linear history. It looks like the message from the hook could be more clear about the reason for failure though and I've mentioned this PR to lwhsu to take a look (In reply to Mikhail T. from comment #7) I am sorry that those inconvenience you encountered. The "rebase" is a recommended practice because it keeps the history linear, just like what we have in Subversion. The "merge commit" isn't really helpful in our current workflow because it makes browsing the whole history "tree" complex and debugging with "bisect" difficult. I would recommend that setting pull.rebase as "true": git config --global pull.rebase true and even branch.autosetuprebase as "always", so you can have something like `svn up`. (I even have an alias: git config --global alias.up "pull --autostash") The only thing not svn is if there is any part of the tree gets updated between your update and push, you need to pull (and rebase if it doesn't be done automatically) because in git the "push" is syncing the commits from local to remote, not let remote to decide everything so this atomic operation is needed. If you check the commit hash, it has changed after rebase because the relationship of the parent and child has been changed, more specifically, the parent of your commit has been changed. (In reply to Mikhail T. from comment #9) Thanks for the suggestion and I will try to squeeze time to work on it. Currently we're using gitolite as the git server to take care of our official repositories. (Because git only provides the mechanisms and it needs other tool to customize the needs.) "Deny merging commit" is a built-in option because it is a common requirement in many setups so we just enable it when setting up the git infrastructure. The other things like committer line or commit message checker are done through the hooks we wrote so we can provide more meaningful messages. I will check how to implement this feature with a customized hook. |
