undefined | Better HN

0 pointsjohnisgood6y ago0 comments

I hate merges. "Merged ... into ..." is such an uninformative message! Some codebases are filled with those. I prefer seeing each individual commit messages, so... rebasing all the way for me! One problem I have with this is that the committer date of all commits become identical instead of retaining their original date aligned with the author date (which I would like to be the committer date). Is there a way to workaround this or fix it in a "non-dirty" way? It might be the case that I am doing something wrong, if so, what am I doing wrong exactly, or how should I go about it?

0 comments

8 comments · 3 top-level

Nullabillity6y ago· 3 in thread

Merge flows are vital for understanding the history after the fact. It should be trivial to make a view that just hides merge commits, if you're so allergic to them, but you can't recover them once they're gone.

For the sake of your future sanity (and your coworkers'), please stop trying to rewrite history for the sake of aesthetics. The defaults are what they are for a reason.

johnisgoodOP6y ago

It is not for the sake of aesthetics though. When I do, say, git pull remote-foo master, then it opens up my text editor with the default "Merge branch 'master' of git://.../foo into bar" commit message. How is this useful or informative? There are lots of repositories with this uninformative commit message. Yes, perhaps rebase is not the best way to go about it, but then could it just be a limitation of git? Or am I missing something? I am not sure. I am looking forward for https://pijul.org/ though, it seems to solve this issue.

Additionally, if I do the aforementioned git pull, I have no way of turning the commit message into an informative one because I have no information regarding the commits. Is there a way to actually know it beforehand to turn that message into a meaningful one? If so, how would you do it? If it is possible, should I just have a list of all the commits' message in that one merge commit? Regardless, I see lots of "Merge branch ... of ... into ..." commit messages and they are not useful to me at all. Why do you think people keep doing it?

Nullabillity6y ago

It's much more informative than not having any information about where or whether a merge happened at all, regardless of what the message is.

> Additionally, if I do the aforementioned git pull, I have no way of turning the commit message into an informative one because I have no information regarding the commits. Is there a way to actually know it beforehand to turn that message into a meaningful one?

If there are any conflicts then it will force you to stop and resolve them, which seems like a decent point to document anything that needs to be. Otherwise, you can always amend in a more relevant message afterwards.

1 more reply

jbergens6y ago

Rebasing and keeping commits makes very easy to read history, everything is in a logical order. The order may not be the exact chronological order in which is was written but that is rarely needded, the rebases guarantee that it _could_ have been written as the history shows and you can see all changes afterwards.

I have used this in projects and it worked great for the whole team for a long time. You can of course do something else which can work for you and your team.

rmgraham6y ago· 1 in thread

If you're using rebase there's the `--committer-date-is-author-date` and `--ignore-date` flags. One uses the author date for both and the other uses the commit date for both.

Without using either flag rebase should update the commit date and preserve the author date.

If by rebase you meant GitHub's rebase merge option I think you're out of luck :-/

johnisgoodOP6y ago

They might be just what I am looking for! I will check them out soon. Thank you! :)

wildpeaks6y ago· 1 in thread

One trouble we're having with rebase is that it loses our PGP signatures, so the commits don't look Verified anymore.

johnisgoodOP6y ago

Hmm, it does? I was not aware of this. I did it twice (with two independent projects) earlier and it seemed to have retained the signature for some reason. It shows "Signature made ..." and "Good signature from ..." for all the commits I made earlier. I will pay more attention to it because those signatures matter a lot to me. Thank you for pointing it out, I will keep this in mind and make sure to double check.

j / k navigate · click thread line to collapse

0 comments

8 comments · 3 top-level

Nullabillity6y ago· 3 in thread

For the sake of your future sanity (and your coworkers'), please stop trying to rewrite history for the sake of aesthetics. The defaults are what they are for a reason.

johnisgoodOP6y ago

Nullabillity6y ago

It's much more informative than not having any information about where or whether a merge happened at all, regardless of what the message is.

1 more reply

jbergens6y ago

I have used this in projects and it worked great for the whole team for a long time. You can of course do something else which can work for you and your team.

rmgraham6y ago· 1 in thread

If you're using rebase there's the `--committer-date-is-author-date` and `--ignore-date` flags. One uses the author date for both and the other uses the commit date for both.

Without using either flag rebase should update the commit date and preserve the author date.

If by rebase you meant GitHub's rebase merge option I think you're out of luck :-/

johnisgoodOP6y ago

They might be just what I am looking for! I will check them out soon. Thank you! :)

wildpeaks6y ago· 1 in thread

One trouble we're having with rebase is that it loses our PGP signatures, so the commits don't look Verified anymore.

johnisgoodOP6y ago

j / k navigate · click thread line to collapse