I know this could've been a question previously asked, but I am not sure it was answered properly.
I am trying to fix merge conflicts when merging to the master branch. So what I did was, I checked out the master branch, did a git fetch, git pull, then checked out my feature branch, and fixed the merge conflicts I needed to fix.
Now, all the files I have fixed will need to be manually added, then committed, then pushed to the master branch. That, I understand.
However, a lot of files showed up in the Changed to be committed section, that are already on the master branch, when I checked the git lab repo.
My question is, am I supposed to keep those and commit them alongside my changes? or should I remove them and just commit and push my changes?
I have tried following this After a Git merge conflict, a lot of files I didn't touch become changes to be committed, but I didn't find it pretty helpful.
If you git diff each file to be commuted with the main branch you should see only your core changes, not the merged changes.
For example: if you are using a tool like IntelliJ, if you right click on an uncommitted file and git compare it with the main branch, only the “new changes” should be highlighted, the merged changes should not be.
I have a set of auto-generated java files which are checked into git. Each file contains the line
final static long serialVersionUID = -4268385597939353497L;
where the part after the serialVersionUID is changed to a random number on each regeneration.
Note: This is set in stone and I am aware of "not checking generated code into version control etc.".
How can I identify all files where only the serialVersionUID changed?
Changed means the files are modified in the working copy, but not committed yet.
My goal is to revert those files via pre-commit hook.
I've come as far as either
git diff -U10000 --raw MyFile.java
which gives me a diff of the whole file
or
git diff -U0 --raw --word-diff=porcelain MyFile.java
which gives me a "diff header" plus a list of changes.
Note: this particular StackOverflow answer doesn't solve your problem (I literally can't solve it properly as I don't have a Java parser). It's all about all the other stumbling blocks you're going to run into, and how to avoid them so that your task really is only the Java-related part.
It's important here to note that there are three copies of every file here:
the one in your current commit, HEAD:MyFile.java (use git show HEAD:MyFile.java to see this one);
the one in your proposed next commit, :MyFile.java (again, use git show to see it); and
the one in your work-tree, MyFile.java, which you can see and edit directly.
The git diff command will, in general, pick two of the three to compare.
Running git diff with no arguments, or with arguments that select only a file (not a commit), compares the index copy of the file with the work-tree copy. It does not extract the currently-committed file. The index copy is the one that git commit will write to a new commit, so it is, in effect, what you are proposing to commit now.
Using git diff --cached tells Git to compare the file(s) in HEAD to the file(s) in the index. Using git diff HEAD tells Git to compare the file(s) in HEAD to the file(s) in the work-tree. So these are how you select which pairs of files get compared. But no matter what, each git diff just picks one pair of files, or one set-of-pairs if you let Git compare all the files.
If you run git commit -a—and I recommend that you don't, here—that's roughly equivalent to git add -u && git commit, except that it builds a temporary index with the updated files. Things get particularly tricky in the various commit hooks here since there are now multiple different index files with different proposed-next-commits. That's why I recommend avoiding git commit -a here. It's already hard enough to work with, and reason about, three copies of a file, and using tricky commit options, such as -a or --only or --include throws a fourth and even sometimes a fifth set of copies into the mix.
(Git can only deal with one index file at a time. A standard git commit has only the one standard index file. The standard index file has copies of the files that would or will go into the next commit.1 The options cause Git to create additional temporary index files, into which it builds the proposed new commit, then run the rest of the operations—including your hooks—with $GIT_INDEX_FILE set in the environment to make these sub-commands look at whichever temporary index is to be used. If all goes well and git commit winds up making a new commit, one of these various temporary index files, with whatever contents are appropriate based on the options and arguments, becomes the new index, after which you're back to the normal situation with a mere three copies of each file.)
Since your plan is to work in a pre-commit hook, you probably should compare the HEAD files against the proposed-for-commit files in the index, i.e., you should probably be using git diff --cached here. However, if you intend to do this by computer program, rather than as something a human peruses at leisure, you should not be using git diff at all. The front-end git diff command is meant for use by humans, which is why it paginates and colors the output and does all those kinds of things that just annoy computer programs. Git calls these fancy front ends porcelain commands.
Each kind of git diff is implemented by a back-end plumbing command. The plumbing command that compares a commit—technically, a tree—to the index is git diff-index, which still needs --cached to tell it to do the desired comparison: git diff-index --cached HEAD produces predictable output, that does not depend on each user's preferred pager, color styles, and so on.
(If you're writing this hook exclusively for your own use, you can use either git diff or git diff-index since you can compensate for your own personal git diff settings. But it's better, in a sense, to use the plumbing command anyway—then there's no need to compensate for anything.)
Whatever you choose here, you still have to write your own code to interpret the diff output. You might instead choose to write a program that simply extracts the two files of interest—HEAD:MyFile.java and :MyFile.java, that is—from the current commit and from the index, and compare them in your own program, rather than using git diff at all. You can extract the files using git show, but that has the slight defect that it's another porcelain command. You can use git cat-file -p, which is the underlying plumbing command, to extract the files directly, without going through git show.
Actually parsing the Java code would be the most reliable method, so that you don't get tripped up by some sort of silly formatting change. A more-hacky method such as assuming that everything must match except for one line of some specific form would be not too difficult in, say, awk (read both files one line at a time, check that only one line is different in the two files and that it has the expected form). All of these seem likely to be simpler than trying to parse diff output, though if you want to parse diff output, a non-Git non-context diff might be simpler.
Finally, regarding:
My goal is to revert those files via pre-commit hook.
This is OK to do (Git will handle it correctly, for some definition of "correct"), but it's also a bit surprising to many Git users. Git hooks like this are not supposed to change things. The intent of the people writing Git is for Git hooks like this to merely verify things. If something fails the verification step, the hook should exit nonzero, which will cause git commit to stop. Any fixing-up is supposed to be done by some non-hook operation.
Note that git commit --no-verify skips the pre-commit hook entirely.
1Technically, an index has references to read-only copies of each file. Because these copies are read-only, they can be shared. So "copying" an index is cheap, because it really just copies all the references. Also, every file that's in the proposed new commit that's 100% bit-for-bit identical to a file that's already in some existing commit, is really just a reference to that file, since every file stored within every commit is itself entirely read-only.
I have recently moved from an old database migration provider to flyway (4.1.2). In our setup we have - as usual - some incremental scripts and scripts that are repeatable. So far things have worked well and I was able to recreate most of the behavior we had before with some improvements thanks to flyway. However I am experiencing weird behavior with repeatable scripts.
Lets imagine the following scripts:
DELETE FROM CONFIGURATION;
INSERT INTO CONFIGURATION (KEY, VALUE) VALUES ('SAF_DELAY', '22');
it gets executed when created and does what it is supposed to. Also an entry in schema_version is created with the checksum. Now I change the 22to 23and run flyway:migrate again, the script is executed and creates a second entry in schema_version with the new checksum. A while later I realize that the 23 is actually bad and 22 was right from the beginning so I change it back.
Now flyway refuses to execute the script again telling me that everything is up to date even though the script has changed from its previous state. I am assuming it does so because it can still find the old entry in the schema_version.
Obviously that is undesired behavior for a repeatable script, the decision point should only be the last executed checksum and not any checksum that ever executed of the script. This is also what I assume the documentation means by "Instead they are (re-)applied every time their checksum changes." I was looking through the configuration section of the maven plugin but could not find anything that seemed like a solution.
Since this is kind of a deal breaker for me I would be happy if you could hint me to the right direction.
I program Java using Eclipse and SVN in my company and one of the commit rules it's that each commit have their own purpose, and it's always one.
Sometimes I can get some work done but can't publish it on the server until the end of the day (it will break the build) and then I have to do some other work (non related to the first) and commit it, but if I do that I'm commiting changes related to 2 tasks.
What I want here it's to have a way to say to Eclipse that I want to separate those changes and on both of the tasks I want to work with the trunk code. So, basically it's a branch, but that never existed, in order to let me make separate commits. I thought about having N eclipse workspaces working with the trunk code and use each onde for each change, but that seems overkilling.
Is it doable?
In Intellij you have changelists that you can commit separately. Maybe this question can help you further on your way: Changelists in subclipse
The only way I can think of doing it so that you can make two different sets of changes within a single file is to checkout a second working copy for the second tasks set of changes, and work on those independently. When either task is complete you can commit the changes made in that working copy, and update the other working copy before committing that once it builds.
I am trying to add Commit Comment messages at end of the Java source file to keep track about the file revision whenever we commit the file to SVN.
Please let me know the syntax. I tried with $Log$: it is not working. one of my projects in the earlier date i remember i used. I don't whether it is Server specific.
You shouldn't do that. Really. SVN is there and has all the history of the file. And it's able to handle branches, which this strategy won't be able to handle.
It's not supported by SVN, for good reasons, explained here: http://subversion.apache.org/faq.html#log-in-source