We Keep Coding

Git: Finding files where only serialVersionUID changed

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.

How can I watch any particular file / directory based upon any file(located under specific directory if directory base watching) attempt for OPEN?

I want to execute few task based open targeted file's OPEN event.
For example, I am watching Sample.docx & whenever user will go for OPEN it, few subsequent task will be performed based upon it's OPEN action.
I have searched on internet & find out few solution but that are based upon file's MODIFICATION & DELETION operation. none of them shows based upon OPEN action which is actually I am looking for.
Any hint/suggestion would help me.
Thanks.

That is an operating-system specific functionality and is not something Java comes with out of the box. If you are on Windows you would use a FileSystemWatcher which exists in .NET, but if you need it in Java you would have to create native bindings if there isn't a library that already exists. Chances are this does not exist as not many people would have a valid use-case to do this and I don't think security people would be happy to see this either.

You could I suppose, in a specific thread, regularly poll currently running processes to see if the file name is contained within a process title.
As for .docx files for example, WORD would have this as its process title:
Sample.docx - Microsoft Word
You would need to utilize a JNA method named getAllWindowNames() to acquire a list of Window Names. This method works quite well. When Sample.docx is detected within the acquired list then start whatever file or files you like.
Keep in mind however, your Java application would need to always be running in the background and because of file association (as mentioned to you in a previous post) this technique would run the files you have associated with Sample.docx regardless of how the file was run (from a double-click in Windows Explorer, a shortcut on Desktop, opened from MS WORD itself, etc).
I have actually created a small demo application that does exactly what you are trying to accomplish however it is too large to post here. There is no tutorial that I know of for this sort of thing, it's just a matter of doing it....that is if the concept appeals to you.
Yes!...most people would not want this sort of thing dancing around on their System(s).

Java Camel RouteBuilder picks up file before copying is complete

I am using Ubuntu (in case it will make a difference) and I am trying use Camel to send files to processor from one folder. But the problem is that when I am saving this file in the folder (takes about 5-10 seconds) Camel picks it up straight away.
To simulate the process I am using gedit with txt file with ~500k rows so it will take some time to save.
I have tried adding options:
from("file:src/Data/new/?readLock=changed&readLockMinAge=3m")
I have tried using
.filter(header("CamelFileLastModified").isGreaterThan(new Date(System.currentTimeMillis()-120000))) to give 2 minute delay.
Nothing seems to influence its behaviour, it picks it up straight away, throws an exception because of some checks while processing file and moves it to the Error folder.
I know there is an issue with FTP file transfers which I will have to face later on, but I can not even get it working on local file system.
Any help will be appreciated!
SOLVED
from("file:src/Data/new/?readLock=changed&readLockMinAge=3m")
Parameters actually work as they should. I was using Jetty to run the project and I should have done whole project clean/install after any amendments.
I had to amend parameters a bit to:
from("file:src/Data/new/?readLock=changed&readLockTimeout=65000&readLockMinAge=1m")
because it was complaining that readLockTimeout should be more than readLockCheckInterval + readLockMinAge.

Have a look into the documentation:
Avoid reading files currently being written by another application
Beware the JDK File IO API is a bit limited in detecting whether
another application is currently writing/copying a file. And the
implementation can be different depending on OS platform as well. This
could lead to that Camel thinks the file is not locked by another
process and start consuming it. Therefore you have to do you own
investigation what suites your environment. To help with this Camel
provides different readLock options and doneFileName option that you
can use. See also the section Consuming files from folders where
others drop files directly.
So I think the doneFileName option will solve your problem.

Is Git Smart Enough to Merge After Refactoring

Assume I have a class.
package org.my.domain;
public class BestClassEver{}
My Workflow
Through some refactoring, I change this class's package.
package org.another.domain;
public class BestClassEver{}
I commit this to my local repository using git and push it to a remote repository.
git add .
git commit -m "Refactoring"
git push origin master
Another Developer's Workflow
Another developer modifies the class, without pulling my changes.
package org.my.domain;
public class BestClassEver{
private String something;
}
Then commits and pushes to the remote repository
git add .
git commit -m "Some Changes"
git push origin master
Questions
Will Git merge the other developer's changes into the class?
If not, what happens?
Is this workflow something that needs to be coordinated amongst the team?

Git won't allow the other developer to push his changes without pulling.
It will throw an error that both refs don't match and therefore his local branch needs to be updated with the remote refs.
That's pretty much all there is to know about that. If there are changes in the remote repository, unless you do a forced push, git won't allow you to push changes if there are changes in the remote.
EDIT
Once he pulls, if there are any conflicts in the file, the developer will have to correct any conflicts, commit them and only then he will be able to push.
If there are no conflicts, git will automatically merge those changes and the developer will be able to push after the pull.
EDIT AGAIN
I didn't realize that you were moving the file. In any case, running git status would give you an idea as to the state of your local repository after a pull. If there was any conflicts, you'd be able to correct them.
NOTE
On git rebase or git pull --rebase are usually used to give you a much cleaner commit history as they will pretty much will apply any local changes on top of any other changes that were pulled.
On the other hand, git pull and git merge will usually make an extra commit to link the changes on the branches.
For more information take a look at this guide Git Rebasing

It is always good idea to let people work on different parts of program.
Merge or rebase in this case should be fully automatic, but in real world it is always a bit dramatic and sometimes there are some conflicts. Of course, this merge/rebase will be done after server rejects push for beeing non-fast-forward.

When such thing fails, some workarounds include:
Just repeating "refactoring" in the other branch prior to merging;
Converting the work to patch (git format-patch), editing the patch (applying that "refactor" to it) and applying the edited patch (git am). It is like manual rebasing.
I think it's better to separate merge-complicating refactoring (one that involves renaming, for example) and usual minor refactoing.
Sometimes for a merge-complicating refactoing a script can be written (such as find -name '*.c' -exec sed 's/something/anything/g' -i '{}' ';'). The script be used to repeat the refactoring multiple times in various places when we need it, so avoiding to merge refactored code with non-refactored one.

YES. Git is able to identify those changes. I am working on a project using git on my own fork (forked from origin). In the meantime another developer refactored the codebase on the original fork, which includes changing package structure.
I used the following commands:
git stash save // this saves all your work onto a personal stash
git pull // fetches all the latest changes on the primary fork and merges
git stash apply stash#{0} // or whatever the stash is where you saved your personal work
Now you will have the refactored codebase+your changes. You can now commit without any conflict and the packaging will not be changed.
Just note that in my case I waited for the original fork to be refactored and then I committed my changes, which are only changes to few files and not repackaging.
Also note that if you have added new files, then you might have to edit a few imports to make sure the imports are correct.
eg. import org.my.domain;
should now be edited to: import org.another.domain;

Is there any way to view Netbeans development output in a tabulated form or a seperate application?

I am building a Java EE application using NetBeans 7.1.1. I would prefer to view the output from the Glassfish server and Ant building process in a separate application. I've set up OtrosLogViewer to tail the glassfish server.log file as well as the applications log4j logs. But I haven't figured out how to tail the ant build log. Nonetheless, while these work I'm hoping for a more elegant solution. (FYI: tail is a linux command that watches a specified log file and updates the output when changed, somewhat like the event viewer in windows)
What I like about OrtosLogViewer is that it uses a pattern to place the information into a tabulated table. That simply makes it easier for me to view what's going on behind the scenes without getting overwhelmed with stack traces. For instance, it's easy for 70% of the log to be taken up with the stack trace. Essential IF I need it but otherwise it's in the way.
Some alternative solutions:
A way to modify the logging output for netbeans in a tabulated table.(A plug-in maybe)
A way to send all the output from netbeans into a specified log file(s), which I can then tail with the application of my choice.
Any other ideas that makes it easier to view application debugging information

Since Ant calls a variable number of other tools while executing your build script, you are never going to find a perfect pattern for the format of it's output - the best you can do is match output like
[javac] Compiling X files...
[echo] compilation done
with a format like [tool] message.
In other words, each component called in the Ant build script is likely to have different ideas of how to format the output.