AUR web interface

Tasklist

FS#45065 - [AUR 4.0] Unable to keep git history on package rename

Attached to Project: AUR web interface
Opened by Doug Newgard (Scimmia) - Sunday, 24 May 2015, 01:27 GMT
Last edited by Lukas Fleischer (lfleischer) - Monday, 08 June 2015, 12:51 GMT
Task Type Bug Report
Category PKGBUILD Parser
Status Closed
Assigned To No-one
Architecture All
Severity Medium
Priority Normal
Reported Version 3.5.0
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No

Details

The git hook that reads the .SRCINFO file from all commits will fail if the pkgbase in one of them is different than the one that is currently at HEAD. This makes it extremely difficult to keep your commit history when renaming a package. Why does this hook care about anything other than HEAD, anyway?
This task depends upon

Closed by  Lukas Fleischer (lfleischer)
Monday, 08 June 2015, 12:51 GMT
Reason for closing:  Fixed
Additional comments about closing:  Fixed in 4.0.0-rc1.
Comment by Janis König (LeonardK) - Monday, 08 June 2015, 09:19 GMT
Additionally, when you have a "development" repo like me on GitHub and do things there in a rush, you might forget to push an .install-file declared in the PKGBUILD. But even if you fix this in a later commit, the current AUR4 parses the whole history no allowing such a mistake in the commit history.
Comment by Lukas Fleischer (lfleischer) - Monday, 08 June 2015, 10:52 GMT
Yes, we check the whole history, not just HEAD, for consistency. Only package base name of HEAD needs to match the repository name, though. If you broke anything in a previous commit, please use `git rebase -i` or a similar command to fix it before pushing.
Comment by Janis König (LeonardK) - Monday, 08 June 2015, 11:00 GMT
Hm, I find that in a way like abusing git^^
Rebasing is nice, but not to "change the history", imho.
Comment by Lukas Fleischer (lfleischer) - Monday, 08 June 2015, 11:09 GMT
Why? You never change history of anything that is published already. `git rebase -i` is actually very often used to rewrite history before merging a commit into mainline, e.g. during the development process of Git itself or the Linux kernel.
Comment by Janis König (LeonardK) - Monday, 08 June 2015, 11:20 GMT
Then I do not know what you mean on how I should fix this with git rebase -i. I mean, when you check the whole history – how should I fix a problem back in history by not changing the history itself?
Comment by Lukas Fleischer (lfleischer) - Monday, 08 June 2015, 11:30 GMT
You *should* change the history. I was just explaining why using `git rebase -i` to edit history *before* pushing to the main repository is not "abusing git".
Comment by Janis König (LeonardK) - Monday, 08 June 2015, 11:37 GMT
Yep, but I'm using a public (development) repo which's published commits I would then change. But I think I just go the way you described, the other repo doesn't matter that much. – I just don't see the point in "for consistency".
Thanks for the clarification on why you do this anyway ;-)

Loading...