31–40 of 136 posts
This looks like it would be a nightmare for working with other developers. Other developer: "I did 'git sprout foo' and made my changes then 'git publish foo'. But now I'm not sure why the foo branch isn't on the public repo." Me: "????"
This looks like it would be a nightmare for working with other developers. Other developer: "I did 'git sprout foo' and made my changes then 'git publish foo'. But now I'm not sure why the foo branch isn't on the public repo." Me: "????"
I think having shortcuts and wrappers like the above is fine if you have a good understanding of the underlying data structure you're manipulating. You're only going to run into problems if you treat these commands as magic and just hope they work.
I strongly disagree with the purpose of this. It still has precisely the same problem that regular git has: you need to understand the language behind it. Just learn regular Git rather than re-inventing the language.
I think the only two commands from this I like are `git sprout newbranch` and `git unpublish branch`. But only because I think `git checkout -b newbranch` and `git push origin :branch` are stupid syntaxes for doing what they do.
From the git man pages [0]
> git push origin master:refs/heads/experimental Create the branch experimental in the origin repository by copying the current master branch. This form is only needed to create a new branch or tag in the remote repository when the local name and the remote name are different; otherwise, the ref name on its own will work.
So, a direct substitution of `git push origin :experimental` says
Create the branch :experimental in the origin repository by copying no branch
Earlier quoted context omitted.
I disagree. A lingua franca is important. If these are indeed common operations, then it's important that everyone talking about, say, `git sprout` means exactly the same thing.
"A lingua franca is important" Exactly! And that lingua franca already exists. This is only useful if you would like a new syntax for personal use and you're too lazy to or don't want to use 'git alias'.
Well, the lingua franca that "already exists" is the standard git syntax.
This syntax pains some people. Now, to alleviate the pain they could either use each their own aliases OR they could share a common new "lingua franca" of aliases.
That's what this project does.
In other words, what you're saying is:
1) a lingua franca is important 2) so use standard git, which is a lingua franca, or have your own personal aliases.
This just doesn't follow.
If a lingua franca is important, then, FOR THE SUBSET OF PEOPLE THAT DON'T LIKE GIT SYNTAX, to have a common alias lingua franca is also important.
It doesn't matter that it's less of a "lingua franca" that standard git-alese, because it is still a lingua franca for that subset, and solves the problem they have with the more established lingua franca.
It seems that git is the new regex. People are actively building things around instead of learning the rules. I suppose that came from writing being easier than reading.
The mathematical principles underneath are good, but the standard regex syntax is arcane and values brevity over readability, modifiability, etc.