Fetching updates on Dreamhack?

[ninetydegrees]

How does one update their repos on their hack now? The 'old' script no longer pulls anything for me (what used to be on http://wiki.dwscoalition.org/wiki/index.php/Dev_Maintenance) and I don't understand how I can keep up with changes. :/

(Context: I'm on Windows; I use PuTTY and WinSCP).

Edit: ok, if anybody else wonders, short answer is you can no longer update your hack using old methods. :/

Edit 2: long answer is you can switch to the new system. See comments for detailed instructions. :)

Comments

[kareila]

I would expect the new instructions on http://wiki.dwscoalition.org/wiki/index.php/Dev_Maintenance to work, but I haven't upgraded my 'hack yet. It may succeed silently?

[ninetydegrees]

They didn't work for me: it gave me an error and the files which should have been updated haven't. Maybe I've done something wrong.

Edit: Aren't these are what I'm supposed to do in Git Shell and not the old system? This is very confusing.

[kareila]

You said you were using PuTTY to get a command line on your Dreamhack, correct? The commands should be used there. Is that what you were confused about?

[ninetydegrees]

As I said the commands don't work for me. No, the confusing part is that I'm still using the old system and I no longer understand how I'm supposed to make it work and I would switch to the new system if I understood how it worked (and if I hadn't been told to keep on doing this the old way). I thought I was supposed to keep doing things as usual until I was told to switch but, apparently, no. I'm lost.

[kareila]

Okay, I think I understand now. If you haven't switched to the new system, you won't be able to pull in the new changes because they're not being posted in the old repository any more. Mark and Fu stopped mirroring the changes in both places after the last code push.

When you were told you could keep working "the old way," that referred specifically to the patch submission process, not the update process. You are still able to submit patches through Bugzilla instead of having to create a Github pull request. But if you want to work against the very latest code, you will need to download it from the git repository.

I'm sorry if this is upsetting for you! I know it's a lot to take in and there hasn't been a lot of communication because the kinks in the process are still being worked out.

[yvi]

Mark and Fu stopped mirroring the changes in both places after the last code push.

Huh, I totally missed that. I guess I have a lot of work to do before I can actually go back to coding again, then.

Was there an announcement I missed? I'm not seeing anything on dw_dev

NEW THREAD

[foxfirefey]

Okay, as far as I know now you have a shiny new git-based install that is up to date. And everything is loading and everything.

I am assuming we want to work through what happens when making changes now?

Re: NEW THREAD

[ninetydegrees]

This is where http://wiki.dwscoalition.org/wiki/index.php/Dev_Maintenance comes in?

The git stash thing seems simple enough although I'll have questions about that later so first thing I want to know is how grab updates because that's always the first thing I do so updating dwu I guess? If so can you link the two scripts with && \?

Re: NEW THREAD

[foxfirefey]

Hmm, I would not trust the dwu script that is up there yet, it hasn't taken into account some things I have found. (needing to be on an originating branch, etc). I've never used those scripts myself. So I think doing it by hand and seeing how it happens is ideal for now.

I went through the Dev Maintenance first section and changed things based on my experiences. Basically, since you should be doing your changes on their own branches, you'll need to checkout the main develop branch, and then pull from the Dreamwidth repository, then push it back to your Dreamwidth fork. If you could look at the changes I made and see if they make sense, I would much appreciate it.

Re: NEW THREAD

[ninetydegrees]

<3 Thank you so much! I'll have a look at it tomorrow because it's evening here and I'm too tired to give it the attention it requires.

Re: NEW THREAD

[foxfirefey]

Thank YOU so much. I'll be around at the same times tomorrow for you, okay?

[foxfirefey]

Okay, I've just finished up some additional revamps of Dev Maintenance. I feel a lot more comfortable with these instructions.

I have also made slight changes to the moving instructions that I hope will improve them for folks new to them.

[ninetydegrees]

The bits I've done seem a lot clearer to me except that I don't understand why dw-nonfree is set apart. Can't tell about the rest yet.
Question: do new users have to move the old hack as well or is it just for people who already had one? And what about the other instructions while I'm at it?

[foxfirefey]

So basically, dw-nonfree is a different repository, and updating it is a separate process from dw-free. If you feel it's better, I can work it into the above, but it's awkward because there might be cases where somebody is working for, say, their clone site and then they don't have dw-nonfree, and we've had people making clone sites start using dw-nonfree before which is awkward.

New users still have to move the old hack--I think Sophie has not yet made a new process for setting up. (It's tricky because of all the account stuff that goes on with Github now.)

I'm assuming by other instructions you mean flow stuff like making a branch, committing changes to it, pushing them up to Github and making a pull request, yes? Because we can make them right now!

[ninetydegrees]

Maybe make a link? Because as I reread that section I wondered: what about nonfree? I mean, from my POV it's logical to update everything at the same time but I get why you made it separate.

No, I meant all the other instructions on the Moving... page but it was a stupid question because yeah of course.

GitHub Workflow

[ninetydegrees]

Let's start coding!

Re: GitHub Workflow

[ninetydegrees]

Ok everything went well (and was so much simpler than before!) so I'm at this point:

Making a pull request

Two questions:

a) Should I do that since we're supposed to be upload patches the True and Tried way (Mark's words :)?

b) If I'm not should I simply generate the diff and upload it as my patch on Zilla? Or do something else?

Re: GitHub Workflow

[fu]

Yes, make a pull request definitely.

I think that Mark was making a joke about the True and Tried way (or maybe saying that we wouldn't be getting rid of that just yet? I don't remember the context in which he said it)

So yup just make a pull request :)

Re: GitHub Workflow

[ninetydegrees]

Ok thanks!

One more question: my original branch didn't have a correct name so I tried to rename it using branch -m. Bad move because now what I see in PuTTY and on GH are different now. On PuTTY everything went fine; On GH it just created a new branch with the name I wanted. How do I get rid of the old branch on GH?

Re: GitHub Workflow

[fu]

Okay try this:

git branch -r -d origin/OLDBRANCHNAME

Note: the origin is part of it and (probably) shouldn't be changed.

If you want to get a list of all your remote branches to be really sure, do this:

git branch -r

dw-old?

[ninetydegrees]

Oh one more question: is there a point in keeping dw-old once you've got everything set up?

Re: dw-old?

[fu]

Nope; only need it if you have patches you haven't transferred over.

Re: dw-old?

[ninetydegrees]

Yippee yay! Thank you!

Re: dw-old?

[denise]

To add on to what Fu said, though: we're not hurting for space, so i'd leave it for at least a month or so to make sure there's nothing you forgot.

Re: dw-old?

[ninetydegrees]

Er, too late. XD But I was 100% sure I didn't have anything on it. I always deleted patches from my queue once I'd uploaded them.