On 2012-07-16 21:37, Adam Wilson wrote:
The only problem I can see with this is that the build would only for
whichever OS the merger happens to be running on. A two step process is
about the best we can do.
./merge does the following
git fetch upstream
git cherry-pick 534d44c979
git
On Mon, 16 Jul 2012 23:17:38 -0700, Jacob Carlborg d...@me.com wrote:
On 2012-07-16 21:37, Adam Wilson wrote:
The only problem I can see with this is that the build would only for
whichever OS the merger happens to be running on. A two step process is
about the best we can do.
./merge does
On Mon, 16 Jul 2012 23:24:04 -0700
Adam Wilson flybo...@gmail.com wrote:
On Mon, 16 Jul 2012 23:17:38 -0700, Jacob Carlborg d...@me.com
wrote:
On 2012-07-16 21:37, Adam Wilson wrote:
./build does the following for all projects
git fetch origin
git merge origin/master
make clean -f
On 2012-07-17 08:24, Adam Wilson wrote:
Each parameter represents a specific commit ID to pick.
So you would pass those to the script?
--
/Jacob Carlborg
On Monday, 16 July 2012 at 17:27:32 UTC, Marco Leise wrote:
Am Fri, 20 Jan 2012 00:36:11 +0100
I didn't check your code, but does it handle case-insensitive
Windows OS as well as Unix like?
I didn't think consider this when working on it, so it's probably
always case-sensitive.
Did you
On Tue, 17 Jul 2012 02:08:55 -0700, Jacob Carlborg d...@me.com wrote:
On 2012-07-17 08:24, Adam Wilson wrote:
Each parameter represents a specific commit ID to pick.
So you would pass those to the script?
Yup, I think that's probably the safest way to do it. Given the goals of
the
On 2012-07-17 19:04, Adam Wilson wrote:
Yup, I think that's probably the safest way to do it. Given the goals of
the project, we need to be explicit about which commits we choose so
forcing the maintainers to write down every commit is good practice.
Exactly. I took that example a bit too
