Is it possible to use git diff to show only the commit log messages? Maybe git diff is not the right tool to use it but basically I want to see the commit messages between certain commits, and I definetely do not want to count lines to see what I want to see. I know there is git log which can show certain lines but that is not what I want. I am trying to compare Blender commits, so there are alot of stuff going on and I definetely do not want to go up and down and cut and paste logs to see what i ned.
thanks
If you want to list just the commit messages (without any other information) between two commits, you can use
git log --format='%s' <old-commit>..<new-commit>
Note that <old-commit> won't be included - use e.g. <old-commit>~..<new-commit> to have it included.
Related
I have been using vim-fugitive which is great but I haven't figured out a good way to work on a commit message while I am adding files. My workflow has been like this...
:Gstatus
diff the files in a vsplit with
dv
look through the diff, go to another editor compose the message and then git add the file
-
repeat for all needed additions copy the composed message from my other editor and then
cc
and paste my commit message into fugitive's commit butter. I would like to develop a way to work on the commit message as I am going through and adding the files without having to get out of vim. What do you think is the best flow to accomplish this?
I have seven commits I need to add change IDs to. I see a lot of people say to use interactive git rebase. I'm not familiar with rebasing, and I'm having trouble with the files and functions that I changed the name of reverting back when I try and reword them to add change IDs.
Is there any other way to add change IDs? Or how do I stop my files/functions reverting back when I try and rebase. Once I abort the rebase, they go back to how I had them.
Thanks!
Try the following, and note you will need to
push and [Submit] one commit at a time:
Set the Gerrit Hook to add the Change-ID as you commit (or amend)
Create a new branch for your changes
For each of the changes, starting with the OLDEST, do:
git cherry-pick ...
git commit --amend (this should add a Change-ID - different one each time)
(push the change to Gerrit - however you do that)
In Gerrit - approve and [Submit] this change
In your branch, again, do git pull --rebase
Here's the scenario -
Development branch was created from mainline, with many thousands
of files in it
A couple of thousand files were modified.
Changes from mainline were "p4 integrated" into the branch.
Hopefully integrations always included the complete mainline as of a
known-good label, but I'm not sure of this
Steps 2 and 3 were repeated an unknown number of times - let's guess
a dozen integrates, and probably another 1000 or more changes,
usually to files already modified
I am now in the painful position of trying to code review this.
Are there any commands that can help me get the diffs for each modified file between the version last integrated to it, and the version in the branch?
Or do I need to write:
A script which will identify all locally changed files.
A script which will find the integration point for each file in the above list
Another script which will use (2) to purge the list in (1) of files with no net change
A wrapper on (2) that will issue an appropriate p4 diff2 command
FWIW, I basically know how to do this manually, file by file. It's the scale that's daunting. Also, there are changes still going into the branch, in response to code review feedback, so I'll probably be recreating my lists repeatedly.
If you know what the known-good label in the mainline was that was used to do the last integrate, this should just be:
p4 diff2 main/...#good-label dev-branch/...
since for each file "the version last integrated" will be #good-label. Files that weren't locally modified won't have any diffs, so there's no special need to filter them out.
FWIW if I were in your position I'd be making use of "p4 ichanges dev-branch/... main/..." and going through by changelist, since diffs make more sense when each is in the context of its changelist, rather than looking at one monster diff per file that each contains a dozen unrelated changes.
First, sorry for such a confusing pesky title, I really can't find a better way to describe this (would appreciate any changes suggested to post).
The problem
I synced a github repo. And also modified some files and codes inside according to my needs. But if I want to resync and update my tree to latest commits.
will my changes be overwritten?
Or will repo simply ignore modified files and move on to other files?
Or will there be patching process (I dont think this would be case since chances of problems with auto-patching are quite high)?
My guess is that it skips over modified files. And I may need to manually get the new commits from repo. But how to determine which files that have been modified have new commits? I just want to determine it, then probably manually fetch and modify them manually.
To clarify:
Consider files named "abc" and "def" which I modified.
The repo owner updated his repo with a lot of new commits.
I ran repo sync and it synced all files to newer commits except those I modified. Now how do I determine if the files that repo owner updated include "abc" and/or "def" too (assuming I myself modified a lot of files, so I can't manually check if each file has new commit or not)?
I don't want to see what files I have modified or a complete list of files with new commits, I just want to see if the files that I modified have new commits or not.
Is there any such possible way?
I do know how to determine files that are changed using `git status,
but how do I want to check if those changed files have any new commits.
When running repo sync, Repo will rebase any non-published topic branches (i.e. branches you haven't uploaded to Gerrit with repo upload).
Or will there be patching process (I dont think this would be case since chances of problems with auto-patching are quite high)?
Git will try, but if there's a conflict that it can't resolve by itself you have to step in and help out.
Consider files named "abc" and "def" which I modified. The repo owner updated his repo with a lot of new commits. I ran repo sync and it synced all files to newer commits except those I modified.
No. Either Repo rebases your branch (and updates/merges all files) or it doesn't do anything and it's up to you need to rebase or merge from the upstream. Git never does partial updates.
I dont want to see what files I have modified or a complete list of files with new commits, I just want to see if the files that I modified have new commits or not.
I think you're asking the wrong question, but sure, you can list the commits that modify a particular set of files or compare two commits and only display the differences in a particular set of files. Both git diff and git log accept one or more paths to files that you want to restrict the output to. To find the files you can use git ls-files -mo to obtain dirty files and untracked files in your workspace, git diff-tree --name-only -r HEAD~..HEAD to get the files modified by the most recent commit, and so on.
Putting it all together, the following command fetches the most recent state from the upstream and shows the new commits (git log HEAD..origin/master) that touch upon files that you yourself have modified on the current branch since the last update from the upstream (git diff-tree --name-only -r origin/master..HEAD):
git fetch
git log HEAD..origin/master -- $(git diff-tree --name-only -r origin/master..HEAD)
A Unix-like shell is assumed. On Windows things may look differently.
You can use git hook to track the list of files.
In your post-receive hook search for the given file and do what ever you need to do.
Another option is to track it manually using the follow flag
git log --follow <path>, it will print out the list of changes made to the given file in each commit
Problem: 2 projects shared trunk and were updating some of the same files. Now one project needs to be released, so a new branch was created from a checkpoint before the projects started.
I have a list of just my changelist numbers from the mainline. Using that I can generate a list changed files and diff output using a script with a series of 'p4 describe #' commands.
Can I reformat that output and apply it to the new branch somehow?
Response to the title: "Is it possible to create a patch using a set of changelists?"
Yes.
p4 diff2 -u //path_to_your_sources/...#cln_minus_1 //path_to_your_sources/...#cln > /tmp/cln.patch.
You can then use /tmp/cln.patch as input to the patch utility. Here, 'cln' is the submitted change list number that you want to create a patch for.
I've just spent two hours struggling with this. Using cygwin patch, I had to munge the paths until they were recognised.
In the end, the magic incantation looked like this (broken across lines):
p4 diff2 -u //depot/foo/main/...#100003 //depot/foo/main/...#100000 |
sed 's#//depot/#E:/Source/#g' |
sed '/^+++\|---/s#/#\\#g' |
patch
That is:
Use p4 diff2 to get a unified diff (-u) of part of the depot between the two revisions that I care about. The second changelist is the one before the first one I want, otherwise it's not included in the diff.
Use sed to change the //depot/ to E:/Source/, which is where my workspace lives.
Change forward slashes to double backslashes (this seems to make it work).
Pipe the results through patch.
Cygwin patch is smart enough to check files out of Perforce, but I'm not sure how to get it to do it silently. It prompts with Get file 'e:\Source\foo\whatever' from Perforce with lock?.
This is with p4 version 2010.1, a fairly recent installation of Cygwin, running on PowerShell.
Oh, and after this, patch wrote out Unix-style line endings, so I used u2d to fix those up.
Perforce will let you cherry-pick changelists for integration, which may be easier than trying to generate and apply a patch. Perforce will keep track of what revisions you've integrated where, which may make future integrations easier.
Let's assume you used to have one trunk:
//depot/mycode/trunk
And you checked in all of your changes there. You branched trunk at some point in the past to:
//depot/mycode/rel
And you have a list of changelists on trunk to merge. From a client spec that maps rel, integrate each changelist:
p4 integrate //depot/mycode/trunk/...#1234,1234 //depot/mycode/rel/...
where 1234 is the changelist number. Resolve after each integration. You may also wish to build, test, and commit your integrations at various checkpoints during your integration, if you can identify good points to do so. (Perforce can handle multiple integrations per commit, but if you make a mistake you'll need to revert to the last version checked in and redo the intermediate integrations and resolves.)
p4 describe -S -du <CL number>
is the shorter and most concise command, in my opinion.