Newbe Dev Stack

Answer : This gets into one of the more obscure corners of Git, but in the end the answer is "it doesn't matter initially which order you use". However, I'd recommend avoiding git pull in general, and never using it in scripts anyway. Plus, it does matter, in a different way, precisely when you fetch, as we will see below. So I'd recommend running your own git fetch first, then simply not using git pull at all. git fetch A plain git fetch (without --tags ) uses a weird hybrid tag update by default, although each remote can define a default tag option that overrides this default. The weird hybrid is what you quoted: tags that point at objects that are downloaded from the remote repository are fetched and stored locally. The underlying mechanism for this is a bit tricky and I'll leave that for later. Adding --tags to the git fetch arguments has almost the same effect as specifying, on the command line, refs/tags/*:refs/tags/* . (We'll ...

Answer : The script passwd to git submodule is run with it's working directory set to the top of the given submodule...so you can simply look at pwd to see if you're in you're in the particular submodule. However, if you take some time to read the git submodule documentation, it turns out to be even easier: foreach Evaluates an arbitrary shell command in each checked out submodule. The command has access to the variables $name, $path, $sha1 and $toplevel: $name is the name of the relevant submodule section in .gitmodules, $path is the name of the submodule directory relative to the superproject, $sha1 is the commit as recorded in the superproject, and $toplevel is the absolute path to the top-level of the superproject. So you can do something like this: git submodule foreach '[ "$path" = "Libraries/JSONKit" ] \ && branch=experimental \ || branch=master; git co $branch'

Answer : Since git 1.8.5 (Q4 2013): " git fetch " (hence " git pull " as well) learned to check " fetch.prune " and " remote.*.prune " configuration variables and to behave as if the " --prune " command line option was given. That means that, if you set remote.origin.prune to true: git config remote.origin.prune true Any git fetch or git pull will automatically prune. Note: Git 2.12 (Q1 2017) will fix a bug related to this configuration, which would make git remote rename misbehave. See "How do I rename a git remote?". See more at commit 737c5a9: Without " git fetch --prune ", remote-tracking branches for a branch the other side already has removed will stay forever. Some people want to always run " git fetch --prune ". To accommodate users who want to either prune always or when fetching from a particular remote, add two new configuration variables " fetch.prune ...

Answer : A comma-separated list inside braces appears to work: pipelines: branches: '{rev,staging}': - step: script: - echo 'step' This is a full example on how you can reuse some steps: image: yourimage:latest definitions: services: ... # Service definitions go there steps: - step: &Test-step name: Run tests script: - npm install - npm run test - step: &Deploy-step name: Deploy to staging deployment: staging script: - npm install - npm run build - fab deploy pipelines: default: - step: *Test-step - step: *Deploy-step branches: master: - step: *Test-step - step: <<: *Deploy-step deployment: production trigger: manual Read more about YAML anchors: https://confluence.atlassian.com/bitbucket/yaml-anchors-960154027.html Instead of interpreting rev|...

Answer : By reading the documentation for ssh forwarding in ansible. I was able to figure out the solution. The problem was that my ssh keys were not being forwarded because Ansible does not by default forward your keys, even if you have set up the key forwarding on ~/.ssh/conf (I updated my question with the ansible.cfg that I had before fixing the issue). The solution is was to add transport = ssh to ansible.cfg under [defaults] plus running ansible-playbook from the location where ansible.cfg is located and make sure thet the following setting exists in the /etc/ssh/sshd_config of the target box: AllowAgentForwarding yes My ansible.cfg now looks like this: [defaults] transport = ssh [ssh_connection] ssh_args = -o ForwardAgent=yes To clone the private github repo over the remote server, I am doing this: First add the ssh key to your ssh-agent: eval `ssh-agent -s` ssh-add ~/.ssh/my-private-key.pem After that I have modified the ansible.cfg : [defaults] ...

Answer : All .idea files that are explicitly ignored are still showing up to commit you have to remove them from the staging area git rm --cached .idea now you have to commit those changes and they will be ignored from this point on. Once git start to track changes it will not "stop" tracking them even if they were added to the .gitignore file later on. You must explicitly remove them and then commit your removal manually in order to fully ignore them. When you think your git is messed up, you can use this command to do everything up-to-date. git rm -r --cached . git add . git commit -am 'git cache cleared' git push Also to revert back last commit use this : git reset HEAD^ --hard if you do any changes on git ignore then you have to clear you git cache also > git rm -r --cached . > git add . > git commit -m 'git cache cleared' > git push if want to remove any particular folder or file then git rm --cached fi...

Answer : The key to reliably “scripting” Git is to use the ‘plumbing’ commands. The developers take care when changing the plumbing commands to make sure they provide very stable interfaces (i.e. a given combination of repository state, stdin, command line options, arguments, etc. will produce the same output in all versions of Git where the command/option exists). New output variations in plumbing commands can be introduced via new options, but that can not introduce any problems for programs that have already been written against older versions (they would not be using the new options, since they did not exist (or at least were not used) at the time the script was written). Unfortunately the ‘everyday’ Git commands are the ‘porcelain’ commands, so most Git users may not be familiar with with the plumbing commands. The distinction between porcelain and plumbing command is made in the main git manpage (see subsections titled High-level commands (porcelain) and Low-level commands...

Answer : For each conflicted file you get, you can specify git checkout --ours -- <paths> # or git checkout --theirs -- <paths> From the git checkout docs git checkout [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <paths>... --ours --theirs When checking out paths from the index, check out stage #2 ( ours ) or #3 ( theirs ) for unmerged paths. The index may contain unmerged entries because of a previous failed merge. By default, if you try to check out such an entry from the index, the checkout operation will fail and nothing will be checked out. Using -f will ignore these unmerged entries. The contents from a specific side of the merge can be checked out of the index by using --ours or --theirs . With -m , changes made to the working tree file can be discarded to re-create the original conflicted merge result. Even though this question is answered, providing an example as to what "theirs" and ...

Answer : Just like GitHub, you have to pull the commits down to your own machine, merge, and then push them back to your fork on Bitbucket. If you go to your fork on Bitbucket you can click "compare fork" to get to a page where you see incoming and outgoing commits. If you go to the "incoming" tab, you will see instructions like $ git remote add <remote_name> git@bitbucket.org:<upstream>/<repo>.git $ git fetch <remote_name> $ git checkout master $ git merge <remote_name>/master which correspond closely to the GitHub instructions. Goto your fork on bitbucket Click the Branches menu from the left navigation pane Click on the "..." button to the right of the branch and select "Compare". Or, in the url add the word “compare”. So that the URL looks like this: https://bitbucket.org/<user name>/<fork name>/branches/compare Click on the switch icon (black up/down arrows between the branch segments) ...

Answer : From your issue, any gitea command (like gitea admin change-password --username myusername --password asecurenewpassword ) ends up with: gitea: command not found If you installed from binary, you will note that the $PATH was not modified, and gitea was called directly from its installation folder. ./gitea web So you can do the same for changing the password: cd /path/to/gitea ./gitea admin change-password --username myusername --password asecurenewpassword Note that Robert Ranjan adds in the comments: /path/to/gitea is gitea's home path, where you find folder custom . In my case gitea's home is /var/lib/gitea . From this path, you should see file: custom/conf/app.ini which is expected by default. For Current GITEA sometime it will not work by cd /path/to/gitea ./gitea admin change-password --username myusername --password asecurenewpassword You need to specify the configuration also e.g. : cd /path/to/gitea ./gitea admin change-passwor...

Answer : I've had a few issues applying SVN generated patches with git. I'd recommend applying any subversion patches directly with patch command, and use git to verify that said patch was successfully applied. $ patch -p0 < xxx_parser.patch $ git diff @emcconville answer works if you have patch as an executable command in the command line. For others: Go to the svn repo svn diff --git >> gitFormat.patch From your (Copy this file to the) git repo git apply gitFormat.patch

Answer : git log takes (among other things): -n num to limit the number of commits shown: choose 1 (and if num is 9 or less you can just write - num , hence, -1 , for short) --pretty=format: string with directives to change the log output format. The %s directive gets the commit "subject", which is what you also get with oneline . Hence: git log -n 1 --pretty=format:%s $hash (or git log -1 --pretty=format:%s ) will do the trick here. For a complete list of format directives, see the git log documentation, under "PRETTY FORMATS" (about halfway down). Depending on how much of the commit message you actually want, there are several pretty-format specifiers that you can use: · %s: subject · %f: sanitized subject line, suitable for a filename · %b: body · %B: raw body (unwrapped subject and body) So something like git log -1 --pretty=format:%b <hash> , or use one of the other specifiers (I think %s is probably cl...

Answer : To list branches you can use: from git import Repo r = Repo(your_repo_path) repo_heads = r.heads # or it's alias: r.branches r.heads returns git.util.IterableList (inherits after list ) of git.Head objects, so you can: repo_heads_names = [h.name for h in repo_heads] And to checkout eg. master : repo_heads['master'].checkout() # you can get elements of IterableList through it_list['branch_name'] # or it_list.branch_name Module mentioned in the question is GitPython which moved from gitorious to Github. After you’ve done from git import Git g = Git() (and possibly some other command to init g to the repository you care about) all attribute requests on g are more or less transformed into a call of git attr *args . Therefore: g.checkout("mybranch") should do what you want. g.branch() will list the branches. However, note that these are very low level commands and they will return the exact code that the git executables...

Answer : Ideally, you should enter: git config --global credential.helper manager-core Then your password would be stored in the Windows Credential Manager. See more at "Unable to change git account". On the first push, a popup will appear asking for your credentials (username/password) for the target server (for instance github.com ) If not, that might means your credentials were already stored. If they are incorrect, a simple git credential-manager reject https://github.com will remove them (on Windows, again. On Mac: git credential-osxkeychain erase https://github.com ) With Git 2.29 (Q4 2020), the parser in the receiving end of the credential protocol is loosen to allow credential helper to terminate lines with CRLF line ending, as well as LF line ending. See commit 356c473 (03 Oct 2020) by Nikita Leonov ( nyckyta ). (Merged by Junio C Hamano -- gitster -- in commit 542b3c2, 05 Oct 2020) credential : treat CR/LF as line endings in the credential protocol...

Answer : As of git 1.8.3 (May 24, 2013), you can use %C(auto) to decorate %d in the format string of git log . From the release notes: * "git log --format" specifier learned %C(auto) token that tells Git to use color when interpolating %d (decoration), %h (short commit object name), etc. for terminal output.) The git log --decorate will put by default: the HEAD in cyan the remote branches in red the tag in green and can be changed through color.decorate config. But the git log --format don't offer a way to display specifically the HEAD or remotes or branch: all three are displayed through %d , with one color possible. Update May 2013, as mentioned below by Elad Shahar (upvoted), git 1.8.3 offers one more option: git log –format now sports a %C(auto) token that tells Git to use color when resolving %d (decoration), %h (short commit object name), etc. for terminal output. This Atlassian blog post comments that this feature i...

Answer : Perhaps GitHub's support for deploy keys is what you're looking for? To quote that page: When should I use a deploy key? Simple, when you have a server that needs pull access to a single private repo. This key is attached directly to the repository instead of to a personal user account. If that's what you're already trying and it doesn't work, you might want to update your question with more details of the URLs being used, the names and location of the key files, etc. Now for the technical part: How to use your SSH key with Jenkins? If you have, say, a jenkins unix user, you can store your deploy key in ~/.ssh/id_rsa . When Jenkins tries to clone the repo via ssh, it will try to use that key. In some setups, you cannot run Jenkins as an own user account, and possibly also cannot use the default ssh key location ~/.ssh/id_rsa . In such cases, you can create a key in a different location, e.g. ~/.ssh/deploy_key , and configure ssh ...

Answer : If you go to the list of branches for a repository, you can click on ... (More Actions) on one of the branches and choose Compare branches This will take you to a URL in the form: https://dev.azure.com/{organisation}/{project}/_git/{repository}/branches?baseVersion=GB{baseBranch}&targetVersion=GB{targetBranch}&_a=files You can then change the baseVersion and targetVersion parameters in the query string. These can take the following forms, and can be mixed and matched: GB{branchName} GC{commitHash} GT{tagName} Just in case that link gets broken, clicking "View Merge Changes" on a pull request takes you to the same page but with a slightly different URL https://dev.azure.com/{organisation}/{project}/_git/{repository}/branchCompare?baseVersion=GC{baseCommit}&targetVersion=GC{targetCommit}&_a=files I'm not sure if there's a nicer way of comparing commits from the UI, as it only shows branches and tags, but if you do it this wa...

Answer : You get this try running pull first to integrate your changes whenever your local branch and your remote branch are not on the same point, before your changes. remote branch commits : A -> B -> C -> D local branch commits : A -> B -> C -> Local_Commits Now clearly, there's a change D that you don't have integrated locally. So you need to rebase , then push, which will lead to the following. remote branch commits : A -> B -> C -> D local branch commits : A -> B -> C -> D -> Local_Commits To solve your issue, do the following git pull --rebase origin branchname git push origin branchname I was getting this message in my Azure DevOps Repos environment because the server had a branch policy on the master branch that requires pull request approval and I was trying to push to master directly. Even after pull and rebase the same message appears. I don't think VS Code really knows how to interpret this specific err...

Answer : There is format problem in patch file. To fixthe path file: Open your patch file in notepad++ then enter these two menus: Encoding/Convert to UTF-8 Edit/EOL conversion/Unix (LF) Run: git apply --reject --whitespace=fix your_patch.patch Updated You might have a file which was not encoded to UTF-8. To fix that on *nix systems (MacOS, Linux etc.) iconv -f ascii -t utf-8 fix.patch -o fix_utf8.patch For windows you can try: Get-Content .\fix.patch | Set-Content -Encoding utf8 fix_utf8.patch If your file may already have color codes in it you can try: git apply --reject --whitespace myfile.patch Passing in color param seems to fix the problem. git diff HEAD --color=never > fix.patch And now check returns no error message. git apply fix.patch --check Changing my .gitconfig file from [color] ui = always change to always [color] ui = auto Fixed my problem so I do not have to pass color option when diffing to patch file. UPDATE: ...

Answer : The easiest of all the above ways is to: Go to Settings>>Appearance & Behavior>>System Settings>>Passwords Change the setting to not store passwords at all Invalidate and restart IntelliJ Go to Settings>>Version Control>>Git>>SSH executable: Build-in Do a fetch/pull operation Enter the password when prompted Again go to Settings>>Appearance & Behavior>>System Settings>>Passwords This time select store passwords on disk(protected with master password) Voila! Note that this will not work if your password is in your URL itself. If that is the case then you need to follow the steps given by @moleksyuk here You also choose to use the credentials helper option in IntelliJ to achieve similar functionality as suggested by Ramesh here After trying several answers, I was finally able to solve this issue (on window 10), >git fetch remote: HTTP Basic: Access denied fatal: Authentication failed for ...