dw_dev | Entries tagged with github

As of this code push, we're using the Git repository for our code on production. If you haven't moved your own repositories over to Git yet, you should soon!

foxfirefey has a handy list of resources for the Git transition.

We just had our 101st pull request to the dw-free repository over on Github! Two of those were test pulls, but the others are all legit ;-)

The dw-nonfree repository, on the other hand, has only had 14 pull requests. Since we don't really want much here other than branding stuff, this is as it should be.

Quick note:

We'd like you to use your Dreamwidth username / email when committing. This makes it a lot easier for us to track who did what in the future. It also helps us match the author of the commit with who you are, and lets us confirm that we've received your CLA.

Edit your config (~/.gitconfig) and add this section:

[user]
        name = USERNAME
        email = USERNAME@dreamwidth.org

Then add your USERNAME@dreamwidth.org email to your Github account, so that the commits on Github will link to your identity on Github.

Please don't forget to tweak this setting on both your local computer and your Dreamhack if you do commits on both. Thank you!

If you're working on other projects, you can also just edit your author identity in just the Dreamwidth repositories (Thanks

shadowspar)

mark

If you use the "dwu" script from the wiki, you will need to update your local copy. I've made some changes because the last version of the script would merge changes from both develop and master, leading to broken environments and GitHub repositories.

http://wiki.dwscoalition.org/wiki/index.php/Dev_Maintenance#dwu_-_Updating_the_repos

Please use the updated script.

If you have gotten yourself into a broken state, let me know and I can walk you through fixing it. There is some force pushing involved, sadly.

mark

We did our first release from git tonight. It went well, I will chalk that up to all of the hard work from folks like fu and exor674 (and others!) to make sure that everything was in place. fu put together a nice "things we have to do" in dw_staff, so that was very helpful.

Anyway, I wanted to document some things that are important to know for the period between releases. This probably won't apply to most of you, but just in case...

So, we are following the document about a successful git branching model. This is what git flow is based on and it's a really efficient model, so we're using it for doing our features and in this case, our release.

The release process was, in essence:

Create a release-1.11.0 branch
Make final tweaks in this branch to get things ready for release
Push this branch live
Merge this branch back in to develop and master
Add a release tag with the version number on master

This leaves our repository in this state:

develop is still open, you can keep committing things to it (no code freeze, yay!)
master has stable tags, so you can always roll back to tags here (easy production rolls!)
release-1.11.0 is open for doing fixes on the live release (easy fixing production, yay!)

The thing that is important to know, if you are going to be committing fixes that you intend to go live, is that you need to make your changes on the release-x.xx.x branch -- not on develop. Any code committed to develop will, because of its nature, have to wait until the next code push -- weeks away.

If you have stuff you need to get live sooner (fixes to things broken in the last code push or stability/important fixes), you need to adjust your workflow slightly. It's pretty easy though, and goes something like this:

git checkout -b release-1.11.0 dreamwidth/release-1.11.0

Now make your fixes, as per normal, and submit a pull request. As long as your current branch is the release branch, then you will be able to submit a pull request on the appropriate branch, and we can merge it in and push it out to the site quite easily.

foxfirefey

As of several weeks ago, all commits to the Dreamwidth codebases have gone to our new repositories on Github:

There are a few relevant wiki documents that have been fully revised to account for this change:

Moving your Dreamwidth installation to use Github -- these instructions will tell you how to move your current Dreamhack/dev environment over to a Github based installation
Dev Maintenance -- this document tells you how to keep your Github Dreamwidth based installation (and your Dreamwidth forks) updated with the code from the Dreamwidth repositories
Draft: Github development process -- This is the document in the least refined state, so keep in mind that it is in stronger need of suggestions and revisions. It goes through the very basics of Git workflow. This and Dev Maintenance might eventually end up merged into one document.

We are working on getting the rest of the wiki development documentation updated (see the dw_wiki post). Feel free to comment to this post with your questions/concerns about the move!

Current Mood: excited

foxfirefey

As part of our move to Github we have a lot of development documentation to update.

If you want to be part of the vanguard, take a gander at the Moving your Dreamwidth installation to use Github instructions. People following them are encouraged to log into the #dreamwidth-dev channel on IRC for real time assistance.

denise

Yesterday I went to

schwern's "Git for Toddlers", an explanation of how git works using Tinkertoys. It was awesome and very helpful. There aren't any slides, but there's video of a previous iteration of the talk, so anybody who wants to watch it can:

Git for Ages Four and Up from OSDC!

denise

Tonight I decided I was going to figure out Git and Github enough to make a patch using it! Behind the cut is my adventures in Git-itude, detailing all the steps I took (and all the false starts, too.) I'm pretty sure this is all correct, but I haven't fact-checked the post with somebody who knows more than I do, so caveat lector (and if you spot an error, please do tell me so I can correct it!)

This post is also a bit vague on some process bits that we haven't decided yet, so when we flip the switch and move to using Github for development wholesale, some of these bits will look a little different. I just wanted to demystify the process a little, since I know that I was feeling a little trepidatious about this (AUUUGH, CHANGE IS SCARY) until I got into the guts of it and started playing around and realized how much nicer this process is going to be!

So, this is a log of the playing around I did tonight. :)

( Watch me flail! Watch me figure it out! )

And thus ends my first forays into git! There's a bunch of other stuff we'll need to go over, such as what to do if somebody else has made changes to the master DW branch while you were working on your patch, but that's a little bit hard to explain with words (usually it requires diagrams, although one of the talks I attended today had

schwern demonstrating it with Tinkertoys) so I'll hold off on that until another day. :)

denise

This morning at YAPC I attended an Intro to Git session presented by Randal Schwartz. It was an awesome session! I learned a lot about git and how it works (and how you shouldn't try to make it work). I was typing up notes to post for y'all, and then he mentioned at the end that he has both the slides and a video of the presentation (a version he gave in January) available online.

So, if you have a spare two hours and would like to learn about git, here you go:

Introduction to Git - video
Introduction to Git - slides

There's also a book that many people have highly recommended, called Pro Git by Scott Chacon. It's available free of charge in many formats, licensed as CC-BY-SA-NC.

I definitely felt much more comfortable with the idea of what git is, how it works, and why it does what it does when I finished the session, so if you're feeling anxious about the migration to github (which is a service layered on top of git, the underlying software), definitely check it out.

I've been reading up on Git, trying to figure out how to document a process that works for everyone, and it just isn't working. All I know is how I want to do things, and I can only guess what would work best for everyone. So instead of my sitting here writing down guidelines, which might get set in stone even if they don't really work for you, let's actually talk about it, and then document the hell out of what we decide on.

Big bold critical disclaimer: If you are uncomfortable with really vague instructions and a process that might break at any point, just hang back and wait! This is the "We need people to try doing this so we know where the major stress points are" step.

Other disclaimer: We'll document what seems a reasonable way to do things to make it easier for anyone coming in, but that doesn't mean you need to stick to the script strictly. You can manage your code on your end however you'd like -- so long as you send that pull request!

Useful links:

github:help -- check out the beginner and intermediate sections, as well as further git resources. I don't think we'll need anything from the other sections, until we run into specific issues.
Git flow -- abstraction on top of Git to make the most common workflow more convenient

( here's what we need to figure out )

After a bunch of discussion, we've decided to move from Mercurial to Git. Mercurial and Git are different version control systems. If you're not sure what that is, they basically manage code and the history of how the code has changed.

One big reason for using Git is Github. Github is a service that hosts code, and provides web-based tools to manage commits and reviews. This will make it a lot easier to work collaboratively, and simplify the process of submitting patches. The changeover may be a bit of a pain, but we will work to make it as easy as possible!

We've also decided to simplify our development environment. Instead of having the $LJHOME directory contain a bunch of repositories that need to be synced and copied around -- no one has ever understood this setup without a lot of explaining and re-explaining -- we will just have one set of directories. This means we can get rid of cvsreport.pl, which is the script that does the syncing between the $LJHOME directory and the repositories within it.

Nothing will change yet, but I thought (and denise agreed) it might be a good idea to post a very basic overview of how the process will be changing.

I'm still banging on the workflow; right now I'm just working with a couple of the more experienced devs so we can get a general idea of what needs to be done. We'll invite more people for a test run once to iron out the more fiddly bits once we have a list of steps to try.I expect we'll have to adjust again after people have tried it out for real.

Don't worry! Nothing is going to happen without a lot more in the way of information and tutorials and explanations, but here is a very high-level overview.

( diagrams and details within )

I did a quick run through of a changeset submission process with

exor674, one for Mercurial and one for Git.

Assumptions:

pulling from the dev branch back to stable is roughly equivalent between Git and Mercurial, or is easy enough to work around on the committer side, so this is not shown here.

we want to move away from asking for patches, to pull requests which include more context

we need to concentrate on the branching workflow. We will encourage branching even for small bugfixes or feature development, to make it easy for devs to pick up a different bug once they have submitted a pull request for what they are currently working on.

This is particularly important because we get devs that happily submit their first patch, and then get frustrated trying to clean up their repo when working on their second. This may also be useful when we discover that tweaks need to be done on review. Instead of doing:
1. clean up old/current work
2. grab patch from zilla or a saved file and reapply
3. do tweaks
4. generate a new patch containing the original patch + changes requested
We might do:
1. save current work on current branch
2. switch to previous branch
3. do tweaks
4. submit pull request again, with the tweaks as a separate commit
Thus the emphasis on branching in this run through.

we're trying to analyze the core features to determine whether they can work the way we need them to, so we've left github and bitbucket out of the equation (except as ways to make the code public)

( mercurial workflow using bookmarks )

( Git workflow using git branches )

Summary of what we found:

When using Mercurial bookmarks, we ran into an odd(?) issue where we lost track of where we were branching from (what would, in git, be the branch "master"). I'm assuming this is a bit of a workflow thing, and we can work around by creating the new bookmark upstream or master, so we could get back to the point in our repo before we started making any changes

Same issue, but this time from the committer side? or, since we've merged at this point, and won't need to eep track of bookmarks, perhaps less of an issue?

What am I doing when I pull then remove the bookmark? I ... managed to merge, right? That's what I did?

Commit messages are now an issue. We standardized around a commit format containing the bug id, commit message, and patch author and enforced it by having the committer supply the commit message.

Now, we'll either need to enforce a strict policy on commit messages before accepting the commit, or have the committer amend the commit messages beforehand. Other options are to make the changelog hook smarter (detect things of the form "Bug #"?), use a "changelog_bot" for all commits. We might also want to look into having the committer sign off the commit.

*Finally* this might become a moot point, depending on what's available to us from github/bitbucket that will let us put stuff into the changelog community.

need to determine what happens if you try to amend someone's commit in Mercurial by running it through MQ in order to fit guidelines above *points up*. At a guess, we'd end up with a dangling commit that would need to be stripped out of the submitting dev's repo, because the changeset hashes would no longer match

git index! oh git index. You might be a pain. The question is, are you a pain that can be hidden away?

it's much easier grokking branches, IMO, than bookmarks, because there's never any risk of forgetting where "master" is.

git lets me do a merge commit, in order make sure that the bug number is mentioned in a related commit. *Might* be a bit of a moot point if we end up doing a rebase instead of a merge

deborah

I want to spin off a new post from the log of last night's IRC developer meeting. The topic of GitHub came up in the meeting, and some concerns with that idea have been raised in the comments of the previous post.

vlion's concerns largely address the difference between mercurial and git, whereas

karelia's concerns also address that difference but touch incidentally on the hypothetical benefit of working in the more public environment of Github.

I was talking to

allen and he pointed out that there are really two different issues in play here, because we can go to a shared, public, relatively popular, FLOSS-friendly environment without ever leaving mercurial, namely, Bitbucket.

I'd actually say there are three questions:

Are there benefits to git over mercurial, and if so, are those benefits enough to outweigh the cost of switching to a new source control system?
Would we like to move our source control management to a public, shared, FLOSS-friendly environment? If so, why? Do we think it would be more friendly to our current developers, do we think it would make it easier to bring in new developers, some combination of the two, or something else?
If we want to move to a shared environment, do we feel that there is a strong reason that it should be Github? What are those reasons, if so? If we think git is worse than mercurial, but we do think there's a benefit to moving to Github, which reason should prevail?

Actually, we should probably add a fourth question, which is "would any of our needs be better served by using mercurial more in the fashion for which it was intended?"

Keep in mind when I write these questions that I use github for other projects and like it,and I have never used mercurial intensely enough to have strong feelings about it either way. Personally I fell in love with Perforce at an early date and find all other VCS systems to be it pale yet free imitations. But I do think that if we make a switch like this, these are the questions we need to answer.

denise

Well, I managed to sleep through the meeting and

mark was fixing the database comment limits problem, so the meeting started a little late. (It's a good thing we're cute?)

Here's the log, lightly redacted to remove discussion of personal and offtopic stuff (and to remove irc administrivia like joins and parts). We'll do this again in a few weeks!

( Meeting log )

Profile

Dreamwidth Open Source Development

January 2026

S	M	T	W	T	F	S
				1	2	3
4	5	6	7	8	9	10
11	12	13	14	15	16	17
18	19	20	21	22	23	24
25	26	27	28	29	30	31

Syndicate

Page Summary

Active Entries

1: Question thread #147
2: Question thread #141
3: Question thread #140
4: Question thread #139
5: Question thread #138
6: Code tour for 2023-11-22 to 2024-11-30
7: Question thread #137
8: Question thread #135
9: Current Code Contributors: November 2024
10: Patching Mood Themes

Style Credit

Style: Lettuce for Crossroads by branchandroot
Resources: P r o l o g u e

Expand Cut Tags

No cut tags

Page generated Jan. 29th, 2026 03:06 pm

Dreamwidth Development

Entries tagged with github

Reminder: We've moved over to Git

Identifying yourself when committing in Git

Important: Update to "dwu"

Release notes

Overdue Announcement: Dreamwidth, Github and you

Development documentation update project in progress

Git for Toddlers

rahaeli's first foray into github: a step-by-step travelogue

Introduction to git talk; Pro Git book

Rough outline of workflow -- aka let's talk

Workflow overview

(no subject)

Git, Mercurial, github, bitbucket

April irc dev meeting log

Profile

January 2026

Syndicate

Most Popular Tags

Page Summary

Active Entries

Style Credit

Expand Cut Tags