Lukas Fleischer 於 西元2015年07月23日 16:13 寫道:

On Thu, 23 Jul 2015 at 09:45:46, Ting-Wei Lan wrote:

...

I forgot 'git push --force' was no longer allowed in AUR4. I forgot to include .SRCINFO changes in the last commit, and I can no longer do 'git subtree push' to fix it because the pushed commit was rebased. I cannot use 'git reflog' and 'git reset' to go back to the old commit because I have pushed changes to other packages after rebasing. It seems the only way to fix it myself is doing 'git subtree pull', but it will cause the history become very ugly. [...]

I haven't used Git subtrees a lot but can't you simply rewrite the history of your "super repository" (e.g. using `git rebase -i`) and drop the latest `git subtree pull` import of the package base, then add a fixup commit that adds the .SRCINFO and run `git subtree pull` once again?

The first 'git subtree pull' creates a very ugly merge commit that causes every mingw-w64-gtk3 changes to be showed twice in my 'super repository'.

Eli Schwartz 於 西元2015年07月23日 22:05 寫道:

On Thu, Jul 23, 2015 at 3:45 AM, Ting-Wei Lan <lantw44@gmail.com> wrote:

...

I forgot 'git push --force' was no longer allowed in AUR4. I forgot to include .SRCINFO changes in the last commit, and I can no longer do 'git subtree push' to fix it because the pushed commit was rebased. I cannot use 'git reflog' and 'git reset' to go back to the old commit because I have pushed changes to other packages after rebasing. It seems the only way to fix it myself is doing 'git subtree pull', but it will cause the history become very ugly.

Can I file a request to remove a commit for mingw-w64-gtk3 package? I cannot find this type of request on AUR4 webpage, but I hope this can be accepted.

I'm not sure if this would work, but what about using filter-branch to restore the rebased commit to its original state? The sha1 checksums for the later commits would change in the master repo, but as long as the content and dates and stuff for the *individual* commits remains constant, I think the subtree push will recreate the same history. Then simply continue from the HEAD with a new commit to update the .SRCINFO. You will have to make sure the rebased commit has the same author/committer *dates* as well as removing the .SRCINFO (I assume that is what you rebased).

Thanks! After I change the date of the rebased commit, 'git subtree push' succeeds.

I suggest you steal some of my infrastructure, though. See: https://github.com/eli-schwartz/pkgbuilds for an example of pre-commit and prepare-commit-msg hooks that do the heavy lifting for you. Automatically generating .SRCINFO on its own is VERY much worth it -- I don't even have to bother remembering they exist!

Yes, I think I should add a pre-commit hook to prevent this problem from happening again.

-- Eli Schwartz

Eli Schwartz 於 西元2015年07月23日 23:47 寫道:

On Thu, Jul 23, 2015 at 11:31 AM, Ting-Wei Lan <lantw44@gmail.com> wrote:

Thanks! After I change the date of the rebased commit, 'git subtree push'

...

succeeds.

It seems we share a hatred of merge commits. :D Glad to hear you were able to fix the problem without resorting to one.

Yes, I don't like non-needed merge commits, especially a merge commit that really merges nothing.

Yes, I think I should add a pre-commit hook to prevent this problem from

...

happening again.

That was the first thing I did -- before committing a single package.

I use your pre-commit hook now and it is great. ;-)

But again -- while you are at it, you might want to also use a hook to preformat the commit message. And I have a script that accepts the name of a directory/package and pushes it to the AUR, no need to manual type out `git subtree push -P some-package aur@aur4.archlinux.org:some-package.git master` The only bit that ever changes is the "some-package".

I usually use my bash_history to save typing here -- I keep all commands I typed since the system was installed in bash_history.

I just use `./aurpublish some-package/` and even let bash-completion do most of that! :D It also handles pulling, in case you ever need that -- and one day you might... package adoption comes to mind.

-- Eli Schwartz