Background: I've just started using git-tf after being extremely frustrated with the wait times pulling down a TFS project with 50+ branches (and so many other reasons). Not a git user previously, so I'm learning all the commands and functionality as I go.
I do all of my development work in local branches, then when I'm ready to push to TFS, I swap back to master and do git tf pull --deep --rebase. Most of the time this works flawlessly - everything is pulled down, files are updated, life is good. Recently though, it has been occasionally failing with the following messages:
Fetching and merging changes in $/TFS/repo at latest changeset: 100%, done
All files were fetched to commit 59ad2a4. The rebase operation was aborted with
the following failures:
Project.Subproject/Folder/SomeRandomFile.sql : the file has uncommitted changes in the
working folder
Prior to running pull, git status confirmed I had zero changes in master. After this, git status still confirms I have no modified files.
At this point I can (and have been) merging '59ad2a4' or whatever it is into master, which works as expected and I go back to work. Just curious what's actually going on here, if there's something I'm doing wrong or not understanding, since this seems to happen randomly.
Related
I'm learning about Github based off another training where the goal is to have training material synced via git between my Windows machine, where I edit them with VS Code, and a linux box where I do a git pull to get the changes and run the code.
The problem was that the first two test changes worked fine (edit the file in VS Code, stage, commit) and showed up in the repository. Doing a git pull from the linux box did update the local files.
Then it stopped. I worked on a few files, did a stage and commit and nothing happened. The VS Code console was not showing any errors, but the repository and the linux "git pull" commands did not show any changes. (this is commit 3)
I then added some more test changes and the same thing; stage, commit, no error, but the repository showed no difference, no update. (this is commit 4 and 5)
Then I did a stage and sync and there! Commits 3, 4, and 5 showed up in the repository!
So what happened? Does github have a time limit or commit amount limit I do not know? Or does sync do something special?
Why could I not see the commits 3, 4 or 5 before the sync? Am I doing something wrong?
There was a confusion in my understanding of how git and github are sructured.
Short answer: I was not pushing to the github repository.
Long answer: I had not understood the function of github and git and did not even think github and git were seperate.
As such, when I was staging, I thought that my changes are now ready. Then with a commit, I expected them to appear in my github repository, when in fact the commit was just adding them to the LOCAL depository.
I was commiting, but I was not pushing. And I was expecting my commits to show up in the github repository.
We are hosting a c/c++ based repo with multiple branches in Github , while doing CI , there are usually on the average 10 pull requests in each integration build , and if something fails , we have to track it in all of the merged PRs to figure out which one did the mess , i want to work it programaticaly so that i can know which pull requests fails the build. What can be the best approach to work on this problem.
One thing that i forgot to mention is that each PR is individually build and tested already before the merge into feature branch.
Thanks.
The best approach is to change your process a bit and only allow merging of Pull Requests that:
Build without errors (including running integration tests)
Are rebased to fit on the tip of your master branch (fast forward commits only)
Since the branch build without errors, and it was rebased on the latest master, merging it will never break master. Unrebased branches that are seemingly without conflicts can still break things if changes in not directly related files conflict with each other as the conflict algorithm is pretty simplistic.
Lacking that, git also has an option that can be used during an interactive rebase to run a command (the exec option) after each rebase step. In other words, you could rewind your branch back to a known working state, and then let git apply each commit in turn and run a command that checks if everything passes your tests with the exec option.
In this way you can automatically discover which commit broke your tests.
Ok, I've got a problem that I have no idea how to go about solving.
First, a bit of history:
I pulled from my upstream to bring in changes and merged them with the branch I was working in. At the time, I may have been using a console window with root access. I say this because I noticed a day later I couldn't save to a lot of the files in my local repo. I noticed the owner / group had been changed to root and permissions were 644. After going through and hunting down all of the screwed up files, I then pushed some changes I had made back to my remote working branch.
A week later (now), and I've added several other commits to an open pull request from my remote branch. In the middle of them was the commit I made after fixing my local repo file permissions. I noticed it has some 1200 "empty" files (no changes). I'm a little concerned that merging this pull request upstream could cause big problems and I have no idea how to remove this one commit or if it's even possible...
I tried creating a new branch and using cherry-pick to get all but the one commit, but I've removed files and couldn't merge the older commits that saw a "conflict" between the file that existed at the time and one that no longer exists in the local repo...
Anyway, any thoughts?
The solution I used was to reset my local branch to the commit just before the one that I didn't want. I then copied and pasted the commits after the failed commit into code, recommited, and pushed toa new branch. Long way around, yes. But it wasn't bad as I didn't have a lot of code to fix. A simpler method might have been to use cherry-pick to pull the later commits into my reset local branch, but I tried that at one point and had problems...
I often see the below errors on doing git pull on totally untouched files which I am NOT working on.
Pull is not possible because you have unmerged files
It is clear the conflicted files have changed in the git repo. But I don't understand why git pull cannot over-write on these untouched files - which I've not touched?
What can I or my team do to avoid getting these errors?
Edited -
Along with the solution I want to understand why the errors are coming.
Just to make clear, the other team members are working on other files (say xyz). And I am working on a separate set of files having no dependency on xyz files. So if I pull the repo changes after a long time with no changes from my side in xyz, why the conflicts in those files?
use git diff to see problem files
look at this git cheat shets for usefull commands
http://www.cheat-sheets.org/saved-copy/git-cheat-sheet.pdf
http://jan-krueger.net/wordpress/wp-content/uploads/2007/09/git-cheat-sheet-v2-back.svg
There are some tips from my own experience. i'm not sure whether they're 100% corerect)
Split work with your team on paralel threads. Try not to work in the same files.
Try to avoid situations when 2 or more persons are adding new files simalteniously. When one added new files others should make pull as soon as possible
the last but not least - make git push very often. this will keep your project git up to date
Since git pull does not pull individual files, it's git merge phase will stop for manual correction of any merge conflicts. git merge and/or git pull (and by nature of the fact that git pull is essentially git fetch followed by git merge) is an all-or-nothing operation - you either successfully merge the changes introduced on both (or all) of the branches you are merging together, or you don't merge any of them. The catch in that is when conflicts arise that must be manually resolved - but in that situation, you are in an in-between state, having neither completed and committed the merge nor rolled it back to your previous state.
The message you are getting implies that you have previously done a git pull or a git merge, which stopped in the middle, requesting that you manually resolve some conflicts, which you have not yet done, but have rather continued on doing other stuff, and are now trying to do another git pull / git merge without ever having completed the first one.
Take a look at git status, and follow the suggested directions for either resolving your in-progress merge issues or resetting back to a not-in-the-middle-of-a-merge state.
I recently re-installed my computer,
and now I'm encountering problems with github for windows (I'll be using GFW in the rest of this text). it say's that my local repo is in sync, but even if I change things, delete files, or add files it keeps saying that it is in sync.
It does check if I make changes on a different computer and push them. but syncing then won't work, so I went to shell
there I can commit (shows in GFW that there are commits ready to be pushed), sync button in GFW still doesn't work (showing that there are problems, and I should continue in git shell). When I commit in shell says that there are changes , insertions, and deletions
Then when I want to push it says Everything up-to-date.
Anyone got any clue what is going wrong?
Check if you are actually on a branch: are your commits made on a branch, or on a "detached HEAD"? (more on this at "cannot push to GitHub: everything up-to-date").
A simple git branch can show you the active branch. If there are none, that would explain why the "sync" button is inactive. You need to fast-forward your branch to that detached HEAD.