On Jan 3, 2013, at 6:31 PM, Derek Gaston wrote:
> One of the greatest things about Git is that there are so many ways to setup
> your project's work flow. Every project can decide for themselves what will
> work best for that project. It's freedom we never had with the old systems.
> It's a
On Thu, Jan 3, 2013 at 2:24 PM, Roy Stogner wrote:
> I didn't know that; thanks. I agree completely. I'm still not even
> entirely certain whether it's a good idea to use an interactive rebase
> to squash the occasional "commit N" and "commit N+1 fixing the bug
> just introduced by commit N" tog
Damon,
Thanks for the email... always good to see what others are doing!
What I'm advocating is _never_ using "git pull" and never having "merge
commits". If no one ever uses straight "git pull" things are much better
(even for public branches, but that can still give you issues). Instead,
ever
On Thu, Jan 3, 2013 at 2:20 PM, Roy Stogner wrote:
> > But note that periodically rebasing a shared branch should probably be
> > frowned upon, since that involves rewriting history (and push -f), and
> > may affect others...
>
> This is half of my trepidation. Before using git, in my imagination
On Thu, 3 Jan 2013, Derek Gaston wrote:
Oh - I also don't like "--no-ff" for merging. It essentially
"squashes" a bunch of commits into one... which I think is a bad
idea.
I didn't know that; thanks. I agree completely. I'm still not even
entirely certain whether it's a good idea to use an
On Thu, 3 Jan 2013, John Peterson wrote:
> It's an alternative to doing periodic merges (as e.g. Ben did with his
> recent meshfree interpolation branch).
Yup. And even with things like "git log --no-merges", the result of
those seems to be slightly annoying. When experimenting with "master
ad
Oh - I also don't like "--no-ff" for merging. It essentially "squashes" a
bunch of commits into one... which I think is a bad idea. Git is all about
working with tons of patches... and being able to swap them in and out of
branches. If you squash them together you lose a _ton_ of flexibility.
T
On Thu, Jan 3, 2013 at 1:58 PM, John Peterson wrote:
> I looked at this diagram for a while, and I like it, other than I
> probably wouldn't make such a big distinction between the yellow and
> green dots...
>
> Feature (pink) branches periodically merge into develop, every once in
> a while deve
On Thu, Jan 3, 2013 at 1:04 PM, Roy Stogner wrote:
>
> (Cc:ing the PECOS local git expert)
>
> On Wed, 12 Dec 2012, Derek Gaston wrote:
>
>> Let's just move to Git and work in master for a little while and let
>> everyone catch their breath...
>
> Although I am still very much mired in the "catchi
On Thu, Jan 3, 2013 at 1:04 PM, Roy Stogner wrote:
> (I'm still not certain under what-if-any conditions "rebase" is a good
> idea, for example)
"rebase" is what you want to use to "update" your branch and "stack" your
patches on top of whatever other work happened in another branch. This is
es
(Cc:ing the PECOS local git expert)
On Wed, 12 Dec 2012, Derek Gaston wrote:
> Let's just move to Git and work in master for a little while and let
> everyone catch their breath...
Although I am still very much mired in the "catching my breath" stage
(I'm still not certain under what-if-any con
On Tue, Dec 11, 2012 at 4:10 PM, John Peterson
wrote:
This workflow is correct, but it isn't complete...
> 1.)
> 2.) git pull --rebase
> 3.) git co master
> 4.) git merge branch_name
> 5.) git push
In order for the pull --rebase request to work properly, you have to
create the branch with the
On Wed, Dec 12, 2012 at 11:04 AM, Roy Stogner wrote:
> Nick Malaya set up something similar over here with the TACC systems -
> longhorn.tacc builds and tests our manufactured solution library MASA
> with the Portland Group compilers, and reports the results back to our
> "master" server where it
Sorry I'm late to the party, been in bed with the flu all day.
On Dec 12, 2012, at 11:27 AM, Derek Gaston wrote:
> Also, I have some libMesh changes that I'm going to be making today, so I was
> thinking about my Git workflow a little bit. I think even _I_ am going to
> clone the libMesh Git r
On Dec 12, 2012, at 12:04 PM, Roy Stogner wrote:
>>
>> Also, I have some libMesh changes that I'm going to be making today,
>> so I was thinking about my Git workflow a little bit. I think even
>> _I_ am going to clone the libMesh Git repo on GitHub over into my
>> own workspace and work on my
On Wed, 12 Dec 2012, Roy Stogner wrote:
> Ben and I (at least) haven't been getting the automatic emails that
> libMesh pull requests are supposed to generate; you might want to ping
> -devel at the same time until we get that sorted out.
Never mind; looks like John figured out the problem.
---
On Wed, 12 Dec 2012, Derek Gaston wrote:
Sounds good. Is there any way we could run a build bot "slave" (I
don't know the BuildBot parlance) here at INL that would report our
test status back to your Build Bot server? If so, we could
definitely set that up.
Nick Malaya set up something simi
On Wed, Dec 12, 2012 at 9:32 AM, Kirk, Benjamin (JSC-EG311)
wrote:
> On Dec 12, 2012, at 9:28 AM, John Peterson
> wrote:
>
>> The development branch can be periodically merged into stable, perhaps
>> automatically by buildbot whenever tests pass.
>>
>> So core developers would primarily work wit
On Wed, Dec 12, 2012 at 10:17 AM, Roy Stogner wrote:
> The PECOS CI server actually is publicly accessible. It's so hammered
> right now that I'd rather not subject its interface to even more usage
> until we get some new hardware going, but email me privately if you
> want the URL to peek at occ
On Dec 12, 2012, at 11:17 AM, Roy Stogner wrote:
> On Wed, 12 Dec 2012, Derek Gaston wrote:
>
>> I am not against this model... (it is VERY close to how we do things
>> with MOOSE... and our "stable merge" is automated by Bitten)
>> however, can we have a small "cooling off" period for a moment
On Wed, 12 Dec 2012, Derek Gaston wrote:
> I am not against this model... (it is VERY close to how we do things
> with MOOSE... and our "stable merge" is automated by Bitten)
> however, can we have a small "cooling off" period for a moment while
> everyone gets up to date with using the new buil
I am not against this model... (it is VERY close to how we do things with
MOOSE... and our "stable merge" is automated by Bitten) however, can we
have a small "cooling off" period for a moment while everyone gets up to
date with using the new build system and pulling from Git? MOOSE still
doesn't
On Wed, 12 Dec 2012, Kirk, Benjamin (JSC-EG311) wrote:
> (1) treating 'master' as the place for stable code, along the lines of Roy's
> suggestion,
> (2) creating 'devel' where the core developers live.
My concern here is that then the core developers don't get the main
benefit of the "devel"->
On Dec 12, 2012, at 9:28 AM, John Peterson
wrote:
> The development branch can be periodically merged into stable, perhaps
> automatically by buildbot whenever tests pass.
>
> So core developers would primarily work with the development branch,
> and users who lie somewhere between "core develo
On Tue, Dec 11, 2012 at 9:53 PM, Roy Stogner wrote:
>
> On Tue, 11 Dec 2012, Kirk, Benjamin (JSC-EG311) wrote:
>
>>
>> http://git-scm.com/book/en/Distributed-Git-Distributed-Workflows#Integration-Manager-Workflow
>
>
> Who volunteers to be integration manager? If it's not the most
> prolific deve
On Dec 11, 2012, at 10:53 PM, "Roy Stogner" wrote:
> A) given another patch designed specifically to fix the failed tests,
> B) reverted to any other newer-than-Master revision that hasn't been
> tested (in cases where multiple patches were added too fast for
> buildbot to test)
> C) reverted com
On Tue, Dec 11, 2012 at 7:24 PM, Kirk, Benjamin (JSC-EG311)
wrote:
> On Dec 11, 2012, at 6:14 PM, John Peterson
> wrote:
>
>> So the process for resolving conflicts during pull --rebase is exactly
>> the same as it is during a normal rebase. I'll discuss the steps
>> below if you want to play a
On Tue, 11 Dec 2012, Kirk, Benjamin (JSC-EG311) wrote:
> http://git-scm.com/book/en/Distributed-Git-Distributed-Workflows#Integration-Manager-Workflow
Who volunteers to be integration manager? If it's not the most
prolific developer then they're not going to be able to keep up (I'm
recalling th
On Dec 11, 2012, at 6:14 PM, John Peterson
wrote:
> So the process for resolving conflicts during pull --rebase is exactly
> the same as it is during a normal rebase. I'll discuss the steps
> below if you want to play along at home:
thanks John.
WRT this:
> Yep, that seems to work just fine.
On Tue, Dec 11, 2012 at 4:10 PM, John Peterson
wrote:
> On Tue, Dec 11, 2012 at 2:21 PM, John Peterson
> wrote:
>> On Mon, Dec 10, 2012 at 5:04 PM, Kirk, Benjamin (JSC-EG311)
>> wrote:
>>> libMesh users & developers:
>>>
>> Then the work flow is as follows:
>>
>> 1.)
>> 2.) git co master
>> 3.)
By the way, you may also want to put the following in your ~/.gitconfig file.
It sets us some nice color coding for looking at logs and sets up a
few two letter abbreviations that are handy.
[user]
name = Your Name
email = yourem...@yourdomain.edu
[color]
diff = auto
status = au
On Tue, Dec 11, 2012 at 2:21 PM, John Peterson
wrote:
> On Mon, Dec 10, 2012 at 5:04 PM, Kirk, Benjamin (JSC-EG311)
> wrote:
>> libMesh users & developers:
>>
> Then the work flow is as follows:
>
> 1.)
> 2.) git co master
> 3.) git fetch
> 4.) git merge origin/master
> 5.) git co branch_name
>
On Mon, Dec 10, 2012 at 5:04 PM, Kirk, Benjamin (JSC-EG311)
wrote:
> libMesh users & developers:
>
> Effective immediately, we are moving our development source tree to GitHub.
>
> https://github.com/libMesh/libmesh
>
> You can check out the current source tree via
>
> $ git clone https://github.c
33 matches
Mail list logo
