Is there any CLI command that can be used to open Accurev Merge window from command line. Assume, I have already logged into Accurev.
I analysed, and understood till these commands
accurev guimerge - to get file's most recent version, merging version and common ancestor version.
accurev cat - to get the contents of a version of an element.
But, using these, I am not sure what is the command that can show the merge window so that user can merge the files manually.
I know that accurev merge command can display the result in command line. But, I am looking for the Accurev merge GUI to open up for me. I am sure this can be achieved but don't know how to proceed.
I can see there are tools like acdiffgui.exe in my accurev installation directory. Can I use it somehow to display Accurev Merge window?
Also, one more point is, I donot want to change Accurev preferences on the user's machine.
Use the -G option with the merge command.
From the CLI manual under section merge:
-G - Use AccuRev’s graphical Merge tool to perform the merge if there are conflicts which require human interaction (any value set in AC_MERGE_CLI is ignored).
Related
There is interchanges command in perforce which lists changelists between two branches that have not been integrated with the convenience of a branchspec.
Is there something that shows the changelists that have been integrated something like the reverse of interchanges and also works with a branchspec?
More interested in terminal perforce rather than p4v.
Thanks
My recommended approach would be to do p4 changes on the source, run p4 interchanges between the source and target to get the source changes that have not been integrated, and diff the two to find the ones that have been integrated.
I'll also describe two other approaches that I would not recommend since they're a bit harder (but you might find elements of them useful):
Run p4 changes -i on the target and then run lots of p4 files commands to filter it down to the changes that originated on the source.
Run p4 integrated -b branch, run lots of p4 changes commands to convert the integration records into changelist ranges, and then sort them into a unified list.
Finding out if a changelist has been integrated into another branch in perforce is not simple. 'p4 interchanges' may not report everything as it relies on meta data and may 'think' that some changelists have been integrated.
Consider the case where CL10 was merged to branch B and then the changes were manually reverted via a 'p4 edit' instead of 'p4 undo' on B. Then if you run 'p4 integrate' with CL10 perforce returns with 'already integrated' message even though the code is no longer there (but might need to be).
Perhaps a solution to your question may involve combining ideas from Sam's answer above, 'p4 interchanges' and also running 'p4 integrate [-f]' within a loop to confirm that a set of changelists was indeed integrated. This is some work since the outputs of 'p4 resolve' and 'p4 diff/diff2' need to be considered.
My point is: do not solely rely on 'p4 interchanges'.
I have recently started using Microsoft's open-source Visual Studio Code IDE for developing web projects, shifting from Eclipse. I find VSCode highly intuitive and very simple to use.
But one feature I miss in VSCode is that the IDE's inability to remember commit messages (or have I not explored enough?!). Unlike Eclipse, which populates a dropdown list of historical commit messages, we have to manually enter commit messages in VSCode every time we commit our changes.
Is there any VSCode extension available for this purpose?
Can I make any entry in settings.json so that older commit messages
are retrieved automatically?
Any help would be highly appreciated.
VSCode 1.51 (Oct. 2020) does have a similar feature: Alt+Arrow Up:
Source Control input box saves commit message history
This addresses a feature request to navigate SCM commit history.
Press kb(scm.viewPreviousCommit) and kb(scm.viewNextCommit) to display the prior and next commits, respectively.
To move directly to the first and last position of the input box, press Alt in conjunction with the corresponding arrow key.
Build off of past commit messages and look back in the history without losing your drafted message.
No need for a separate extension or something like that. Git can handle this via commit templates and VSCode supports them already.
For example, assuming you have a unix-like and are in the root of your repository:
echo "My fancy commit message" > .mycommitmsg.txt
git config --local commit.template .mycommitmsg.txt
From there, VSC will automatically use the content of .mycommitmsg.txt.
Second step is to fill this message file with the content of your last commit. That can be achieved with Git hooks, in your case you want the post-commit hook.
Create/edit the file .git/hooks/post-commit with the following content:
#!/bin/sh
printf "`git log -1 --pretty=%s`" > .gitmessage.txt
Don't forget to make it executable:
chmod +x .git/hooks/post-commit
From there, everything should work as you described. The post-commit hook will automatically fill the message file with the content of your last message and VSC uses the new message as soon as you commit.
there's an extension that might be interesting for some people:
https://marketplace.visualstudio.com/items?itemName=JanBn.git-last-commit-message
I've just installed it before knowing about #kwood's answer, given that it helped me for a bit , I'm leaving this as a secondary option.
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
To see the history of each checkin a user has done in a directory tree i can type:
tf history . /recursive /user:name /noprompt /format:detailed
It displays all checkins "name" has performed with checkin comments and paths to the changed files. I want to display, in addition to that, the diff of each affected file. Like /format:extraverbose. Is there a way to have tf do that? If not, how can you create a powershell script that does that for me?
You can disregard things like branches and merges - there are none in the directory tree.
I don't think there's a command line for that right now, maybe you can create a Powershell script using the TFS Powertools CmdLet.
Otherwise you can still make a command line exe using the TFS API, it's easier than one might think. Look at this answer to get the source files of a command line tool that I made for someone.
I want to easily tell which files where renamed when looking at the changelog using the tortoisehg UI. The out-of-the-box config only shows that a file was added/removed (i.e. the standard hg log message without the -C option).
Unfortunately, you can't do it with TortoiseHg now.