I'm using the following command in an Eclipse CDT pre-build step, to generate a header file containing my current short Git hash as a string macro:
git log --pretty=format:'#define GIT_HASH_STRING "%h"' -n 1 > ../Inc/gitcommit.h
Works great, but it doesn't indicate the status of the working tree. Like when running git submodule status, if there are working tree changes, I'd like it to spit out something like
a289542-dirty
Is this possible? I checked the man page for git-log formats, but didn't see anything that looked pertinent.
Context: The GIT_HASH_STRING macro is displayed when issuing a version command via the CLI of an embedded device. If I can include a -dirty flag in the string, it can serve as a warning that the device is running an unreleased version of firmware that doesn't align with a specific commit.
The git log command does not inspect the work-tree, so it cannot do this.
There are many commands that do inspect the work-tree. One simple one is git describe:
git describe --always --dirty
will print out a string that will end with -dirty if the work-tree or the index is modified with respect to the current commit (i.e., in the same situations where git status would say something is staged for commit or not staged for commit).
If you want to check submodules as well, you will need more.
Related
I have been searching for weeks looking at responses for similar questions and can't get anything to work
I am working on an Android project with another developer. I only want to commit/push certain files that I change. Instead whenever I compile or even open android studio, Sourcetree wants me to commit files in .gradle, .idea, etc...i have tried "stop tracking" but then they add those files to "staged" and expect me to commit them. I discard them instead and start all over.
Please help!
Switch back to command-line just for testing, and try:
git rm --cached -- aFile_you_dont_want
git check-ignore -v -- aFile_you_dont_want
If the second command does not return anything, check if you can add *.graddle (for example) in a .gitignore.
Repeat then the check-ignore command (you don't even have to add/commit: the ignore rules apply immediately to present files)
Once that is working (meaning the files are un-tracked and ignored), you can switch back to SourceTree.
I'm transitioning from using Subversion in Eclipse for code management to GitHub in RStudio. It's starting to make sense, but I can't seem to figure out how to pull effectively.
Specifically, if I use the Pull arrow in RStudio, every file change in the repository automatically updates my local files without warning. I can see how many files were updated, but not what changed!
Here are the questions I'm hoping to get help with:
1) Can I preview the repository file changes in RStudio before I pull them locally? With SVN in Eclipse, there was an indicator showing files with a difference, and the option to view side by side.
2) If multiple files have been changed on the repository, is it possible to pull just 1 locally?
3) How can I revert a local file to a previous version?
Right now I've been trying to do this all within RStudio for simplicity. I haven't used things like the GitHub desktop client.
I appreciate the help!
I would suggest you better get used to the git's own tools to stay informed about your repository.
For example you could do following.
Before you pull, check your current commit logs
git log
This should show you how your current commits stack up. Note the latest commit id (first 4-5 letters would usually do)
Now after pulling you can see the difference using following command
git diff --color your_previous_commit_id..HEAD
If you don't like the changes and want to go back,
you can just reset to your favorite commit with following command. BTW run "git stash save" to keep a copy of your uncommitted changes.
git reset --hard you_favorite_commit_id
Note: that this will delete all your uncommitted changes unless you stashed them and put your local branch behind the remote repo branch you are tracking again.
Wondering where to put these commands? Check https://git-scm.com/downloads.
What's good about using these git tools is that if you switch between IDEs you don't need to search for same functionalities you had in your earlier IDEs.
When merging files it will be helpful (as for me) to show an author of each line. Is there any diff or merge tool supporting that?
The bundled gitk tool is not really a merge tool, but it shows conflicted lines with red and blue and "+"'s in front, and you can Rightclick->"Show origin of this line" on any of them, to go to the commit which introduced the line:
You can run your mergetool, or just a text editor with diffmarks in parallel
So what you really want is a tool that can easily identify your changes
relative to other's changes in a merge conflict, rather actually identify
the author of each line (which would be a mean to achieve that), right?
If I understood you correctly, I have some relatively good news: It
can be done with git + kdiff3. For merging you can just use git mergetool
(which you can configure to use kdiff3). But it is not supported natively
if you get a merge conflict when doing interactive rebase, so for that
some manual scripting is required.
Instead of making up my own simple merge conflict example, I will use
http://www.gitguys.com/topics/merging-with-a-conflict-conflicts-and-resolutions/
as an basis. Follow that page to git merge test. From after the merge
command I diverge a bit from that example by running different commands
(but basically doing the same job). I'll do all the manuall steps first.
So we have a merge conflict and git has inserted content from both
contributing sources into the file in this <<<<<<<...>>>>>>> format,
which I really do not like at all and never consider even looking at it.
Instead I use my favourite merge tool, kdiff3.
First we need to find which versions that are involved.
$ git ls-files -u
100644 b0ed415d15862ac5582b51e4de65528e86934cd2 1 README
100644 56300e3ac4e4521c3500618a301bb2ab2d6a52f5 2 README
100644 9585db7d9c2d9ca05075f67a878f2554886d7b1a 3 README
$
Basted that information we can perform a three way merge:
$ git cat-file blob b0ed415d15862ac5582b51e4de65528e86934cd2 > v1
$ git cat-file blob 56300e3ac4e4521c3500618a301bb2ab2d6a52f5 > v2
$ git cat-file blob 9585db7d9c2d9ca05075f67a878f2554886d7b1a > v3
$ kdiff3 -o merge_result v1 v2 v3 &
[2] 18394
$
Which gives the following view where you can select from which ancestor
you want to merge from.
Afterwords (if you are satisfied with the merge result)
you need to
$ rm v1 v2 v3
$ mv merge_result README
$ git add README
All the manual steps above are done automatically with git mergetool.
So why showing all that then? Well, because if you get a corresponding
conflict during git rebase -i, then it has to be done that way (before running git rebase --continue).
In this small example there is only one conflict
line, so it does not show the more typical case where a lot of lines
are automatically resolved, leaving you to just manually resolve the
ones that was not done automatically.
A more real life example might look more like the following:
Notice that in the merge result you now clearly see the origin of the C lines that
were automatically resolved. I think this is sort of what you were asking for when asking for getting the author for each line, right?
That information is completely absent in the <<<<<<<...>>>>>>> text (and it is difficult/impossible to spot that you should update the printed string in the hello function).
I cannot recommend kdiff3 highly enough. Using a graphical merge tool like that compared to some lines from both sources mixed inline in the file is like using an excavator versus a spade.
No. And, I think, never will be - when we merge, we think about content, not authorship
In my development team we use requirements management to control the expected behavior and functions of our products and a bug report tool to track 'problem reports' (PR). Any change in the requirements is done by a 'change proposal' (CP) which acts much like a commit on a code repository.
In order to make any commit that changes the final product one must supply on the CVS commit commentary a trace which can be either a CP (this means that the change on your code reflects a change in the product) or a PR (which means the changes in the code are being made to correct a problem). CPs and PRs are numbered so that one can link changes in code to the causing item (CP or PR).
Sample commentaries
Error correction commit commentary:
Kind: Error Correction
Trace: PR-015 Crashing upon startup
Description: Edited file foo.c in order to verify uninitialized variables.
Product change commit commentary:
Kind: Development
Trace: CP-053 New login mechanism
Description: Added login mechanism with library X and blablabla.
My problem here is that I don't have any easy way of retrieving all the files that were changed for a specific CP or PR neither can I retrieve all the changes made to the code.
I have tried to use regexp (RE from python) in order to parse the log but it has been a little tough to cover all possible logs. My regular expressions failed to retrieve the list here and there even after adapting it some times.
So, I've been thinking if there isn't any easier way or any project or product or even a CVS built-in feature that might help me here.
The objective question: How do I retrieve the list of modified files in a commit which is identifiable by a well-formed tag (the CP or PR)? Is there an easier way or should I stick to log parsing?
Environment details:
OS: Windows XP
CVS server: cvsnt
CVS client: tortoise / cvsnt
Didn't want to answer my own question but I think it may be helpful for future reference for people with the same problem.
Well, I managed to perform a search within the 'log messages' (cvs term for the commit commentaries) filtering by the content of the text in the log message and group the files changed on that commit.
As pointed out by 'Joakim Elofsson' here, cvsps is a good tool for grouping commit information in 'patch sets' which are individual commits with references to all the files changed in those commits.
I used the version of cvsps packed for cygwin as at this moment there's no port for windows.
Just install the cygwin with the internet setup available here and, when choosing packages, search for cvsps and cvs, install both.
I couldn't manage to use the checked out files on my system (through the /cygdrive/c folder) so I checked them out from the cygwin shell.
BEGIN Obs for tortoise users
You'll need to setup CVSROOT environment var to the current CVSROOT of your repository by the command:
export CVSROOT="Your CVSROOT string here"
Usually, if check the properties page of any file of your checked out code base there will be a tab named CVS. There'll be your CVSROOT string. (if you're using :sspi: to connect to your remote repository as I do, you may try to switch it to :pserver:, it did work for me but I don't know exactly why).
END Obs for tortoise users
Well, after checking out your repository use command:
cvsps
This will create the cvsps patchset base for your requests. Then use:
cvsps -l "Some regexp code"
It will search the patch sets for log messages matching the input regexp.
This is a sample from using cvsps -lP100-PR-FEX` on my database (changed some filenames and paths for being able to make it public...):
PatchSet 71
Date: 2012/10/25 11:30:44
Author: GUARITA
Branch: HEAD
Tag: (none)
Branches:
Log:
Kind: Error correction
Trace: P100-PR-FEX145
Description:
Corrections of the TRUE and FALSE conventions used by the C++ (true:everything but 0, false:0) P100 interface to the VB6 (false:0, true:-1 or 'all bits set to 1 which is -1 in 2's complement') P100Interface ActiveX object.
P100 Panel Version increment.
Members:
SidePanels/P100.wimp:1.2->1.3
SidePanels/Calcs/P100Interface/private/P100Interface.cpp:1.2->1.3
You may also use it to compare changes between tags (which I use to control releases) with cvsps -r <tag1> -r <tag2>.
Before pulling from the central repositiry, I usually use the 'hg incoming' command to see what I will be pulling. However, this only gives me a list of changesets with some comments, and not a list of the actual files that have been modified.
1) In such a situation, how can I get a list of modified files (including some basic info about the chane, like Removed, Moved, etc)?
2) Similarly, when I do an 'hg status', I get the differences between my local working copy and what is currently on the repository. However, a more useful feature would be to get the differences between what is incoming and my local working copy. How can I get this?
Thanks!
1/ Most options are presented in "how to see files in repository before running 'update'":
hg incoming --stat
Notes:
For remote repository, using --bundle avoids downloading the changesets twice if the incoming is followed by a pull.
--stat: output diffstat-style summary of changes.
(ie: Statistics of changes with the following format: "modified files: +added/-removed lines")
2/ See RDiff extension (and the SO question "Using Mercurial, is there an easy way to diff my working copy with the tip file in the default remote repository")
If you don't have a recent enough version for --stat, you can get a similar overview using status:
cd repo
// grab the newest changes into a bundle
hg incoming --bundle morechanges.bun
// get an id for the current tip
hg tip
changeset: x:abcdef
...
// see what's changed by overlaying the bundle on the repo
hg -R morechanges.bun status --rev abcdef:tip
//info you're looking for
// everything's good; add the bundle to the repo
hg pull morechanges.bun
rm morechanges.bun