I created a new branch from my windows command box from the devdesktop application. but when I got to git bash and try to find this branch it doesn't exist. What can I do to sync what I see in git bash with what I created?
Choose one of below commands:
(1) Display latest branch with timestamp:
git for-each-ref --sort='-authordate:iso8601' --format=' %(authordate:relative)%09%(refname:short)' refs/heads
(2) List all branches at remote and local:
git branch
(3) List all branches, order by commit time desc, you will see lasted touched branch:
git branch --sort=-committerdate
(If order in ASC, git branch --sort=committerdate)
I was in another repository which had the same directory structure but was on a separate drive.
Related
I'm trying to set up a vanilla new separate repository for the first time with git 2.37.1 on two W10 systems using drive mapping but I can't find any answered questions that fit my case given my novicitry. :-) Sorry the format is messed up, I did 4 spaces in front of code but most code lines ignore that for some reason.
Spent hours looking at other similar questions, but they all seem to say that there are no commits in the remote repository I'm trying to clone, which is not true. There are lots of commits.
I created a git repository on System1 and it works.
git ls-tree --full-tree --name-only -r HEAD
shows all my files (with lots of commits)
git show HEAD
shows
commit 557...27d (HEAD -> master)
# and the diff between the latest and previous commit
And
git branch -a
shows
* master
No branches, no complexity, no nothing
I go to System2, and create my repo directory, cd into it, then
git init
git remote add origin s:/cap2office # that's my mapped System1 repository)
git pull origin master
I get: fatal: couldn't find remote ref master
git remote
I get: origin
git branch -a
shows nothing
git ls-remote
shows: From s:/cap2office
I also tried:
git clone s:/cap2office
and it says
Cloning into 'cap2office'...
warning: You appear to have cloned an empty repository.
I know I'm missing some trivial magic command, but can't figure out what it is.
You are not cloning a repository, you are trying to clone the working directory of a git clone.
The git repository is stored in the .git folder inside the working directory.
Try this:
git remote add origin s:/cap2office/.git
On system 2, instead of doing git init then git remote add and git pull, do just this:
git clone s:/cap2office/.git
or if you're in Git Bash, sometimes the colon does not work so you need
git clone s/cap2office/.git
Then you can cd to the folder where it was cloned and do the usual git status, git checkout, change stuff, commit, and push to the remote.
I need to extend a given tool with a Bash script that is supposed to work with Linux and MacOS. The script gets 2 parameters:
A repository location (file system, ssh, http(s), ...)
A commitish, e.g. branch, tag, commit hash
I have no influence on the parameters
The result of the script's run should be that
the repository is cloned to a fixed destination (always the same for one repository)
the repositorie's working tree should correspond to the latest state of the comittish (e.g. if it was a branch the tip of that branch)
If the repository does not (yet) exist locally, the procedure is as simple as
git clone $REPO_SOURCE $REPO_DIR
cd $REPO_DIR
git checkout $REPO_REF
My question: Consider a repository is already cloned to /repos/foo. After an obvios git fetch, how to I update that repository to the provided $REPO_REF?
If $REPO_REF was a branch, a git checkout $REPO_REF && git pull should work
If it was a commit hash, there was no update needed (just git checkout $REPO_REF?)
If it was a tag, then the tag might have been moved on the origin, how to handle this?
How to handle other edge cases?
Is there a simple reset-repository-to-this-commitsh way, so the repository behaves just as if it was freshly cloned?
Side nodes:
The same repository might be used with different commitish's, but only sequentially: It is guaranteed that the script isn't invoked more than once at the same time
All external changes to the repository might be always discarded without notification
While deleting and cloning the repository would work, it is impractical due to their sizes and it being an ugly solution
No (git) changes are needed, so checking out a detached head is okay
The only totally-foolproof yet convenient way is to have the other Git (the one you might be cloning, but might not) resolve the name for you. Then you have a hash ID and a hash ID is universal.
If the name is a branch or tag name, you can use git ls-remote to achieve that step. If it might be some other formulation (e.g., master~13) you're out of luck here. So, if you need to resolve the name locally:
If tag discipline is obeyed, no tag will ever move. This means that if you have an existing clone that has the tag, it has the right tag, and you're OK here, and if you have an existing clone that doesn't have the tag, you can add the tag and resolve it.
If tag discipline is not obeyed, you'd have to delete and re-create the tags (yuck), or else re-invent remote tags: copy their refs/tags/* names to your refs/rtags/<remote>/* name-space. See Git - Checkout a remote tag when two remotes have the same tag name.
If you have a branch name or something relative to a branch name, turn the branch name into your own remote-tracking name (e.g., replace master~13 with refs/remotes/origin/master~13) and resolve it.
In any case, you now have a hash ID and can use detached HEAD mode.
Using a "standard" git clone you could to this:
# cleanup old cruft
git reset --hard HEAD
git clean -fdx
# detach from current branch (if on any)
git checkout --detach
# delete all local branches
git for-each-ref --format="%(refname:strip=2)" refs/heads |xargs -r git branch -D
# fetch and update all remote refs and tags
git fetch --force --all --tags --prune --prune-tags
# checkout
git checkout "$COMMITISH"
That way you can rely on git checkout to do its job as usual and you don't need to replicate any of its heuristics, shortcuts etc.
I have a develop branch and a master branch. I want to get the differences between the two on a box where I've never cloned any repos. So I tried:
git diff --no-index remotes/origin/master remotes/origin/develop
It tells me error: Could not access 'remotes/origin/master', which is fair enough since it doesn't know what repo to get it from.
So how do I tell git the location of the repository, so that I could get the diff?
That's not the way to do it. Try this:
git diff origin/master origin/develop
You don't need to use the remotes.
The remotes is the folder where git store the branch files.
In git branches are simply files with a given SHA-1 which are stored under inside the remotes folder
In order to compare branches, you dont need to use theremotes`
# Using the diff command
git diff origin/<branch_name> origin/<branch name>
# Using the log command
git log ^origin/<branch_name> origin/<branch name>
git log origin/<branch_name> ^origin/<branch name>
I noticed that, on Windows, when I create a new branch in my repository using the shell, Git doesn't change the branch I am on. When using Linux, it does. How's that? Is there a possibility to change that, to the way Git in Linux does? (I'm very new to Git.)
To create a new branch and switch to it at the same time, use git checkout -b <branchname>.
I noticed that, on Windows, when I create a new branch in my repository using the shell, Git doesn't change the branch I am on
The commands for branching are the following:
# create branch and stay on the current branch
git branch <branch name>
# create a branch and switch to the new branch
git checkout -b <branch name>
# You can always create branch from any given commit/tag/branch etc you need
git checkout -b <SHA-1>/tag/branch
You can find in this answer a very useful information what it does and how to do it:
How to move HEAD back to a previous location? (Detached head)
My colleague created by accident a branch named develop-client (lower case 'c') from our main branch "develop-Client" (upper case 'C'). We all work on windows. Now, how I can merge the develop-client back into develop-Client? Git in windows sees both branches as one, so when I try do "git merge --no-ff origin/develop-client" (when I am on develop-Client), it says "Already up-to-date".
Determine its SHA using command git rev-parse Branch_name and
merge using command
git merge SHA1
Either specify the hash of the HEAD commit of the branch you want to merge, or alternatively, manually rename the offending branch to a temporary name inside the .git/refs/heads directory.
This happened to me on my local repository. It was one commit ahead of remote. I simply renamed the files as Michael suggested:
In
.git/refs/heads/<in-lower-case>
to
.git/refs/heads/<in-Capital-case>
As I had also accidentally pushed to remote, I deleted the upstream lower case branch (at Github in my case) and in my local repo, changed remotes:
.git/refs/remotes/origin/<in-lower-case>
to
.git/refs/remotes/origin/<in-Capital-case>