Re: [fossil-users] Fossil mentioned on HN

[Joerg Sonnenberger]

On Thu, Dec 17, 2015 at 06:57:06PM +0300, Konstantin Khomoutov wrote:
> On Thu, 17 Dec 2015 13:16:43 +0100
> Joerg Sonnenberger  wrote:
> 
> > Now the tricky part is this can be done *without rewriting history*.
> > Essentially, you can (semi-automatically) reapply all changes on top
> > of the new commit and record which commit they were originally. This
> > allows three things:
> > (1) Tight main line with keeping incremental stages.
> > (2) Preservation of what commits originally happened in case you need
> > the full audit trail because there was a subtil merge fault or the
> > like.
> > (3) It allows automated follow-up rebases for 3rd parties that already
> > got the initial changes. I.e. you can safe push your work-in-progress
> > and still transplant it later.
> > 
> > "git rebase" only really allows the first point.
> 
> Not quite.  Well, `git rebase` does indeed replace the tip of the
> branch it operated on with a set of changed commits, but this counts as
> a so-called "drastic head movement" in the Git parlance.  Such
> movements are recorded in the so-called "reflog" ("reference log" --
> with refs or references being heads (branches) and tags), so as soon as
> a rebase operation completes successfully (as opposed to having been
> aborted using `git rebase --abort` where the branch being operated on
> is left intact), you can retreive the previous tip of the affected
> branch from the reflog.  The reflog keeps about 30 days worth of such
> changes by default which is more than enough to cover the "oops!"
> situations.

The very need for reflog and the 30days recovery frame is one of the
saddest part of the git design. It is an arbitrary implementation detail
and not really related to the way "git rebase" works.

> As to "without rewriting history" bit, this might be a terminological
> issue but in a (typical) DVCS you simply cannot cherry-pick or
> otherwise (re-)apply an existing commit to some tip to produce another
> commit without essentially rewriting it because the commit hash includes
> the commit creation date.  And once you've changed a commit's hash, the
> next commit being applied on top of this one will have its hash changed
> also because it will refer to the changed hash-name of its parent
> commit, and this "link" is hashed as well.

The part you are still missing is that the original commit never
got lost. That's why am I talking explicitly about *recreating* and not
*rewriting*. It's like kind of like editing the commit message -- that
doesn't change the original commit either, but creates an update entry
in fossil that just says "well, take that commit, but show *this* commit
message".

> Another point is that when you rebase (or "linearize"), the new upstream
> tip might actually contain changes which will make some or all of the
> commits in the series being rebased/linearized be apply with some
> fuzz, and in complicated cases they might even fail to apply.  In this
> case, even "the contents" (as opposed to metadata) of the
> rebased/linearized commits will be re-written quite literally.  In the
> sense that if you had a commit A on top of upstream's U, and then
> rebased A on top of the updated U' to produce A', the differences A':U'
> and A:U might be substantial.

Yes, some commits might have been getting obsoleted. That's why it can't
be a fully automated process. So you start transplanting the other
commits and either include a dummy entry for nothing at all. Unless the
3rd party was explicitly basing the changes on that now irrelevant
commit, the transplating of their changes can still continue.

Joerg
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil mentioned on HN

[Andy Bradford]

Thus said "Gaurav M. Bhandarkar" on Thu, 17 Dec 2015 11:04:06 +0530:

> Normal merge or rebase both "enables" fast-forward merges. But the
> advantage "rebase-before-ff-merge" has is that it avoids other(s) extra
> "merge commits" that you would have done to get your branch updated with
> changes from remote.

Among the  reasons that brought me  to Fossil, over Git,  was that there
are fewer surprises in how it behaves  and that it was so much easier to
use. I've  never had to  worry about  ``rebase'' with Fossil.  Indeed, I
find that I use Git more like I use Fossil.

Do I need  the ``power'' that Git supposedly has?  I've always felt more
in control with Fossil.

Andy
-- 
TAI64 timestamp: 40005672ef59


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Rewrite of fossil-v-git.wiki. Was: Fossil mentioned on HN

[Ross Berteig]

On 12/16/2015 6:42 PM, Ron W wrote:


Actually, I think it's "spread sheets". In the company I work for, it's
customers and it's suppliers, when we meet with "project managers" about
the status of issues, the PMs are presenting from their spread sheets
and updating them as we disuss the issues.


As a consultant, I deal frequently with external customers who hired my 
company because they don't do (or often understand) software themselves. 
Getting them to use tickets directly is worse than herding cats.


We usually resort to spread sheets containing summary reports, often 
backed by printing the hot tickets so they can be discussed by email or 
across a table.


To make that process less painful, I built a tool that uses the optional 
JSON support to run ticket reports and present them in PDF created via 
Markdown and Pandoc. It is at Chiselapp, but I haven't touched it in a 
while.


  https://chiselapp.com/user/rberteig/repository/Ticketer/home


Fossil already has a way to "export" in a "flat file" format: "fossil
ticket show". It's basically TAB separated values. The fields shown are
driven by selecting a report that has been defined via the Fossil GUI.


There is also a built-in report number 0 which dumps all fields of all 
tickets.



Would be nice if there was a "fossil ticket export" command that would
produce a "proper" CSV file. While "proper" is still something of a
debate, most spread sheet apps (Excel, LibreCalc, GnomeCalc, etc) seem
to adequately digest CSV files where fields that contain comas or
newlines are enclosed in double quotes, with any contained double quote
escaped (I think by doubling - ie. like "has ""quote"" inside").


A problem with CSV is that there really isn't a clear definition of it 
at its edge cases other than testing what Excel will import correctly.


But it is true that the existing options supported by "fossil ticket 
show" do not even attempt to create valid CSV other than for simple 
reports where the columns are known to contain only "safe" characters.


Build fossil with JSON support, then you get access to a bunch of 
features with data transported in JSON with suitable quoting. I'm not 
sure why JSON is not enabled in the official distributions, it works for me.


--
Ross Berteig   r...@cheshireeng.com
Cheshire Engineering Corp.   http://www.CheshireEng.com/

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil mentioned on HN

[Warren Young]

On Dec 16, 2015, at 5:25 PM, Scott Robison  wrote:
> 
> fossil commit -m "" --branch sue --private

It never occurred to me that you could combine --branch and --private, probably 
because the possibility isn’t mentioned on this page:

  http://fossil-scm.org/index.html/doc/tip/www/private.wiki

It talks about automatic naming of the branch to “private,” so I assumed that 
was the only way it could work.

Perhaps someone with checkin rights could add an example of an explicitly-named 
private branch.

If you let Fossil name the branch for you, it behaves as I said: after creating 
the second private branch, you get complaints like "WARNING: multiple open leaf 
check-ins on private:” from “f stat”.

I wonder if automatic naming is a good thing.  Maybe --branch should be 
required by --private?
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Rewrite of fossil-v-git.wiki. Was: Fossil mentioned on HN

[Stephan Beal]

On Thu, Dec 17, 2015 at 9:28 PM, Ross Berteig  wrote:

>
> Build fossil with JSON support, then you get access to a bunch of features
> with data transported in JSON with suitable quoting. I'm not sure why JSON
> is not enabled in the official distributions, it works for me.


It's historical: Richard said, way back when, that he'd enable it if it got
full-featured testing, including fuzzy input tests (to check against
external exploits using invalid inputs). i never did that, and my ongoing
arm nerve damage (from too much/sustained typing!) is keeping me from
meaningfully contributing to any software for the foreseeable future, so
i'm not likely to ever get around to it :/. Contributions would be welcomed!

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Rewrite of fossil-v-git.wiki. Was: Fossil mentioned on HN

[Eric Rubin-Smith]

>
> > >> Would be nice if there was a "fossil ticket export" command that would
> > >> produce a "proper" CSV file. {snip}
> > > A problem with CSV is that there really isn't a clear definition of it
> at
> > > its edge cases other than testing what Excel will import correctly.
> >
> > Which is a sorry state of things, in itself. Reading an article about
> support
> > of CSV files in PostgreSQL {snip}
>
> If you want to get files with newlines etc into Excel, your best bet is
> always the libreoffice round. Alternatively, creating Office XML might
> also be an option.{snip}


Maybe JSON is a better bet.  Fossil could support a JSON ticket dump in
some standard form.  And hey, we can reuse someone's work who has already
figured out a decent way to represent a ticket database in JSON:

https://confluence.atlassian.com/jira/importing-data-from-json-495976468.html

So if you follow that form, then you get your Jira export capability for
free. :-)

Eric
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] bug: fossil import --git (somteimes tag will be missing)

[taka]

bug: fossil import --git (somteimes tag will be missing)

https://git-scm.com/docs/git-fast-import
reset
> 'reset' SP  LF
> ('from' SP  LF)?
> LF?

fossil skip the tag of reset.
https://www.fossil-scm.org/index.html/artifact/19f34d2902649e2ca572089b3766f259f0a5c132?txt=1=547


Index: src/import.c
==
--- src/import.c
+++ src/import.c
@@ -542,12 +542,18 @@
   gg.xFinish();
   gg.xFinish = finish_tag;
   trim_newline([4]);
   gg.zTag = fossil_strdup([4]);
 }else
-if( strncmp(zLine, "reset ", 4)==0 ){
+if( strncmp(zLine, "reset ", 6)==0 ){
   gg.xFinish();
+  trim_newline([6]);
+  z = [6];
+  if( strncmp(z, "refs/tags/", 10)==0 ){
+z += 10;
+if( z[0]!=0 ) fprintf(stderr, " Sorry, The Tag was missing: %s\n" , z);
+  }
 }else
 if( strncmp(zLine, "checkpoint", 10)==0 ){
   gg.xFinish();
 }else
 if( strncmp(zLine, "feature", 7)==0 ){

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Rewrite of fossil-v-git.wiki. Was: Fossil mentioned on HN

[Richie Adler]

Scott Robison decía, en el mensaje "Re: [fossil-users] Rewrite of
fossil-v-git.wiki. Was: Fossil mentioned on HN" del 17/12/2015 21:12:09:

> Microsoft software has been exporting and importing CSV files for multiple
> decades. The CSV "standard" is just over one decade old. There are plenty of
> reasons to object to Microsoft, but this doesn't seem like one of them, 
> really.

Please, read 1.1 at http://www.pg-versus-ms.com/ in full if you haven't done
so. I think the argument they make there is compelling.

Microsoft has also been creating operating systems for many years now. That
doesn't seem to make them particularly good at it, though. But if you think
that might makes right and that a de facto standard trumps a better designed
one, by all means, say so explicitly so I can adjust my e-mail filters
accordingly.

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Rewrite of fossil-v-git.wiki. Was: Fossil mentioned on HN

[Richie Adler]

El 17/12/2015 a las 17:28, Ross Berteig escribió:

> On 12/16/2015 6:42 PM, Ron W wrote:

>> Would be nice if there was a "fossil ticket export" command that would 
>> produce a "proper" CSV file. While "proper" is still something of a 
>> debate, most spread sheet apps (Excel, LibreCalc, GnomeCalc, etc) seem to
>> adequately digest CSV files where fields that contain comas or newlines
>> are enclosed in double quotes, with any contained double quote escaped (I
>> think by doubling - ie. like "has ""quote"" inside").
> 
> A problem with CSV is that there really isn't a clear definition of it at
> its edge cases other than testing what Excel will import correctly.

Which is a sorry state of things, in itself. Reading an article about support
of CSV files in PostgreSQL (at http://www.pg-versus-ms.com/), I learned that
there is somewhat of a standard of CSV defined as a RFC at
http://tools.ietf.org/html/rfc4180; I also learned that no Microsoft product
(including MSSQL Server, Excel and Access) can import the standards-compliant
file linked in the article. So apparently your use of JSON was the safest
course of action.

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil mentioned on HN

[Konstantin Khomoutov]

On Wed, 16 Dec 2015 14:28:39 -0700
Scott Robison  wrote:

[...]
> I realize that 'get rebase -i' gives a lot more tools, but couldn't
> 99% of rebase use cases be handled with private branches?

`git rebase` is about rewriting history.  It has several modes of
operation (that is, it can be used for tasks different from its
original intent -- rebasing -- such as squashing several commits
together, editing a commit, splitting commits, deleting commit etc) but
no matter what mode `git rebase` is being used in, it rewrites
(recreates) commits.

If a VCS assumes the dogma of never touching a commit once it's created,
it can't have rebase-like functionality.

On the other hand, whatever is being said here about having rebasing
in Git is mostly religious bs: any sensible Git user knows that
you never rebase what you already pushed to a repo accessible by anyone
other than whoever did that push.  So if the talk is about not touching
the sacred history on a branch but rather creating another (private)
branch and recreating some of the original work there differently
(through using cherry pick etc) then yes, it's almost like rebasing,
just less convenient to use.

And there's another problem: say, if I support a pile of code I intend
to eventually submit upstream on a dedicated branch (a typical case for
"classic" rebasing) I do periodic synchronization with upstream by
pulling in their changes and replaying my changes on top of theirs.
Each time after this act I have a changed branch, and I want to push it
somewhere (to another maching I work at, for instance), and to support
that, the VCS has to 1) allow me to do that; 2) support "forced
pushing" where I explicitly tell it I want to overwrite a remote branch
with the branch I'm pushing.  IIUC, Fossil's private branches as of now
don't quite cut it because they don't support the points above.
Hence to me, private branches look more like what's known in some VCS
systems as "shelving": a possibiliy to keep some bits uncommitted/not
sent to a rendez-vous repo.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users