Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

home-made Git convenience functions #35

Open
jgonggrijp opened this issue Apr 9, 2013 · 6 comments
Open

home-made Git convenience functions #35

jgonggrijp opened this issue Apr 9, 2013 · 6 comments

Comments

@jgonggrijp
Copy link
Member

Git has a friendly feature that enables you to add a new subcommand bla (just like checkout is the subcommand in git checkout) simply by putting git-bla somewhere in your PATH (for example $RED_SPIDER_ROOT/bin). We could exploit that feature to streamline some of the common branch manipulations in our project. In particular I was thinking about the following commands:

git puma ( PUll MAster) should be equivalent to

git pull upstream master

without first switching to a particular branch; one can have valid reasons to merge upstream/master into any branch and it should be harmless in nearly all cases.

git creto <name> ( CREate TOpic) should be equivalent to

git checkout master
git puma
git checkout -b <name>

In other words, a quick command for everyone who starts working on something new.

git fito <name> ( FInish TOpic) is specific for the situation after a pull request, when your topic branch has been merged into the integration branch but not yet into your local master branch. It should be equivalent to the following "chord":

git checkout master
git puma
(git branch -d <name> && git push origin master :<name>) || echo "Error: not merged."

Note that, if for historical reasons <name> happens to be master, that branch should of course be retained both on the local repo and on the public fork.

More sophistication is possible, for example git-fito could default to the current branch if no <name> is provided. In addition the commands could temporarily cd to $RED_SPIDER_ROOT to ensure that the underlying git commands are able to find the repository.

The suggested commands aren't meant to be exhaustive, one could probably think up more of them.

@lramati
Copy link

lramati commented Jun 4, 2013

I know Lleu started working on this, but I'm not so sure its relevant to the project...
Maybe it should be an optional second branch called opt-dev-tools that can be merged into your local copy, with its entire folder (maybe $RED_SPIDER_ROOT/dev/) in the .gitignore file of all the other branches. I would even venture to include everything NOT in $RED_SPIDER_ROOT/dev/ to the opt-dev-tools .gitignore so you can work on both branches simultaneously for ease, but that might be incredibly ugly/messy so I'm not sure its a good idea

@jgonggrijp
Copy link
Member Author

Well of course it's relevant, but only for the hackers. I think it's fine if we just add it into the master branch but don't list it in the user-oriented documentation (as you suggested for the command that walks over all steps necessary for integration). Stuff with parallel branches is bound to get messy.

@lramati
Copy link

lramati commented Jun 4, 2013

The reason I said it wasn't relevant is that its more of a git hack, trying
to make it easier to work with, than a useful part of the actual project to
anyone other than a dev

@lramati
Copy link

lramati commented Jun 4, 2013

I think a more interesting alternative would be to take a look at the hooks git provides in the project/.git/hooks/ directory

@JonETMeans
Copy link
Contributor

So I've been playing with the 'creto' subcommand you suggested. It is not obvious to me that creating a custom command that accepts input. What I have so far is a command that creates and checks out a new branch called "new_branch." Then the user has to rename the branch to the name he wants with "git branch -m " I don't think this is enough of a simplification to justify its existence. Thoughts?

@jgonggrijp
Copy link
Member Author

I think you're right, that certainly doesn't seem like enough of a simplification. However I'm very sure that you could create a subcommand that accepts additional arguments. Perhaps you could push the experimental code that you've written so far, so we can have a look?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants