Hi Warren,
On 10/21/2016 11:14 AM, Warren Young wrote:
On Oct 21, 2016, at 10:02 AM, Nikita Borodikhin <elit...@gmail.com> wrote:
== color support - review the change, history analysis ==
One should not underestimate the significance of color on terminals these days,
that's why both git and mercurial and a lot of tools have color support in
their base distribution. It makes it much easier to spot the changes in a diff
For diff, simply install colordiff, which is almost certainly already packaged
for your OS. Then:
$ fossil set diff-command 'coloridff -wu'
$ fossil diff -r 2016-10-01 | less
to group similar files together in a status report at a glance
Define “similar.” Do you just mean that all the modified files should group
together separate from the added files and such, or something different?
This is one of the areas where working code will speak louder than well-crafted
prose.
Let's suppose I have some changes to fossil:
$ fossil status
EDITED src/bisect.c
MISSING src/blob.c
EDITED src/comformat.c
ADDED src/configuration.c
MISSING src/configure.c
EDITED src/content.c
If you color lines by meaing, it is easier to understand:
$ fossil status
EDITED src/bisect.c
*MISSING src/blob.c*
EDITED src/comformat.c
ADDED src/configuration.c
MISSING src/configure.c
EDITED src/content.c
== change sets - preparing the change ==
I often end up having several sets of unrelated changes.
You admitted to not using branches, apparently because you don’t see the point
of them in a single-developer project. This is one good use for them.
That is, if you’re working on one feature and then see that you’ve gone off on
a tangent and are now building something unrelated, you can check the first
feature’s unfinished changes into a branch, then return to the trunk to work on
the second feature.
You’re using branches in this case to stash unfinished work without breaking
the trunk or admixing unrelated features in a single checkin.
I can use branches for that, that's true. There is also another use
case - changes are not directly related to each other and are logically
separated, but I have to have both of them until I finish the work.
E.g. Makefile changes to dramatically speed up the build on my machine.
Working with git, I use staging area to collect the needed changes and group
them together
I think the git staging area fights against team cohesiveness, primarily
serving the needs of the sort of developer who likes to go off and hide in
their office, not showing their work to their team members until it’s
“perfect.” Committing publicly, early, and often is objectively better, a fact
that falls naturally out of the mathematics of control theory.
I realize that this is not a problem for you, but I’d guess that more Fossil
users are on teams than not.
Anyway, before the commit, you have to make sure you're committing what
you want, and you review your changes before the commit, right? Staging
area in git is the instrument created exactly for what I'm taking about
- to help developer to prepare the commit and separate what he's going
to commit from what he's not going to commit.
How much time it takes - minutes, hours, or weeks - is up to developer.
Every instrument can be perused, you can hit nails with a microscope,
but it is not intended to be used that way.
subversion really shines here with its changelists
Some months ago, a proposal was made that I consider vastly superior to svn
change lists: a flag for the stash command that would let you select and reject
each hunk of the current diff interactively.
If you had three essentially unrelated changes in the current working copy, you
could stash all the hunks belonging to two of them, then test the third change
separately and check it in once you’re happy. Then you could “stash pop” and
repeat to polish the other two, one at a time.
It is important that this not be implemented in terms of checkin, since you
need to test each unrelated feature separately before checking it in.
I missed that proposal, but it must looks more like hg record than svn
changelists. If that is the case, it is more granular, but in the way
it becomes a completely different tool. It just works on too a
different level.
== grep - development support ==
Often the projects building process leaves many temporary files in the working
directory. I could grep over the directory using standard grep but then I have
to filter out those temporary files created by my build system.
The solution to that is ag, The Silver Searcher:
http://geoff.greer.fm/ag/
If you’re looking for a project, it would be nice if someone would teach ag
about Fossil ignore rules. It already knows about git, hg, and svn.
Meanwhile, we have its built-in .agignore feature.
ag is awesome in many other ways. In addition to being much faster than grep
and with a shorter typical command line, it has much smarter defaults:
- color output
- case insensitive
- recursive on the current directory
- etc.
Thank you, I'll take a look at it, may be it would work for me. But
built-in grep, even if it is not that blazing-fast, would be a good
thing. It is not a top priority for me anyway.
== combined log - history ananlysis ==
The most unusual thing about Fossil is that it does not have "log" command.
There are two different commands to access file history - timeline and finfo, but all
other systems use log command to access history of both files and directories, be it the
root directory of the project or a subdirectory. In Fossil, there is no easy command
line way to get the history of a subtree.
I initially missed that when moving from Fossil, but I retrained my muscle
memory quickly enough. I suppose it would be nice to have “fossil log” simply
for those who can’t or won’t use Fossil enough to retrain, though.
You mean when moving _to_ fossil? timeline/finfo is not necessarily a
good or bad thing, but it is too unusual an approach, I wish I had a
more regular thing.
Ticket d1b50f4d06579e43c24d0e35f9d28d9562e95126 is the perfect example of this.
Any unique prefix of a ticket ID will suffice. (The same goes for all Fossil
artifacts, in fact.) You don’t have to paste all 40 characters of the hash.
For ticket IDs, the first 4 or 5 characters should suffice.
It also would have been kind of you to give a URL rather than just the ticket
ID. Abbreviations are allowed here, too:
https://www.fossil-scm.org/index.html/tktview?name=d1b50
I know. I found tickets looking through all the tickets in the
database. Ticket id is that long there :)
== linear history - history analysis ==
The other thing is that Fossil, like cvs, but unlike svn or git, shows global
history, including changes committed to branches parallel to the currently
checked out one.
I think this is a result of Fossil being so dependent on its web GUI: the
graphical timeline solves most of the problem here, and if you want to see one
branch in isolation, it’s a mouse click away.
There is a way to get the same effect on the command line, though:
$ fossil timeline ancestors current
That asks Fossil timeline to show only ancestors of the current checkout’s
branch.
You may want to wrap that up in an alias or script to get a shorter command.
Key to this solution is that Fossil has several special checkin names: current,
tip, next, previous, ckout, and root:branchname:
https://www.fossil-scm.org/index.html/doc/trunk/www/checkin_names.wiki
Learning these helps in many other situations.
This is not exactly what I'm looking for. timeline ancestors follows
all lines of ancestry, but I would like to have only following primary
line of ancestry. For example, 816bc43b8064bf4d is a merge of
ca6c8f9be80531d8 into 3a66ed0bee8ab3fc. timeline ancestors follows both
lines:
fossil % fossil timeline ancestors 816bc43b8064bf4d
=== 2016-08-23 ===
17:30:56 [816bc43b80] *MERGE* Add extensive tests for the 'settings'
and 'unset' commands. Also, add --exact option to the 'settings' /
'unset' commands. (user: mistachkin tags: trunk)
17:21:46 [ca6c8f9be8] Add a comment. (user: mistachkin tags: settingsTest)
14:12:26 [3a66ed0bee] Fix harmless comment and spacing typos. (user:
drh tags: trunk)
== relative revisions - history analysis ==
In Fossil there is no way to refer to a parent of a revision, with the
exception the parent of checked out revision.
Can you give examples of why you’d need to do this? I mean, what’s wrong with
“fossil up 1234abcd” between each diff? Is the problem simply that it changes
working directory contents? I don’t mean to trivialize that if so, I just want
to be clear on what you see as the problem.
The Fossil web UI has a semi-hidden feature to do this. Just click two bubbles
in the timeline and you get a diff page showing the changes between those two
versions.
Reviewing the history of changes in a branch. Sometimes when you're
looking into history of a file, what you need is to go into the history
one commit at a time. After you found the last revision of the branch,
you can check three commits without having to copy three revision hashes:
git show sha1
git show sha1^
git show sha1^^
UI does not need this, because you point to the revision visually.
== diff for a revision - history analysis ==
I often use "svn diff -c rev" and "git show rev" to show a single commit as a whole.
Until recent Andy Bradford's change introducing --checkin option, the only way to achieve that in
Fossil was to use "fossil diff --from parent_rev --to that_rev”.
I’m not seeing a request here. Are you calling our attention to this new
feature, or did you want something more than fossil diff --checkin?
It is still not in the latest release yet :)
I just started collecting the requests some time ago, before that
change. Ignore that item.
== "checkout as repository" ==
most of the time I hardly use that at all
Yes, I agree; “fossil clone” should have much of the functionality of “git
clone”. Instead of cloning into a .git directory within the clone target, I
propose that it clone to a repository file in the target directory called
.fslrepo or _FSLREPO, as appropriate.
Examples:
$ fossil clone http://fossil-scm.org
Because you didn’t give a file name, it clones into fossil/.fslrepo and opens
.fslrepo in place within that directory. It gets “fossil” from the tarball and
zip file option in Admin > Configuration.
$ fossil clone http://fossil-scm.org trunk
Same as above, except that it uses the directory name “trunk” instead of
“fossil”, just like git does.
$ fossil clone --branch version-1.30 http://fossil-scm.org v1.30
Checks out the v1.30 feature branch into a directory of that name. (Without
the final argument, it would still use “fossil” as the clone directory name.)
This idea does create a potential ambiguity, in that the parameter after the
clone URL could either be a named Fossil repository file or a directory. I
propose that it be solved by enforcing the current reponame.fossil convention:
if the parameter ends in .fossil, it’s a file name, else it’s a directory name.
That could be extended to cover other common conventions in use. Does anyone
who has read this far use anything other than *.fossil?
One other detail: Fossil would need to behave as if .fslrepo and _FSLREPO are
always in the ignore lists. You wouldn’t want to nuke your working copy via
“fossil clean”.
It would be good enough without that destination logic:
fossil clone --checkout <source> <dest>
== wiki syntax ==
I would appreciate a lot if there were links to the official wiki_rules and
md_rules files.
You wouldn’t want a simple link, because that would throw away your wiki page
edits. What you want is a way to open those documents in-place as a sidebar,
or to open them in a separate tab.
You can open link in a tab/window, there's an html attribute for that.
Nikita
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
