Re: [git-users] Help with collaboration, sharing/pushing changes, keeping history clean, etc.

2018-11-23 Thread Michael


On 2018-11-23, at 3:24 AM, Philip Oakley  wrote:

> 
> On 23/11/2018 01:29, Michael wrote:
>> On 2018-11-22, at 2:49 PM, Philip Oakley  wrote:
>> 
>>> if it is just URL replacement then consider a smudge/clean filter so that 
>>> the worktree (local checked out files) have the URLs you want, but when you 
>>> checkin/add/commit the URLs are replaced (changed back to) the URLs the 
>>> upstream wants.
>>> 
>>> 
>>> I guess it is a simple sed invocation, with reverse in the other direction.
>> And if I'm talking about serving something out of github in the first place? 
>> ... Between github.io which serves github, gh-pages branch, or jsdelvr, 
>> which will serve any github _ref_ but caches it for a week (makes it 
>> impossible to do testing or changes)?
>> 
>> I guess this is the problem. It needs to be in github to be usable, it needs 
>> to be on gh-pages for github.io to serve as current, which in turn means 
>> that "gh-pages" is a moving branch that gets reset between testing and 
>> deployment
> 
> It would appear that it is that distinction between the testing environment 
> and the deployment environment that needs to be made clear.  They are (should 
> be?) distinct, independent parts, even if they of on top of the same host 
> infrastructure. Is the testing 'private' [does it need to be secure?]

Ok. There are three sets of configs. None are private/need security.
The changes are the URL base that serves the scripts, located in two places: a 
.user.js for tampermonkey, and the main "AutoTrimps2.js" that loads the 
modules. AT2.js also contains the changelog.

Set number 1 is what the upstream uses. If I want to push any changes as a pull 
request, they need to use this.
Set number 2 is my production release. This is what will be used normally. This 
is the stuff that I publish for others to use when it has not yet been pulled, 
and what I use normally. It has my modified changelogs, as well as my URL's. To 
keep it up to date, every so often I merge upstream in; this "pollutes" the 
history, as discussed in the "rerere" manpage.
Set number 3 is my testing release. This isn't private or secure -- anyone 
could use it -- but it has the "Warning, this may destroy your game/save file" 
notice. I want this to use a third URL. 

Number three ran into the problems. Jsdelvr can serve any github named ref, but 
it wants to cache -- so I have to purge everything between updates. That's 
feasible for hosting my releases -- set #2 -- but not for hosting my testing -- 
set #3. So moving forward, that will be a change, but it in turn means I have 
to compile a list of every URL this wants to serve from me (and I only think I 
know what they are ... :-).

What I did, that I thought would be usable: First, I made a "test patch" off 
the merge base, that just replaced the changelog with the "Test version, may 
destroy your save" warning, changed the URL's to my github, and tried to use 
rebase --onto to put that at the end of my current editing. It ... needed a 
merge edit, but worked. Unfortunately, it also removed the original source (ok, 
it removed the reference, but it made it effectively unreachable and subject to 
garbage collection), so it's not something that I can repeat automatically as a 
"sh makeTestDeploy" type of command.

It also had the flaw of making my gh-pages branch now contain the test, so 
after I had tested, I would have to revert and repush -- effectively making it 
so that others could not rely on my version of the script.

> It is likely that you would want a special script that will take the last 
> test branch commit and convert that to being a commit on top of the deploy 
> branch (using the `git update-ref ` to 'move' the cleaned files onto the 
> deploy branch.

"update-ref" ?? ... Ha! I had been using "git reset --hard" to do this! So much 
cleaner.


> It is the making of the 'Chinese Walls' between the two that will clarify the 
> separation of concerns. You need two sets of 'gh-pages' one is the deployed 
> [public access] version, and one is the test version [seen by you] [plus the 
> security question..]. If you can only test by placing the test code onto part 
> of Github, then you'll need a distinct place for that (e.g. your 
> https://github.com/keybounce/AutoTrimps).
> 
> you may need an additional 'deploy' branch that has the sed conversion 
> applied to it if you cannot test locally. In that way you have moved the 
> smudge/clean filter from being in the repo<->worktree checkout step to being 
> between the test & deploy branches. The deploy branch can then be PR'd to the 
> upstream.
> 
> It is likely that you would want a special script that will take the last 
> test branch commit and convert that to being a commit on top of the deploy 
> branch (using the `git update-ref ` to 'move' the cleaned files onto the 
> deploy branch.
> 
> P.
> 
>> , which in turn means if I want to publish I need to ... ??? Still working 
>> on that, lets call it "step 2" for now :-).

Re: [git-users] Help with collaboration, sharing/pushing changes, keeping history clean, etc.

2018-11-23 Thread Philip Oakley



On 23/11/2018 01:29, Michael wrote:

On 2018-11-22, at 2:49 PM, Philip Oakley  wrote:


if it is just URL replacement then consider a smudge/clean filter so that the 
worktree (local checked out files) have the URLs you want, but when you 
checkin/add/commit the URLs are replaced (changed back to) the URLs the 
upstream wants.


I guess it is a simple sed invocation, with reverse in the other direction.

And if I'm talking about serving something out of github in the first place? 
... Between github.io which serves github, gh-pages branch, or jsdelvr, which 
will serve any github _ref_ but caches it for a week (makes it impossible to do 
testing or changes)?

I guess this is the problem. It needs to be in github to be usable, it needs to be on 
gh-pages for github.io to serve as current, which in turn means that "gh-pages" 
is a moving branch that gets reset between testing and deployment


It would appear that it is that distinction between the testing 
environment and the deployment environment that needs to be made clear.  
They are (should be?) distinct, independent parts, even if they of on 
top of the same host infrastructure. Is the testing 'private' [does it 
need to be secure?]


It is the making of the 'Chinese Walls' between the two that will 
clarify the separation of concerns. You need two sets of 'gh-pages' one 
is the deployed [public access] version, and one is the test version 
[seen by you] [plus the security question..]. If you can only test by 
placing the test code onto part of Github, then you'll need a distinct 
place for that (e.g. your https://github.com/keybounce/AutoTrimps).


you may need an additional 'deploy' branch that has the sed conversion 
applied to it if you cannot test locally. In that way you have moved the 
smudge/clean filter from being in the repo<->worktree checkout step to 
being between the test & deploy branches. The deploy branch can then be 
PR'd to the upstream.


It is likely that you would want a special script that will take the 
last test branch commit and convert that to being a commit on top of the 
deploy branch (using the `git update-ref ` to 'move' the cleaned files 
onto the deploy branch.


P.


, which in turn means if I want to publish I need to ... ??? Still working on that, lets 
call it "step 2" for now :-).

Meanwhile, there's still all the other issues about contributing pull requests when any branch will 
have both pullable and non-pullable changes, maintaining my own "current", and keeping a 
readable history. Git for Windows, as I understand it, does straight rebasing and losing all 
history of patches; there has (?) to be better? right? imerge's "rebase with history" -- 
did anything ever come from that?


P.

On 22/11/2018 21:09, Michael wrote:

I think that I am using git incorrectly. What I want to do is way too hard.

I have forked someone's repository from GitHub.
I had to make some initial changes to URLs to be able to run my version.
I made changes that consist of code change, and a change log change.

First issue: I want to make a pull request for GitHub that has those code 
changes. I don't want to include the changed URLs, and I know that the change 
log change will not apply cleanly. How do I contribute my changes back to the 
base?

Second issue: I have other changes after that first one. How do I contribute 
those changes as separate pull requests without having them contain the first 
change, or the changed URLs, etc.?

Third issue: I want to keep up to date with the parent. As it makes changes, I want to 
merge those changes in. I know this is what rebase is for, and I know that this is the 
issue that "Git for Windows" and others have to deal with, but either I'm doing 
it wrong, or it's a lot harder than it ought to be.

Fourth issue: I want to keep my history clean. A quick look at the "rerere" man 
page shows the issue -- showing a lot of merges from the origin back to me that later 
wind up being merged back into the origin results in a mess. By now this has to be a 
solved problem, right? If it got Linus to complain, then there's a solution, right?

Fifth issue: test deployment. Separate from my live branch (which others may be 
using), I want a test deployment. This would have a different set of URLs that 
I changed in the first step, as well as a different change log/welcome message 
to indicate that it is the test deployment. But it would basically be the same 
set of changes, that would be applied wherever it was needed. Except that the 
last time I moved this change, with a rebase -onto, I discovered that it was 
actually moved. What I think I want would be a way to reapply a set of changes 
at the tip of a branch head for test deployment, without deleting that set of 
changes -- ideally, so a single script could apply the same constant set of 
changes.

The problem with that fifth issue is that as far as I can tell there's no way 
to do that in Git, so clearly that's not what I want to do.

Help? I feel 

Re: [git-users] Help with collaboration, sharing/pushing changes, keeping history clean, etc.

2018-11-22 Thread Michael


On 2018-11-22, at 2:49 PM, Philip Oakley  wrote:

> if it is just URL replacement then consider a smudge/clean filter so that the 
> worktree (local checked out files) have the URLs you want, but when you 
> checkin/add/commit the URLs are replaced (changed back to) the URLs the 
> upstream wants.
> 
> 
> I guess it is a simple sed invocation, with reverse in the other direction.

And if I'm talking about serving something out of github in the first place? 
... Between github.io which serves github, gh-pages branch, or jsdelvr, which 
will serve any github _ref_ but caches it for a week (makes it impossible to do 
testing or changes)?

I guess this is the problem. It needs to be in github to be usable, it needs to 
be on gh-pages for github.io to serve as current, which in turn means that 
"gh-pages" is a moving branch that gets reset between testing and deployment, 
which in turn means if I want to publish I need to ... ??? Still working on 
that, lets call it "step 2" for now :-).

Meanwhile, there's still all the other issues about contributing pull requests 
when any branch will have both pullable and non-pullable changes, maintaining 
my own "current", and keeping a readable history. Git for Windows, as I 
understand it, does straight rebasing and losing all history of patches; there 
has (?) to be better? right? imerge's "rebase with history" -- did anything 
ever come from that?

> 
> P.
> 
> On 22/11/2018 21:09, Michael wrote:
>> I think that I am using git incorrectly. What I want to do is way too hard.
>> 
>> I have forked someone's repository from GitHub.
>> I had to make some initial changes to URLs to be able to run my version.
>> I made changes that consist of code change, and a change log change.
>> 
>> First issue: I want to make a pull request for GitHub that has those code 
>> changes. I don't want to include the changed URLs, and I know that the 
>> change log change will not apply cleanly. How do I contribute my changes 
>> back to the base?
>> 
>> Second issue: I have other changes after that first one. How do I contribute 
>> those changes as separate pull requests without having them contain the 
>> first change, or the changed URLs, etc.?
>> 
>> Third issue: I want to keep up to date with the parent. As it makes changes, 
>> I want to merge those changes in. I know this is what rebase is for, and I 
>> know that this is the issue that "Git for Windows" and others have to deal 
>> with, but either I'm doing it wrong, or it's a lot harder than it ought to 
>> be.
>> 
>> Fourth issue: I want to keep my history clean. A quick look at the "rerere" 
>> man page shows the issue -- showing a lot of merges from the origin back to 
>> me that later wind up being merged back into the origin results in a mess. 
>> By now this has to be a solved problem, right? If it got Linus to complain, 
>> then there's a solution, right?
>> 
>> Fifth issue: test deployment. Separate from my live branch (which others may 
>> be using), I want a test deployment. This would have a different set of URLs 
>> that I changed in the first step, as well as a different change log/welcome 
>> message to indicate that it is the test deployment. But it would basically 
>> be the same set of changes, that would be applied wherever it was needed. 
>> Except that the last time I moved this change, with a rebase -onto, I 
>> discovered that it was actually moved. What I think I want would be a way to 
>> reapply a set of changes at the tip of a branch head for test deployment, 
>> without deleting that set of changes -- ideally, so a single script could 
>> apply the same constant set of changes.
>> 
>> The problem with that fifth issue is that as far as I can tell there's no 
>> way to do that in Git, so clearly that's not what I want to do.
>> 
>> Help? I feel like this is where I move from being a beginner with Git to an 
>> intermediate with Git.
>> 
>> For reference:
>> 
>> My Fork: https://github.com/keybounce/AutoTrimps
>> Upstream: https://github.com/Zorn192/AutoTrimps
>> 

---
Entertaining minecraft videos
http://YouTube.com/keybounce

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [git-users] Help with collaboration, sharing/pushing changes, keeping history clean, etc.

2018-11-22 Thread Philip Oakley
if it is just URL replacement then consider a smudge/clean filter so 
that the worktree (local checked out files) have the URLs you want, but 
when you checkin/add/commit the URLs are replaced (changed back to) the 
URLs the upstream wants.



I guess it is a simple sed invocation, with reverse in the other direction.

P.

On 22/11/2018 21:09, Michael wrote:

I think that I am using git incorrectly. What I want to do is way too hard.

I have forked someone's repository from GitHub.
I had to make some initial changes to URLs to be able to run my version.
I made changes that consist of code change, and a change log change.

First issue: I want to make a pull request for GitHub that has those code 
changes. I don't want to include the changed URLs, and I know that the change 
log change will not apply cleanly. How do I contribute my changes back to the 
base?

Second issue: I have other changes after that first one. How do I contribute 
those changes as separate pull requests without having them contain the first 
change, or the changed URLs, etc.?

Third issue: I want to keep up to date with the parent. As it makes changes, I want to 
merge those changes in. I know this is what rebase is for, and I know that this is the 
issue that "Git for Windows" and others have to deal with, but either I'm doing 
it wrong, or it's a lot harder than it ought to be.

Fourth issue: I want to keep my history clean. A quick look at the "rerere" man 
page shows the issue -- showing a lot of merges from the origin back to me that later 
wind up being merged back into the origin results in a mess. By now this has to be a 
solved problem, right? If it got Linus to complain, then there's a solution, right?

Fifth issue: test deployment. Separate from my live branch (which others may be 
using), I want a test deployment. This would have a different set of URLs that 
I changed in the first step, as well as a different change log/welcome message 
to indicate that it is the test deployment. But it would basically be the same 
set of changes, that would be applied wherever it was needed. Except that the 
last time I moved this change, with a rebase -onto, I discovered that it was 
actually moved. What I think I want would be a way to reapply a set of changes 
at the tip of a branch head for test deployment, without deleting that set of 
changes -- ideally, so a single script could apply the same constant set of 
changes.

The problem with that fifth issue is that as far as I can tell there's no way 
to do that in Git, so clearly that's not what I want to do.

Help? I feel like this is where I move from being a beginner with Git to an 
intermediate with Git.

For reference:

My Fork: https://github.com/keybounce/AutoTrimps
Upstream: https://github.com/Zorn192/AutoTrimps



--
You received this message because you are subscribed to the Google Groups "Git for 
human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.