Fix code snippet in the CHANGELOG.rst file on master

[Elliria]

AutoKey is a Xorg application and will not function in a Wayland session. Do you use Xorg (X11) or Wayland?

Xorg

Has this issue already been reported?

• I have searched through the existing issues.

Is this a question rather than an issue?

• This is not a question.

What type of issue is this?

None

Choose one or more terms that describe this issue:

• autokey triggers
• autokey-gtk
• autokey-qt
• beta
• bug
• critical
• development
• documentation
• enhancement
• installation/configuration
• phrase expansion
• scripting
• technical debt
• user interface

Other terms that describe this issue if not provided above:

No response

Which Linux distribution did you use?

No response

Which AutoKey GUI did you use?

None

Which AutoKey version did you use?

No response

How did you install AutoKey?

No response

Can you briefly describe the issue?

The python3 setup.py test code snippet is missing its closing backtick in line 113 of the CHANGELOG.rst file on the master branch. Note that this has been fixed on the beta and develop branches already.

Can the issue be reproduced?

Always

What are the steps to reproduce the issue?

No response

What should have happened?

The snippet should have had a closing backtick.

What actually happened?

The closing backtick is missing.

Do you have screenshots?

No response

Can you provide the output of the AutoKey command?

No response

Anything else?

No response

[sebastiansam55]

I'm not sure that a separate commit is the way to approach this, the idea of git is that you can pull those changes from the other branch into the develop branch.

I think having multiple commits doing the same thing across different branches is just going to cause conflicts when they eventually get merged no?

[Elliria]

The CHANGELOG.rst files aren't identical on our three main branches, so you can't go copying one over onto another branch and must handle changes to them individually. Also, for the heck of it, I just now went through the git history to try to find the commits in which that change was made to those two branches and wasn't able to find it. You're welcome to look for it and give me the commit number if the change was made at a time when the files were identical and if there's a way to cherry-pick or rebase or merge (or something) that commit over at that point in time without interfering with the current differences in the files (I'm thinking an interactive rebase could be used for that, but I'm not sure and would welcome advice).

Also, long story short (or TLDR), it doesn't seem to make a difference whether you cherry-pick commits or make manual commits. In the end, you're always making more commits and there will be "duplicates" either way when branches later get merged (see below). The good news is that there won't be conflicts as a result of duplicating identical content since that's stored only once by git.

Since you had brought this topic up before, I had stopped doing changes that need to be done on more than one branch while I tried looking into it. I first asked in here on multiple occasions inside of discussions and issues. I then asked in Gitter. I didn't get information that I could use to make decisions with from any of those attempts. I did a bunch of searches online, but got wildly differing information all over the place, so I turned to the GitHub channel on IRC on multiple occasions and tried to get help with it, but nobody responded. Ever. I seriously think that that channel is a void or a black hole. If you have any secrets you've been carrying around that you'd like to unburden yourself of, that seems like the perfect place in which to do so. It then finally occurred to me to try the git channel on IRC. I asked this question and immediately got this response:

Question: If I have two identical branches and I add a file to branch1 and commit the change, is there any difference in the end result between cherry-picking that commit onto branch2 vs manually making the same change on branch2 and committing it? In both cases, I end up with two new commits and the identical file, right?

Answer: Yes, in either case, you'll have two different commits and one file (an identical file will always only be stored once).

That caused a lively conversation in which they provided me with all kinds of solid resources to use. That caused me to go down a huge rabbit-hole afterwards and learn what I could about the details. It's possible I may not be properly understanding the information or that I was given unreliable information. Please look over my notes from that journey below and let me know if any of it is incorrect or needs more research or if anything is missing that should be there. I'm trying to put together as solid of a framework as possible so that I always know where the walls of my box are and I always appreciate any help I can get.

My notes on commits and cherry-picking:

• Commits reference not only files, but also their metadata.
• Each commit contains various metadata:
  • author
  • author timestamp
  • committer
  • committer-timestamp
  • commit message
  • tree
  • parent
• git cherry-pick does not copy a commit. Instead, it creates a new commit that applies the same set of file changes.
• git cherry-pick creates a new commit that reuses the original author, author timestamp, and commit message.
• Manually committing creates a new commit with fresh metadata (you could, however, choose to use the exact same commit message if you like and if you're the same author, the same author will be used).
• When cherry-picking commits from a source branch into a target branch, the source branch will remain untouched, but you may get conflicts on the target branch.
• The author and author time-stamp are not important for conflict-resolution. They're just for information purposes. All merge conflict-resolution uses the structure of the history for figuring out which changes to use (i.e. where are the merge commits, what lines of history do they combine, etc.).
• Although merging will often work just fine (as it compares the current state vs shared ancestor), when cherry-picking commits, you're effectively duplicating commits. This means that if you ever decide to merge a branch that you've cherry-picked things into back to where you cherry-picked them from, you'll end up with duplicate commits in your history (although the same thing would happen if you had committed the same changes manually). While the content of the commits (as in files) may be the same, the commit objects (as in metadata) differ, so if, for example, develop is merged back into master, the history will have both the orignal and the cherry-picked commits, which can lead to confusion (and which is no different from manual commits that change the same file in the same way) if unexpected.

[josephj11]

I'm not sure that a separate commit is the way to approach this, the idea of git is that you can pull those changes from the other branch into the develop branch.

I think having multiple commits doing the same thing across different branches is just going to cause conflicts when they eventually get merged no?

We are painfully aware of the problems, but do not understand how to fix it yet.