navit-project.org

forum for navit navigation tool
It is currently 26 Jun 2017, 02:00
View unanswered posts | View active topics


All times are UTC


Forum rules


Feel free to ask anything here related to the development process - coding, creating new features, fixing bugs and custom changes of Navit.

Note: For reporting bugs, use the bug tracker.



Post new topic Reply to topic  [ 9 posts ] 
Author Message
 Post subject: Merge: To squash or not to squash...?
PostPosted: 22 Nov 2015, 22:10 
Offline

Joined: 27 Sep 2014, 23:41
Posts: 15
This discussion came out of a merge request for a new feature that I'd developed. The merge request had a squashed commit (of some 6 individual commits) implementing the feature, and sleske asked if I could merge the individual commits instead, arguing they are easier to work with (reading them or doing bisect operations) than a single squashed commit.

On the other hand, I remember when we were ready to commit HighFive (which we developed in a separate repo as the main one was still SVN), kazer suggested that we make a single commit. Also, I have in the past filed a merge request for another project, mapsforge, and the maintainers asked that I squash my commits (about 10 of them) rather than merging the entire history.

We realize that this is a general topic that we should discuss as a community. As for the legibility/maintainability of individual commits over a squashed one, I gave an example (loosely based on my own experience) where a squashed commit is probably easier to work with.
  • Let's say I want to implement a new feature. I start by digging my way through the code and find that many of the functions I might need for my new feature are not documented, so I add a bunch of Doxygen comments. When I'm about to write the first line of actual code, I first commit the documentation back to trunk.
  • Now I create a new feature branch feature42 and start coding. As I go along, I notice more functions that need documentation (that is, I might need to rely on them but they are not documented and I do not understand them right away, so I analyze them) and add what is missing. At this point new code and documentation get hard to separate – I don't want to commit the code because it may be so incomplete that Navit may not even build, but I also need the documentation before I continue coding.
  • After writing some more code, I discover a bug in a different place which I need to fix urgently. The bug has nothing to do with my feature, so I need to switch to trunk or a new feature branch. So I either stash my current working state – or, because multiple stashes get messy to work with, I just commit them with the message "stash", knowing that I'm going to amend this commit later – and then I fix the bug, ultimately committing it back to trunk.
  • Eventually I switch back to my feature branch and continue coding up to a point at which I have a rudimentary new feature, so I commit that (amending the earlier "stash" commit – not an issue as long as that commit has not yet made it anywhere official). I put the code up for discussion and collect some feedback on it.
  • In the meantime, someone comes back to me with feedback on another branch, feature22, that I've put up for discussion a while back, and suggests some changes. I realize that these changes are going to rely on some functions for which I have worked out the documentation in feature42 but it's in a commit mixed with code changes (see three points before). So I cherry-pick that commit into my local copy of trunk, amend it by undoing the code changes and leaving only the documentation, then push it back into the upstream repo. A merge of trunk into feature22 and I can finally finish my work there.
  • Back to feature42: to be safe, I merge trunk back into feature42 – else merge hell might ensue if I make any further edits to the documentation I cherry-picked into trunk.
  • Now I get some feedback on feature42 and realize I need to throw away and rewrite a good portion of the code I wrote for that feature. Eventually I finish work on feature42, but the commit history is quite a mess, showing documentation that I have already pushed to trunk in the meantime, as well as a bunch of merge operations, and commits that (at least partially) cancel each other out. The "stash-and-amend" tactic will not work if for some reason I need to merge before I can fully amend the "stash" commit. As a result, some of the intermediate commits may not even have produced workable code, defeating bisect.

A real-world example that has suffered from the above scenario is at https://github.com/mvglasow/navit/tree/ ... f-trac1325. Feel free to clone it and view it in git gui. Github makes things look a bit tidier by arranging commits chronologically, but this just hides the mess underneath.

So the question goes out to the community: given development scenarios like the one I've outlined above, what is the best way to merge it?
  • Merge the entire commit history as it originally happened, no matter how messy?
  • Squash the commits into one, with a commit message listing the original commits, and keeping the original feature branch around for later analysis?
  • Decide individually for each case?
  • Or something completely different (e.g. rebasing)?

And if the answer is something like "it depends", what are the criteria?
  • Merge the full history when the squashed commit would have more than X lines or Y files changed?
  • Squash when the commit history has merges, especially with trunk?
  • Squash when the commit history has "broken" commits which won't build or don't work properly?
  • Squash when you have undone a lot of the changes you introduced since you created the branch?
  • Keep add/fix/refactor changes separate rather than mixing them in a single commit?
  • Keep independent features (or independent bug fixes, or independent refactor operations) in separate commits? (We currently do have a similar rule to *try* to commit per feature if that is feasible.)

Please give us your opinions and suggestions.

Edit: There are guidelines for SVN in the wiki at: http://wiki.navit-project.org/index.php/SVN_guidelines. Though some of it may have been obsoleted by changes in technology, I still feel we should still ask ourselves how to apply the spirit of these guidelines to the infrastructure we have now.


 Profile  
 
 Post subject: Re: Merge: To squash or not to squash...?
PostPosted: 01 Dec 2015, 21:45 
Offline

Joined: 23 Jun 2013, 20:15
Posts: 65
Location: Essen, Germany
Thank you for starting this discussion.

I agree that just blindly merging a messy history with lots of reverts
and half-baked commits will not help.

However, in my opinion (and experience) this is an area where git really
shines, specifically git rebase (there had to be a reason why we
switched to git :-) ).

-------------------------------

I took the example branch you gave,
https://github.com/mvglasow/navit/tree/ ... f-trac1325 ,
and tried to clean it up.

# git checkout -b android-laf-trac1325-clean remotes/mvglasow/android-laf-trac1325
# git rebase trunk

I had to fix two fairly simple conflicts, then the rebase went through.
This already creates a neat, linear history - much more readable IMHO
because the merge commits from master disappear.

Next, I note that one commit seems to revert earlier commits.
  • First: 2015-11-06 mvglasow Add:port_android:New android_menu OSD
  • And then: 2015-11-19 mvglasow Add:gui_internal:Replace android_menu osd with simple button

The next step would be to see if these commits can be squashed together
(again, using rebase -i, by first moving them together, then squashing
them).

That way, you can selectively clean up your history.

I have done this in the past, for example when I committed the changes
to switch the gtk_drawing_area graphics from GDK to Cairo (commits
d0e8a73 to 9f1d27e). I spent several hours reworking these commits
(which were the result of weeks of work), and managed to cut the number
of commits by half, and make them (I hope) quite readable.

This does take work, but I believe it is worth it. For simple cases,
just rebasing on top of trunk already helps a lot, because it gets rid
of intermediate merge commits. Then maybe some squashing of intermediate
or reverted commits, and result is quite presentable.

Of course, after rebasing one needs to check that all new intermediate
commits at least compile. For this, I have a small "smoketest" shell
script, which compiles and runs navit. I run it in a loop for each
commit, which makes sure no compilation errors slip through.

-------------------------------

To address your points in detail:


mvglasow wrote:
I create a new feature branch feature42 and start coding. As I go
along, I notice more functions that need documentation
[...] and add what is missing. At this point new code and
documentation get hard to separate – I don't want to commit the code
because it may be so incomplete that Navit may not even
build, but I also need the documentation before I continue coding.

This is where "git add -i" can help. Use add -i to only commit your new
comments. Then you can rebase on top of trunk, and push the
documentation commits to Github right away (if you want to).

Also, "the code may be so incomplete that Navit may not even build" is
not a good situation to be in. I find it helpful to always make small
changes, test them, then commit them right away. It does not matter that
you don't plan on keeping them - you can rebase/reset them away later
:-).
mvglasow wrote:
In the meantime, someone comes back to me with feedback on another
branch, feature22, that I've put up for discussion a while back, and
suggests some changes. I realize that these changes are going to rely on
some functions for which I have worked out the documentation in
feature42 but it's in a commit mixed with code changes (see three points
before). So I cherry-pick that commit into my local copy of trunk, amend
it by undoing the code changes and leaving only the documentation, then
push it back into the upstream repo. A merge of trunk into feature22 and
I can finally finish my work there.

Looks good, except that again, rebase makes for a simpler history than
merge. Of course, care must be taken with rebasing published branches,
but as long as you are the only one working on it, I find it ok.
mvglasow wrote:
Now I get some feedback on feature42 and realize I need to throw away
and rewrite a good portion of the code I wrote for that feature.
Eventually I finish work on feature42, but the commit history is quite a
mess, showing documentation that I have already pushed to trunk in the
meantime, as well as a bunch of merge operations, and commits that (at
least partially) cancel each other out. The "stash-and-amend" tactic
will not work if for some reason I need to merge before I can fully
amend the "stash" commit. As a result, some of the intermediate commits
may not even have produced workable code, defeating bisect.

This can, I feel, partly be avoided by always committing small steps
(this avoids the need for stashing, which I thingk should be used
sparingly). If the mess still happens, judicious use of rebase and
squashing can usually clean it up in my experience.

In particular, if you have a commit in your history that you
cherry-picked to trunk, then during a rebase on top of master, git will
usually see that the changes are already in master, and drop the commit
during rebase.

-------------------------------

tl;dr:

Use git rebase, rebase -i and intermediate commits, and things
should come out fine in the end :-).


 Profile  
 
 Post subject: Re: Merge: To squash or not to squash...?
PostPosted: 01 Dec 2015, 21:46 
Offline

Joined: 23 Jun 2013, 20:15
Posts: 65
Location: Essen, Germany
One more point:

If you, mvglasow (or someone else) has a particularly messy branch, I'd be glad to try fixing it up.
I'd then push it as a new branch for review, and then we can discuss the result.


 Profile  
 
 Post subject: Re: Merge: To squash or not to squash...?
PostPosted: 04 Dec 2015, 10:27 
Offline

Joined: 27 Sep 2014, 23:41
Posts: 15
OK, I'm trying this for the trac712 branch. An interactive rebase suggests me a linear history of 7 commits.

I start by picking the first one, a857267. The next one, d3c698f, fixes some annoying issues of its ancestor, which is why I would initially consider squashing the two together. On the other hand, the bug occurs only under certain circumstances, so I decide to pick it as an individual commit. However, d3c698f also introduces a good deal of experimental code, which is removed again in a later commit, 0b1d8e4, so I move the latter up in the history and squash it behind d3c698f. Since 0b1d8e4 also modifies comments introduced in 0b699db, I also need to squash that in between the two. Eventually, there's a forgotten import left over from d3c698f, which I removed in 2535b0f, so I squash the latter in at the end, too.

That leaves me with two more commits to pick – they are pretty clean single-feature commits, so I can just pick them individually. The first of them is an actual bug fix – again, the bug occurs only under certain circumstances, so I pick it as a separate commit. The last change is an API change with no implementation added, so I can keep that as a separate commit as well.

sleske wrote:
However, in my opinion (and experience) this is an area where git really
shines, specifically git rebase (there had to be a reason why we
switched to git :-) ).


Even without that, there are still plenty of other reasons ;-)

sleske wrote:
This does take work, but I believe it is worth it. For simple cases,
just rebasing on top of trunk already helps a lot, because it gets rid
of intermediate merge commits. Then maybe some squashing of intermediate
or reverted commits, and result is quite presentable.


I guess that's where we need to balance – how much is OK to commit in one go, and when should we start committing things individually? Ultimately, that's a decision to be made already during coding – when we're ready to rebase, it's too late to split commits in two. Here I'd favor updating the old SVN guidelines to our current infrastructure. "Commit per feature" is definitely a principle to keep up. It's less clear with "make sure each commit leaves the repository in a compilable state" – does that still apply to git commits? Or only to the last commit in a series when pushing multiple ones? I see you consider that to apply to each commit, and I tend to agree with that.

sleske wrote:
Of course, after rebasing one needs to check that all new intermediate
commits at least compile. For this, I have a small "smoketest" shell
script, which compiles and runs navit. I run it in a loop for each
commit, which makes sure no compilation errors slip through.


Again, a bit of work (which I could simplify by squashing :twisted: ) but I realized that it's fairly easy to set up CircleCI for your own Navit repo. The only constraint is that (iirc) when pushing multiple commits, CircleCI will run only for the latest, so we'd need to figure out how to run CircleCI on every single one of them.

That being said, maybe we should make CircleCI part of our guidelines? For example, "before pushing a commit to the main repo, make sure it has passed CircleCI"? Or maybe relax that by requiring "CircleCI or your own equivalent test"?

sleske wrote:
mvglasow wrote:
I create a new feature branch feature42 and start coding. As I go
along, I notice more functions that need documentation
[...] and add what is missing. At this point new code and
documentation get hard to separate – I don't want to commit the code
because it may be so incomplete that Navit may not even
build, but I also need the documentation before I continue coding.

This is where "git add -i" can help. Use add -i to only commit your new
comments. Then you can rebase on top of trunk, and push the
documentation commits to Github right away (if you want to).


I assume you are referring to staging and committing just a subset of the files changed, rather than everything? (Not everyone uses the command line tools – some prefer a seat on top of the porcelain, such as gitk or similar.) That approach will work if the documentation and code are in different source files, but often enough, they are in the same files, and I don't know of a easy way to split that once it's committed.

sleske wrote:
I find it helpful to always make small
changes, test them, then commit them right away. It does not matter that
you don't plan on keeping them - you can rebase/reset them away later
:-).


That works for small fixes, but for larger features, I often find myself having to do a fair amount of coding before getting to a point where Navit will build again. Of course, many features start with refactoring. With a little planning, you can do this first, commit it and run a smoke test on the refactored code (which is probably a good idea anyway), thus reducing the weight of the initial commit. Occasionally, though, you may discover that you need to do some extra refactoring after you've already started coding your feature. Then you can either mix your forgotten refactoring with the new feature, or you can try stashing, then doing the missing refactoring, committing that (possibly with a smoke test) and replaying the stash. If replaying the stash causes a conflict, though, things get fiddly again.

I would propose a new guideline here:

Refactor first. When you are developing a fix or feature that requires refactoring existing code, try to do the refactoring first, test and commit it, and only then begin with the actual implementation.

In any case, I believe most new features will still begin with a fairly huge commit.

sleske wrote:
rebase makes for a simpler history than
merge. Of course, care must be taken with rebasing published branches,
but as long as you are the only one working on it, I find it ok.


My proposals here:

Use rebase. When you've spent a lot of time working on a new feature, other changed may have happened in trunk in the meantime. Consider rebasing your changes on top of current trunk rather than merging them – this makes for a cleaner and more legible history.

Don't rewrite history. Once you've pushed to the official Navit repo, do not amend, rebase or in any other way modify the commit history, as this may break things for other people. If you need to force the push, it's a sure sign you shouldn't be pushing this. Instead, add another commit on top that makes the changes you need. Note that this goes only for changes to the official repo – feel free to do as you please in your own fork, in a branch you've never pushed to the official repo, or with commits you haven't pushed yet.

sleske wrote:
mvglasow wrote:
Eventually I finish work on feature42, but the commit history is quite a
mess, showing documentation that I have already pushed to trunk in the
meantime, as well as a bunch of merge operations, and commits that (at
least partially) cancel each other out. [...] [S]ome of the intermediate commits
may not even have produced workable code, defeating bisect.

This can, I feel, partly be avoided by always committing small steps
(this avoids the need for stashing, which I thingk should be used
sparingly). If the mess still happens, judicious use of rebase and
squashing can usually clean it up in my experience.

In particular, if you have a commit in your history that you
cherry-picked to trunk, then during a rebase on top of master, git will
usually see that the changes are already in master, and drop the commit
during rebase.


Emphasis on partly... in some cases it will work, but as I said above, the first "add" commit of a new feature tends to be a larger one which can't be meaningfully broken down. Cleaning up by means of rebase and squash will probably work, though in cases like trac712 I still end up with a fair amount of squashing.


 Profile  
 
 Post subject: Re: Merge: To squash or not to squash...?
PostPosted: 19 Dec 2015, 23:12 
Offline

Joined: 27 Sep 2014, 23:41
Posts: 15
In the meantime I have created a draft version for new Git guidelines. You can find them at http://wiki.navit-project.org/index.php/User:Mvglasow/Git_guidelines_%28draft%29. Input is welcome.

Another question: when pushing multiple commits, is there a way to run CircleCI on each of them, not just the last one?


 Profile  
 
 Post subject: Re: Merge: To squash or not to squash...?
PostPosted: 21 Dec 2015, 14:51 
Offline

Joined: 23 Jun 2013, 20:15
Posts: 65
Location: Essen, Germany
Thanks for your extensive reply.

I like how you reworked the trac712 branch - that is what I had in mind, too :-).

mvglasow wrote:
I guess that's where we need to balance – how much is OK to commit in
one go, and when should we start committing things individually?
Ultimately, that's a decision to be made already during coding – when
we're ready to rebase, it's too late to split commits in two.

Actually, git rebase can split commits in two (or three...). You start an interactive rebase (git rebase -i), then edit the commit to split it. The manpage of git rebase explains it quite nicely.
mvglasow wrote:
That being said, maybe we should make CircleCI part of our guidelines? For example, "before pushing a commit to the main repo, make sure it has passed CircleCI"? Or maybe relax that by requiring "CircleCI or your own equivalent test"?

I would propose "CircleCI or your own equivalent test". I, for one, often develop off-line, so access to CircleCI is not always guaranteed. I think for intermediate commits the rule "Navit builds and starts" is enough. The cross-platform thing could be a problem, but so far it has usually worked out well enough, so I'd just recommend to build for a second platform if practical.
mvglasow wrote:
sleske wrote:
This is where "git add -i" can help. Use add -i to only commit your new
comments.

I assume you are referring to staging and committing just a subset of the files changed, rather than everything? (Not everyone uses the command line tools – some prefer a seat on top of the porcelain, such as gitk or similar.)

Yes - I always use the command line. I realize not everyone does, though
:-).
mvglasow wrote:
That approach will work if the documentation and code
are in different source files, but often enough, they are in the same
files, and I don't know of a easy way to split that once it's committed.

The nice thing about add -i is that you can stage individual hunks of
changes, even if they are in the same file. You can even manually edit
what you want to be staged.
mvglasow wrote:
I would propose a new guideline here: Refactor first.

Yes, I like that. May not always work in practice, but then you can dis-entangle the commits later (see above :-) ). And sometimes new feature just need a big commit, that's okay, too.

I very much like the Git Guidelines you formulated; thanks for the work.
If you don't mind, I'll just be bold and edit the Programming guidelines in the Wiki to make them our new guidelines.

Then everyone can chime in with further ideas.


 Profile  
 
 Post subject: Re: Merge: To squash or not to squash...?
PostPosted: 21 Dec 2015, 22:47 
Offline

Joined: 27 Sep 2013, 21:10
Posts: 42
I really like the fact that Navit's community is embracing better collaboration workflows. Thanks a lot guys.

I don't have much to add to the discussion, excepted this :
- by all means, feel free to edit the wiki. Your draft is really good, Michael and we should leverage more and more git
- we currently merge directly from trunk to master when the CI tests pass, but I wonder if some other folks would be interested in doing more code reviews via the pull requests. What is your take on this?


 Profile  
 
 Post subject: Re: Merge: To squash or not to squash...?
PostPosted: 22 Dec 2015, 13:09 
Offline

Joined: 27 Sep 2014, 23:41
Posts: 15
sleske wrote:
Actually, git rebase can split commits in two (or three...). You start an interactive rebase (git rebase -i), then edit the commit to split it. The manpage of git rebase explains it quite nicely.

Yes, I came across that, too. Taking a few files out of one commit and putting them into another is still relatively easy. When you have just one file and you want to take some of the changes to that file out of the commit and put them into a separate one, things get more difficult. It still is somewhat doable when the changes are independent of each other, but if they are somewhat intermingled, pulling them apart after the fact gets messy.
sleske wrote:
mvglasow wrote:
That being said, maybe we should make CircleCI part of our guidelines? For example, "before pushing a commit to the main repo, make sure it has passed CircleCI"? Or maybe relax that by requiring "CircleCI or your own equivalent test"?

I would propose "CircleCI or your own equivalent test". I, for one, often develop off-line, so access to CircleCI is not always guaranteed. I think for intermediate commits the rule "Navit builds and starts" is enough. The cross-platform thing could be a problem, but so far it has usually worked out well enough, so I'd just recommend to build for a second platform if practical.

I'm fine with that. Developing offline is indeed an argument that I hadn't considered.
sleske wrote:
The nice thing about add -i is that you can stage individual hunks of
changes, even if they are in the same file. You can even manually edit
what you want to be staged.

You mean stage, make more modifications, test, and if the tests are successful, stage that, too? I'm aware of that, but as far as I know I won't be able to pull these hunks part again once they're committed – or is there a git feature I haven't discovered yet?
sleske wrote:
mvglasow wrote:
I would propose a new guideline here: Refactor first.

Yes, I like that. May not always work in practice, but then you can dis-entangle the commits later (see above :-) ). And sometimes new feature just need a big commit, that's okay, too.

This eventually ended up in http://wiki.navit-project.org/index.php/User:Mvglasow/Git_guidelines_%28draft%29#Commit_per_feature. We might want to point out that these are guidelines, not hard-and-fast rules, and devs should use their own judgement. For that reason it is also important to answer the question: what is the purpose of this guideline?
sleske wrote:
I very much like the Git Guidelines you formulated; thanks for the work.
If you don't mind, I'll just be bold and edit the Programming guidelines in the Wiki to make them our new guidelines.

Then everyone can chime in with further ideas.

Feel free to use my work – that's what the wiki is for.
KaZeR wrote:
we currently merge directly from trunk to master when the CI tests pass, but I wonder if some other folks would be interested in doing more code reviews via the pull requests. What is your take on this?

If we are going to do code reviews, I'd say they should happen before merging into trunk. Therefore, merging trunk into master automatically upon successful completion of the CI tests is OK and I wouldn't change that.

The way I currently do it:
  • Trivial changes (mostly Doxygen) go straight into trunk via a commit.
  • Other minor changes (refactoring, fixing obvious bugs) I develop in a private branch and, after brief testing, merge it into trunk.
  • For bigger changes I create a private branch and then file a merge request, which I leave open for some time so that others can comment on it. Usually there's a ticket that goes with it, in which case I link the pull request from the ticket. (If the changes have been previously discussed on some other channel, it makes sense to link the merge request from there, too.) My last two merge requests I also announced on IRC. If nobody objects within a certain amount of time, I merge my changes. (hint hint: currently got two merge requests in the queue...)

We're already asking devs to discuss any changes to a 'core' component. I'd use that as the starting point for anything related to code reviews. In my draft I've elaborated a bit on the term 'core': anything exported in a header file as well as configuration handling. We might want to elaborate on the 'how'. For example, we could ask people to file a merge request, maybe announce it (where?) and allow for some feedback. If they get green light, or if they don't get any negative feedback within a certain period of time, either the dev or someone else with commit rights can merge it. We might want to figure out who's in a position to authorize such merges: is it enough to have just a second person review it? Or does it take a particular level of experience? A certain amount of past contributions? Commit rights? Project lead?

The folks over at CyanogenMod use a dedicated system (Gerrit) for code reviews – though I have no practical experience with that. Maybe someone else has experience with that and can give us some more insight? Would this help us, or would it introduce too much overhead?

There's another point we might want to provide an answer to: branches in the official repository. Do we want people to create new branches on the official repo as they see fit, or do we want them to fork the repo and create the branches in their own forks? Suggestion: as long as there's only a single person working on it, keep it in a private repo. Bigger changes on which multiple devs co-operate over a longer period of time (HighFive comes to mind) might justify a branch on the official repo.


 Profile  
 
 Post subject: Re: Merge: To squash or not to squash...?
PostPosted: 22 Dec 2015, 23:29 
Offline

Joined: 23 Jun 2013, 20:15
Posts: 65
Location: Essen, Germany
mvglasow wrote:
You mean stage, make more modifications, test, and if the tests are successful, stage that, too? I'm aware of that, but as far as I know I won't be able to pull these hunks part again once they're committed – or is there a git feature I haven't discovered yet?

Well, after each staging, you can commit if you want to - that gives you separate commits. If you want to pull the commits apart after the fact, that is possible with rebase -i , by editing the commit.

mvglasow wrote:
We're already asking devs to discuss any changes to a 'core' component. I'd use that as the starting point for anything related to code reviews. In my draft I've elaborated a bit on the term 'core': anything exported in a header file as well as configuration handling. We might want to elaborate on the 'how'.

Yes, using pull requests for code review seems like a good idea. I admit so far I've just commited my work to trunk once it was ready, but that could change :-).

As to "who reviews": I'd keep it as simple as possible, and just let anyone with commit rights merge a pull request, as long as a few days or a week passed without objections. FInally, if bad code gets merged from time to time that's no big deal, we can always revert. Personally, I favor "move fast and break things" - within reason, of course.


mvglasow wrote:
There's another point we might want to provide an answer to: branches in the official repository. Do we want people to create new branches on the official repo as they see fit, or do we want them to fork the repo and create the branches in their own forks? Suggestion: as long as there's only a single person working on it, keep it in a private repo. Bigger changes on which multiple devs co-operate over a longer period of time (HighFive comes to mind) might justify a branch on the official repo.

Again, I'd keep it liberal and simple, and leave the decision up to each developer. Having the branch in the main repo makes it more visible (and does not really hurt anyone); having it in a private repo may feel more comfortable for code that is "not ready", plus it's the only option for people without commit access. Again, we can always clean up branches if we feel it's getting out of hand.

So, in short:
  • Move fast, break things...
  • ...but avoid causing too much trouble for others
  • Have fun!


 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 9 posts ] 

All times are UTC


Who is online

Users browsing this forum: Google [Bot] and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Silver Orange 2.0.6 for IPB Designed by Skins and Hosting
Converted for phpBB3, based on Royal Blue template by BigB © 2007 2008 AEON KINGS