I have a change-set in Gerrit that for a while has been based off of the master branch.
So, my push commands have looked like this:
git push origin HEAD:refs/for/master
But now, I need to start working off of a topic branch (but still using the same change-set).
So, I tried pushing like this:
git push origin HEAD:refs/for/myTopicBranch
But, this seems to have created a whole new change-set, rather than simply altering the metadata of my current change (as updating a topic does).
Is there a way associate a change-set with a different branch after creation?
No. You can't do that. If you want to work in a different branch, push to this new branch like you have done (git push origin HEAD:refs/for/myTopicBranch) and abandon (using the Gerrit web interface) the original change.
Related
Right now, I am committing the changes for a bug fix (ticket), and then do a
git push origin HEAD:refs/for/master
and then go through the code review on Gerrit. If a coworker proposed a totally different fix, is there a way to try this alternative fix somehow as the same Gerrit code review but as an "alternative way"?
I thought of using this way:
do a git log to look at the commit number exactly before the commit
git checkout that commit
git checkout -b ticket-1234-alternative to start another branch and try the alternative fix
So this method starts from how the project was when you make the fix, and then lets you do an alternative fix, as a separate branch. Is there a way that might not involve creating a different branch but using the same branch and possibly associate it with the same Gerrit code review?
If you want to try a different fix you can choose one of the following:
1) You can amend your original commit (git commit --amend) and push the new commit as the patchset2 to the same change. If you decide to go back to the original commit you'll need to push it again as a patchset3.
2) You can make a new commit based in the parent commit (as you have suggested) and push to a new change on Gerrit. When you decide which change will be used you just need to abandon the other one.
Suppose that I made some changes and did this:
git add -A
git commit -m "comment commit_1"
Now I made more changes and did this again:
git add -A
git commit -m "comment commit_2"
Now, I basically want to discard commit_2 and start modifying my project again at the point of commit_1.
How do I do this?
If you don't mind losing the revisions at all (as if they never happened at all), you can do:
git reset --hard HEAD~
If you want to keep the current history and get a new version on top of what you have where you get rid of the changes of the revision, you can do:
git checkout HEAD~
git reset --soft the-branch
git commit -m "Taking back changes from the last revision"
# And if you like the result of this:
git branch -f the-branch
git checkout the-branch
There you go.
Now, I basically want to discard commit_2 and start modifying my project again at the point of commit_1.
If you literally want to discard commit_2, then it may be that you can use
git reset --hard HEAD^
(Note that at the time I wrote this, another post incorrectly told you to use HEAD~2; that would discard both commits, which is not what was asked.)
There are caveats to using commands that remove commits from a branch.
The first is that you could lose the changes you made in affected commits. That may seem a strange warning - you asked how to discard the changes - but realizing that mistakes happen, it's cause to be careful with these commands. (Just to clarify - if you did something like this accidentally, the changes would not be immediately lost forever; the reflogs offer a little safety net.)
Other issues arise if your repo has remotes and you've pushed the commit(s) in question to any of the remotes. It doesn't sound like that's an issue here, but if it is then there is more you should consider before removing commits from a branch.
But if you've looked it over and determined that you really do just want to discard the commits, the above should work. Do note, HEAD^ is just one of the possible expressions that refers to the second-to-last commit. At the moment it may be the simplest thing to use, but it won't always refer to that particular commit. HEAD^ really means "the commit which is the parent of the currently-checked-out commit".
If you're on the master branch, then master^ would also work - and would not depend on what's currently checked out. Even that changes whenever the master branch moves; if for some reason you need an expression that would continue to refer to the particular commit, you could create a tag
git tag mytag master^
and then mytag would work; or you could look up the commit ID of the commit in question (though it won't be a user-friendly name)
But I digress...
This is different from - and more drastic than - merely loading the 2nd-to-last commit as the question title suggests. To simply update your working tree with the 2nd-to-last commit's state, you could
git checkout HEAD^
This moves the HEAD (i.e. changes what's checked out) and updates the index and work tree, but it still keeps the commit on master in case you need it again later. However, it also puts you in a state called "detached head", meaning that git isn't really expecting you to create new commits from here.
If you want to both keep the old commit around, and be in a state where you can add commits on top of commit_1, then you need to create a new branch. If you did the previous checkout command, you could then
git checkout -b mybranch
and new changes could be committed to the new branch while leaving the original commit_2 on master. Or, you could put a branch (or tag) on commit_2 and then move master back to commit_1.
git checkout master
git branch mybranch
git reset --hard HEAD^
That may seem like a confusing number of options; but really that's because each one serves a somewhat different purpose, and only someone involved in your project is likely to have all the context to decide which makes sense.
So tl;dr - it sounds like you might be looking for git reset, but just doing that alone is only suitable if you really intend to permanently discard the changes from commit_2. If you really would want to preserve them for future reference (But maybe just weren't sure if that's an option) then there are ways to do that, too.
I would like to push build tags to a non-standard location on gerrit, mainly to avoid them from showing up as an official tag and also to avoid polluting users with a bunch of build tags.
On old versions of gerrit, I was able to grant myself permissions to create refs and tags in, say, refs/builds/tags/*, and then do
git push origin refs/tags/BUILD-123:refs/builds/tags/BUILD-123
The beauty of the scheme is that this way, the build tags don't pollute ordinary users' git repos, but if someone is interested in the build tags, they can run:
git fetch origin 'refs/builds/tags/*:refs/tags/*'
and then all the build tags appear and become usable as tags.
It seems that on newer versions of gerrit (2.16?) direct push is limited to the standard locations.
It also appears as if one can only push tags of commits which are direct ancestors an existing branch, so if my build does anything unusual (for example rebase to the tip), it fails.
Is this configurable anywhere?
It turns out there is no such restriction, you just have to grant yourself all the required permissions, like so:
[access "refs/builds/*"]
create = <me>
createSignedTag = <me>
createTag = <me>
delete = <me>
read = <me>
I forgot to give myself read permissions...
The restriction that does exist is where you cannot push a tag that is not for a commit that is an ancestor of an existing known branch. The reason this restriction exists is because access to commits is controlled via ACLs that feature wild carded refs as primary key to permissions. If someone knew a "forbidden" sha and was allowed to push a tag, this scheme can be bypassed.
The trick is to give up on pushing tags and to push branches instead. Branches can be pushed to non-standard locations just like tags, and if someone fetches them into refs/tags, they also act like lightweight tags.
I have configured a Jenkins Pipeline that correctly receives webhooks push notifications from GitHub, on push events.
The authentication is done through a deployment key.
Jenkins configuration seems to rely a lot on the concepts of branches and pull requests.
Given my workflow, which consists mostly of creating branches for any needs, and merge changes back onto master once things would look fine on the CI, I do not really care about seeing my builds categorized by branch or PR.
I would prefer to see builds based on commits' hashes. I do not see the need to tell Jenkins what branch I want it to match.
My current configuration is not selecting the commit revision I desire. I do not understand how it decides which branch or commit to build, once it receives a push notification. In Jenkins I have set the branch to **.
Checking the webhook payload, I noticed that it contains both the list of commits but also something called head_commit, with its id property being the commit's hash I want to see being built.
I would like Jenkins to do the following:
Check what's the head commit in the webhook notification (head_commit.id in the payload)
Build that precise commit, no matter the branch it is part of
Setting a green tick or a red cross beside the commit's hash on Github
Is this possible?
We use Gerrit 2.5-rc1) ACLs to manage access to our git projects & branches. We try to keep the rules simple for developer groups; refs/heads/* allow Push, Create Reference, Push Merge Commit.
There is a need to mark a specific branch, call it foo, as read only. I have tried adding a new rule for refs/heads/foo/*, allowing READ, but DENYing Push, Push Merge Commit, etc. (both with and without "Exclusive" tickbox ticked). In any case, developers are still permitted to push to that branch.
Any idea how to do this without writing server hooks, etc?
For your Gerrit version I think the following set should do the trick:
refs/heads/* ALLOW
refs/heads/foo/* BLOCK