I have committed some code, below I have given my problem statement.
commits
abcdef5 - empty
qwerty5 - my code
Both of them are on my branch abc
How to merge both of them into 1 commit?
I just need qwerty5 in my branch.
If abcdef5 is really empty (and it the most recent commit on your local branch abc), you could simply drop it:
git reset --hard #~
No squash required there.
Then you can push your branch.
You can use the following steps to squash your empty commit:
git rebase -i HEAD~2
1. Review the commits
pick abcdef5 a
pick qwerty5 b
2. Squash commit a into b
s abcdef5 a
pick qwerty5 b
3. Edit the final commit message
# This is a combination of 2 commits.
# The first commit's message is:
message from commit a
# This is the 2nd commit message:
message from commit b
4. Push your code
git push --force
Hope this helps. :)
Related
I've scoured several different posts but there doesn't appear to be any that match with this exact issue of an "apparent" branch renaming occurring but nothing seeming to line up.
Essentially, I've been trying to delete a remote branch off of an enterprise git version but I've been getting rejected and I was wondering if there was any additional steps I can try out?
here is the following CLI information:
| => git branch -a
* master
remotes/origin/HEAD -> origin/master
remotes/origin/master
remotes/origin/releases/v1.7.2_log4j2
(base)
| ~/Documents/<repo> # (user)
| => git push origin -d releases/v1.7.2_log4j2
To https://github.<company>.com/<org>/<repo>.git
! [remote rejected] releases/v1.7.2_log4j2 (branch releases/v1.7.2_log4j2 is being renamed)
error: failed to push some refs to 'https://github.<company>.com/<org>/<repo>.git'
My git version: 2.24.3 (Apple Git-128).
EDIT: there are no branch protection rules that apply to this branch and I have tried the command in the suggestions of git push -d origin releases<1.7.2_log4j2 with the same result
This looks like a github issue. There is a github-community thread where someone got the exact same message and it turned out to be a flag that was set within the github system that marked the branch as being renamed at the moment. They had to ask the github-support to clear that flag and then were able to delete the branch.
You seem to have your parameters backwards. Try
git push -d origin releases/v1.7.2_log4j2
Is it possible to customize what is commented in Jira when a commit is pushed in GitHub?
Currently the following information is commented:
Triggered by: John Doe
Comment: #TST-1234: dummy commit to test jira-github integration
Repository: testing
Branch: refs/heads/master
Git Issue URL: https://github.com/...
And I want it to comment only the URL part, all the rest is not interesting information for me, and I want the comments to be clean.
a possible solution could be to customize the commit message itself
ensure that commit messages include the branch name, which in JIRA are most likely derived from the issue title.
To achieve this, coworkers have to include in their .git/hooks directory a file named commit-msg with the following contents :
#!/bin/bash
current_branch="$(git rev-parse --abbrev-ref HEAD)"
tmp=$(mktemp) || exit
echo "$current_branch $(cat "$1")" > "$tmp"
mv "$tmp" "$1"
Then when someone is committing on the feature branch ABC-1234-customers-cant-log-in, a commit command like this :
git commit -m "Awesome changes"
...will actually produce the following commit message :
ABC-1234-customers-cant-log-in Awesome changes
...and JIRA will then link the commit to the issue.
solution and credits goes to answer here: https://stackoverflow.com/a/55008618/7540322
In my github repo's readme.md file I have a Travis-CI badge. I use the following link:
https://travis-ci.org/joegattnet/joegattnet_v3.png?branch=staging
The obvious problem is that the branch is hardcoded. Is it possible to use some sort of variable so that the branch is the one currently being viewed?
Not that I know of.
GitHub support confirms (through OP Joe Gatt 's comment)
The only way to do this would be to pass the link through my own service which would use the github's http referrer header to determine which branch is being referenced and then fetch the appropriate image from Travis CI
I would rather make one Travis-CI badge per branch, for the reader to choose or consider the appropriate when seeing the README.md.
Update 2016 (3 years later): while nothing has changed on the GitHub side, fedorqui reports in the workaround mentioned in "Get Travis Shield on Github to Reflect Selected Branch Status" by Andrie.
Simply display all the branches and their respective TravisCI badges.
If you have only two or three branches, that could be enough.
I worked around this issue with a git pre-commit hook that re-writes the Travis line in the README.md with the current branch. An example of usage and pre-commit (Python) code (for the question as asked) are below.
Usage
dandye$ git checkout -b feature123 origin/master
Branch feature123 set up to track remote branch master from origin.
Switched to a new branch 'feature123'
dandye$ echo "* Feature123" >> README.md
dandye$ git add README.md
dandye$ git commit -m "Added Feature123"
Starting pre-commit hook...
Replacing:
[][travis]
with:
[][travis]
pre-commit hook complete.
[feature123 54897ee] Added Feature123
1 file changed, 2 insertions(+), 1 deletion(-)
dandye$ cat README.md |grep "Build Status"
[][travis]
dandye$
Python code for the pre-commit code
dandye$ cat .git/hooks/pre-commit
#!/usr/bin/python
"""
Referencing current branch in github readme.md[1]
This pre-commit hook[2] updates the README.md file's
Travis badge with the current branch. Gist at[4].
[1] http://stackoverflow.com/questions/18673694/referencing-current-branch-in-github-readme-md
[2] http://www.git-scm.com/book/en/v2/Customizing-Git-Git-Hooks
[3] https://docs.travis-ci.com/user/status-images/
[4] https://gist.github.com/dandye/dfe0870a6a1151c89ed9
"""
import subprocess
# Hard-Coded for your repo (ToDo: get from remote?)
GITHUB_USER="joegattnet"
REPO="joegattnet_v3"
print "Starting pre-commit hook..."
BRANCH=subprocess.check_output(["git",
"rev-parse",
"--abbrev-ref",
"HEAD"]).strip()
# String with hard-coded values
# See Embedding Status Images[3] for alternate formats (private repos, svg, etc)
# [][travis]
# Output String with Variable substitution
travis="[![Build Status](https://travis-ci.org/" \
"{GITHUB_USER}/{REPO}.png?" \
"branch={BRANCH})][travis]\n".format(BRANCH=BRANCH,
GITHUB_USER=GITHUB_USER,
REPO=REPO)
sentinel_str="[![Build Status]"
readmelines=open("README.md").readlines()
with open("README.md", "w") as fh:
for aline in readmelines:
if sentinel_str in aline and travis != aline:
print "Replacing:\n\t{aline}\nwith:\n\t{travis}".format(
aline=aline,
travis=travis)
fh.write(travis)
else:
fh.write(aline)
subprocess.check_output(["git", "add", "README.md" ])
print "pre-commit hook complete."
I updated the work of Dan Dye so it's now able to change any git variable into a readme. It also works now with python 3. For example, handling badges by branch for Github actions:
[](https://github.com/{{ repository.name }}/actions/workflows/integration-tests.yaml?query=branch%3A{{ current.branch }})
And in your pre-commit file add:
.githooks/replace_by_git_vars.py readme.md README.md -v
-v displays the available variables and more
https://gist.github.com/jclaveau/af2271b9fdf05f7f1983f492af5592f8
Thanks a lot for the solution and inspiration!
The best solution for me was to create a server where I send a query with username and repo's name and get a svg image with the build status for all branches.
change 1, change 2, change 3, change 4
/
master >> Branch A
\ Branch A1
\
change 1001
I have made a branch A from the master at the beginning. Then I have made a branch out of branch (A1).
Over time I have make several changes to Branch A.
I have also done some changes to Branch A1.
Now I would like to get only Branch A1's change to master (change 1001), without the changes to Branch A (changes 1-4).
Can this be done easily with git? And if it's possible, what would be appropriate steps to achieve this?
I'm using eGit plugin in Eclipse.
You have
x--x--x (master)
\
y--y1--change 1, change 2, change 3, change 4 (branchA)
\
change 1001 (branchA1)
or:
change 1001 (branchA1)
/
x--x--x (master)
\
y--y--change 1, change 2, change 3, change 4 (branchA)
In the second case (branchA1 comes from master), you could simply merge branchA1 on master.
But in the first case (branchA1 comes from branchA), you can:
git cherry-pick change 1001
But that would leave some duplicate commits and is subject to functional dependencies.
I try to avoid cherry-picking, if possible.
Or:
git rebase --onto master y1 branchA1
That will move all commits from branchA1 (after y1 of branchA) onto master branch. No duplicate commits
As I understand one of the main advantages of distributed revision control system like Mercurial is that you should not worry about breaking something in your super-important main repo (which is used by quite a lot other developers), and do all you work and researches in your personal remote clone until you understand that everything stable and you can push your work back.
And hence I got my question: if it possible to push back not all your changes history (with several revisions which you made for yourself), but only one which is actually diff between your repo and current state of master.
One example:
hg init master-repo; cd master-repo
echo -e 'Important file\nWith Bug!' > file
hg commit -A -m "initial commit"
cd ..; hg clone master-repo hotfix-repo; cd hotfix-repo
echo "fix1" >> file
hg commit -m "first attempt to fix bug"
echo "fix2" >> file
hg commit -m 'Fixed it!'
Now (possibly after pull and merge with newest master-repo' changes) I want to push back only one changeset containing all changes that I've done without my local commits history.
One possible solution is to create one more clone then use diff/patch between two clones to extract/apply changes from first one and commit them all at once in second repo. Then do push as in normal case. But is it possible to so using only mercurial commands?
Thanks in forward!
Opinions differ on whether or not it's good to collapse trial-and-error changesets into a single changeset before pushing:
Pros: you avoid having changesets in your history where your test suite fails — those changesets are bad for hg bisect and add noise.
Con: you cannot collapse changesets that you have published to other repositories — doing so would only rewrite your local changesets and you would then have to clean up the other repositories manually.
Technically, it's perfectly safe to collapse a set of changesets into a single changeset before pushing. You start with
... a --- b --- c --- x --- y --- z
and you rewrite this into
... a --- b --- c --- w
where w has exactly the same repository state as z had (but a different parent changeset, obviously). There are no merges here (and hence no merge conflicts) so it cannot fail.
After rewriting, you can pull and merge with the upstream (d and e):
... a --- b --- c --- w --- v
\ /
d ----- e
You need an extension to do any kind of history rewriting. Here I would suggest one of:
Collapse extension: as the name implies, this extension is dedicated to collapsing changesets.
Histedit extension: full-fledged history editing, but the fold command let's you collapse changesets.
Rebase extension: this standard extension can move changesets around and collapse them at the same time. In the example above, it would move x --- y --- z after e:
... a --- b --- c --- d --- e --- x' --- y' --- z'
You can then optionally collapse x' to z':
... a --- b --- c --- d --- e --- w'
Compared to just collapsing x to z, rebasing does involve merges so it can fail.
Intro
I think, rewrite history and send/get "polished" changesets (in Git-boys style) is, in common, bad idea - history is history, it have own value.
After all, for "mainline" branch (you use branches, isn't it), all your changes will be presented as one mergeset, regardless of changesets count in branch
Short answer
No. In Mercurial you pull/push and get&accept full set of changesets, which created difference in repo history
Long answer
Somehow you can, by rewting your history of changesets before exchange to "other side". Just remember - each changeset represent not new state of object, but diff between old and current (if describe it shortly), thus - by ordinary removing changests you can get wrong final result.
Anyway, you have a lot of ways to rewrite own history (as extensions):
Collapse
History Edit
MQ (with mq-patches per se, folding changesets in mq-patch and splitting the same way)
Maybe some others, unknown for me