Closed deivid-rodriguez closed 4 years ago
In theory, is it possible to break someone's "flow" by this change? If so, did that "flow" worked just by accident? It probably heavily relies on each local setup.
Anyway this change seems reasonable :+1: .
I can't image any "flow" that this change would break... :thinking:. I thought of a potential scenario where git
is only made available to the user (put in the PATH) by the .bashrc
file or something. But, our gem helpers already run many other git
commands without spawning new shells, so nothing would really work in that case.
@bundlerbot merge
What was the end-user problem that led to this PR?
The problem was that I almost went crazy when trying to release the last bundler version.
rake release
was hanging and I didn't know why.What was your diagnosis of the problem?
Thanks to passing
DEBUG=true
to the task, I noticed that it wasgit push
andgit push --tags
commands that were hanging:The debugging output is very interesting because it also tells us that these commands are the only ones passing Strings to
IO.popen
instead of Arrays. That means these commands are spawning a new shell.That's when I realized that I have hub installed on my system and
git
aliased to it. So I figure this aliasing was interacting with the subcommand in a bad way.Indeed, disabling
hub
fixed the issue and let me make the release.What is your fix for the problem, implemented in this PR?
I think we can avoid other issues similar to this for people pushing releases by not spawing a shell here, just like we do with all of the other commands.
I think it's a good practice anyways.
Why did you choose this fix out of the possible options?
I chose this fix because I think it makes the code better. Of course I can disable
hub
every time I release, but I think this is worth doing.