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: Rich
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
> r
On Thu, Dec 17, 2015 at 3:33 PM, Warren Young wrote:
> 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
On Thu, Dec 17, 2015 at 4:39 PM, Richie Adler wrote:
> 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
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&ln=547
Index: src/import.
>
> > >> 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 s
On Thu, Dec 17, 2015 at 08:39:03PM -0300, Richie Adler wrote:
> 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 some
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
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
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 issue
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 f
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
On Thu, 17 Dec 2015 18:57:06 +0300
Konstantin Khomoutov wrote:
[...]
> 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 i
On Thu, 17 Dec 2015 13:16:43 +0100
Joerg Sonnenberger 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
On Thu, Dec 17, 2015 at 02:43:56PM +0300, Konstantin Khomoutov wrote:
> 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 ab
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
16 matches
Mail list logo
