[L2Ork-dev] Introductory Mail GSoC participant

[Jonathan Wilkes]

On Sat, May 5, 2018 at 11:24 AM, pranay gupta
<pranayguptastudent at gmail.com> wrote:
> Hello Jonathan,
>
> Currently I have a feature branch for the double version in my fork of
> pd-l2ork. I was hoping if you could make one in your repository to which I
> could keep making merge requests.

For this first case with such a small change, go ahead and make a
merge request to master.

Ideally I'd like to keep it that way. However, Gitlab CI is
unfortunately *extremely*
brittle and breaks even for trivial cases where I want to give other developers
access. (Worse, runners can fail without any error given.)

I think the only way to deal with this is to set up a generic "dev"
branch where I accept
merge requests just in order to trigger CI.  Again, not ideal as it
introduced complexity,
but I don't see any alternative.

I'll set up a "dev" branch later today.

>
> Also I had pushed some binaries in the first commit that I made but now I
> have reverted that and here is the link to the new commit.
> https://git.purrdata.net/pranay_36/purr-data/commit/39b27d199de7de798c6da47a07207c7417e0e33b

If you make a merge request from that branch, you'd be requesting to merge this:

small_change_with_binaries -> another_commit_that_removes_the_binaries

That would mean that if we merged it, git would add objects to git for all those
binaries, plus the delta for the second commit that fixes the first
error. But we
don't want to carry that data around in the git history for Purr Data.

In the master branch we want to end up with this:

small_change

It's probably easiest in this case to just make a new branch and try committing
the small change without adding the binaries. But if you want to get
some practice
with git you can try creating a new branch off your existing one and rebasing.

-Jonathan