Normally I open a bash prompt inside my Test folder. I then git add, commit, and push origin the file and it goes into my Test folder in bitbucket. Now somehow my Test folder instead of showing .../Test (Development), it shows another repo, .../Test (Review). I do not know why it changed. How can I get (Review) to be (Development)?
In git there are pretty much three stages. When pressing git status you probably get a similar few to this with many more files:
# On branch review
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: file.txt
#
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: file2.txt
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# file3.txt
file.txt on top has staged changes. These will go into the next commit when you do git commit.
file2.txt has unstaged changes. This file is tracked in the repository but the changes will not be added to the next commit. Only if you git add this file will it get staged.
file3.txt is an untracked file. You have to add it with git add which will automatically put it into the staged area. Next time you will make changes to it you will find it in the unstaged area like file2.txt
from this situation git checkout master gives:
error: Your local changes to the following files would be overwritten by checkout:
file2.txt
Please, commit your changes or stash them before you can switch branches.
Aborting
This is probably what you get too. Git noticed that you made changes in the tracked file file2.txt but you didn't specify what to do with them. Similarly I suspect that you made changed to those '50 or so files' and now git doesn't know what to do.
Either add them to your commit and do a commit:
git add <files>
git commit -m "did some work"
or drop the changes:
git checkout <files>
Then they will return to the way they were at the last commit.
You can also add some files and drop others, or even do partial adds with git add -p.
Check the changes you made with git diff.
After this is resolved you can switch branches again with git checkout <branchname>.
Without more information on your branch structure in your bitbucket and your commit history it is hard to say what you can push to where.
Related
We have a git submodule, it's in a folder called 'config' in several repos.
I am getting this when doing a merge:
On branch oleg/feature/1537299444
Your branch is up to date with 'origin/oleg/feature/1537299444'.
Changes not staged for commit:
modified: config (modified content)
no changes added to commit
and it exits with 1.
How can I ignore all changes to the 'config' folder, which is a gitsubmodule?
I tried:
git checkout config
but that didn't do anything
Try first to check what kind of of diff/new element you see in the submodule.
cd config
git status
git diff
If you can, do a git reset --hard in that config folder (if you don't need any local modification done in config)
Then go back to the parent repo, and retry your git merge.
How do I check the last date time of git pull request made, as I have done some changes in my repo and trying to push them but before it I used "git pull" but it says "Already uptodate", now I use "git push" but unable to push changes as it says "Everything up-to-date". While git status shows modified files in staged and unstaged.
What am I doing wrong ?
While git status shows modified files in staged and unstaged.
You need to commit the staged files first, in order to be able to push
cd /path/to/repo
git commit -m "Add files"
git push
I want to learn to use git-svn. I have an svn local repository on my disk that I've checked out a while ago using something like this:
svn co http://myserver.com/mysvnrepo/trunk/ /mysvnrepo/
ls -a /mysvnrepo/
. .. .svn foo bar
This /mysvnrepo/ is HUGE, so I want to avoid re-downloading or copying the files at all costs.
I'm wondering if there's a way to git clone this local repo without downloading / copying anything (because it's already there).
I have this which seems to be what I'm looking for, but when I do that it doesn't quite give me what I expect.
cd /mysvnrepo/
git svn clone file://mysvnrepo/
ls /mysvnrepo/
. .. .git .svn foo bar
git status
# On branch master
#
# Initial commit
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# .svn/
# foo/
# bar/
I would expect git to detect foo and bar as "versioned and up-to-date".
According to the docs it seems that I need to use git svn init because git svn clone runs a fetch, which I certainly don't want. So I tried
git svn init --trunk=file:///mysvnrepo/
...but no luck.
I'm completely new to git, so my confusion is off-the-charts... am I doing something utterly wrong?
Thanks in advance
You cannot take a subversion snapshot and convert it into a git repository.
It sounds like you are trying to avoid a lengthy initialization of the git repository from svn: which ordinarily will try to ready your entire history. This can be done in another way, by limiting the fetch to recent history depending on how much history is relevant to you:
git svn clone -s -r 12334:HEAD https://svn.host.org/repo
Where 12334 is the earliest svn revision you are interested in and assuming that the repo is laid out in a standard svn way with branches and tags.
I've corrupted one file and I'd like to revert it back. My project is using git-svn.
So how can I revert this one particular file? Or even better if I could view whole change set of this file.
Detailed steps would be appreciated.
git revert SHA1_OF_FAULTY_COMMIT
add back the changes but don't commit
git cherry-pick -n SHA1_OF_FAULTY_COMMIT
Modify what needs to be modified, e.g.
git reset HEAD file_that_should_not_have_been_modified
Commit
git commit -m "to_be_merged"
Squash the two commits, put a meaningful comment.
git rebase -i HEAD~2
Review your changes, it should only contains the modification on the single file you:
git show
You can now push that to svn
git svn dcommit
I'm pretty happy with how Git itself handles line endings, via core.autocrlf, core.eol + gitattributes (Tim's post is excellent).
I have a Windows Git repo that has autocrlf set to true. So, all text files are stored in the repo as LF and live in the working directory as CRLF. This repo was cloned from an SVN repo, which we still use to push from / pull to (the SVN repo is our central, blessed repo for triggering CI etc).
But I don't know how git-svn handles line endings during the push / pull operations.
Can anyone explain what git-svn does in this instance?
I'm interested in this too. Supposing you have a repo that was created via git svn clone, I think you could break it down into three different questions:
Does any git newline normalization/alteration happen at git svn fetch time, in moving commits from svn to the git repo?
Does any git newline normalization/alteration happen at git commit time [i.e. during a normal local git commit to a repo with svn remotes]? How about merge/rebase time?
Does any git newline normalization/alteration happen at git svn dcommit time, in pushing/replaying/whatever git commits against svn?
I'd love to hear what's theoretically supposed to be true for these questions, but for now I did a little experiment that seems to show that there is no newline normalization in case #1 at least:
rem We'll make a svn repo with CRLF newlines, clone it into git with
rem autocrlf enabled, and try to see if that results in LF-only newlines
rem getting stored in the git repo
cd c:\code
rem Step 1. Prepare SVN repo with CRLF type newlines.
rem The pre-1.4 flag is to prevent an error during git clone.
svnadmin create --pre-1.4-compatible svnrepo
svn checkout file:///C:/code/svnrepo svnworking
cd svnworking
echo "First line" > file.txt
echo "Second line" >> file.txt
echo "Third line" >> file.txt
rem NOTE: At this point file.txt has CRLF newlines
svn add file.txt
svn commit -m "Add file.txt"
rem NOTE: At this point file.txt still has CRLF newlines
cd ..
rem Step 2. Clone the svn repo into git and inspect work copy newline type
git svn clone file:///C:/code/svnrepo gitrepo
rem The following outputs true on my machine
git config --get core.autocrlf
cd gitrepo
rem The following also outputs true on my machine
git config --get core.autocrlf
git svn fetch
rem NOTE: At this point file.txt (git working dir copy) has CRLF newlines
rem Step 3. Disable autocrlf to inspect repo's inner newline type
rem Use the following and my editor to set core.autocrlf to false:
git config --edit --local
rem This now prints false:
git config --get core.autocrlf
git checkout .
rem NOTE: At this point file.txt (git working dir copy) still has CRLF newlines
del file.txt
git checkout .
rem NOTE: Even after explicitly deleting the old one and checking out again,
rem file.txt still has CRLF newlines
If git newline conversion had taken place during my git svn pull, in contrast, then I would expect file.txt to have LF-only newlines at the end of all this.
Here's a sanity check that step 3 above actually implements a valid test of whether the repo has LF-only newlines:
rem We'll a git repo with core.autocrlf on, then switch it off to
rem pull out a file
rem The following outputs true
git config --get core.autocrlf
git init gitcrtest
cd gitcrtest
rem The following still outputs true
git config --get core.autocrlf
echo "First line" > file.txt
echo "Second line" >> file.txt
echo "Third line" >> file.txt
git add file.txt
git commit -m "Add file.txt"
rem NOTE: At this point file.txt (git working dir copy) has CRLF newlines
rem Use the following to set core.autocrlf to false
git config --edit --local
git checkout .
rem NOTE: Now file.txt (git working dir copy) has LF-only newlines
In summary: Based on the above, it seems that when git-svn pulls from svn, the svn commits get added to the git commit graph without any crlf translation, even when autocrlf is enabled. That is, whatever type of newline your files have in your svn repo, they're also going to have in your git clone thereof. (But your git working copy may have different newline types.)
Note that this is pretty consistent with the discussion of end-of-line normalization in "git help attributes"; there normalization is presented as something that happens either with commands that pull stuff from the repo into your working directory (e.g. checkout or merge) or with commands that move things from your working directory into the index/repo (e.g. add or commit). "Git svn fetch" doesn't seem to do either of those things, so it makes sense that no end-of-line normalization would happen at that time. I'm fuzzier about what dcommit does, so I'm not sure whether to expect end-of-line normalization at that time.
Note there's an additional wrinkle if SVN's svn:eol-style property is set on your repo/machine. I think the SVN default is to not do end-of-line conversions on its end, but I'm not 100% sure.
Update: For a real-world svn->git migration perspective on newlines, see also Tim Abell's description thereof. CRLF newlines were not converted to LF-only newlines by git-svn, with non-ideal results if git's automatic end-of-line normalization was left on. Solutions were to normalize the line endings in git or to disable end-of-line-normalization.