Note to self:

for /f "tokens=*" %i in ('git branch --format="%(refname:short)" ^| findstr /C:"feature/"') do @echo git branch -m "%i" "old/%i"

Then remove @echo to make it "really happen".

(That adds old/ to the front of anything that starts with feature/.)

Labels: cmd, git, noteToSelf

Note to self: To look through your git history to find files by name (and to have the files edited in each commit listed)...

git log --all --name-only -- "**/*Base*"

Though note that it's case sensitive, and not because I used a capital B. It's always case sensitive. Looks like there are weird workaround depending on your git version, like not including a glob for filename and piping EVERYTHING to grep to figure out or using git's really unwieldy pathspec.

Labels: git, noteToSelf

Okay, I've had this open in drafts too long. I think it's got most of the info I wanted, so let's cut it loose for when I need it in the future.

I often take a different laptop with me when I'm travelling than whatever the "prime" development box is for a project, often to ensure I don't lose sensitive information if the laptop "disappears" while I'm out. When doing this, I usually copy the folder I'm working in, remotes (so personal access tokens, VPN setup, etc) be darned, and work from that.

The issue is often getting that work back onto the "prime" boxen. That usually means remembering how to make and apply git patches.

Look, here's the deal... ;)

If you want to copy over and preserve individual commits, you want to use "email" formatted patches. You can envision why. If you came before the time when everyone had shared remotes or if your workforce is distributed and most simply don't have remote access, it's easy to schlep around code via email. And so git has email support built-int! Though do note we're only using the format, as it carefully preserves each commit separately; we're not actually emailing anything. Unless you really want to.

On the travelling box:

Let's say I wanted the last 5 commits. I'd use this command to create an email-formatted patch file:

git format-patch -k --stdout HEAD~5 > patch.patch

Open up the text file and take a look! It's actually kinda interesting, begging for an SMTP server to send it on its way.

On the "prime" development box:

git am -3 patch.patch

Now look, if you used git apply here, it would apply EVERYTHING IN THE FILE AS A SINGLE ACTION and not commit anything. It's like rolling all the changes into a single worksession that needs to be committed. Using git apply for an email versioned patch reduces to the same operation as creating a diff with git diff and git applying it.

We DON'T want that. You have to use git am to get the email action going.

The -3 is for three-way merge if there's a conflict git can't resolve, and is the way I (and several other StackOverflow users, apparently) best prefer to manage conflicting patch applications. But you really shouldn't run into that much if you just worked on an existing branch.

Do make sure you're on the right branches on both boxes.

TODO: How do you get the patch to include staged files?

Labels: git, noteToSelf

On Windows, I have two tools that get a lot of work when I'm ready to check in files:

1. Merge tool: KDiff3 -- since 2012, it appears.
   
2. Diff tool: WinMerge -- more recently; used to use KDiff3 for both
   

The WinMerge usage is recent-ish. When you want to compare two files and two files only, its simplistic UI is refreshing compared to the busyness of KDiff3.

One problem: KDiff3 uses KDE and is available pretty much everywhere. WinMerge is, um, Windows specific.

When I'm on macOS, I've been using BBEdit (nee TextWrangler) in place of WinMerge more recently and, I've found, you can use BBEdit as your official diff tool in SourceTree now too with a dedicated dropdown option.

One problem: SourceTree puts the more recent file on the left in BBEdit for some reason. That's not how SourceTree does it with WinMerge.

How do I swap that? Funny you should ask... Just ran into this SourceTree help request today that happens to show exactly how...

I spoke to BBEdit about this and they reminded me of the solution I had (with their help) implemented previously, before SourceTree added BBEdit to the official part of the external diff menu. I pass it along here, in case it is helpful:

in the "Diff Command" field, it needs the full path to bbdiff, e.g.

/usr/local/bin/bbdiff

I had been just putting "bbdiff" and that may have been the full problem I was having. In the "Arguments" field I put "--ignore-spaces --wait $REMOTE $LOCAL" and that seems to work well.

That still puts the newer edit on the left, but that's easy to fix. Swap $REMOTE and $LOCAL and...

Success. That's a nice, usable working environment I've almost got on macOS. 😉

Labels: BBEdit, git, macOS