search

cristibalan / braid

Simple tool to help track vendor branches in a Git repository.
http://cristibalan.github.io/braid
MIT License
457 stars 64 forks source link

Fix `braid diff` with multiple custom arguments. #113

Closed mattmccutchen closed 2 years ago

mattmccutchen commented 2 years ago

This fixes one of the bugs I found in #105. The tests pass on my Linux and Windows systems.

This real (albeit minor) bug fix gives us an excuse to do a release. That's probably a good thing to do anyway to get the infrastructure changes in #109 and #105 out to normal users. Those changes weren't supposed to affect normal users, but if they cause an unexpected problem, it would be good to fix it soon rather than leaving it latent until the next release, which might be to fix an urgent bug.

@realityforge This seems like a good opportunity to ask: Now that you've decided I qualify as an "author" in the readme, would you be comfortable giving me the necessary privileges to do releases so that I could continue to maintain Braid if you're unavailable for any reason? I made a RubyGems account with the username "mattmccutchen" (same as on GitHub). I could do the release of this PR as "practice", or if you're worried about me messing it up, I could do a release under another gem name (e.g., mattmccutchen-braid) as practice.

realityforge commented 2 years ago

Oops - I didn't realize you didn't have access to rubygems ;-) I have invited you to the project ... I believe you should be able to log in and click accept. I am more than happy for you to do a release. All I usually do is bump the version in master, tag the version and push the gem to rubygems. I keep meaning to automate this and also to create a "release" on GitHub but I have never got around to it as it would take longer to automate than it does to do about 10 releases ;-)

mattmccutchen commented 2 years ago

I released Braid 1.1.7. Unfortunately, I made a small mistake: I built my version-bump commit (15290b6f2876ce2fc5a881d4371f6f62e0b0dd46) on top of the wrong commit ID (fbaf8a9310b40d0955b56e442918b7d25e867a84 instead of 322d8bbe19894c6f0031ec43caca94938a060e7a; that is, the tip of PR #113 instead of its merge to master), although the tree content is the same, so the published gem is fine.

How should we recover? (What would be least confusing to people?)

In any event, I should probably let you do the recovery. :slightly_frowning_face: Sorry.

realityforge commented 2 years ago

Just push the v1.1.7 tag and merge your commit to master ... and the way git works it will appear as if it was on master ;-)

mattmccutchen commented 2 years ago

Done. Yes, the v1.1.7 tag will appear in the history of master, but on a "side branch"; for example, it will not be in git log --first-parent master. So I technically deviated from the proper procedure, but it isn't likely to cause a problem for anyone unless they're specifically auditing our release procedure. I don't care that much. I expect the next real release will be coming in the next few days anyway (I have another bug fix almost done), so I don't think there's much value in doing another release right now just for the sake of having the latest release be "proper" in the meantime.

Thanks for all your help.