In Pijul how can I see what happened in a patch?
I'm looking for something similar to git diff <commit> <commit>^.
I tried pijul diff but it seems to only work with branches. And I couldn't get pijul log to show any details of patches, either.
I suspect what I'm looking for is possible because clicking a patch in Nest shows a diff and there is patch pretty-printing in libpijul which includes a change list.
I believe you are looking for pijul change ⟨patch-hash⟩
Edit: patch is now called change
I don't see how to do this with current pijul?
pijul 1.0.0-beta.2
Pierre-Étienne Meunier <pe#pijul.org>
USAGE:
pijul <SUBCOMMAND>
OPTIONS:
-h, --help Print help information
-V, --version Print version information
SUBCOMMANDS:
add Adds a path to the tree
apply Applies changes to a channel
archive Creates an archive of the repository
change Shows information about a particular change
channel Manages different channels
clone Clones an existing pijul repository
credit Shows which change last affected each line of the given file(s)
debug
diff Shows difference between two channels/changes
fork Create a new channel
help Print this message or the help of the given subcommand(s)
init Initializes an empty pijul repository
key Key generation and management
list Lists files tracked by pijul
log Show the entire log of changes
move Moves a file in the working copy and the tree
pull Pulls changes from a remote upstream
push Pushes changes to a remote upstream
record Creates a new change
remote Manages remote repositories
remove Removes a file from the tree of tracked files (`pijul record` will then record
this as a deletion)
reset Resets the working copy to the last recorded change
tag Manage tags (create tags, check out a tag)
unrecord Unrecords a list of changes
Related
As in not only the major changes maybe the installed dependencies and all before a release without checking one by one?
Since Git won't know which commits are important to you, you'll have to first define your own set of guidelines/format on how you write your commit messages, which you can then use later on to easily differentiate all the commits made for a particular development period.
For example:
If it's a bug fix, prepend the commit message with a "[bugfix]"
If it's a new feature, prepend the commit message with a "[feature]"
If it's a project setup change, prepend the commit message with a "[migration]"
Then, once all the branches have been merged to the main branch (let's say it's develop), checkout the develop branch and use git log --grep=<PATTERN> to identify a specific set of commits.
For example, if you only need the bug fix commits, do a:
git log --grep="bugfix"
which will show you all the commits with "bugfix" in the commit message.
If you only need the commits for a specific period, you can use the --since=<date> option:
git log --since="2017-06-01" --grep="bugfix"
If you want a formatted list (something that you can easily output to some sort of release notes, I assume), you can use the --format=<format> option:
git log --since="2017-06-01" --grep="bugfix" --format="(%ci) %h : %s"
The command above will give you something like this:
(2017-06-18 18:26:36 +0800) 63f330f : [bugfix] prevent crash when dialog is sent to background
(2017-07-01 10:03:40 +0800) cdcbd91 : [bugfix] remove extra row at the end of the list
You can check out the other format options from the complete git log docs.
Basically, it will all depend on your commit message format.
As a tip, you can look into using a commit.template to make it easier to format your commit messages.
commit.template
If you set this to the path of a file on your system,
Git will use that file as the default message when you commit. For
instance, suppose you create a template file at ~/.gitmessage.txt that
looks like this:
subject line
what happened
[ticket: X]
Here's the scenario:
User1, Branch1: adds "abc.def"; commits.
User2, Branch2: adds "abc.def" (same file name, but more details in the file); commits.
Now User1 wants to merge the updated version of the "abc.def" file. So (using TortoiseSVN 1.7.10), User1 starts in the Working Copy of Branch1, selects Merge... -> Reintegrate a Branch, then chooses Branch2 and selects Merge. Predictably, a "Tree Conflict" results, with this text:
The last merge operation tried to add the file 'abc.def' from Branch2, but the file was already added locally.
How do you want to resolve this conflict?
But the only choice is a single button labelled Keep the local file. There is no option to choose the remote file, which is the one that User1 really wants.
What am I doing wrong here, and how do I fix it? More specifically, how do I get User2's version of the file into Branch1?
(Of course, I'm sure User1 could manually delete the file prior to merging, but that obliterates any history that User1 may have wanted to preserve. Plus it's just a clunky workflow, particularly when there are numerous files in this predicament.)
Unfortunately, this scenario isn't even mentioned in the TortoiseSVN documentation on Tree Conflicts
UPDATE:
In addition to choosing "Reintegrate a Branch" I have also tried "Merge a Range of Revisions" and "Merge two different trees". For the latter case, I chose the remote branch (Branch2) as the "Start" and the local branch as the target (Branch1; choosing the Revision prior to the addition of the file.) I got the same result in all cases: Tree Conflict with no option to select the User2 version of the file.
UPDATE #2:
According to the documentation, there should be "a checkbox in the merge progress dialog called Merge non-interactive", which, if unchecked, supposedly opens the "Merge Conflict Callback Dialog" during the Merge. However, I cannot find any such checkbox in the merge process. Where is it?
I was able to merge from one branch to another in version 1.9 of TortoiseSVN with the following procedure.
Setup
With a test repository, I did the following steps:
Create a branch, "first"
Create a file "doc.txt" with contents "FIRST" in the new branch
Add and commit the file to the new branch
Create a branch, "second"
Create a file "doc.txt" with contents "SECOND" in that branch
Add and commit the file to the new branch
So my structure looks like:
branches/
first/
doc.txt => "FIRST"
second/
doc.txt => "SECOND"
Merging
In this example, my goal is to get the contents of second/doc.txt into the first branch.
Right-click on the first branch folder, and select TortoiseSVN > Merge...
Select "Merge two different trees"
Fill in the "From" box with the URL for /branches/first, and the "To" box with the URL for /branches/second.
(This is where I got tripped up originally - I thought it would be the opposite! The docs explain: "This may sound wrong, but remember that the trunk is the start point to which you want to add the branch changes.")
Hit Next and try a test merge if you want. It should show that "doc.txt" is replaced, with no tree conflicts. For this example the default merge options were fine.
Do the merge and check the contents of first/doc.txt - it should now read "SECOND".
Run an update and then commit the first folder to save the merge to the repository!
Complete log:
Reintegrate a branch vs merge a range of revision
I think what you want to do is merge a range of revisions first and then merge the branch back into the tree.
There is a dialog called
Merge Conflict Callback Dialog
Relating this issue:
the Merge Conflict Callback Dialog should come up
- when merging multiple revisions via "Merge a range of revisions"
- when merging via "Reintegrate a branch"
at the moment the Merge Conflict Callback Dialog only comes up in the
first case.
It will be included in the upcoming 1.6.0 release.
That allows to you to select the repository change instead yours
Consider my local repository contains more than one file, while doing checkout for a particular commit of a file, other files in the repository got deleted.
I am using following API (git is the instance of git repository)
git.checkout().setName(commitId).call()
Is this correct way to check out a particular commit of a particular file?
The JavaDoc of setName() says
When only checking out paths and not switching branches, use setStartPoint(} to specify from which branch or commit to check out files.
And for addPath() it states:
If this option is set, neither the setCreateBranch() nor setName() option is considered. In other words, these options are exclusive.
Therefore I think you should use
git.checkout().addPath( ... ).setStartPoint( ... ).call();
Your call reset the index (and can remove files no longer present in the new commit you check out)
You can look for a more precise example in jgit/porcelain/RevertChanges.java
// revert the changes
git.checkout().addPath(fileName).call();
In your case:
git.checkout().setname(commitId).addPath(fileName).call()
I have found a way to print out on a file on the master, every time that I get a commit on my project:
f.addStep(StringDownload(Interpolate("%(prop:got_revision)s\n"), slavedest="/Users/master/data/commit.txt"))
Now, I would like to have also the user that made the commit, and the message (if any), but the manual for Buildbot seems to omit the name for some of the properties (found got_revision by chance, like most of the Buildbot answers).
What (prop:) should I pass to obtain also the name of the committer and the message? I want to save on a text file on the server, the equivalent of
git log -1
But I was able to find only the commit.
Thanks
In theory you can access changes properties this way:
changes = self.getProperty("changes") or [] # returns None if there are no changes
for ch in changes:
changed_by = ch.who
But I haven't tried it myself
I'm not particularly experienced with ClearCase, so if my terminology is incorrect please let me know.
In Git I can run the command:
git archive -o /tmp/dump.zip $SHA_FROM_THE_PAST path/to/dump
I want to do something similar in ClearCase.
The ClearCase repository contains two branches: main and snapshot_foo.
snapshot_foo branches from main at some point in the past.
What I want is a dump of all the files as they looked at the time the snapshot was first created.
I understand that there is no 'global' state identifier like there is in Git; in AFAIK, in ClearCase each element is versioned individually, so there will not necessarily be a one-to-one equivalent to that command.
I've thought about creating a new snapshot starting at the same point in time from main, and just copying what I need from that, but I am bewildered and confused as to how I would go about it.
The simplest case would be when you have set a label on main just before creating snapshot.
But if you have no such label, you can get all the files at the time just before the creation of the snapshot_foo branch:
a/ cleartool descr -l brtype:snapshot_foo#/myVob to get the date of creation for this branch
b/ make a snapshot view with a time-based selection rule similar to this question
element /myPath/... /main/{!created_since(01-Sep-2008.12:34:56)}
element /myPath/... /main/LATEST
(with 12h 34 minutes 56 seconds being the time just before the creation of the brtype snapshot_foo)
(see the config_spec man page)
Once the snapshot view is created with the right versions in it, you can zip its content, achieving a similar result to the git archive you mention in your question.