Dutch translation

[kwoot]

Here you go. Succes!

[gitblit]

I manually merged your changes due to the complexity of the commit history in this pull request.

In general it's a good idea to create a topic branch (i.e. do not use your master). This allows you to fast-forward fetch my master onto your master and for me to cleanly grab your topic branch. The commit history here is complex because of merging with my master instead of basing your changes on my master.

Thanks for the translation updates! I've updated my dev server and assuming your browser is setup for nl it should be in Dutch: https://dev.gitblit.com

[kwoot]

Hi James,

Strangely enough I am a big fan of git (and Gitblit!)
but the whole workflow keeps being a puzzle for me.
I know how to branch, checkout/clone, push.
But what it is that rebase does or how to fast-forward fetch is still a
mystery to me.

I know you have better things to do, but if you could
give me a sequence of commands to do I will be able to do it myself next
time.

Kind regards and again, thanks for such a wonderfull piece of software!

Jeroen

op 06-03-14 20:17, James Moger schreef:

I manually merged your changes due to the complexity of the commit
history in this pull request.

In general it's a good idea to create a topic branch (i.e. do not use
your master). This allows you to fast-forward fetch my master onto
your master and for me to cleanly grab your topic branch. The commit
history here is complex because of merging with my master instead of
basing your changes on my master.

Thanks for the translation updates! I've updated my dev server and
assuming your browser is setup for nl it should be in Dutch:
https://dev.gitblit.com

—
Reply to this email directly or view it on GitHub
#150 (comment).

Jeroen Baten | EMAIL : JBATEN@I2RS.NL
____ _ __ | web : www.i2rs.nl
| )|)( | tel : +31 (0)345 - 75 26 28
|/_| __) | Molenwindsingel 46, 4105 HK, Culemborg, the Netherlands

[gitblit]

Here is the general idea to get back to a happy place right now.

1. delete your fork
2. delete your local clone
3. fork my repo again
4. clone your fork

Once you are at that step do this:

git remote add gitblit https://github.com/gitblit/gitblit.git

That will add my github repo as one of your remotes.

When you want to start on a new pull request follow this plan

git checkout master
git pull gitblit master --ff-only

That pull syntax help to ensure your have not commited to master in your repo - which in a fork is a bad idea. Think of master in your fork as mine - even though it is technically yours. :)

git checkout -b nl-update
<work magic>
git add .
git commit
git push origin nl-update

This will push your branch up to GitHub - then create your PR as usual.
Once the PR is merged, pull my master and delete your local branch.

git checkout master
git pull gitblit master
git branch -d nl-update

That is the general idea. Where things go wrong is when we are both working on the same branch and we merge things back & forth at different times. We might end up in the same place, but the pathways are different and if you create a PR from your master to mine with all those pathways, then you are asking me to pull all your merge commits into my repo too.

Summary: short-lived topic branches are good, continue to pull my master to keep up-to-date.

Git, of, course, is quite good at recursive merges so you probably could keep working & creating PRs from a master branch, but it makes people frown because it creates alot of commit noise in the repository.

Thanks again for the speedy translation!

[gitblit]

Github destroyed the formatting since I sent form email. I've edited my comment for readability.

[kwoot]

This is such a nice overview! Big thanks!

Jeroen

op 06-03-14 22:13, James Moger schreef:

Here is the general idea to get back to a happy place right now.

1. delete your fork
2. delete your local clone
3. fork my repo again
4. clone your fork

Once you are at that step do this:

git remote add gitblit [1]https://github.com/gitblit/gitblit.git

That will add my github repo as one of your remotes.

When you want to start on a new pull request follow this plan

git checkout master

git pull gitblit master --ff-only

That pull syntax help to ensure your have not commited to master in
your repo - which in a fork is a bad idea. Think of master in your
fork as mine - even though it is yours. :)

git checkout -b nl-update

git add .

git commit

git push origin nl-update

This will push your branch up to GitHub - then create your PR as usual.

Once the PR is merged, pull my master and delete your local branch.

git checkout master

git pull gitblit master

git branch -d nl-update

That is the general idea. Where things go wrong is when we are both
working on the same branch and we merge things back & forth at
different times. We might end up in the same place, but the pathways
are different and if you create a PR from your master with all those
paths, then you are asking me to pull all your different merge paths
into my repo too.

Summary: short-lived topic branches are good, continue to pull my
master to keep up-to-date.

Git, of, course, is quite good at recursive merges so you probably
could keep working & creating PRs from a master branch, but it makes
people frown because it creates alot of commit noise in the repository.

Thanks again for the speedy translation!

-J

References

1. https://github.com/gitblit/gitblit.git

—
Reply to this email directly or view it on GitHub
#150 (comment).

Jeroen Baten | EMAIL : JBATEN@I2RS.NL
____ _ __ | web : www.i2rs.nl
| )|)( | tel : +31 (0)345 - 75 26 28
|/_| __) | Molenwindsingel 46, 4105 HK, Culemborg, the Netherlands

[kwoot]

Except for the change in the original file, this workflow has helped me
enormously.
Thanks!

op 06-03-14 22:13, James Moger schreef:

Here is the general idea to get back to a happy place right now.

1. delete your fork
2. delete your local clone
3. fork my repo again
4. clone your fork

Once you are at that step do this:

git remote add gitblit [1]https://github.com/gitblit/gitblit.git

That will add my github repo as one of your remotes.

When you want to start on a new pull request follow this plan

git checkout master

git pull gitblit master --ff-only

That pull syntax help to ensure your have not commited to master in
your repo - which in a fork is a bad idea. Think of master in your
fork as mine - even though it is yours. :)

git checkout -b nl-update

git add .

git commit

git push origin nl-update

This will push your branch up to GitHub - then create your PR as usual.

Once the PR is merged, pull my master and delete your local branch.

git checkout master

git pull gitblit master

git branch -d nl-update

That is the general idea. Where things go wrong is when we are both
working on the same branch and we merge things back & forth at
different times. We might end up in the same place, but the pathways
are different and if you create a PR from your master with all those
paths, then you are asking me to pull all your different merge paths
into my repo too.

Summary: short-lived topic branches are good, continue to pull my
master to keep up-to-date.

Git, of, course, is quite good at recursive merges so you probably
could keep working & creating PRs from a master branch, but it makes
people frown because it creates alot of commit noise in the repository.

Thanks again for the speedy translation!

-J

References

1. https://github.com/gitblit/gitblit.git

—
Reply to this email directly or view it on GitHub
#150 (comment).

Jeroen Baten | EMAIL : JBATEN@I2RS.NL
____ _ __ | web : www.i2rs.nl
| )|)( | tel : +31 (0)345 - 75 26 28
|/_| __) | Molenwindsingel 46, 4105 HK, Culemborg, the Netherlands