Am 20.07.2019 um 23:18 schrieb Martin Frb:
On 20/07/2019 23:13, Sven Barth via fpc-devel wrote:
For example I myself don't commit my .gitignore, but simply have it
lying around as untracked file.
Try
.git/info/exclude
https://git-scm.com/docs/gitignore
Nice! :D
Regards,
Sven
On 20/07/2019 23:13, Sven Barth via fpc-devel wrote:
For example I myself don't commit my .gitignore, but simply have it
lying around as untracked file.
Try
.git/info/exclude
https://git-scm.com/docs/gitignore
___
fpc-devel maillist -
Am 20.07.2019 um 22:29 schrieb Ryan Joseph:
On Jul 20, 2019, at 4:19 PM, Sven Barth via fpc-devel
wrote:
Why is your .gitignore so big? Mine looks like this:
I’m sorry, what I wrote didn’t make any sense. I mean that after I delete
.gitignore then all the .o etc.. files that it was
On 20/07/2019 22:14, Ryan Joseph wrote:
On Jul 20, 2019, at 4:02 PM, Martin Frb wrote:
"origin/master" is the not modified trunk?
No, what I did was fork https://github.com/graemeg/freepascal and then a create
new feature branches based on master. “origin” I believe refers to my forked
> On Jul 20, 2019, at 4:19 PM, Sven Barth via fpc-devel
> wrote:
>
> Why is your .gitignore so big? Mine looks like this:
I’m sorry, what I wrote didn’t make any sense. I mean that after I delete
.gitignore then all the .o etc.. files that it was ignoring now come flooding
back into the
> On Jul 20, 2019, at 4:12 PM, denisgolovan wrote:
>
> Have you renamed your branch?
> Last time you mentioned it was "gen-const-new”.
The branch is called “generic_constants” but I’m making temporary copies for
testing so I don’t mess up the safe one.
> And you didn't include enough log
Am 20.07.2019 um 18:58 schrieb Ryan Joseph:
3) remove .gitignore (which now includes thousands of .o/.ppu files which need
to be deleted) and any other unrelated personal files.
Why is your .gitignore so big? Mine looks like this:
=== file begin ===
# ignore binary files
*.o
*.ppu
*.exe
> On Jul 20, 2019, at 4:02 PM, Martin Frb wrote:
>
> "origin/master" is the not modified trunk?
No, what I did was fork https://github.com/graemeg/freepascal and then a create
new feature branches based on master. “origin” I believe refers to my forked
repo on GitHub and “upstream” is the
On 20/07/2019 22:02, Martin Frb wrote:
IF this does not show all of your commits (because the branches where
merged), find the revision ONE BEFORE your first commit. (say it is
0abcde):
git rebase -i 0abcde origin/master
That may have to be
git rebase -i --onto origin/master
> Here’s the results of "git log —graph” on the feature branch. Does that first
> part look right? I feel like I messed up something from the very start but
> I’m not sure what.
>
> Ryans-MacBook-Pro-2:fpc-git ryanjoseph$ git log --graph
> * commit c5a6c2c0822d6c869a788a98a144e739a97d517a
Am 20.07.2019 um 18:38 schrieb Ondrej Pokorny:
The old Wiki page should propably be updated to reflect the current
state of affairs...
I deleted the old information (nearly everything) and put a link to
the new Wiki page there.
Probably for the best ;)
You can also take a look at Delphi
> On Jul 20, 2019, at 3:01 PM, denisgolovan wrote:
>
> Generally it means all your feature branch commits are on top of
> origin/master.
>
> It's a bit difficult to explain via text.
> Try doing "git log --graph" before and after doing rebase and you will see it
> changes in feature branch
On 20/07/2019 19:57, Ryan Joseph wrote:
On Jul 20, 2019, at 1:04 PM, Jonas Maebe wrote:
You can rebase your feature branch on latest trunk/master instead of
merging. I think that may even work after you have previously merged it
(and it should get rid of all merge commits).
I tried doing
> I tried doing "git rebase origin/master” on the feature branch BEFORE I
> merged the master but it says "Current branch gen-const-new is up to date.”.
> What is rebase doing that it thinks the feature branch is up to date?
Generally it means all your feature branch commits are on top of
Hello,
I updated trunk now and wanted to test the attributes support - and now
I get Internal error 200510032 when compiling the SynEdit package. (See
attached screenshot.)
synedithighlighterxmlbase.pas(236,31) Error: Internal error 200510032
Rebuild clean doesn't help. I can go over the
> On Jul 20, 2019, at 1:04 PM, Jonas Maebe wrote:
>
> You can rebase your feature branch on latest trunk/master instead of
> merging. I think that may even work after you have previously merged it
> (and it should get rid of all merge commits).
I tried doing "git rebase origin/master” on the
On 20/07/2019 18:58, Ryan Joseph wrote:
> I’m getting better with git but I’m still having problems with basic
> workflows. My newest dilemma is trying to submit a patch which is actually up
> to date with the current master branch
> (https://bugs.freepascal.org/view.php?id=35140). Here’s what
I’m getting better with git but I’m still having problems with basic workflows.
My newest dilemma is trying to submit a patch which is actually up to date with
the current master branch (https://bugs.freepascal.org/view.php?id=35140).
Here’s what I do:
1) pull changes from the master remote
On 20.07.2019 13:56, Sven Barth via fpc-devel wrote:
Here: https://wiki.freepascal.org/Custom_Attributes
Thank you!
The old Wiki page should propably be updated to reflect the current
state of affairs...
I deleted the old information (nearly everything) and put a link to the
new Wiki
Note that there is possible room for improvement with this concept (like
maybe only running the semantic check on nodes that exist before the
first pass, not executing it on any transformed nodes), but I wanted to
get something clean working first, and fix the bugs that have been on
the system
On Sat, 20 Jul 2019, Marco van de Voort wrote:
Op 2019-07-20 om 16:04 schreef Michael Van Canneyt:
Why is this field deprecated and not published? It really
complicates dual maintenance of apps with database fields.
Because it is redundant. The fieldkind property is what you need.
Set
Op 2019-07-20 om 16:04 schreef Michael Van Canneyt:
Why is this field deprecated and not published? It really
complicates dual maintenance of apps with database fields.
Because it is redundant. The fieldkind property is what you need.
Set fieldKind=fkLookup
As said, it causes annoying
On Sat, 20 Jul 2019, Marco van de Voort wrote:
Op 2019-07-20 om 14:40 schreef Michael Van Canneyt:
Why is this field deprecated and not published? It really complicates
dual maintenance of apps with database fields.
Because it is redundant. The fieldkind property is what you need. Set
Op 2019-07-20 om 14:40 schreef Michael Van Canneyt:
Why is this field deprecated and not published? It really complicates
dual maintenance of apps with database fields.
Because it is redundant. The fieldkind property is what you need. Set
fieldKind=fkLookup
As said, it causes annoying
On Sat, 20 Jul 2019, Marco van de Voort wrote:
Why is this field deprecated and not published? It really complicates
dual maintenance of apps with database fields.
Because it is redundant. The fieldkind property is what you need.
Set fieldKind=fkLookup
Michael.
Why is this field deprecated and not published? It really complicates
dual maintenance of apps with database fields.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Ondrej Pokorny schrieb am Sa., 20. Juli 2019, 12:04:
> Hello!
>
> I saw that Sven committed property attributes support in trunk. Thank
> you for this!
>
> Is there any documentation how to use them? (Syntax, reading information
> during runtime etc?) I only found very old information:
>
Hello!
I saw that Sven committed property attributes support in trunk. Thank
you for this!
Is there any documentation how to use them? (Syntax, reading information
during runtime etc?) I only found very old information:
https://wiki.freepascal.org/Property_attributes
28 matches
Mail list logo
