So I'm not sure if this is possible but I'm hoping it is. Basically, we just moved to SVN from Sourcesafe (I know a lot of you almost threw up in your mouth just now ;)) and I'm setting up eclipse to work with it. I installed Subversive and have a repo set up with my project. Just FYI, I'm working on an Android project written in Java. Here's what I want:
As I'm working on each Java file making changes, I want to write the SVN Commit Messages right their in code just as I add javadoc comments. This is because I have to change a ton of files before I commit and I want to remember each thing I changed (client requirement). But I don't want to have to remember all of that (especially as I'm deleting a lot of code) and them add the comments when I commit all my changes from all my files. Ideally, I simply add some tag and then the commit message that SVN understands and as I commit the file, I don't have to manually add the comments but it gets done automatically based on the commit messages tagged in my source file?
As an example, say I deleted a function foo in footest.java, I would simply type in the following in footest.java:
// __ (hopefully some tag here) deleted foo
Now when footest.java is commmitted, I don't have to type anything, the commit message 'deleted foo' gets added to it.
Finally, ideally, this is done automatically per revision. That is, once I make another change in footest.java, say, added function newfoo(), I could tag it like before with comment "added newfoo()" and when I commit only "added newfoo" comment gets put on the revision and not the one for the previous version "deleted foo".
Is this possible? Any issue anyone sees here?
Thanks,
-Vivek
Generally speaking, mixing your commit messages & your code is discouraged.
Subversion (or any client I'm aware of) has nothing of the kind built in, because it would require knowledge of the code itself and your custom markup.
You would need to write a wrapper around svn commit (or your client's equivalent) to process your files.
But have you considered that to do this right, you'd also have to remove those comments from your code once you've committed the changes? Now you're into your wrapper script messing with your code - and a bug there could break your code, either introducing subtle, hard-to-find bugs or rendering it impossible to compile.
Why not just keep a text file on your desktop with your notes? Or make smaller self-contained commits instead of delaying until the point where you've forgotten why you made some of the changes?
Related
I have very confusing issue with conflicts during pull request at bitbucket. I have 137 conflicts like those below. How to fix it and prevent this from happening in the future? It's Android Studio's project on macOs.
As you can see I've just added some lines, but git treats it as conflicts.
Below you can find conflicts with merge.conflictStyle=diff3.
I still have no idea why it's conflict instead of edition.
Your diff3 screenshots provide the answer. (Aside: don't use screenshots here. Cut-and-paste the text directly. In this case that should drop the gutter information with the line numbers, but that's OK. See How do I ask a good question.)
Remember that in Git, a merge is about combining work. There are three commits involved:
You, on your branch, started with some commit. Git calls this the merge base commit.
They, on their branch, started with this very same commit.
So Git first runs two git diff commands (or the internal equivalent anyway). One compares this merge base to your version of the code, and the second git diff compares this merge base to their version of the code.
I'll start with the middle conflict.
The diff3 style diff includes the merge base code (from commit ce442625), where we can read—I have retyped this, so I may have added some typos1—that the original line said:
chage_lang.setOnClickListener { openDialogToSelectLang() }
This is clearly defective: it should read change_lang rather than chage_lang.
In your commit, in HEAD, you kept this line but added one more blank line after it. This is one "diff hunk".
In their commit, in feature/dark_mode, they fixed the spelling and replaced the single blank line with a non-blank line, to get:
change_lang.setOnClickListener { openDialogToSelectLang() }
change_theme.setOnClickListener { openDialogToSelectTheme() }
Here, Git does not know whether to keep your added blank line, or keep their removal-and-replacement of a blank line; it does not know whether to keep the wrong spelling, chage_lang, or use the corrected spelling, change_lang. So it produces a conflict: you must select the correct resolution.
Just below this, the last conflict is similar: the merge base version says:
android:layout_marginTop="#dimen/standard_margin"
android:background="#color/white"
In your version, you *changed the first line" to read "8dp" and kept the second line intact, but in their version they kept the first line intact and deleted the second line. Once again, Git does not know whether to take your version, their version, some combination of both, or what. You must choose the correct resolution here.
The first diff is the most confusing: here, the set of lines taken from the merge base version is empty. The change on your side is that you added one blank line, while they added one non-blank line reading:
setBackgroundColor(ContextCompat.getColor(context, ...
As in both other cases, Git does not know whether it should add your blank line, or their line, or both, or neither, or what. You must choose.
Edit the file in question to have the correct combination (and to no longer contain the conflict markers), or use a merge tool to achieve the same effect. Then use git add on the resulting file, or use a merge tool—probably the same merge tool, all as one thing—to run git add for you. The git add updates the copies of the files in Git's staging area so that Git knows the correct resolution.
(Git assumes that whatever you told it is correct, is correct, so be sure you tell it the right thing here! In other words, make sure the entire file is correct. Usually that means you should test your merge resolution before giving it to Git. That's one reason I don't like git mergetool: you do the merge, and then git mergetool immediately tells Git it's right, and if it's not right, you have to start over.2)
1This risk-of-typos is why the "ask" page suggests using cut-and-paste.
2You can start over with just this one file, and/or edit-and-debug it without re-creating the conflict, but it's now harder to see the original three input files. Using git checkout -m to re-create the conflict works, but that loses your resolution. Once you know exactly what you and Git are doing, there are workarounds for all of this, but overall this whole user-experience seems like a bad one, to me.
For a mistake i've overwritten my two project that has same names from android studio and i've dismissed that action today i've tryed to open the main project and i've found no Java classes in it and just the layout's files.
While in the second project to which i was overwritting there is a huge confusion of files and trying to recover the project version by using history of Android Studio even those files has disappeared.
Is it possible in anyway to recover the whole project?
Ps: all that remain from that project is a generated apk.
I have some solutions that may work.
Candidates are:
Search for $AppData$ folders
Search for registries
(Hardest) you may have to preserve the disk state and carve the files yourself..
Cheers, and hope it helped..!
To use the third method(file carving), you may not cause many file operations occur!!(The system may overwrite the previous data)
Hopefully you used source control such as git or svn and it is a simple matter of reverting to the last commit you made, however that is done in your chosen source control. If you don't use source control, perhaps this will serve as a lesson to do so in the future.
I've not used Android Studio, but as a JetBrains product like IntelliJ, it will have a local history record of changes. But that would only record very recent changes.
If that doesn't work, you may have to find out if your chosen operating system backed up the files in a restore point etc.
If you have turned on the file history, you can use that to go to a previous version of the folder. Can also use system restore to go back to a previous date. Can also use third party softwares such as Recuva to get deleted files back.
Make sure to keep a copy of current state somewhere before trying these out.
A very common thing that I tend to do is when I need to update a graphic or something in the drawable-nodpi folder, or any other folder for that matter, Android Studio doesn't detect the change so of course when I try to "PUSH" to GitHub it doesn't actually push and just tosses me the "No Changes Detected" message.
Is there a way to push anyways? Just to force a commit on specific files that I want to push because I know for a FACT there was a change and I need it submitted?
Lately I been having to delete it first from within Android Studio, then save the file, then add it to GIT then try a commit, but even this works only 70% of the time and is very annoying.
Perfect Example.... I have a splashimage.png in the drawable folder, I am in Photoshop and I change something then do an override to the splashimage.png with my change, but of course Android Studio doesn't see this as a change so I can't Commit this file to Git or anything.
Are you using external editors like photoshop when editing files? If so, press refresh in Android Studio to make it detect changes in file system. Then it says something has changed and suggest you to commit. Of course you can use command line to add changes anyway and commit without even using Android Studio.
Apparently the item I was looking for was the Synchronize. I just go to the file and Right Click > Synchronize and it then does a check against the last one manually and see's if it was different. Kind of a Refresh like Kuitsi had stated, but its called Synchronize. Also some reason I can't get it to work by just clicking Synchronize next to the SAVE icon at the top under File menu. Not sure why.
Whats your git status after you copy the file? Do you commit the changes, before pushing?
Have the same problem. Resolved.
The multi-root project used to work just fine for years, detecting changes in sub gits, properly pushing/pulling per sub, but not anymore. After some playing with a broken merge, it has stopped working. And that's not a local git repo issue. Cloned it from scratch - same issue. Changes (doesn't matter internal or external) are not detected by the Studio VCS facility, though git from console shows changes, View/Recent Changes shows them, Local Changes tab doesn't show any (single Default changelist).
It looks like something has happened with the VCS roots detection or related settings. Fixed with Preferences/version Control adding missing roots manually. I wish there is an option to rescan a folder or to delete some settings file and have the studio detecting these roots again.
I have an android project, and mistakenly added bin folder to stage and committed it. Now how can I ignore this bin folder and ignore it for ever?
I added bin/ to the .gitignore file, but nothing changes and I see all files in this folder in working copy in SourceTree.
I am using SourceTree as the git client.
Along with ignoring the folder, you need to git rm it. Git only ignores files that aren't already under its control.
Be aware, though: doing so will cause git to remove that folder for anyone else who pulls those changes. You'd better be sure that folder is just the output from building, or can otherwise be easily reconstructed.
If you haven't published the changes yet (that is, if you've never pushed them to anywhere and no one's pulled them from you), then you have the option of rewriting the history. You can simply say git reset --soft the_commit_before_you_added_bin (of course, you'll need the actual commit ID, or another name for it, like HEAD~3 etc) to basically "uncommit" to right before you added it. Your working copy will still have the latest versions of the files, but Git will all but forget you committed them. (This also means you lose intermediate changes.) You can then redo your commit(s), being careful to avoid bin this time.
Git has a filter-branch command that can allegedly help with automating all that, and can even preserve intermediate changes. I've never used it, though, and couldn't tell you how to use it.
Obligatory Big Bold Warning:
Don't rewrite history that has already been published.
Only undo/rewrite commits that have never been pushed or pulled. Otherwise, wackiness ensues.
I use eclipse to build an android app, and git running locally for version control. Currently I have a value in strings.xml that represents the version number. If i change that number, the very next thing I do is a code commit in git using the same version number in the comment, so that I can tie a specific build to the matching code that generates it. Very manual process.
Larsks comment helped in pointing me in a direction of defining things better. I think what I want is some type of git hook. Something where, if I change a particular version variable, it will automatically add a corresponding tag. Or, if I issue a tag of a specific format "v3.1.4", it will update the version number in code.
I think prior to reading about hooks, I was hoping for something where I could put "ReplaceWithVersion", or some other special code, and on commit git would know automatically to replace that with the current tag/version.
Am I hoping for too much? Is there a feasible way to get that the versions/tags in sync?
This sounds like the precut use for git tags. After you update strings.xml and commit the change, tag the commit with the version number:
git tag 3.14.15
You can then use this tag in other git commands to refer to this specific commit. For example, too see any change you've made since a release:
git diff 3.14.15