On Sat, Jul 20, 2019 at 5:14 PM 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
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
> 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
> 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
17 matches
Mail list logo
