Hi,
Avery Pennarun apenw...@gmail.com writes:
On Tue, Jul 27, 2010 at 3:11 PM, Raja R Harinath harin...@hurrynot.org
wrote:
* clean up the main repos
[snip]
My proposal is to
(a) create a read-only set of fork/clones at github.com/historic-mono
(b) remove all inactive branches from
I've personally found this workflow to be a lot of extra work for
little gain, and certainly:
We've already seen issues with unintended (but safe) merges causing
confusion -- the confusion is exacerbated by the GitHub UI showing 'git
diff --first-parent' on merge commits, rather than
Avery Pennarun apenw...@gmail.com writes:
I've personally found this workflow to be a lot of extra work for
little gain, and certainly:
We've already seen issues with unintended (but safe) merges causing
confusion -- the confusion is exacerbated by the GitHub UI showing 'git
diff
On Wed, Jul 28, 2010 at 4:31 AM, Raja R Harinath harin...@hurrynot.org wrote:
Avery Pennarun apenw...@gmail.com writes:
However, it's just so easy to do this:
git checkout master
# do stuff
git commit -a
git pull
git push
That I think asking people to do fancier
Hi all,
So, now instead of a svn checkout, in order to build from sources,
should we type something like the following?
git clone git://github.com/mono/mono.git
Is that correct?
I guess not really since it's downloading the entire mono repo, which is
a terrible overkill, isn't it??
Thanks,
Hey,
On Wed, Jul 28, 2010 at 10:21 AM, pablosantosl...@terra.es
pablosantosl...@terra.es wrote:
Hi all,
So, now instead of a svn checkout, in order to build from sources,
should we type something like the following?
git clone git://github.com/mono/mono.git
Is that correct?
Yes, this
Hi Alan,
But, now I'm downloading the entire history of mono instead of a single
copy of 'master', right?
pablo
On 28/07/2010 11:24, Alan wrote:
Hey,
On Wed, Jul 28, 2010 at 10:21 AM, pablosantosl...@terra.es
mailto:pablosantosl...@terra.es pablosantosl...@terra.es
Yes you are but if you aren't interested in contributing with this
repository (no pushing or pulling from) you can pass the --depth 1 switch to
git clone which will only fetch one revision (that is HEAD). You will still
be able to pull from github but that's pretty much it.
--
Jérémie Laval
Excellent!
On 28/07/2010 11:32, Jérémie Laval wrote:
Yes you are but if you aren't interested in contributing with this
repository (no pushing or pulling from) you can pass the --depth
1 switch to git clone which will only fetch one revision (that is HEAD).
You will still be able to pull from
On Tue, 2010-07-27 at 17:15 +0900, Atsushi Eno wrote:
Hello,
I wanted to import a password-protected pfx certificate, but it was not
supported in our certmgr. So I have created a small patch to enable it.
If it's looking good I'll push it in git (or feel free to do instead).
Looks fine.
On Tue, 2010-07-27 at 17:50 +0900, Atsushi Eno wrote:
Hello again,
This patch adds support for X509Store.TrustedPeople in Mono.Security
and certmgr.
Sorry for that this patch includes the previous change, I was lazy :|
Looks fine too :)
Thanks
Sebastien
2010/7/28 pablosantosl...@terra.es pablosantosl...@terra.es
Excellent!
On 28/07/2010 11:32, Jérémie Laval wrote:
Yes you are but if you aren't interested in contributing with this
repository (no pushing or pulling from) you can pass the --depth
1 switch to git clone which will only fetch
The source trees at github.com/mono/ have a lot of junk^W branches left
over from the SVN days. However, we mostly work on two or three main
branches. For instance, in the mono/ tree, we work on the unstable
master, the stable mono-2-6 and very occassionally on mono-2-4.
So, looking at the
Hello,
I have another proposition to make. Can we stop using Changelog files?
Those can be generated from the commit logs for tarballs and releases
without losing anything at all. Commit messages would still have to be at
least as informative as they currently are.
As soon as someone
On Wed, Jul 28, 2010 at 5:01 PM, Miguel de Icaza mig...@novell.com wrote:
As soon as someone writes the tool that generates the ChangeLog from the
commit messages when producing a tarball, I am fine with dropping the
ChangeLog-on-commit.
If nobody else does it I'm volunteering - I really,
Hello,
For commit messages, how about gnome style ones?
http://live.gnome.org/Git/CommitMessages
We'll end up with messages like this:
http://github.com/mono/moon/commit/feadf070d237c1227ff2709cf1d0131d267118e2:)
This is a great suggestion, I have added it here:
On 2010-07-28, at 11:27 AM, Andreia Vidigal Gaita wrote:
Dropping the per-file changes as a rule is not good, I think. Things
won't be as well documented as they should be, and we'll end up having
to dig through the commit itself to parse the code and try to understand
which change does
On 2010-07-28, at 10:52 AM, Miguel de Icaza wrote:
In general I like the idea of cleaning this up a little bit, perhaps the idea
of tags that was brought up on the list would allow us to keep the history in
some form, while keeping branches useful.
* Real release branches, these have
I'm porting an app and ran the migration wizard. Found a MonoTodo, and
subsequently found that
System.Text.RegularExpresssions.Regex.CompileToAssembly method is currently
not implemented.
The app used it pretty extensively to speed up regex pattern matching. How
would I find out if this method
Hello.
I would like to propose this 2 patches for review, to fix the mono-2-6
branch. In LindenLab we use Debian Etch, and were having 2 issues
building mono 2.6.7:
1) Fix for first patch: avoiding the use of 'var' (Etch has mono 1.9):
http://monobin.com/__m138c04d6
2) Fix for TimeZoneInfo.cs in
On Wed, Jul 28, 2010 at 10:52 AM, Miguel de Icaza mig...@novell.com wrote:
* Real release branches, these have value in that we can determine what we
shipped when. The older the release, the lesser the value.
Using tags for this works just as well, and lets you move the names
out of the more
Hi,
I'm using libgdiplus-2.6.7.
I see that in the below files there is Status s; or Status status;.
Status is declared in Xlib.h as an int.
But on those contexts it should be GpStatus and not Status.
GpStatus is an enum so using Status compiles anyway.
But I think GpStatus is more correct.
I've added a couple of simple workflows to our git faq,
http://www.mono-project.com/GitFAQ#Workflow . See if these work for
you, they should make it easier to avoid merge commits. There are
plenty of ways to do things, and these don't include working on forks,
although it's not too different. More
I've added a couple of simple workflows to our git faq,
http://www.mono-project.com/GitFAQ#Workflow . See if these work for
you, they should make it easier to avoid merge commits. There are
plenty of ways to do things, and these don't include working on forks,
although it's not too different. More
This isn't QUITE accurate. Tags are intentionally harder to change precisely
because they are intended to have a degree of 'permanence' and be outside of
the day-to-day workflow that branches are for.
To that end, they include another important feature that branches do not, which
is the
On Thu, Jul 29, 2010 at 12:03 AM, Jon Frisby jfri...@mrjoy.com wrote:
This isn't QUITE accurate. Tags are intentionally harder to change precisely
because they are intended to have a
degree of 'permanence' and be outside of the day-to-day workflow that
branches are for.
Right, but I don't
On Jul 28, 2010, at 11:21 PM, Avery Pennarun wrote:
On Thu, Jul 29, 2010 at 12:03 AM, Jon Frisby jfri...@mrjoy.com wrote:
This isn't QUITE accurate. Tags are intentionally harder to change
precisely because they are intended to have a
degree of 'permanence' and be outside of the day-to-day
On Thu, Jul 29, 2010 at 1:07 AM, Jon Frisby jfri...@mrjoy.com wrote:
On Jul 28, 2010, at 11:21 PM, Avery Pennarun wrote:
Hmm, if it's only a branch that you're working on - which is implied
by the jfrisby/ prefix - then I don't see any reason to put it in the
shared repo. That's exactly why
28 matches
Mail list logo
