3
\$\begingroup\$

After having a good experience with virtualenvwrapper built on top of the venv, I thought maybe it could be benefitial to have similar shortcuts for standard activities with git which could be time saving as opposite to typing many commands.

I've given it a try like the following:

Start session (sync current repository with origin, create a session branch for the to-be merge request):

#!/bin/bash

set -ex
DATE=$(date +%F)
git fetch --all --prune
git pull
git branch "$USER-$DATE"
git checkout "$USER-$DATE"

Close session and integrate results to origin:

#!/bin/bash

set -ex

DATE=$(date +%F)
DEFAULT_BRANCH = "main"

git add . --all
git commit -m "$1"
git push -o merge_request.create -o merge_request.target=$DEFAULT_BRANCH origin "$USER-$DATE"
git checkout $DEFAULT_BRANCH
git branch -d "$USER-$DATE"

This works.. more or less, but it would be great to sort out some concerns I have got, general and specific.

  • In general, maybe there is something I am missing therefore fixing details is waste of time because then I will discover some fundamental blocker, or maybe it's a common problem already solved (maybe in this, or other way)
  • Specifically, there is some bash scripting yet to do which I could though sort out in separately, but maybe this is not all, therefore I try to review these details myself first.

So the issues with the code are, from what I see:

  • It's random whether the default branch is called "main" either "master". So the script needs to detect/decide that somehow.
  • The merge request branch name could be derived from repository name
  • Not sure what could be a proper error handling to enable for defined states
  • Is it matter of taste, or reasonable decision to put these scripts as separate files under ~/bin, either integrate as functions to something bigger, and call through command line parameters? Then I will have possibly to look on Bash tabbing as well.

Thanks for reading and looking forward to your feedback!

\$\endgroup\$
1
  • \$\begingroup\$ Regarding the main vs. master branch, you could (A) see which branch exists in the repo but you might have to choose one if both are there or (B) use a config file in the repo to say which main branch is /the/ main branch. \$\endgroup\$ Commented Nov 18, 2021 at 17:35

1 Answer 1

Reset to default
3
\$\begingroup\$

Addressing your main concerns

In general, maybe there is something I am missing therefore fixing details is waste of time [...]

Actually I'm wondering if there's something that I am missing about the intended context of these scripts.

My typical workflow with Git goes something like this:

  • I create a feature branch following the pattern features/username/very-brief-summary. The benefits of the pattern:
    • My collaborators and I can easily find my branches
    • My collaborators and I can guess what a branch might be about without looking further
  • I make several commits, one per logical step, before creating a merge request

This is not compatible with the workflow suggested by the posted code:

  • The date in branch names doesn't look very useful, and will be little help to find relevant branches
  • The commit + create merge request combo might inadvertently include something in the merge request that I might have wanted to keep local, uncommitted

As such, I couldn't use these scripts. I assume you have some specific workflow in mind where these scripts would be useful.

It's random whether the default branch is called "main" either "master". So the script needs to detect/decide that somehow.

Something you could do is save the name of the current branch in a file before switching to a new branch.

Not sure what could be a proper error handling to enable for defined states

You have set -e and I think that's good. When something fails, the script will exit immediately. That's good, so the user can see the relevant error message and the script doesn't just carry on, leaving to confusion about states. There are also no obvious error modes here that could be caught and handled automatically by the script. So I think this is fine.

Is it matter of taste, or reasonable decision to put these scripts as separate files under ~/bin, either integrate as functions to something bigger, and call through command line parameters?

I think the answer to that depends on what is practical for your intended target users.

  • As scripts, it's very easy to drop them in any directory that's on PATH.
  • As functions, you would have to copy paste into a file that is sourced by their shell, typically .bashrc. This seems less convenient.
  • As Git aliases defined in .gitconfig, you would have to copy paste, similar to Bash functions. This has the advantage of being Git specific, not polluting the namespace in the shell.

Creating a merge request easily

I find the part of creating a merge request useful, I would keep just that command in a script, with a small improvement:

targetBranch=${1:-main}
git push -o merge_request.create -o merge_request.target="$targetBranch" origin HEAD

That is:

  • take the target branch as an optional parameter, with "main" as the default when omitted
  • HEAD is a very useful substitute for the current branch name, since they both point to the same thing
  • always double quote variables used in commands

Beware of large repos

Note that fetch --all is not practical in large repositories. Unless you have an important use case for it, I suggest to drop it, and only add it when there is a specific good reason.

\$\endgroup\$

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.