A merge request isn't a git thing; It is an extension of some platforms.
If you continue developing on the same branch as the mergerequest was issued for, github and gitlab will list your commits within the Merge Request once you have pushed them to your remote.
If you do not want this, you can simply branch off after issuing your merge request.
ok, so a "merge request" can be viewed as "merge of branch1 into master will happen at a time I cannot control".
Now, branch1 is checked out, if I do git switch -c branch2, it will start a new branch2 based on the last commit from branch1, right? I feel it's safer, since I don't know when branch1 will merge, server-side.
Depending on the upstream guidelines (check for a CONTRIBUTION file) you may open a MR with your initial development efforts. And reuse the branch until you have finished the feature. Then you request a review.
Or you may first mention your branch on a issue and only create the merge request once the entire feature is developed.
If you are developing another feature, use a dedicated branch.
In any case, the author merging may elect only specific portions of your change.
Also note that it is perfectly normal that a merge request will be open for months. So don't be discouraged. There may already be people profiting from your change. You just don't see it.
For a super long time, I was a CLI-purist when it came to git, and I still maintain that anyone who knows how to use git should be able to do anything via the CLI entirely.
However, over the past few months I have used gitui through vim-floaterm, with it setup to auto-launch as the floating terminal opens. Super useful to just hit a hotkey while in nvim and bash out a super quick commit/push with just a couple keystrokes.
That's hacky in a way I love, but since you're on the same network by design, why not just expose a remote on a machine that all other machines will use?
@christophski I used to use it some time ago. It was to store cryptographically verifiable timestamps of the commits. Git has native support for cryptographically verifiable proof of authorship (using GPG and SSH keys), but not for timestamps. I used FreeTSA (https://freetsa.org/index_en.php) for this.
You should check out git reflog if you don't know about it already. It allows you to view the history of commit changes which is very handy if you want to undo an --amend or rebase for example
That's a really good explanation. I would just add that I find easier to search for orphans with git log --graph --reflog than using `git reflog directly, especially if it's one of the top entries in the reflog.
This is a good example of what understanding your tools can give you.
Answer is new or novel approaches to the old problems.
Ability to create a patch from any diff is really really usefull.
If you have wip changes, but don't want to commit it to, then creating a patch is a quite easy way to go.
Git
Oldest