Anders Melander

Okay. Yes, I can see that there's a git merge --squash command. So I guess SourceTree squashes commits by default because when I merge and push I only get one new commit in the history of the target. The only reference to "squash" that I've come across in SourceTree is in the Interactive Rebase dialog (which I don't understand enough to dare use).

I meant the function doesn't need it to be zero terminated (it has the length already).

So how do you deal with mapped drives, mounted volumes, symbolic links, junctions and hard links?

Squash? But that's a rebase thing, right? So how can you squash without rebase? Anyway. Let's say I have my 'master' commit history: 1. Initial commit 2. Made some changes 3. Fixed some changes At commit #2 I branch 'master' into 'FooBar' and make "a few" commits to that branch: 1. Experimental stuff 2. Enhancements ... 999. Refactorings 1000. Updated easter egg Now I merge my 1000 commit branch into master (resolve conflicts etc): 4. Merge branch 'FooBar' into 'master' And push. So the now 'master' commit history will read: 1. Initial commit 2. Made some changes 3. Fixed some changes 4. Merge branch 'FooBar' into 'master' Are you saying that you'd want the whole 1000 'FooBar' commits to appear in the 'master' commit history? I can see that if you don't have 'FooBar' pushed to the remote then the history will be lost, in which case it makes sense, but if you have pushed it, then there's no need to duplicate that history in 'master'.

You didn't answer any of the questions.

I'm not sure I agree with it. As I read it, and I may well be misunderstanding it, it assumes that when I merge my 1000 commit feature branch into master that I want all 1000 commits to appear in the master commit history. Well I definitely don't. The 1000 commits are the sausages being made and I only want the finished sausage in the master commit history. There's also this: What it should have said is: never rebase a public branch. It's perfectly safe and normal to rebase a private branch on a public branch. Assuming on=onto. Maybe that's what he meant.

Well I meant without opening the file. Of course Windows itself is able to determine if two local files are the same. If opening the file is OK then, yes GetFileInformationByHandle will get the job done. There are also other API functions that can be used if opening the file is okay. For example the undocumented NtQueryObject API can be used to get the logical filename of just about anything (e.g. C:\Windows -> \Device\HarddiskVolume1\Windows). The PIDL solution definitely won't work. PIDLs live in the shell namespace and you need to go much lower than that to determine identity.

There's no need to state the obvious. While the function may behave as designed, it's at the very least poorly documented. I looked at both the documentation and the implementation before I came to the conclusion that there was a bug. I'm fine with the implementation staying the way it is (to avoid breaking existing code) but it should be documented that the array is assumed to be zero terminated. Actually since the array doesn't need to be zero terminated (we know the length of the "string" already from the array) I can't see why the zero termination couldn't be made optional. Either way: fix the documentation.

Ah. I didn't check the source. I just assumed the documentation was correct. Silly me

\\?\UNC\ isn't an extension of \\?\ https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file#win32-file-namespaces This means that if the path starts with \\?\ then what ever follows is beyond what ExtractFileDrive was meant to handle. It could attempt to just strip the \\?\ part and retry but it I think it would be reasonable to give up and just return an empty string. Good luck with that. It isn't even possible to determine if two fully qualified paths refer to the same file.

Yes but each element is an UCS4Char (which is 4 bytes), so the string (it's an array actually) size is 9 * SizeOf(UCS4Char).

Yes it does: function UCS4StringToWideString(const S: UCS4String): _WideStr; var I: Integer; CharCount: Integer; begin SetLength(Result, Length(S) * 2 - 1); //Maximum possible number of characters CharCount := 0; I := 0; while I < Length(S) - 1 do begin if S[I] >= $10000 then begin Inc(CharCount); Result[CharCount] := WideChar((((S[I] - $00010000) shr 10) and $000003FF) or $D800); Inc(CharCount); Result[CharCount] := WideChar(((S[I] - $00010000) and $000003FF)or $DC00); end else begin Inc(CharCount); Result[CharCount] := WideChar(S[I]); end; Inc(I); end; SetLength(Result, CharCount); end; The bug is the Length(s)-1 in the while condition (or the < instead of <=). The first SetLength also seems strange. And can't see why it should do a -1 there.

No. Seems like it's gone. Strange.

One could argue that it's equally meaningless to use ExtractFileDrive on that path since whatever comes after the "\\?\" is handled directly by the file system and not by the file namespace parser. I guess the correct thing to do would be to return an empty string as documented: I do not agree with your suggestion that it should attempt to extract anything if the string starts with "\\?\" (or \\.\ for that matter). The result would be meaningless in the context.

I'd say that if you have records that size then the iterator is not the problem you should be focusing on

I think you might be confusing UTF-8 and Unicode because your example is using unicode strings and not UTF-8 strings. If what you have is in fact unicode and you just want to remove non-printable characters then you can use the TCharacter class: for var i := Length(s)-1 downto 1 do if (not TCharacter.IsValid(s[i])) or (TCharacter.IsControl(s[i])) then Delete(s, i, 1);

Why would calculating a pointer cause a cache miss?

Sure. For personal projects I rarely use branches at all. It's only when I start on something that I'm not sure I will end up using in the end (e.g. experiments) or some feature that will take so long to implement that I don't want it interfering with whatever else I'm working on) that I use branches. But even for personal projects it's good to be able to go back in time to find out what what you did that broke something. Sometime you can even use the commit message to clear up why some piece of code is there in case you forgot to document it properly with comments in the code. You could say that the individual code comments document the tactic while the commit message document the strategy. Of course it would be best if the code comments did both but we're not all super humans.

You should examine the diff of your changes before you commit them instead of just committing all files that has changed. Practices differ but for example when I have made a change to a form I only commit that specific change - and directly derived changes. All the Explicit* and Original* fluff that the IDE changes are left out. Also adding a file to a project usually result in 40-50 changes (relating to platforms I haven't even installed) of which only one or two need to be committed.

We also do all work in feature branches but our branches are always pushed to remote (and for this reason alone we almost never rebase). We need to have the branches on the remote for several reasons; There are mostly more than one person working on a feature and they need to have access to each others changes. Of course it's up to the individual if they want to create local branches of the feature branches and do their work in those. Personally I just stash and only push when I have something that I know will build. We also to have the branches on the remote in order to have the build server run unit- and integration tests on them. Finally when work on a feature branch is complete we create a pull request to have it merged into the main branch. When QA have tested the build, which they've grabbed from the builder server, someone performs code review on the changes and only then is the PR allowed to be merged into the main branch.

Yeah, that one is one of the more stupid things I've encountered. But what does it have to do with the naming?

I don't think you can push unless you're on the tip of a branch. Your changes would overwrite the changes made between your current commit and the remote tip. I guess the remote could do an automatic merge but would that then be made in a new commit or would it alter the commit you made? Doesn't seem likely.

What problem is that supposed to solve?

1 bit, 2 bit, 3 bit, 4 4 bit, 3 bit, 2 bit, 1 You're bit, he's bit, no bit, none - Eminem

I think maybe she used a 3 bit computer and the "7 days" legend is just the result of the actual count overflowing. Anyway. I was referring to an actual entity, not an imaginary one.