drjdpowell

TortoiseGit is an interesting middle way between command line and a "full-featured" UI tool, as it mostly just replaces text commands with menu selections, and it can be configured to show the basic few commands (with a submenu for less-used commands): Then on top of commands is the "log", which is a visual representation of the repo.

Tried GitKraken a bit. Couldn't see enough improvement over SourceTree to consider a paid product (but I may be missing something). If I were going command line, I would first look into Gitless, and attempt by Computer Scientists to fix the flaws of Git. There is a paper on it here: Purposes, Concepts, Misfits, and a Redesign of Git.

The task manager should work, though like Neil I also find it displays too much, and have a more specialised tool built into my "Messenger Library" framework:

If only there was a > git fast-forward <new branch> One step, and no scary "-force" or "delete" involved.

Just for info: my recipe to fix a "detached head" is (using SourceTree) Create a temporary branch on the detached head commit (I prefer to name it "GitIsStupid") "Checkout" the real branch it should be on (usually) "Merge" the temporary branch into the current branch (no actual code merge occurs, so this is non-intuitive to me) Delete the now-unneeded temporary branch Git: making the easy things hard, and the hard things possible.

You are trying to create your ini file adjacent to your vi; in your exe that path is inside your exe, which cannot have files created in it. You need to have your ini file in a different place.

Unfortunately, the SQLite DLL uses bare pointers, rather than safe refnum references, and is not protected against using a pointer after the thing pointed to has been released. If I were doing the library again, I would use a DVR to prevent calling functions on a dead pointer.

I am hoping that the need to branch the submodule repo will be a big improvement on the current situation. Needing to make an explicit commit/branch in the submodule will give the developer a point to think if they really meant to change something in the common component. If they do, they will be making a commit message describing that change. And I, if I'm the prime developer for that submodule) will notice this commit by another developer and can go and talk to them and deal with the issue (I will follow an aggressive merge-branch-quickly policy in common components).

In our case it's the opposite problem; shipping code for a test station that has not been tested for that station. We have multiple stations, that cannot all be tested at the same time, so changes to a shared component, made in developing one station type, should only be pulled into another type explicitly, not be a general "update all" thing. Admittedly, I would much rather update common components asap, and I'm hoping splitting the common components into submodules will allow most to be pulled often. Currently, the different stations get branched, with all shared components, which is a me

My problem with the "Attachment" feature is that is difficult to come up with an intuitive API. Just look quick example using a couple of Future Tokens to do one request-reply, with attached info. Way too complicated, with four bits of info in the reply message (envelope label, attachment, inner message label, and inner message data). This needs simplifying to be more than a niche feature.

Can you show me how you use "Add Attachment"? It's tricky to document its use, as I only use it as part of "Use Outer Envelope", and also because "Object Message" does double duty as "Outer Envelope" (as a Message is an object, then Object Message, when containing another Message, is acting like an outer envelope about that inner message).

It's badly documented, but it appears to be there for me, but in the "UseOuterEnvelopeLabel" vi (see below). This is because that is where I envision it being useful, with a requestor attaching something to the reply. But you may be using the "Add Attachment" vi, directly. This is still on disk, just not in the palettes. I will add it back into the palettes (issue 5).

That's what I mean. You'll fix that problem, but a junior programmer will not know what to do, and just carry on, possibly losing commits if the problem isn't seen in a month.

The problem I had is that submodules are connected to a specific commit, rather than branch, so when one checks them out originally one must remember to manually create a branch, else if you commit changes they are a "detached head", which is then fixable, but a pain. I find Git to be very much "'Oh, you should have used the "engage safety" and "don't_point_at_foot" options when you called the "git new_gun" command'.

Who uses Git Submodules? I know Greg Payne does and have watched his talk, but does anyone else have experience. I'm especially interested in experience with projects with multiple developers and multiple products (that might need to use different versions of the subprojects).