I'm stuck at the following problem:
This is what I want:
a git command, that I can use to show the 'US' changes
it should work like status, (show what I did) in comparisation to the remote
This is what I tried:
git diff [in JGit -> diffentry] with many options e.G. master..branchName
I tried to find a git status cmd, that does work with 2 commits.
I watched through the whole diffEntry[JGIT] methods to find a method to get my desired Output
I googled for JGit methods, that will show me my desired Output
To 1. -> The problem is : When I change a file on remote, the git diff command shows the file as 'M' for modified, but the user did not modified it, it may be true, but is not what I search
To 2. -> git Status is something I'd like to use, because it shows exactly what I want.... but only from index to head...
For what?
I want a list from all files that the User had modified/added/deleted so I can iterate through it and put head informations in every file, just before he pushes the file.
Hows the workflow?
I clone a branch, do N-commits and now I want to push.
Every file in this N-commits must be modified. (and that's the Problem with this modified, if it's modified in the remote branch, but not locally, than I should not touch it with my script, but I have no way to differentiate between this two)
€dit: Additional Infos
git diff-index does nearly what I want.
The problem: I need to filter only 'our' changes. So if a file is modified on remote, I dont want to see it. I want to see MY modified files.
If you want to see changes on Your side only, you should update the index before you diff, so run git fetch <remote> <branch> and your index tree will be up to date, after this you can run git diff-index <branch>
you can add the --diff-filter=ADM if you want to select only files that are Added (A), Deleted (D), Modified (M)
Related
I have created two branch with the same feature/Dev23 and feature/dev23.
At the time of checkout in IntelliJ I was getting "there exist a branch with the same name".
So I deleted one (feature/Dev23) and checkout the new feature/dev23.
But now I want this branch as well.
I am expecting the branch to be seen in Bitbucket and retrieve it properly.
But now I want this branch as well.
From a command line, check the output of git reflog: you can use said output to recover a deleted branch (assuming it was deleted recently)
git switch -c feature/old-Dev23 HEAD#{**number**}
If feature/Dev23 is not listed in reflog (because you never switch to it), check the output of git branch -avv, and:
git switch -c feature/old-Dev23 origin/Dev23
Note I use a different name to re-create the branch, that way it does not interfere with your new feature/dev23.
See this answer bon branch name case sensitivity.
I need to sequentially check out tags over a branch I created with JGit.
CheckoutCommand checkout = new Git(testRepository).checkout();
if (!branchExists())
checkout.setCreateBranch(true).setName("branch-for-test").setStartPoint(key);
else
checkout.setName(key);
checkout.call();
Where key is a String which contains the name of the commit I want to checkout (key changes in a loop). I don't want to create a branch each time I checkout as I don't need to. The following error is shown:
org.eclipse.jgit.api.errors.JGitInternalException: Could not rename file target\TestRepository\server\db\scripts\postgresql\._db_script.sql6197897692249726905.tmp to target\TestRepository\server\db\scripts\postgresql\_db_script.sql
at org.eclipse.jgit.api.CheckoutCommand.call(CheckoutCommand.java:320)
Before this happened I was trying to checkout inside the else statement with
checkout.setName("branch-for-test").setStartPoint(key);
It did not throw any error but it did not checkout the tag either.
Well, it seems that using JGit in Windows may generate conflicts related to managed files sometimes. What I made for solving this recurrent issue was to execute a git clean --force followed by a git reset --hard before each git checkout <ref_name>. This was totally fine for me, as I didn't need to stage changes...
The problem was that basically after using some files (even in a read-only way), they were marked as changed (I verified it with git status). The solution explained above implied more operations, but totally solved my problem.
For further details, refer to git documentation about these actions:
Git clean: Removes untracked files from the working tree.
Git reset: Resets current HEAD to the specified state.
And develop the appropiate implementation of these two actions with JGit:
Clean with Clean Command.
Reset with Reset Command
I have working on local brach in my computer; moreover, I have one public Github account. The only author of the code, as you guess, is me. Whenever I want to git push origin master, I get you should merge before pushing error, so I always does pull origin master and then git add .. & git commit -m "merged. However, this lines of code sucks my code. In other words, in my code, I see <<<<<<<<<head, hash code and merged version of old and new code in same file. Even if I am only author, my Github account does not recognize my past and always pushes me to merge the old version with new version in the same file. Moreover, automatically, add <<<<<<<head sort of lines in my code. How can I clean merge, no <<<<head sort of things or no merging old with new one in same file, my new version of code with old one ( not to prefer using without using -f flag)?
I am using Git shell in Windows.
tl;dr JGit's checkout throws exceptions while command line git checkout works fine
I'm currently trying to use JGit to check out certain revisions from an online Git repository, in Java (for work). My current approach is (and I'm very new to Git, coming from a SVN background, so this may be wrong):
clone the repository to a temporary location on my hard drive
figure out which revision I want, (I have tried using the SHA-1 hash as well as the name of a branch)
checkout that revision
from there, I would be using the checked out files as inputs to a later part of the program.
checkout a different revision
use those files as inputs to another part of the program
Essentially, I want to be able to swap the contents of my temp folder with whichever revision. With the command line interface I've been able to do this with git checkout master and git checkout dylanbranch (where dylanbranch is a branch I made on my own clone with an arbitrarily chosen revision), but my Java code attempting to do the same thing fails:
Git git = Git.open(new File("checkout")); //checkout is the folder with .git
git.checkout().setName("master").call(); //succeeds
git.checkout().setName("dylanbranch").call(); //fails
And the exceptions printed to the console:
Exception in thread "main" org.eclipse.jgit.api.errors.JGitInternalException: Checkout conflict with files:
src/sizzle
test/qunit
at org.eclipse.jgit.api.CheckoutCommand.call(CheckoutCommand.java:211)
at com.avi.scm.git.BranchCheckout.main(BranchCheckout.java:30)
Caused by: org.eclipse.jgit.errors.CheckoutConflictException: Checkout conflict with files:
src/sizzle
test/qunit
at org.eclipse.jgit.dircache.DirCacheCheckout.checkout(DirCacheCheckout.java:387)
at org.eclipse.jgit.api.CheckoutCommand.call(CheckoutCommand.java:162)
... 1 more
I can verify that the files in question are marked as deleted and not staged for commit by using git status though I'm not sure why those changes are there, and they come back any time I switch back to the master branch. Despite that, I can still successfully change the working tree with command line Git.
So my question: Why won't JGit work for this application when command line git will?
Any other helpful information is appreciated- educate me :)
Update I've been testing with the jQuery repository, and have noticed a few more problems with JGit: When I am working with the "master" branch, git status temms me that I'm #On branch master and that there is nothing to commit (working directory clean), but using JGit's status command I see that test/qunit and src/sizzle are marked as Missing. JGit's reset seems to do nothing.
The two directories mentioned in the stack trace are Git submodules (test/qunit and src/sizzle) which is most likely the cause of the problem since JGit does not have full submodule support yet.
This may function differently in the 1.1 JGit release due out this month based on this commit.
You can read more about the current state of JGit submodule support here.
I know this doesn't directly answer your question, but I've also had problems with the Java implementations of Git. What worked best for me was to simply ditch the java implementations, and execute command-line calls to git from within the application. It may not be ideal, but it'll do exactly what you want since you'll fully control the command.
Simply call
Runtime.getRuntime().exec(...)
Link to Javadoc for Runtime class
I had a similar problem with Checkout. I think that the fact that you can switch branch with unstaged content in Git is actually a tolerance, not a feature.
JGit is globally not as tolerant as Git, so you should usually test many cases.
It seems it is not directly your problem (which is related to the submodules), but for more general cases you would want to commit your changes before using checkout to switch to another branch.
Note that the CheckoutCommand works perfectly for me to start a new branch from an old revision (you have to set the name of the branch and the start revision).
I am playing around with Mercurial to see if it is suitable for use in our company. One of the big selling points of it is the merging capabilities. So I have been playing around with creating branches and merging them back into the default line. The tested involved simply adding a new method (methodA) to a single Java file in one branch, and adding a different method (methodB) in a completely different place in the same file in another branch.
When I first tried it in Eclipse using the team-> merge option I found that the first merge worked fine (i.e. it added method A). When I try to merge the second branch now it tells me there is a conflict that I must resolve. This is very unfortunate as I thought this simple kind of merge was exactly the kind of thing Mercurial was supposed to handle with ease?
I tried the exact same test using the command line, and this time it worked fine, i.e. both of the merges were successful with no need to resolve conflicts. Looking at the console output in eclipse it is using the following command to perform the merge:
hg -y merge --config ui.merge=internal:fail -r 611ca2784593525cdafd3082b17d3310037a5d58 -f
whereas when I run it myself from the command line I simply do:
hg merge -r 1234
Is the use of the merge strategy 'internal:fail' causing this to happen within Eclipse?? And if so is it possible to change the default behaviour so that it works the same way as it does at the command line?
The internal:fail tells Mercurial to not to try merge anything at all. See the mercurial wiki for more details.
It seems whomever wrote the Eclipse plugin for mercurial felt they could better control the merge in eclipse by having Mercurial automatically fail to merge everything and then to do the merge in Eclipse, and presumably call hg resolve --mark ... as files are merged.
From the Mercurial command line you're getting both the premerge behavior which handles trivial merges, and then if there are still conflicts the invocation of tool from your MergeToolConfiguration that has the highest priority for that file type and is available on your local system.