-
I honestly don't know what to suggest for how you want to use Github. I haven't published anything on there, except for some patches to SimpleDesk and comments on a couple of things.
Re PM popup, what I planned to do was open a popup with a special template of your messages, but I guess if we use the notification system it could be better served by that?
-
I honestly don't know what to suggest for how you want to use Github.
As for minor components, this is where I'm unsure where to go: either an organization repo, or my own repo. I guess I'll make a decision when time comes...
I'm not even excited about github. But I'm considering that since most people who do open source dev are on github, it's more likely we'll draw attention from external devs if we're on it rather than bitbucket (mercurial...) or others.
I simply just feel silly with all the options git has. I'm concerned that I might actually work much slower than usual from the moment I switch to git, because it'll be annoying for me to commit anything...
If I could only find a good reason not to use github...I haven't published anything on there, except for some patches to SimpleDesk and comments on a couple of things.
Re PM popup, what I planned to do was open a popup with a special template of your messages, but I guess if we use the notification system it could be better served by that?
Actually, I didn't even remember there was a popup system for that. I always disable it...
Oh, speaking of popups, please have a look at the current version. I added a background dimming for popups. This is usually something I detest (it was a feature in Highslide, and I never even gave the option to enable it...), but somehow it grew on me when I tried to implement it in reqWin 'just for fun'. It's currently enabled with an asModal boolean, so it's disabled by default, but I enabled it by default on wedge.org so that you can have a look and tell me what you think.
The original idea was that we could turn some (if not all) alert calls into modal popups and the background dimming would be a visual clue that it requires an action and clicking elsewhere won't just close the popup.
What do you think...?
Plus, the 'Close the window' link is the perfect place to show buttons ;)
Posted: July 6th, 2012, 07:32 PM
Oh, and the background dimming also gives a hint that your click 'did' something when we're loading the contents through Ajax... On my dev platform it's immediate, but here it can take a couple of seconds, so it's nice to have some feedback.
-
Oh, and the background dimming also gives a hint that your click 'did' something when we're loading the contents through Ajax... On my dev platform it's immediate, but here it can take a couple of seconds, so it's nice to have some feedback.
Actually, I didn't even remember there was a popup system for that. I always disable it...
If I could only find a good reason not to use github...
I'm not even excited about github. But I'm considering that since most people who do open source dev are on github, it's more likely we'll draw attention from external devs if we're on it rather than bitbucket (mercurial...) or others.
As for minor components, this is where I'm unsure where to go: either an organization repo, or my own repo. I guess I'll make a decision when time comes...
-
Yep! Thus, I'm unsure whether to keep it to the future modal mode or just use it always...
In the case of a help popup, it's probably best to have the best possible visibility for anything underneath it. OTOH I made the dimming relatively subtle (20% IIRC), so it's not that big a deal.
I played a lot with css3 transitions to make it work, and then gave up and did it in jQuery with a simple fadeIn(), ah ah... Silly me. It's similar in performance, maybe a tad jerkier in Safari. Who cares.The PM notification is one of the more sucky things in SMF, it's just a bare JS alert().
And because alerts came up every time my tabs reloaded, if I left my browser and relaunched it later, it would have plenty of tabs that needed a button to be clicked to get control back... Meh!It uses silly non-linear non-numbered revisions. That enough for you? :niark:
Why is the interface so incredibly hard to decipher? It has too much information, and too simple a color scheme to spot the right bits -- it's basically gray on grey... Or gray on grey, depends on your taste.That's generally true but honestly I'm not bothered myself about whether it's on Github or not. I find it tends to get in my way when trying to do anything.
Or just use SVN... :P But I'm sure that at the very least, hg would be more realistic to entice users into participating. I don't know.For minor components you probably would be better served with your own repo, e.g. the selectbox.
-
I can run private Git repos on RepositoryHosting too so that's not a big deal, just that Github is the go-to place. Except that the UI is entirely confusing and the whole thing makes me not want to use it.
-
So we agree on everything here.
Maybe some of our consultants will help. Heck John I noticed you were very active this week on SMF 2.1. Considering you have the Wedge source I'd love to know how you manage to come back to a codebase that is, with all due respect, neatly behind in many ways... :^^;:
-
I can run private Git repos on RepositoryHosting too so that's not a big deal, just that Github is the go-to place. Except that the UI is entirely confusing and the whole thing makes me not want to use it.
Nawe forked joshuaclayton/blueprint-css 15 hours ago
Forked repository is at Nawe/blueprint-css
So... I just went in, deleted the repo.
Now the glorious notification message is STILL on my page. There is no way to cancel it.
Thank you github for making me look like a git...... -_-
-
Did you need another reason not to use Github?
-
I just want to ensure a successful future to Wedge. That really is the only reason to consider github...
-
My personal preference is actually Google Code, after having tried both solutions. It's very easy to understand for newbies, has SVN access and is fairly fully featured for more savvy devs.
-
But GC doesn't have the one thing I like in git: committing to your own repo (either local or remote) and then automatically submitting a patch for maintainers to review.
Basically -- if SVN had that capability, I'd stay with it for a wide-scale development. I don't know if hg has it though... I suppose it does?
-
I believe hg might have that, I'm not so sure about exactly what it can or can't do.
-
Not trying to be biased but Hg has nothing over Git, AFAIK it can do pull requests like the way git does but it is not better and most likely worse. Plus in all honesty github is perhaps the best repository hosting option out there ATM. Google code hardly has anything like fork support or pull request (Google itself doesn't use it for Android), source forge is old news, bit bucket/repository hosting have much less features than github (AFAIK) plus a much smaller user base.
-
Not trying to be biased but Hg has nothing over Git,
AFAIK it can do pull requests like the way git does but it is not better and most likely worse.
I would even prefer git+bitbucket (or git+gc) at this point. I just don't like github as a website... What do you know, I'm a design and UX lover. I just don't think github is very 'practical' when it comes to being a collaboration tool AND a social network.
Do you know how to remove a notification from my own timeline? (you know, the one that says Nawe has forked blueprint-css, when I never did in the first place, and removed said fork anyway...)
If you can't, then it's not a social network, it's just a fucked up mess of bugs.
bitbucket has a more readable UI, has private repos (so it doesn't smell like "we'll shove openness down your throat, whether you like it or not!!!!!!!!!1"), and generally I tend to say "fuck" to things that people tell me to join ONLY because they're popular. Hey, I've got news for you: SMF doesn't get contributions from anyone else than the usual suspects. I'm sure that if SMF were to be hosted on GC or BB, it'd get the same usual suspects to register over there, and contribute just the same.
Now, GC and BB both support git so it's not even an issue with what you chose to go with...
There are so many reasons (both good and bad, both rooted or unrealistic) for which I don't like github, it'd just feel like a disaster to go with it in the end. Give me a new readable design for it, give me sequential commit numbers (we're talking about something that's doable(http://blogs.codewise.org/wrf/article/sequential_revision_numbers_in_git)), give me tools to contact people (PM or email or whatever), give me tools to control my own page (like deleting entries or whatever), give me a good tutorial to make the transition from svn less painful, *AND* then I'll consider github.
Because, REALLY, "3 million repos" is the fucking worst reason to join it. Just like "It has plenty of members" was the worst possible reason to join Facebook. How many active repos/members in both of these, eh? Certainly a lot, but I'll take Google+ and Google Code anytime as better replacements, because they know something about UX design. And I don't even LIKE Google!Plus in all honesty github is perhaps the best repository hosting option out there ATM. Google code hardly has anything like fork support or pull request
Are they self-taught or what? Well, maybe someone should give them a course or something... They've improved a bit since last year, but they still suck hard. For instance, when will they stop using stupid animations for transitions between pages? It's certainly a lot of fun to them, but as a professional user I don't want animations, I want functionality. And these animations get in the way.(Google itself doesn't use it for Android),
source forge is old news,
bit bucket/repository hosting have much less features than github (AFAIK) plus a much smaller user base.
I don't know why github is popular. Maybe it's the animations that won most of the userbase. Maybe they spent a lot of money trying to get everyone in the bay area to use it or something, and then it naturally spread from there. Maybe the guys who run it are absolutely charming. Or maybe it's just the better tool and I'm too old for this shit. I don't know.
What I do know, though, is that I need some pretty good reason to use github, after all the mess I've been witnessing, and "it's popular" is SO NOT a good reason for me to do that... Because popularity is the first thing you lose when you start making mistakes, and github might very well end up being replaced with a superior system. One day. And then everyone will laugh at github users for still being on that piece of crap etc etc...
Been there done that ;)
-
I don't like git. I just can't wrap my head around it.
-
Hey, look at Wordpress. They seem to get by with SVN. Neither do they use SF or GC or whatever. Perhaps, staying with how you roll right now isn't such a bad idea after all.
-
GC is basically SVN with a few nice additions though.
-
Yep I know
-
http://www.theregister.co.uk/2012/07/10/github_100m_investment/
-
Hey, look at Wordpress. They seem to get by with SVN. Neither do they use SF or GC or whatever. Perhaps, staying with how you roll right now isn't such a bad idea after all.
I'm sure one can quote dozens of major projects that are still using SVN (Wedge being among them!), but more than SVN vs Git, it's more of a question about methodology really. Do we want other developers to join in and share their code? Yes we do. Do we want to keep the whole thing secure and not give everyone commit access? Yes. Because of this, it's more realistic to rely on Git (or Mercurial) than SVN. Thus, I'm spending a lot of time trying to get used to the idea that I'll have to use that annoying pseudo-social network...
Heck, if the Netscape guy gave them $100M, I'm sure they can finally get to work on *actually* integrating ways to communicate with each other and modify own's homepage..?!
-
Here's the thing, though: WP doesn't just make use of SVN in its own repo, it deploys an SVN repo for each plugin author, and pushing versions of plugins also works from that repo (it's the only way to publish plugins on the master site)
I don't recall them being too hot about accepting patches from outside, however their bug tracker does regularly have patches posted, and as such everything is more integrated.Do we want other developers to join in and share their code? Yes we do.
Thus, I'm spending a lot of time trying to get used to the idea that I'll have to use that annoying pseudo-social network...
-
I'm going to check all code as I do these days. i.e. carefully but not being too anal about it.
What would you prefer to do yourself, Pete, regarding:
- When to change our system (if ever)?
- What system to use? (SVN, Git, Mercurial, Bazaar...?)
- Where to host it? (Repohosting, Bitbucket, Google Code, Github...)
Right now I'd say Bitbucket + private Mercurial (and public later), but I have a feeling that we're going to end up going to Github, like most people... (It's nearly funny, watching all of the other sites pointing people to their most active repos, and when you click a repo whose name you've heard of, you end up with this final commit message: "Moved project to github"... Lol. It happened several times. Last one I remember is XBMC.)
-
Me, I prefer to go with what works.
I'm comfortable with SVN, both Git and Hg are new to me. I don't like Bazaar.
I'm not too fussy about hosting provided that there's no chance of being held hostage - I trust free repo hosting as much as I trust free web hosting, which is very little. I pay a reasonable sum to RH per month for what I get, but I could just as easily set up my own repo (done that in the past) and I'm comfortable with the options provided by RH, I wouldn't want to give any of the flexibility up that I currently have with RH.
-
What does RH offer that others don't...?
So, going with what works = SVN + RH, private right now, public repo later?
Meh. I don't know. I'd rather use RH to try for a dual SVN/Git repo where we do some Git testing or something.
Or perhaps we could use Github with a SVN client... (It sounds silly but they do support that.. https://github.com/blog/966-improved-subversion-client-support and https://github.com/blog/1178-collaborating-on-github-with-subversion)
-
Bazaar is probably the worst distributed visioning system, it's has the worst performance, I would say Git mainly because it's feature rich (file staging is a big plus for me, easily allows me to keep one commit per chance) and is very efficient in most case when compared to SVN.
I use git-cola interface, very easy to work with and is cross platform.
-
What does RH offer that others don't...?
There is also a vast array of facilities we actually don't use at RH but that we could should we decide we want to - we get a free wiki, free bug tracking etc.
I can certainly set up a Git repo in there.
-
It can be open source too
Host Open Source Projects
Allow the general public to view your repository, add new tickets, or see your wiki. By default all projects are private.
So Github is not necessary.
-
Unlike Github where everyone can push things to a project and that puts an onus on the project leaders to review and accept patches.
-
That seems to have been about pull requests.
-
It is referring to pull requests - from the perspective of contributors, they're pushing to the project and expecting the project to take it onboard.
Nothing says 'get stuffed' than not accepting any inward contributions, but if there's no obvious way to do that, that's actually better than appearing to solicit such things without accepting them.
-
Well, why wouldn't we be soliciting their help...?
-
Not quite my point.
If you open the doors and appear to accept patches, there is then a pressure on you to accept everything and anything that comes in. There is not the same pressure when the repository is not open.
-
Then SMF 2.1 has an edge over us..?
-
Yes and no. Being open means you open the doors to a potential flood of submissions. You then have the joy of wading through the submissions in the hopes of finding good things. If you get a collection of great coder submissions, great, but the odds are not in favour of that being the case, given what has been approved as mods in the past.
Seriously, being open is not the magical panacea it's supposed to be. Being open means you get more input. It doesn't mean it's any *better* input. If anything I'd almost say that it will eventually dilute things because there will be pressure to accept patches that aren't up to snuff.
Consider the past of SMF. It was hard enough getting to be a beta tester, let alone a dev badge. Consider the people who earned that badge. Consider also the people who've submitted patches in the past to SMF, and how few of those were historically accepted. It's not merely a lack of time that caused all those things to be the case, it was the overall low quality of submissions.
In fact, going back it was pretty much only the people who were team members who ever got patches approved, and even then you're pretty much talking about the Cust. team people who ever got anything into the core who weren't the dev team. I haven't been through 2.1 but I suspect the people whose patches have been approved are the people who didn't make it into the Cust. team primarily out of politics or not wanting to be involved, but the same people nonetheless who would have been eligible anyway.
In short: I don't think it's really as open as might want to be believed and while I want to believe the best, I'm not sure it's the right path for them to take.
To be brutally honest, I want to be wrong about this. But I want to see SMF take their main repo public and see what happens, I see no reason to think our experience will be substantially different. Everything I'm predicting is almost certain to come true sometime after SMF makes the 2.1 repo public, and I do not want us to fall into the same trap.
-
Seriously, being open is not the magical panacea it's supposed to be. Being open means you get more input. It doesn't mean it's any *better* input. If anything I'd almost say that it will eventually dilute things because there will be pressure to accept patches that aren't up to snuff.
-
Yes and no. Being open means you open the doors to a potential flood of submissions. You then have the joy of wading through the submissions in the hopes of finding good things. If you get a collection of great coder submissions, great, but the odds are not in favour of that being the case, given what has been approved as mods in the past.
Seriously, being open is not the magical panacea it's supposed to be. Being open means you get more input. It doesn't mean it's any *better* input. If anything I'd almost say that it will eventually dilute things because there will be pressure to accept patches that aren't up to snuff.
If it's not up to my standard, I'll just comment on the source code and tell people what's wrong with it. (It's one of the advantages of github -- you can comment on a specific line.)
Then I'll wait for them to adapt their code because later they'll remember to do it without my input.
Well, it's pretty much what John did after I commented his commits to Wedge back in the day ;)Consider the past of SMF. It was hard enough getting to be a beta tester, let alone a dev badge.
Consider the people who earned that badge. Consider also the people who've submitted patches in the past to SMF, and how few of those were historically accepted. It's not merely a lack of time that caused all those things to be the case, it was the overall low quality of submissions.
In the SMF 2.1 repo, though, there's quite some activity (on par with Wedge I'd say.)
In the end, though, it's mostly about two developers, emanuele and spuds, doing most of the commits.
https://github.com/SimpleMachines/SMF2.1/graphs/contributors
Aside from them, *only* team members (or ex-members) can be found: norv, Thantos, Nas, John, nend (beta tester IIRC -- I suspect he's sicommnend at github), Trekkie, DrDeejay, IchBin.
So, even though the development process is now public, it's pretty much as if SMF had given commit access to all of their teamies. No need to go public indeed. I guess that going public and hoping for developers is either good for limited projects (which are more likely to receive external improvements, maybe the JS and PHP snippets I wrote could be part of that), or for huge projects that a lot of people are into, such as a programming language or OS or whatever.
I could suggest that we open a private git or mercurial or svn repo somewhere with a bug tracker (with a good one I mean... I don't know if RH's is any good?), and then we give commit access to anyone who requests it (basically people in our Friends and Consultants groups).
I know that a couple of years ago I was more protective of the codebase and will probably keep annoying the hell out of people like I did with John (and I'm still sorry about that), but I think it's better to have as many people as possible on the project, than basically just me these last few months. I'm sure there are areas that others would like to modify.
We could use a DCO like SMF 2.1 currently does, if no one wants to write a contributor agreement. The copyright would still be shared between Pete and I. No secrets about that, obviously.In short: I don't think it's really as open as might want to be believed
To be brutally honest, I want to be wrong about this. But I want to see SMF take their main repo public and see what happens, I see no reason to think our experience will be substantially different. Everything I'm predicting is almost certain to come true sometime after SMF makes the 2.1 repo public, and I do not want us to fall into the same trap.
Don't see why it would be an active repo if it's not the official one..?
-
And I guess you're wary of going back to a similar system...
So, even though the development process is now public, it's pretty much as if SMF had given commit access to all of their teamies. No need to go public indeed.
I could suggest that we open a private git or mercurial or svn repo somewhere with a bug tracker (with a good one I mean... I don't know if RH's is any good?), and then we give commit access to anyone who requests it (basically people in our Friends and Consultants groups).
I'm not sure about this anymore..? I remember SMF 2.1 was at one point hidden away at Spuds' repo, but now it's at SimpleMachines..?
-
The problem with giving direct access to commit is that you cannot review their work before including, it, in some ways, can be worse than a pull request. I know declining a pull request can be a slap in the face, but a lot of projects have pulled it off fairly fine. There really are not many good ways of rejecting a fully coded submission. Or we can go even more heavy duty by using something like gerrit.
-
I use git-cola interface, very easy to work with and is cross platform.
I'm not sure it's that 'easy' to work with if it requires installing msysgit, *then* Python, then PyQt... Meh! :^^;:
Posted: July 17th, 2012, 06:04 PM
The problem with giving direct access to commit is that you cannot review their work before including, it,
in some ways, can be worse than a pull request.
Posted: July 17th, 2012, 06:08 PM
I'm wary of dragging us into that particular quagmire. I'm hoping that there will be a higher quality of submission of plugins.
Wow, they actually made the repo public, as opposed to the playpen repo. But yes, it is as I suspected.
RH's bug tracker is pretty good, IMO, you should be able to try it out?
Yup it's now the main public repo, didn't realise it had actually been moved (see, I told you I don't check their repo!)
Oh, and BTW, I'm now 'officially' post-unbanned from simplemachines.org. It took some time because the person who originally unbanned me didn't remove the custom additional group I was in that prevented me from modifying my profile (ahem) and posting on most boards as well.
-
Git's workflow is quite different to that of SVN, but Git and Hg have very similar workflows (as someone that uses/has used all three). TBH, once you get your head into the two-step commit/pull way of working, it's not a hassle. Personally, I much prefer Git, but that's cause I've mostly migrated all my development work over to my Mac and that has Tower - The most powerful Git client for Mac(http://www.git-tower.com) (best damn Git client it's been my pleasure to use; I just wish someone would do something this good for PC).
Between GH and BB, I prefer the BB website, but I'm not using the wiki or ticketing systems on either of those two sites. Tower has inbuilt GH integration (you can create a GH repo from within Tower, and some other stuff too, but as I say, I don't really use it so the integration is overkill for me and my workflows)
-
Has git-cola got any advantage over the competition...?
I'm not sure it's that 'easy' to work with if it requires installing msysgit, *then* Python, then PyQt... Meh! :^^;:
-
@CJ> You're saying it's easier to use. I'm saying it's harder to install. I'm just asking, what tells me it's going to be 'easy' to use once I install it? SmartGit isn't that hard to use, heck even TortoiseGit is okay after the initial learning curve...
Git's workflow is quite different to that of SVN, but Git and Hg have very similar workflows (as someone that uses/has used all three). TBH, once you get your head into the two-step commit/pull way of working, it's not a hassle. Personally, I much prefer Git, but that's cause I've mostly migrated all my development work over to my Mac and that has Tower - The most powerful Git client for Mac(http://www.git-tower.com) (best damn Git client it's been my pleasure to use; I just wish someone would do something this good for PC).
Hey I laughed at this quote of his:
"Btw, (...), you're a quality example of why I detest the github
interface. For some reason, github has attracted people who have zero
taste, don't care about commit logs, and can't be bothered."
Source:
https://github.com/torvalds/linux/pull/17#issuecomment-5659970
The thread is a funny read... Although I stopped early on.Between GH and BB, I prefer the BB website, but I'm not using the wiki or ticketing systems on either of those two sites. Tower has inbuilt GH integration (you can create a GH repo from within Tower, and some other stuff too, but as I say, I don't really use it so the integration is overkill for me and my workflows)
Anyway, I'm still not entirely convinced. I think that for now, repohosting or bitbucket will be fine...
-
@CJ> You're saying it's easier to use. I'm saying it's harder to install. I'm just asking, what tells me it's going to be 'easy' to use once I install it? SmartGit isn't that hard to use, heck even TortoiseGit is okay after the initial learning curve...
-
Holy shit Linus is badass.
I like him more and more.
-
Anyway, I'm still not entirely convinced. I think that for now, repohosting or bitbucket will be fine...
Getting a client you like will always be the hardest thing (Tortoise* if you're Windows only is probably the best of them. It's lacking some features in it's UI, but you've always got the command line tool to fall back to), as a repo host is a repo host for the most part, especially if you're not using them for all their webness bells and whistles (like Linus does with GH).
-
@Norodo: That's the level of bad-ass I seek to attain, I'm still learning.
-
@Norodo: That's the level of bad-ass I seek to attain, I'm still learning.
-
SmartGit is written in Java, as long as you not using a mixed OS environment (Virtual Machine) as I am, you should be fine, power to you, for me Java just screws round with clipboard synchronisation that Virtual Machine uses,
TortoiseGit is pretty much Windows only, I choose to use something cross platform and not written in Java. Use whatever you're comfortable with. ;)
Posted: July 23rd, 2012, 03:32 PM
You can always use BB for a Git repo ;)
-
Right now? I'm 100x more comfortable with TortoiseSVN... :^^;:
Posted: July 23rd, 2012, 03:32 PM
Yeah, of course, but if I can choose between hg and git, I'll take hg anytime because of the comparatively better user friendliness...
*BUT*
There's not going to be pressure from me to steer you guys one way or the other, I'm comfortable in SVN, Hg and Git (although Git is my favourite of the three now I know how to work with it) :eheh:
-
People find Git to be more user friendly than Hg :P, I find them to be same.
-
I just now found out that you can stage a chunk or even a single line of a file in Git :D That is so awesome!
-
Yes, that's the only feature I'd actually appreciate in Git itself... ;)
-
People find Git to be more user friendly than Hg :P, I find them to be same.
Yes, that's the only feature I'd actually appreciate in Git itself... ;)
-
I just now found out that you can stage a chunk or even a single line of a file in Git :D That is so awesome!
In my diff file -> open file (from the side I want to modify)
Back to the diff file -> on each line I don't want to commit, I just click the corresponding button to revert the line.
Now save.
Back to the opened file - in Notepad2 I get a notice "File modified, do you want to save?". I say no... Then I just press Space then Backspace, to remind me that it's a modified file.
Commit.
Back to opened filed. Save. Done...
Really, it's how I do it. Otherwise, I'd never been committing anything...
-
/mehas never done the staging stuff, if he's not ready to commit it as-is, he'll either revert and just deal with it later or do madness with copying files around.
-
Yesterday I took a backup of our svn repo, and converted it to git...
It takes quite a while to do, lol. Thankfully I have a fast machine but it still easily took an hour overall.
so it's "doable", perhaps I'll upload it to bitbucket (as a private repo obviously), to do some further tests.
Posted: July 27th, 2012, 07:09 AM
Well, so I did my tests, internally so far (haven't been using bb for this), and I really have to say... I can't live without rev numbers. That's all I can say for now. Maybe someone can give me therapy or something, but I was doing a blame earlier today, and everything I did based on this, would have been much harder if I hadn't had revision numbers. Revision dates are less 'blatant' to me, I can't sort them quickly in my heard, if I read 'October 2011' it'll take a tenth of a second to determine if it's earlier or later than 'May 2012', while between rev 1212 and rev 1574 it's immediate. Things like that...
I could try and force a 'tag' on each and every commit so far, can probably do a script for that, but I don't know if it's workable...
-
It'd be workable but I suspect not that practical because future commits may or may not end up having that.
Git promotes a style of forking and merging complete features, not gradual iteration.
-
Yeah, and as such it promotes strong conflicts... :P
Okay, a question for git specialists...
I tried changing my e-mail address (which is freely viewable because of the git commits, duh!) into nao@wedge (a dummy one), and followed the instructions here using a github-sponsored gist:
http://stackoverflow.com/questions/750172/how-do-i-change-the-author-of-a-commit-in-git
As a result, here's the log I have now in my local and remote repos... Great.
Now, how do I:
- Get rid of the extra... what is it, branch? (Which still shows my e-mail address!!)
- Clean this up on my github repo so that it doesn't show these rewrites as new commits...?!
PS: as you can see, I tried adding numeric tags to my commits as an attempt to make it 'look like svn'... :-/
-
Just to make it clear...
Here's my personal decision on our workflow. Pete is free to give his opinion if it's any different of course :) I'm just assuming we're in agreement on this. Also, if anyone finds a good compromise on ease of use that doesn't require SVN... I'm all ears. But in the end I think SmartGit is just annoying and TortoiseGit is confusing the hell out of me, and command-line is... well, I asked for ease of use, not for ways to become a cyb3rzw4rL0rd.
- Present and Near feature: Repositoryhosting + SVN (private)
- Later future: Repositoryhosting or Google Code + SVN (public)
- Ways to allow for external contributions to code: use TortoiseSVN -> Create Patch -> post the .diff/.patch file somewhere. It's not particularly 'harder' than, say, allowing github forking and, instead of doing their own git fetch/merge crap, getting the fork on my hard drive, syncing it and then diffing between repos locally. Plus I can just read the patch file and modify it inline before I do my magic...
-
Yesterday I created an account on GH... I needed to submit a pull request. It's rather expensive though to have a paid account (private repos)!
-
Yesterday I created an account on GH... I needed to submit a pull request. It's rather expensive though to have a paid account (private repos)!
-
The question is whether you need private repos or not. If you don't, and most people don't, it's not a problem.
But this is why I use RepositoryHosting ;)
-
I need a private repo because I want to try to have a script on my VPS that automatically pulls updated files from gh for a static website I have.
@0x: thanks!! :) it worked!!
-
Eh, can do that quite happily with RH ;)
-
I'm new to git in general, so for me it's quite the same... Luckily I got the GH edu account so it should be ok. RH seems paid too though.
-
I never said it wasn't paid... but it is cheaper than Github. I have several more than 5 private repos for my $6 a month.
-
Meh, been paying 12$/mo since forever and love it :P
-
Uhm, this is weird. I can't find a button to revert a commit on GH website. Is only possible via command line?
-
Uhm, this is weird. I can't find a button to revert a commit on GH website. Is only possible via command line?
-
I'm becoming mad.
I forked a repo. Created a new branch from website (named "anythingslider").
Then:
cd /home/multiformeingegno
git clone git@github.com:multiformeingegno/cdnjs.git
Enter passphrase for key '/root/.ssh/id_rsa': (done)
I do the changes I need to do on /home/multiformeingegno/cdnjs
Then I'd like to push my changes to anythingslider (not to master).
cd /home/multiformeingegno/cdnjs
git add ajax/libs/anythingslider/*
git commit -m "Updated AnythingSlider to reflect original dir structure and added missing default.png"
git push origin anythingslider
Enter passphrase for key '/root/.ssh/id_rsa': (done)
But I get a:
error: src refspec anythingslider does not match any.
error: failed to push some refs to 'git@github.com:multiformeingegno/cdnjs.git'
<_<
-
Welcome to the madness that is called git... :lol:
-
If you do a git remote show origin, is anythingslider tracked?
-
Here you are @Dragooon
* remote origin
Fetch URL: git@github.com:multiformeingegno/cdnjs.git
Push URL: git@github.com:multiformeingegno/cdnjs.git
HEAD branch (remote HEAD is ambiguous, may be one of the following):
anythingslider
master
Remote branches:
anythingslider tracked
master tracked
Local branch configured for 'git pull':
master merges with remote master
Local ref configured for 'git push':
master pushes to master (fast-forwardable)
-
Well I'm not sure, you sure your working branch is anythingslider and not master?
-
Well I'm not sure, you sure your working branch is anythingslider and not master?
-
Well I'm not sure, you sure your working branch is anythingslider and not master?