elogv: accept PORTAGE_LOGDIR

[parona-source]

https://bugs.gentoo.org/901961
https://bugs.gentoo.org/668538

Unsure how to attribute this one.

(The patch is created from Ninpo,
with help from [Arfrever] and sam_)

Manually applied and tested it works.

[thesamesam]

Why no Bug: or Closes: tags?

As for attribution: Thanks-to, I suppose.

[thesamesam]

Also, @sping, please merge w/ rebase rather than merge commits (see https://www.gentoo.org/glep/glep-0066.html#id6, we broadly apply this to other repos as well). I just usually pick up PRs with pram but you can do it with normal git fetch and such too.

Thank you both for giving some love to elogv!

[hartwork]

@parona-source thanks for this! One small thing:

log_dir seems like a suboptimal variable name in this context since it's a name/key/attribute to look up, not a directory. Almost any other name is likely better. Maybe env_var or logdir_var or var_name or …? Would be great, thanks! 🙏

[parona-source]

@thesamesam @hartwork addressed everything I hope

[thesamesam]

Please switch the first bare bug link to 'Bug: https://bugs.gentoo.org/668538' (rather than just a bare link), then remove blank lines between the trailers, then lgtm

[hartwork]

@thesamesam I'm not a fan of that request. The Git history is perfectly readable with the merge requests and it's been like that for years in this repository.

It could hardly be less of a problem and it does have semantic value: The pull request scope is directly visible. This is not some 2k commits per second repository. I understand the the value of rebase merges in some Git repositires but here? I don't get why this should change now and be dictated by a policy that was made for a largily different scenario, the main ebuild repository 🤷

[thesamesam]

I'm just telling you what Gentoo normally does. I'm not dictating anything, it could well've been that you either had no preference or weren't aware. If you really prefer them, then so be it, it doesn't make any difference to me if it's a repo where you're doing all the work. You need not shrug :)

[hartwork]

@thesamesam PS: Without the merge commits I will have to re-write all commit messages to contain Signed-off-by: <me> lines also. It requires not-plain-Git tooling that would not be needed at all otherwise. For little to no value.

[thesamesam]

git am -sS, git rebase -sS

[hartwork]

git am -sS, git rebase -sS

@thesamesam I knew the amend one, -s with rebase seems to be merge strategy though? Found --signoff now, good to know, thanks!

I'm just telling you what Gentoo normally does. I'm not dictating anything

Okay, I did read "please merge w/ rebase rather than merge commits" and "we broadly apply this to other repos as well" quite wrong then, probably because of your position in Gentoo and the reference to "we", it sounded like "sping, get in order, rule 15 over here" to me. Thanks for the clarification.

, it could well've been that you either had no preference or weren't aware. If you really prefer them, then so be it, it doesn't make any difference to me if it's a repo where you're doing all the work. You need not shrug :)

Thanks.

[hartwork]

Please switch the first bare bug link to 'Bug: https://bugs.gentoo.org/668538' (rather than just a bare link), then remove blank lines between the trailers, then lgtm

@thesamesam I believe that's all done/satisfied now, let me try merge this with rebase and see if GitHub still considers it merged (I think it should)…

@parona-source thanks!

[hartwork]

[..] let me try merge this with rebase and see if GitHub still considers it merged (I think it should)…

@thesamesam the experiment failed apparently, despite e2b9632 on master GitHub does not consider this pull request merged. And git cherry agrees and does not consider the commits the same, even when both sides have the Signed-off-by line. Isn't that weird? Given…

The equivalence test is based on the diff, after removing whitespace and line numbers. git-cherry therefore detects when commits have been "copied" by means of git-cherry-pick(1), git-am(1) or git-rebase(1).

…in man git-cherry — any idea what I may be missing?

To reproduce this very case locally:

# git checkout -b one c5dab19631d0813c558404107dcdafdefc9ce944

# git checkout -b two c5dab19631d0813c558404107dcdafdefc9ce944^ && git cherry-pick c5dab19631d0813c558404107dcdafdefc9ce944

# git cherry -v one two
- 2d..temporary..bc elogv: accept PORTAGE_LOGDIR  # should be empty, no?

# git cherry -v two one
- c5..temporary..44 elogv: accept PORTAGE_LOGDIR

# git --version
git version 2.42.0

[hartwork]

(Merged at e2b9632 despite being closed)

[hartwork]

@parona-source anything more needed before elogv 0.8.3?

[parona-source]

I don't have anything particular in mind. I might look at the open feature request at some point, but I can't promise any ETA.

So its fine in my view to release.

[hartwork]

@parona-source good, thanks!