We need to change to a new VCS system. I can't seem to find one that tracks change comments both per file and per change-set. Currently when we view file history in our present VCS it shows the various check-ins and the comments for the file on that check in and the over-all check-in comment. We are currently evaluating hg and like it, but can't find how to implement this behavior. Can anyone suggest how to do it in hg - or what VCS would allow this feature? Thanks so much.
You can run
$ hg log your-file
with Mercurial to get the history of just that file. It also works for directories or multiple files where you get a log of changesets changing either of the specified files.
Mercurial is actually very efficient for this: despite having repository-wide changesets, it stores the deltas on a per-file basis and this makes it very easy for Mercurial to show you the per-file history.
Hg's commit works on either the changed files you specify or all the files that it finds have changed. That group of files then makes up the changeset and the same commit message will then be applied all. It sounds like you are looking for a super commit to wrap several commits into one bigger commit.
Named branches are the intended method for something like this. You can then have commits with comments that are specific to certain files and the overall branch name is the feature you are grouping together. Through the command line or Tortoise Hg you can select what files are part of each commit.
Related
I have to change ("refactoring" is the proper name) a lot of branch names in my SVN repo (For migration to git, many branch names are equal to some tag names and that broke the migration). With the plugin of eclipse subversion, it is not possible to rename all the branches togther so I have to do it one by one (almost impossible too). I was looking a way to automate this. I must keep all the history of the branches and directories.
I appreciate your help, love this community.
You're not going to be able to accomplish this with an svn client. Changing the name of the branch and committing it will still leave the old name in history - and it will collide.
You said you must keep all the history... However, the easiest thing to do is to exclude the branches and keep the tags.
If you need all those old branches, you can dump the repo with svn dump and then use sed to rename the branches (or the tags)
I'm new to github and have been working on a group project for school. Recently it turned out we were missing some stuff and nothing was organized (every file was just uploaded into the main directory) so I removed everything using a command in the github shell. Then I proceeded to make files and organize all the code and re-upload and store everything in there.
However, when I did this, I had to keep committing every time I made a new folder and stored a bunch of files in it. I would like to keep the changes made during those commits (because I created folders and re-uploaded the stuff), but I want to remove those commits from the history because they are cluttering up the project.
Is this possible, and if so can you please walk me through the steps. Also I'm new to github so I don't know much.
Here is a picture of the ones I want to remove from my history because they are cluttering up the screen (see red marks):
Thanks :)
EDIT: PLEASE NOTE: I don't want to revert the changes, I just want all those history to be removed because they are cluttering up the commit history.
You should use:
git rebase -i HEAD~14
To rebase and squash your unwanted commits. Just use p to mark the last commit and use f to mark the unwanted commits for squashing it with the previous commits. This will remove it from commit log keeping the changes.
More info: https://git-scm.com/book/gr/v2/%CE%94%CE%B9%CE%B1%CE%BA%CE%BB%CE%B1%CE%B4%CF%8E%CF%83%CE%B5%CE%B9%CF%82-%CF%83%CF%84%CE%BF-Git-Rebasing
It is possible in GitKraken to revert changes of a single file to an earlier commit instead of reverting an entire commit?
Answer
A revert in the git-sense of it can only be performed on a commit. It introduces a new commit that exactly negates the reverted commits' changes. See here. GitKraken supports this: right click on a commit, Revert <branch> to this commit.
What you want to accomplish, however, can be done via git checkout. I do not think GitKraken supports this funtionality for a single file yet. You can, however, use the command line.
Reset single file via command line
git checkout <commit> <file>
Check out a previous version of a file. This turns the <file> that
resides in the working directory into an exact copy of the one from
<commit> and adds it to the staging area.
Documentation can be found here.
git checkout HEAD~1 <filename> will thus reset a single file to the commit before the current HEAD.
You can accomplish this in the GitKraken UI, but it's a little roundabout:
Revert the most recent commit(s) back to where the file was deleted, but when GitKraken asks if you want to immediately commit the reversion, click no.
Unstage all changes
Stage only the add for the file you're trying to restore
Right click in Unstaged, and Discard all
This should leave you with only an add for the one file you wanted to restore. Commit that, and now you've got your one file back.
Note that this can work across numerous commits, not just one... but since it's going to have to roll back everything from all of those commits, and then discard all of the rollbacks (except one) it can be quite slow if involves massive changes. In situations like this, it is probably better to use the git CI as suggested in kowsky's answer.
Although it doesn't strictly involves using git commands, GitKraken offers the possibility to visualize the content of any project file at any given commit.
When acting on a single file, it might be much easier to copy/paste the targeted commit file's content than using complicated git commands that might very well end up messing your whole project's commit history.
To achieve this, simply:
Open your git project in GitKraken
Click on the desired commit in the commit history line
In the right panel, check the View all files checkbox
Locate the desired project file and click on it
The file content will be displayed in the main panel
You can now copy/paste the content
Simple and efficient when you only need to revert a very limited number of files...
GitKraken 7.3.0 (probably older versions too) does allow for effectively running git checkout on a single file in the UI: Right click on the file under "unstaged files" and select "discard changes". Works on folders as well.
(This answer was previously a comment to the accepted answer)
You can make an UNDO to the last commit edit it and after that make a Force push to overwrite that. Works very well
Hope GitKraken can do this, as "TortoiseGit" does.
I am comparing two folders using a diff tool. I have tried a few different diff tools, but right now I'm using WinMerge. There are many files which show as unique to the right or left side, for example:
On the right we have: /bar/some_organized_characters.txt
On the left we have: /foo/some_similar_organized_characters.txt
The text file may have slight variations, but it's mostly similar. I would expect a tool to exist in most merge/diff tools which could tell you that these files are likely the "same" (meaning they have the same base), but the file has been moved, renamed, and slightly modified.
What I'm specifically trying to do is a "vendor merge." We have some customized software, and we want to merge the changes from a recent official release with the changes we have made. Many files have moved in the latest official release, and finding every move/rename by hand is difficult.
use a version control tool to check for changes. Simply commit the structure as an initial commit. Then overwrite the structure with the new version and commit that. The patch view will show you moved items. I've been able to do this with Git very easily. These tools are made to see how something has changed and will dig into the contents of the file. In fact, in git, you can set the threshold of what percentage of changes in a file constitutes a move and change, vs a delete and create.
I don't think this is possible with diff (I couldn't find it in the manpage).
However git diff detects this by default and can create patches that are applied with git apply in a similar way to patch. You can use it on arbitrary directories, not just repos, with --no-index (see Diffing between two entire directories/projects in hg or git?).
Sometimes need arises to update a library or file that has previously been put into .hgignore.
Normally, I would delete its entry from ignore list, commit/push a change and put ignore entry back.
Is this a good practice or there is some better/elegant way to deal with such a situation in Mercurial?
From the hgignore man page
The Mercurial system uses a file called .hgignore in the root directory of a repository to control its behavior when it searches for files that it is not currently tracking.
This library is obviously tracked. At some point you did hg add <library>. hgignore is no longer part of the equation for this file. In the future just update your library and commit.
hgignore is used for things like stopping mercurial talking about certain files when you do an hg status or adding them on hg addremove. It doesn't stop mercurial noticing if a tracked file changes.
You don't need to remove the entry from .hgignore; you can just hg add the file.
However, when you use a GUI, this GUI might use the .hgignore entries to show you a filtered list of files you can add. In this case, you would either have to add the file maqnually with hg add, or remove the entry temporarily from the .hgignore file.