search

Fossy-Cats / Git-Buch_EN

English translation of "Das Git-Buch" (The Git Book)
https://git.io/gitbook
Other
1 stars 0 forks source link

Comment out the remaining German texts #27

Closed SicroAtGit closed 3 years ago

SicroAtGit commented 3 years ago

There were still a few places where the German text was not commented out.

tajmone commented 3 years ago

Thanks!

At this stage, you should just submit the commits yourself, either directly via Git or, if you prefer, create a PR and submit it yourself (in case you wish to be able to unroll it via the GH WebUI, if the need be). Before working on any new changes, I always fetch to check if you committed anything, so the chances of conflicts are rather slim.

Furthermore, when contributions starts to come in, I think you should be in charge of approving PRs, since you're the native German speaker and can verify that the translation matches the original text. For more complex contributions (affecting the toolchain, ADoc formatting issues, etc.) we can review them together.

In any case, when (if) contributions start to flow in, we could enforce PR review policies, especially for merging into master where we could require review approval by both, etc.

tajmone commented 3 years ago

Deleting Branches after Merging

I'm not sure whether I should have deleted the branch after merging, but I left it there since you could have selected the auto-deletion option and thought that if you didn't it was because you might want to keep it for a while.

I think there's also another old PR branch left.

SicroAtGit commented 3 years ago

At this stage, you should just submit the commits yourself

Ok, the next changes I commit directly to the branch beta-dev.

I think you should be in charge of approving PRs, since you're the native German speaker [...] For more complex contributions [...] we can review them together.

Yes, is good.

Deleting Branches after Merging

As far as I know, there is no option during PR creation to have the branch automatically deleted. After the merge, only a delete button appears in the PR to delete the branch afterwards.

However, you can set a checkbox in the repository settings to ensure that PR branches are automatically deleted: Managing the automatic deletion of branches It would be good if you could activate this.

tajmone commented 3 years ago

As far as I know, there is no option during PR creation to have the branch automatically deleted.

I thought I've seen this as a new feature when creating PRs, but I might be wrong (or confusing it with GitLab).

However, you can set a checkbox in the repository settings

I know that, but I prefer not to.

It would be good if you could activate this.

I'm not sure about it. If the branch is from a collaborator (i.e. on the repository) then it might be a long standing branch, whereas if its from a contributor than the branch is on his/her repository, so it's up to him/her to decide.

What would be the benefits of enabling it?

I usually delete old PRs branches after a while, both locally on GitHub, and sometimes immediately delete the branch on GitHub if its not long-standing. Doing it on the WebUI has the advantage that makes it easier to restore after deletion, whereas if you delete them or prune them via Git you have to use the RefLog to restore them.

In any case, if you can access the repository settings feel free to enable this, although I'm not sure you can (it would require a Team to allow multiple owners).

SicroAtGit commented 3 years ago

What would be the benefits of enabling it?

More automation. I always delete my PR branches after the merge. But you are right, some may want to continue using their branch after the merge. Alternatively, you could enable it and if someone complains about it, disable it again. No data is lost, because I assume that in this case also the branch in the PR can be restored.

Doing it on the WebUI has the advantage that makes it easier to restore after deletion, whereas if you delete them or prune them via Git you have to use the RefLog to restore them.

If you use Git to delete the PR branch, you can also restore the branch in the PR later.

In any case, if you can access the repository settings feel free to enable this, although I'm not sure you can (it would require a Team to allow multiple owners).

Yes, I do not have access to the repository settings.

tajmone commented 3 years ago

If you use Git to delete the PR branch, you can also restore the branch in the PR later.

Are you 100% sure about this? Once I deleted by mistake a branch on GitHub via SM, and didn't have a local copy of it (it was a new orphan branch for a GHPages website), and didn't manage to restore it via the WebUI. But maybe that was because it was an orphan branch? Luckily its creator had still a copy of it, so we managed to restore it.

Yes, I do not have access to the repository settings.

That's why in the early stages I proposed to crate a Team, so we could both share same privileges on the common repositories. I'm not sure if it's too late now, since we'd have to transfer the repository to the Team account. Maybe the old URL would be just redirected to the new one, but I'm not 100% sure.

What I'm sure about is that we can't change the Git.io Posh URL, but we can hope that redirection will work for that too, and that it's going to be permanent. IRC, redirection doesn't work for GHPages websites, I once transferred a repository that had a website to another account and lost the Posh URL that I had created.

For the ALAN project we've created a Team so that we can all have full access to our repositories settings, which means that if there's an emergency any developer can access all options, and that when we need to enable features we don't have to wait for an owner to do so.

Should we create the Team at this point? My only concern is losing the Git.io short URL, for we were lucky enough that no one had taken https://git.io/git-book already (quite a cool domain I'd say).

SicroAtGit commented 3 years ago

Are you 100% sure about this?

Yes, in this repository I deleted some PR branches with SM and I still see a restore button when I look at the PRs.

But maybe that was because it was an orphan branch?

Yesterday I created a test repository on GitHub to test also PRs to orphaned branches and also in this case there is a restore button.

Maybe there were problems in the past.

That's why in the early stages I proposed to crate a Team

Yes, I can remember. We haven't come up with a good name for the organization yet, and because I assumed we wouldn't be creating repositories that both require full access rights, it's been a low priority on my to-do list until now.

I'll think about an organization name again today and email you then.

Maybe the old URL would be just redirected to the new one, but I'm not 100% sure.

What's transferred with a repository? All links to the previous repository location are automatically redirected to the new location. When you use git clone, git fetch, or git push on a transferred repository, these commands will redirect to the new repository location or URL.

IRC, redirection doesn't work for GHPages websites, I once transferred a repository that had a website to another account and lost the Posh URL that I had created.

What's transferred with a repository? If the transferred repository contains a GitHub Pages site, then links to the Git repository on the Web and through Git activity are redirected. However, we don't redirect GitHub Pages associated with the repository.

My only concern is losing the Git.io short URL

I suspect that will happen, sorry.

I read here that you can tell Git.io a desired short name (see: specify your own code). Maybe gitbook, git~book or _gitbook is still free.