Implement some missing string functions

[th-otto]

No description provided.

[mikrosk]

Are you sure you have intended to base it on all of that PR merges and unrelated commits? A PR should be as small as possible, ideally rebased against master. If it's based on some other PR (for a good reason), noting something like "please merge PR #XY first" is enough.

Among others, there's commit 143c212 which was explicitly rejected by @atic-atac in #15

[th-otto]

On Montag, 16. Oktober 2017 00:12:39 CEST Miro Kropacek wrote: Are you sure you have intended to base it on all of that PR merges and unrelated commits?

Not really, but it looks like it worked out this way. That strange list of commits appears because i merged my own local PR branches into master, for those that were already merged upstream.

Among others, there's commit 143c212 which was explicitly rejected by @atic- atac in #15

Yes, i know. Actually, only the last 2 commits should been part of that PR. Any idea how to fix that now?

[mikrosk]

What I do before applying any PR is that I switch to master, pull, create a branch and start committing. For another PR I basically repeat the same process.

If/when I screw up, it's still very similar -- usually the mistake is to have master --> some branch --> maybe some other branch --> my code. So the most dumb-proof solution is just to switch to master, create something like branch_name_new, cherry pick given commits, switch to branch_name and reset its tip to branch_name_new's tip and force push. That way the PR gets fixed without anyone knowing. ;-)

[th-otto]

On Montag, 16. Oktober 2017 00:52:32 CEST Miro Kropacek wrote: If/when I screw up, it's still very similar -- usually the mistake is to have master --> some branch --> maybe some other branch --> my code. So the most dumb-proof solution is just to switch to master, create something like branch_name_new, cherry pick given commits, switch to branch_name and reset its tip to branch_name_new and force push. That way the PR gets fixed without anyone knowing. ;-)

Thats sounds complicated, and also not very transparent ;) And you can only do a forced push as long as nobody else has already pulled the new objects. In our case, the PR applies cleanly, although some of the referenced commits have already been merged into master. I think that is just because git sees the same commit ids in both master and this PR. So only problem is how to get rid of those commits as part of this PRs, otherwise its not very obvious what is new and what not.

[mikrosk]

And you can only do a forced push as long as nobody else has already pulled the new objects.

But that doesn't matter -- it's your PR, your branch, your code. You can rebase it ten times and will be still OK because the reviewer get the look on your latest changes, not the mess which led there.

So only problem is how to get rid of those commits as part of this PRs, otherwise its not very obvious what is new and what not.

See above, feel free to rewrite your branch's history, totally fine.

[th-otto]

Hmpf. That did not work. Now the commits are empty. New try.

[th-otto]

Ok, that looks better ;)

[mikrosk]

But still not there. :) For instance the PR-4 merge commit drags in the time zone stuff again. What do you want to have is a history in your PR-stringfuncs branch like this:

b9040d2
1de0b34
3a0a845 (master's tip)

Nothing else (unless there's a good reason to base it on some other PR).

[th-otto]

hm but i now have only
b9040d2
1de0b34
on that branch:

git rev-list --left-right master...PR-stringfuncs

b9040d2
1de0b34

[mikrosk]

... and did you push it? ;)

[th-otto]

$git status
Your branch is up-to-date with 'origin/PR-stringfuncs'.