a2disconf, a2dismod, a2dissite, a2enconf, a2enmod, a2ensite, a2query, apache2ctl : add French translation

[patricedenis]

• The page (if new), does not already exist in the repo.
• The page is in the correct platform directory (common/, linux/, etc.)
• The page has 8 or fewer examples.
• The PR title conforms to the recommended templates.
• The page follows the content guidelines.
• The page description includes a link to documentation or a homepage (if applicable).

[bl-ue]

Beautiful. @patricedenis yours are really good PRs!! ❤️

[bl-ue]

@sbrl / @waldyrious which would work better for this PR: rebase or squash?

[waldyrious]

Rebase is only appropriate if the commits are cleaned up to be atomic and descriptive. As they are currently, it's better to squash since there are various fix-type commits, but it's up to @patricedenis if he prefers to clean them up.

We might want to edit the guidelines in case this isn't clear.

[patricedenis]

@waldyrious : for my information : is it possible to merge several commits into single ones even when then have already be commited?
And also, what is the difference between rebase and squash?

[marchersimon]

@patricedenis as far as I know, that's exactly what squash does. Rebase on the other hand merges every single commit into master.

[waldyrious]

for my information : is it possible to merge several commits into single ones even when then have already be commited?
And also, what is the difference between rebase and squash?

@patricedenis I'm glad you asked! 🤓

So, in git, commits are immutable, which includes not only their contents, but also their metadata such as the author, message, and location in the commit graph — i.e. who their parent is. This last point means that they can't be moved around, and in general they can't be edited, combined, etc. Branches, however, can be freely moved around to point to different commits, which allows you to create the effect of "editing", "replacing" or "combining" commits. The way this works is, say you have a branch starting from master, with 3 commits:

  * commit B3 ← your-branch
  * commit B2
  * commit B1
 /
* commit M3 ← master
* commit M2
* commit M1

First off, let's see what a rebase is. As the name hints, a rebase is the act of "transplanting" a branch onto a different base. You could for example rebase your-branch into commit M2 instead of the tip of master, commit M3. You can use git's rebase command, which takes as arguments the target base, and optionally the branch to be rebased:

git rebase M2 your-branch

And the result is this:

* commit M3 ← master
| * commit B3' ← your-branch
| * commit B2'
| * commit B1'
|/
* commit M2
* commit M1

Notice how the commits are now named B1', B2' and B3'. That's because they are copies of the original (immutable) commits, which are still around, but invisible because no branch is pointing at them.

Now imagine you want to do something fancier, such as removing commit B2 from your branch. You can use an "interactive rebase" to do this. An interactive rebase allows you to interactively decide what to do with each commit of the branch, rather than copying them all automatically to the target location.

Among the things you can do in an interactive rebase are removing commits, rewording their messages, combining various commits into one (this is what's called squashing!), etc.

Another interesting point in the rebase operation is that you can keep the same base; that, in effect, allows you to "edit" the commits in-place.

With that in mind, let's go back to the example of removing B2 from the branch. Here's what you do:

git rebase --interactive master your-branch

(Note how you keep the same target location —master— as where the branch currently is.)

At this point, git will open a text editor (typically vim, if you haven't configured it otherwise) with text like this:

pick B1 Commit message for B1
pick B2 Commit message for B1
pick B3 Commit message for B1

Underneath this text there will be instructions about what you can do. In this case, dropping a commit can be done by changing the word "pick" next to it to say "drop" instead. So make that edit to the file, save it and exit the editor. Git will automatically apply your instructions, resulting in this graph:

Before	After
* commit B3 ← your-branch * commit B2 * commit B1 / * commit M3 ← master * commit M2 * commit M1	* commit B3' ← your-branch * commit B1 / * commit M3 ← master * commit M2 * commit M1

An interesting to notice is that B1 didn't change, because neither its contents, nor its metadata (message, author, date, parent commit, etc.) changed; B3, however, needed to be changed to have B1 as its parent, rather than B2; so git made a copy of it, B3'.

---

So, these are the basics of a git rebase, and we briefly looked at what squashing is as well. This allows us to tackle what they mean in the context of merging a PR on GitHub:

• a rebase-type merge will transplant all the commits of the branch into the latest commit on the master branch (which may or may not be the same base from which the PR branch was created from — for example if other PRs were merged into master in the meantime)
• a squash-type merge will do the equivalent of an interactive rebase where all the "pick" lines were changed to "squash", so we'll end up with a single commit with all the changes of the PR.

If we want something fancier, the PR author needs to make an interactive rebase on their local clone of the repository, and decide which commits to reword, combine, drop, etc.; once this is done, they can push the changes, overwriting the existing commits in the PR branch, with a force-push, which should looks like this: git push --force origin master. Then we can merge the PR using the "rebase" option, thus preserving all the individual (cleaned-up) commits that the author crafted manually.

I highly recommend that you watch the excellent video Git For Ages 4 And Up, and also play with the interactive tutorial at https://learngitbranching.js.org. These two resources will provide you with an intuitive basis from which to learn the rest of git's amazing complexity.

[patricedenis]

whaou ! @waldyrious thank you so much for this didactic and very much detailed content.
I see that I need to dive more into it because I want to understand it more.

So as I understood, I have a chance to a try this process of merging my commits myself and then try to construct a PR that will need no edits from managers.

Please let me try this one before merging.
I think it's a good exercise for me to learn more about the arcane of git and this way I will improve my knowledge and practice for future PRs.

Again thank you very much for your feedback !!

[waldyrious]

Please let me try this one before merging.

Of course! Just to be clear, when you force-push to this PR's branch (apache2-commands-french-tranlation), the PR will be automatically updated, so there's no need to create a new PR (in case that's what you meant by "construct a PR").

Also, a good tip to keep in mind when doing this sort of history rewriting with git is to take note of the commit at the top of the branch before you make any changes (in this case, it's the latest commit in this PR, 57eab88b). That way you can always restore the original branch if something goes wrong. The good thing about git commits being immutable is precisely that once you commit a change, it's actually very hard to lose it — even though the commit may disappear from sight, as long as you have its hash, you'll be able to recover it. 😉

[sbrl]

Tip: To interactively rewrite the history of the current branch, you probably want to use git rebase -i earliest_commit_hash_to_modify

[waldyrious]

@sbrl just a nitpick, but the first argument to git rebase is the new base, not the first commit of the branch to be rebased — so IIUC, it should be the parent of the earliest commit one wants to modify, right? Like this: git rebase -i earliest_commit_hash_to_modify~1

[patricedenis]

OK, I imported an ssh key to github.com so I will now be able to work from CLI, as I did not see where from the Web GUI I would be able to use the requested commands.

I will then now pull my tldr's fork locally so I can work on these commits.
If I do well, I could then push them to my branch on github.com and that will automatically update the PR.
Have I understand well enough?

[waldyrious]

That's exactly right @patricedenis 👍

[patricedenis]

Ok I think I've managed to do it.
Please let me know if I missed something.
That was not easy but I learned much !
@waldyrious

[bl-ue]

Looks good to me! Merger: please rebase.

[waldyrious]

Looks great, @patricedenis! Congrats on your newly gained knowledge ;) 💪

Maybe next time we can cover how to split a commit during an interactive rebase (e.g. the link change part of 52f0413 would make more sense as part of 717af47). But the overall branch is looking great already, so I'll go ahead and merge.

Also, for the future you might want to set your local git configuration to use an email address matching the one of your GitHub account, so that the commits don't appear to be authored/committed by two different people with the same name:

[bl-ue]

Nice to see you merging PRs again @waldyrious ;). but it would've been even nicer to see a green "waldyrious approved these changes" :D

[waldyrious]

Nice to see you merging PRs again @waldyrious ;)

Don't take it for granted! 😅

but it would've been even nicer to see a green "waldyrious approved these changes" :D

Hahaha I thought about that, but since there were 2 approvals already, and I expressed my approval in my comment, I felt it wasn't needed :) But sure, why not? Next time I'll do it regardless.

[patricedenis]

@waldyrious My mistake for #52f0413 as I melt it myself using fixup during the interactive rebase.
Also I did not notice my login name was different but it won't be anymore hopefully as I fixed it up in the .gitconfig file for the local repo.

Again thank you all for the time and the explanations @bl-ue @sbrl @waldyrious @marchersimon !
🥰