when i want to do git commit . thats time i face this problem .
this problem come almost every time when i want to do git commit.
please tell how remove this problem on my computer
That's not a problem. It just means that your local copy of the branch is up to date with the remote (probably on a server somewhere).
Related
When working on a branch together with colleagues, I find it useful to limit IntelliJ IDEA's Git Log view to the local branch I'm working on plus the remote tracking branch. This way, I see all the commits that are relevant to working on this branch.
Every time I switch branches and want to get that filter, I manually select HEAD and the remote branch. I found no way to tell IDEA to always select the current branch and its remote tracking branch.
Is there a way to let the Git Log view select "the current branch's remote tracking branch" once, and have it automatically pick the right remote branch when I checkout another local branch?
I'm currently using IntelliJ IDEA 2019.3.4, but will likely update to 2020 soon.
You can update to 2020 and check new Branches Dashboard under Log tab in Git tool window.
Then you can select local and remote branches and you will get log filtered.
Please see what's new in 2020 here:
https://www.jetbrains.com/idea/whatsnew/#version-control
Also please see and vote:
https://youtrack.jetbrains.com/issue/IDEA-233730
I was trying to migrate an svn repo with history which was working fine but when it comes to the final few revisions it says a name in author.txt not found (due to case sensitivity issue).
It took almost 2.5 days to reach this point.
Is there a way after updating author.txt, we can continue the process from the last state or we have to start it again from starting?
If there is a way to continue it.. please mention the commands and step.
Thanks
I have a clone for server development and another for client development. Both material will eventually make it into the same branch, but I want to synchronize them and I want it to perform a merge as though I had commit pushed and pulled, but I want to do it without that.
I'm able to make a patch with this script I wrote:
git diff --cached
git diff
on the server, but applying that to the client is much harder.
I've tried the Unix patch command, for some reason, it keeps asking me what files to patch, like I can't find them. (Yes, they're there) I've tried
git apply -3 patch.patch
but that gives a lot of errors like "with conflicts" (without making any changes) and "does not match index". It doesn't even seem to be trying to patch the other half of the files.
Stashing, then applying the patch, and then popping from the stash doesn't work, because unstashing refuses to do merges.
It looks like doing it without the pulling isn't going to work--I haven't found a way to do it conveniently and safely. However, my problem with committing is that I didn't want to spam the git log with garbage like:
Sync'ing to client
Sync'ing back to server
Oops! Sync'ing something I forgot to the server again!
etc.
But I can avoid all this by committing, then pulling from the remote repos. In the end, I wouldn't have to push those commits, since I would use reset to remove them all from the local repo and then, with all my changes in the working directory, do a proper commit and push it.
Gotachas
They are many.
It's commonly known that you shouldn't reset your local repo if something has already pulled from it. This is probably from the obvious confusion that results when one repo delete commits that another repo believes were there. For that reason it's important that the same reset is performed on both repos before they start sharing code again.
If after you've done your commits that you later want to reset, then pull/merge, you could make things very difficult for yourself. There should be a way to manage it, but I haven't yet figured it out. One idea is to reset, stash, pull, merge, and commit again. Another involves revert with the -n option.
Instructions
The following example assumes you have 2 clones; one called "client" and the other "server".
Following https://help.github.com/articles/adding-a-remote, setup your client's and server's repo on each others' systems to they can pull from each other.
When you want to sync, just commit on the donor system, then instead of pulling from the origin, pull from a remote. Say the client wanted a commit from the server. On the client:: git pull myserver-repo mybranch.
Merge and conflict-resolve as necessary.
Loop back to 2 as many times as is necessary.
After several iterations of 2-4, you arrive at the point when you are ready to push your changes to the server. Go to whichever local repo has all the changes you want pushed, then run git log. Find the commit before the first commit you did in 2. Copy its hash to the clipboard.
Then git reset: git reset <hash you copied in 5>.
You should then see all the commits you don't want disappear from the log and all the changes therein in your working directory. Commit and push.
It's important that you do a cleanup on the repo from which you didn't perform 5-7. So if you pushed from your server repo, you need to perform the same reset operation on your client, then dispense with the changes as you see fit. My preferred method is git stash save "delete_me".
I created a shared repository on my laptop. In that repository, I created a branch named trunk. Then I created an unbound branch of trunk on my desktop so I could do work on either machine and sync my changes manually.
This works pretty well except for one nagging issue. On my desktop, Bazaar Explorer is forever trying to reach the remote branch. Every time I hit Refresh (for example) Bazaar Explorer hangs for several seconds while it does ... something. If my laptop isn't on the network, Bazaar Explorer hangs for even longer and then displays the error message, "Not a branch: <branch URL>". Afterward, I can proceed as normal.
One of the reasons I switched to a DVCS from Subversion is that you can keep on working and commiting even when "the server is down". Technically, I can keep working, but the constant freezing is killing it for me. Is there a solution?
Edit .bzr/branch/branch.conf and remove the line with parent_location = ....
Note: later if you merge or pull from another branch, it will again save the parent_location. To prevent it from doing that, add the --no-remember flag when you merge or pull.
As #bialix pointed out in a comment:
if you want to disable remembering of parent_location you can also edit branch.conf and put there: parent_location = that is nothing (or space) after equal sign.
Hit the following situtation a couple of times today:
Myself and another dev both have bazaar local checkouts of a repository.
I make some changes.
The other dev makes and commits some changes.
I update.
The other dev realises their previous changes were broken and uncommits them.
I update.
Now the other dev's uncommitted changes appear as a pending merge in my local checkout, and I can't find a way to separate them from my changes and remove them from my 'local' tree.
Every time this has happened I've had to manually work out which changes are mine and which are not, save my changes, revert, and then re-apply my changes.
I've tried doing a "cherrypicking" reverse merge on my checkout between -r -1..-2, and between -r 0..-1, but neither helped. (0..-1 said "nothing to do", although I might not have done it properly. -1..-2 was the wrong set of changes and thus made things worse.)
How can I fix this situation when it happens (other than going over and smacking the other dev upside the head)?
It is recommended that you don't uncommit in branches that are published somehow, thus avoiding this issue.
Well once you have updated (step 4), the other guy's changes will be merged with yours permanently. Since your changes were uncommitted, they aren't stored anywhere. Therefore, once step 6 has happened, I don't really see a way of automatically separating out your changes from his.
So let's say you manually remove all of his changes so you're just left with yours. You still have this pending merge to deal with. You can fix that by typing
$ bzr revert --forget-merges
That will not change your working tree; it will only remove the pending merge from your "bzr st" so that when you commit it will not look like a merge. This should save you from having to save your changes, revert and re-apply.
To avoid this happening again, you could run bzr update only immediately before you commit. Once merged, to a bzr commit right away, and your changes are locked in. Now he won't be able to uncommit without first updating and seeing your changes, and now it's probably too late for him to do that. If he really wants to go ahead with his uncommit, he's the one that has to deal with the mess, not you.
One final thing you can do -- if you really don't want to deal with it and you don't care too much about having a nice version history. After step 6, just commit. Maybe explain in your log that the other dev uncommitted this change but too late.
This is where the pending merge comes in. If you commit, the uncommitted revision will go back into the repository, as a branch, just as if the other dev had send those changes to you in an email and you merged them. It will look like this:
------------------------------------------------------------
revno: 34 [merge]
committer: You
branch nick: trunk
timestamp: Fri 2010-11-26 15:57:27 +1100
message:
Made my changes to the file.
Note, other guy did some of these changes and uncommitted, but
I already merged.
------------------------------------------------------------
revno: 33.1.1
committer: Other Guy
branch nick: trunk
timestamp: Fri 2010-11-26 15:39:39 +1100
message:
Made some changes to the file.
------------------------------------------------------------
When he runs update again, he'll have his old changes thrown back at him, and probably get a conflict. He'll have to clean it up, then commit his fixes (whatever reason he had to uncommit in the first place). This is probably just as effective as a smack upside the head, and works over a network :)
It looks like bzr pull --overwrite :bound is what you're after.