I need to forbid pushing of specific commit (by its sha). Is it possible to do with gitolite configuration?
I tried specifying something like
repo myRepo
- 794b62a8b1cf4417c8320a261177b43bd5d8331e = #all
But it does not work as intended. I guess that VREFs can help here but I din't find much info on that.
You can set in place a VREF which will list commits pushed and reject the push if one of those commits matches the one you want to block.
Check as an example src/VREF/MERGE-CHECK, which does use git rev-list to list commits.
See Adding a VREF to implement and add your own.
Related
I have this repository that i forked from another one, and now i need to make a pull request to it, but it says that: "There isn’t anything to compare.", and my commits are not showing:
https://github.com/amorimll/desafio-sharenergy-2023-01
Any help is appreciated, really need this for today.
This is showing in the git rebase:
Short answer
will be checkout to your main branch get the lastest code, then go back to your current working on branch and do git rebase [currentBranchName] main
Explain
so when your create a branch from another branch, is like your created a snapshot code from that branch at that moment. ideally the branch you copied form should prevent make any more changes if possible, until you done working in the new branch and create the PR and done marge it.
what rebase command will do is in case the origin branch had changes, it will pull the latest code form that branch into your working branch first, then to applied any changes you was made for your current working branch. Usually this process will need have some conflict need to fix, if they changed the same file.
Hope this is help you understand :)
I want to setup the squash on merge policy in GitLab. This gif showcases exactly what I would like to have:
Merge Strategies
I have set the GitLab merge method to "Fast-forward merge" and the squash commits policy is set to mandatory when merging.
Once merge is done, the git log of the main branch is exactly like I want it. The feature branch commits were squashed and the whole feature appears as one commit in the git log.
Here's the problem:
The squashed commit that is now the head of the main branch has the timestamp of the last commit in the feature branch. I would expect it to be the timestamp of when the fast-forward merge happened (squash). Is there a way to set it up in GitLab?
The merge timestamp is important for me since I need to know when the feature made its way into the main branch. However, I want to keep the commit history streamlined and straightforward, so the default option with an additional merge commit for every merge is something I want to avoid.
I'm new to GitLab ci and I was curious if something could be done inside the .gitlab-ci.yml. For our project we want two different things to happen dependent on two actions. For instance, when a new file is added to the master branch we want Job1 to run. However, when a file is updated in the master branch we would like Job2 to run instead.
Based on reading through Gitlab's documentation on ci/cd it looks like you could do this by using variables and rules.
So, would this be possible inside the yml file or would you have to go about it another way?
Thank you for your replies.
As you might have already noticed there is a rule named changes which you could try out. If that's not sufficient you still could execute something like git diff-tree inside a container and then decide what to do.
I doubt that you can do it directly with a conditional over a file because the commit push (which is the action that triggers the pipeline containing the job, ultimately) could contain several files.
Having said that, you have a bunch of predefined variables with information about the commit itself, so maybe you can agree with the team on a commit description template for when they add a file and another one for the case of the update. Then you can easily use rules to determine which job has to run. For this particular case, you will be using the CI_COMMIT_DESCRIPTION variable.
You can also base your condition on a tag, but I think that it will make the repository too dirty.
I know that it is easy to forget the rule, but still, it is an easy workaround.
I'd like some Git log command to list out the commits before some specific commit ID/hash in the current working branch.
E.g. Something like
git log --before <commit id>
But I haven't been able to find what the correct command to do this is.
Just give the commit hash as the ref to explore via log
git log <commitHash>
and it will output all history from that point, backwards, until initial commit.
Alternatively, if you need to exclude this specific commit itself, then refer to its parent with
git log <commitHash>^
Sidenote about your mention of "in the current working branch"
Branches are technically irrelevant here to tree traversal logic. This won't limit output to what's "in" the branch, largely because the common metaphor is quite bad : commits are just not "on" branches. Branches are to be seen as soft (and disposable) shortcuts to designate one commit in the tree.
I'm new to Gitlab API, I know how to create a tag on a specific branch, let's say I have several branches on my repository, and I created several tags on each branch. Now I want get all the tags on a specific branch with GitLabAPI. I've read the Branchs API and Tags API docs carefully, however was unable to find an answer to my question. Please help me out.
I am unsure what you're trying to accomplish as you literally described your problem with one short sentence, so it will be more of a guess.
If what you want to do is to create GitLab tag for a specific commit for a specific branch, you simply do that as you can define branch when creating it. Will not post description of how it should be done as there is documentation.
With GitLabAPI(as you wanted based on you problem description) follow this link:
How to with GitLabAPI
And instead of Release tag just make same steps for any other tag. For tagging from console you should follow this one:
How to with git
If you're looking for a way to find specific tag with GitLabAPI just go that way:
Repository->Tags->Filter by tag name
Tags are unique across the whole repository.
For doing checkout from console:
git checkout <tag>
Your consternation, I believe, comes from misunderstanding the idea of tags. It's kind of a snapshot of repository at specific point, might be for release, may be for backup purposes, does not matter, it's up to you. Important part is that no matter where you will place it, it has to be unique in scope of a whole repository not just a branch you place it. There is no way to create two same tags on two different branches, git won't let you. Read info from links and everything should be clear.
If my answer is not what you were looking for, expand your question to get more proper and accurate one.