rails-devel

Re: [Rails-devel] Git troubleshooting

[brett l. <bre...@gm...>]

Ok... I've made a few small commits with EGit, and I think I'm getting
the hang of the interface. It's a bit clumsy, but it seems to do
everything I expect. The EGit user guide is a fairly lengthy document,
but as Stefan noted earlier, it's got a lot of important details that
will help you learn the interface:
http://wiki.eclipse.org/EGit/User_Guide

I think everyone should probably take a step back. I have a feeling we
tried to run before we learned to walk. ;-)

Set aside the work you've done, do a clean clone of the repo in a new
location following the EGit User Guide. Then, find some small one-line
change to make. Commit it, push it, as directed by the User Guide.
Let's try to get everyone to commit and successfully push a few small
changes before we try to bite off anything bigger. Once we've got a
few pushes and pulls done, we can come back to the bigger pieces of
work that are being done.

Next...

Also, in your git configs (usually a .gitconfig file in your home
directory), it's very handy to default to always rebasing incoming
changes. Merge commits are supposed to be meaningful, but the default
behavior is to always merge incoming changes (and create a merge
commit for them). The tradeoff here is that rebasing changes the
commit history, which is potentially dangerous and less obvious than
adding a bunch of extraneous merge commits every time you do a pull.

You can configure certain branches to always do this without the --rebase flag:

# make `git pull` on master always use rebase
$ git config branch.master.rebase true
You can also set up a global option to set the last property for every
new tracked branch:

# setup rebase for every tracking branch
$ git config --global branch.autosetuprebase always

The .gitconfig is an ini-style file, so the above is also represented
as this if you want to update the file directly:

[branch]
   autosetuprebase = always


Finally...

I'm happy to continue lending support as y'all run into troubles. It
took me a while to fully acclimate to Git's workflow, too. It's
different, but very powerful once we get past the first few hurdles.
:-)

---Brett.

Re: [Rails-devel] Git troubleshooting

[brett l. <bre...@gm...>]

Oh... One more note:

EGit seems to be pretty tolerant of me mucking about in the repository
via the CLI.  I haven't done anything too drastic yet, but so far it
hasn't had a problem picking up changes I've done via the CLI.

So, with any luck, that's a good difference between EGit and the SVN
Eclipse plugin.

---Brett.



On Thu, Jul 21, 2011 at 10:59 AM, brett lentz <bre...@gm...> wrote:
> Ok... I've made a few small commits with EGit, and I think I'm getting
> the hang of the interface. It's a bit clumsy, but it seems to do
> everything I expect. The EGit user guide is a fairly lengthy document,
> but as Stefan noted earlier, it's got a lot of important details that
> will help you learn the interface:
> http://wiki.eclipse.org/EGit/User_Guide
>
> I think everyone should probably take a step back. I have a feeling we
> tried to run before we learned to walk. ;-)
>
> Set aside the work you've done, do a clean clone of the repo in a new
> location following the EGit User Guide. Then, find some small one-line
> change to make. Commit it, push it, as directed by the User Guide.
> Let's try to get everyone to commit and successfully push a few small
> changes before we try to bite off anything bigger. Once we've got a
> few pushes and pulls done, we can come back to the bigger pieces of
> work that are being done.
>
> Next...
>
> Also, in your git configs (usually a .gitconfig file in your home
> directory), it's very handy to default to always rebasing incoming
> changes. Merge commits are supposed to be meaningful, but the default
> behavior is to always merge incoming changes (and create a merge
> commit for them). The tradeoff here is that rebasing changes the
> commit history, which is potentially dangerous and less obvious than
> adding a bunch of extraneous merge commits every time you do a pull.
>
> You can configure certain branches to always do this without the --rebase flag:
>
> # make `git pull` on master always use rebase
> $ git config branch.master.rebase true
> You can also set up a global option to set the last property for every
> new tracked branch:
>
> # setup rebase for every tracking branch
> $ git config --global branch.autosetuprebase always
>
> The .gitconfig is an ini-style file, so the above is also represented
> as this if you want to update the file directly:
>
> [branch]
>   autosetuprebase = always
>
>
> Finally...
>
> I'm happy to continue lending support as y'all run into troubles. It
> took me a while to fully acclimate to Git's workflow, too. It's
> different, but very powerful once we get past the first few hurdles.
> :-)
>
> ---Brett.
>

Re: [Rails-devel] Git troubleshooting

[Stefan F. <ste...@we...>]

Brett,
thanks for your support. Some comments below.

I have used subversion for several years now (I switched to svn as soon as it 
worked somehow).

My experience with subversion was that if you do not follow the recommended 
workflow from the beginning you are in a mess (e.g. not setting up the repo 
with trunk/branch/tag, avoid berkleyDB ...).

On Thursday, July 21, 2011 07:59:43 pm brett lentz wrote:
> Ok... I've made a few small commits with EGit, and I think I'm getting
> the hang of the interface. It's a bit clumsy, but it seems to do
> everything I expect. The EGit user guide is a fairly lengthy document,
> but as Stefan noted earlier, it's got a lot of important details that
> will help you learn the interface:
> http://wiki.eclipse.org/EGit/User_Guide

The main issue I have with the document is that if you are potential user of 
git most likely you do not need snapshots of each dialog, but better 
explanations and FAQs.

It is like the assumption of Microsoft (in the beginning) that admins would 
prefer day-by-day work using a GUI.

> 
> I think everyone should probably take a step back. I have a feeling we
> tried to run before we learned to walk. ;-)
> 
> Set aside the work you've done, do a clean clone of the repo in a new
> location following the EGit User Guide. Then, find some small one-line
> change to make. Commit it, push it, as directed by the User Guide.
> Let's try to get everyone to commit and successfully push a few small
> changes before we try to bite off anything bigger. Once we've got a
> few pushes and pulls done, we can come back to the bigger pieces of
> work that are being done.

OK.

> 
> Next...
> 
> Also, in your git configs (usually a .gitconfig file in your home
> directory), it's very handy to default to always rebasing incoming
> changes. Merge commits are supposed to be meaningful, but the default
> behavior is to always merge incoming changes (and create a merge
> commit for them). The tradeoff here is that rebasing changes the
> commit history, which is potentially dangerous and less obvious than
> adding a bunch of extraneous merge commits every time you do a pull.

Now you lost me: First you suggest to always rebase incoming changings and 
then you claim that it is potentially dangerous. Why should I choose such an 
option? 

More seriously:
This is set in the branching dialog for each branch. Given the documentation 
egit should use the default from .gitconfig for new branches, the egit default 
is merging.

http://wiki.eclipse.org/EGit/User_Guide#Branching

The connection is then set for the tracking relationship (rebase or merge on 
pull) and it seems that this cannot be changed via UI (maybe by setting a 
property in the git explorer view).

see here
http://wiki.eclipse.org/EGit/User_Guide#Pulling_New_Changes_from_Upstream_Branch

And the link above has a critical reminder for Windows user:
There is an existing bug such that WIndows users should avoid "git pull" on 
the command line if using egit. 

Hope it will soon all be sorted out.
Stefan

Re: [Rails-devel] Git troubleshooting

[brett l. <bre...@gm...>]

On Thu, Jul 21, 2011 at 11:41 AM, Stefan Frey <ste...@we...> wrote:
> Brett,
> thanks for your support. Some comments below.
>
> I have used subversion for several years now (I switched to svn as soon as it
> worked somehow).
>
> My experience with subversion was that if you do not follow the recommended
> workflow from the beginning you are in a mess (e.g. not setting up the repo
> with trunk/branch/tag, avoid berkleyDB ...).
>

Git is a *very* different tool, written to *very* different requirements.

SVN is "CVS done right", ignoring the fact that the CVS design is
fundamentally flawed and using a development methodology from the
1980s (the initial release of Gnu RCS was in 1982, and CVS is the
successor to RCS). Whereas Git is "Let's make a brand new VCS that can
handle the current linux-kernel development model."  Git is solving
today's problems where SVN is (re-)solving 20-30 year old problems.

I've had numerous problems over the years with corrupt SVN DBs; or
somebody using the wrong version of the SVN client and the stupid
server auto-upgrades the central SVN repo's DB, which makes all other
clients incompatible and causes much breakage. There are many design
decisions that SVN made that, IMO, are seriously flawed.

One of the things Git does right, IMO, is that it doesn't complicate
things with crap like using a DB. Everything in the .git directory is
a file. Your changes are stored as plain-text diffs. For performance,
Git gzips the files and repacks them, but they're all accessible for
viewing if you care to look.

I have a suspicion that this is the reason that I can muck with Git
outside of Eclipse and have EGit "just work". It doesn't have to
interface with a DB. It just looks at the state of the filesystem and
can see updates and just automatically refresh the view inside
Eclipse. As I've seen Linus post a few different times, "Git is a
stupid content tracker."  It's stupid, which makes it very smart. ;-)

> On Thursday, July 21, 2011 07:59:43 pm brett lentz wrote:
>> Ok... I've made a few small commits with EGit, and I think I'm getting
>> the hang of the interface. It's a bit clumsy, but it seems to do
>> everything I expect. The EGit user guide is a fairly lengthy document,
>> but as Stefan noted earlier, it's got a lot of important details that
>> will help you learn the interface:
>> http://wiki.eclipse.org/EGit/User_Guide
>
> The main issue I have with the document is that if you are potential user of
> git most likely you do not need snapshots of each dialog, but better
> explanations and FAQs.
>
> It is like the assumption of Microsoft (in the beginning) that admins would
> prefer day-by-day work using a GUI.
>

Agreed. The screenshots aren't super-helpful and a few are even outdated.

But, that's the way they chose to write their docs.

>>
>> Next...
>>
>> Also, in your git configs (usually a .gitconfig file in your home
>> directory), it's very handy to default to always rebasing incoming
>> changes. Merge commits are supposed to be meaningful, but the default
>> behavior is to always merge incoming changes (and create a merge
>> commit for them). The tradeoff here is that rebasing changes the
>> commit history, which is potentially dangerous and less obvious than
>> adding a bunch of extraneous merge commits every time you do a pull.
>
> Now you lost me: First you suggest to always rebase incoming changings and
> then you claim that it is potentially dangerous. Why should I choose such an
> option?

Rebasing is changing the ordering of the commit history. It's an
incredibly important and powerful feature, but changing history is one
of those topics that's traditionally very scary to users. And, yes,
I've seen a number of "OMG! Rebasing ate my baby!" blog posts from
users who have misused or misunderstood the feature.

It's the one feature that trips people up the most because it's a
completely foreign concept if you're coming from CVS/SVN.

My point was, it's not the default behavior for good reason. However,
for the simple "git pull" operation, it tends to be the best option
(once you understand how it works) because it keeps the commit history
cleaner and separates the "update from upstream" and "merge your local
work" steps into two discrete actions. This separation makes it more
clear when the rebase of upstream changes causes a merge conflict and
when your local changes are causing the merge conflict.

This is one of those areas in which; unlike CVS/SVN, where you can get
away with not caring about the tool's internals; it is very helpful to
have some knowledge of _how_ Git works because it helps you do more
advanced things with the repository.

>
> More seriously:
> This is set in the branching dialog for each branch. Given the documentation
> egit should use the default from .gitconfig for new branches, the egit default
> is merging.
>
> http://wiki.eclipse.org/EGit/User_Guide#Branching
>
> The connection is then set for the tracking relationship (rebase or merge on
> pull) and it seems that this cannot be changed via UI (maybe by setting a
> property in the git explorer view).
>
> see here
> http://wiki.eclipse.org/EGit/User_Guide#Pulling_New_Changes_from_Upstream_Branch
>
> And the link above has a critical reminder for Windows user:
> There is an existing bug such that WIndows users should avoid "git pull" on
> the command line if using egit.
>

Yep. We're going to need to learn platform-specific issues with the
new tool. My main machines are running Linux or Mac OS X. I've got an
old Windows machine I use occasionally, but not often.

> Hope it will soon all be sorted out.

Yes. Unfortunately, this is one of the down sides to EGit. For better
or worse, they decided to use a complete re-implementation of Git in
Java (JGit) instead of just hooking into the pre-existing tools and
libraries. It's not the choice I'd have made, but that's what they
went with. I'm certain it'll get better over time. Judging by the
mailing list, the project is under active development, so we should
see fixes relatively soon. The project has already come a long way in
the last year (when we opted for CVS->SVN instead of CVS->Git) and I'm
confident these issues will be sorted relatively soon.

> Stefan
>

---Brett.

Re: [Rails-devel] Git troubleshooting

[Erik V. <eri...@xs...>]

It seems to me that Egit is not yet mature in all respects. 
For instance, the errors I have got are much better explained on the command
line than they are in Egit.
But we'll have to live with it.

Do you have an example of how to configure --rebase in .gitconfig?

Erik.

> -----Original Message-----
> From: brett lentz [mailto:bre...@gm...]
> Sent: Thursday, July 21, 2011 9:28 PM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Git troubleshooting
> 
> On Thu, Jul 21, 2011 at 11:41 AM, Stefan Frey <ste...@we...> wrote:
> > Brett,
> > thanks for your support. Some comments below.
> >
> > I have used subversion for several years now (I switched to svn as
> > soon as it worked somehow).
> >
> > My experience with subversion was that if you do not follow the
> > recommended workflow from the beginning you are in a mess (e.g. not
> > setting up the repo with trunk/branch/tag, avoid berkleyDB ...).
> >
> 
> Git is a *very* different tool, written to *very* different requirements.
> 
> SVN is "CVS done right", ignoring the fact that the CVS design is
> fundamentally flawed and using a development methodology from the 1980s
> (the initial release of Gnu RCS was in 1982, and CVS is the successor to
RCS).
> Whereas Git is "Let's make a brand new VCS that can handle the current
> linux-kernel development model."  Git is solving today's problems where
> SVN is (re-)solving 20-30 year old problems.
> 
> I've had numerous problems over the years with corrupt SVN DBs; or
> somebody using the wrong version of the SVN client and the stupid server
> auto-upgrades the central SVN repo's DB, which makes all other clients
> incompatible and causes much breakage. There are many design decisions
> that SVN made that, IMO, are seriously flawed.
> 
> One of the things Git does right, IMO, is that it doesn't complicate
things with
> crap like using a DB. Everything in the .git directory is a file. Your
changes are
> stored as plain-text diffs. For performance, Git gzips the files and
repacks
> them, but they're all accessible for viewing if you care to look.
> 
> I have a suspicion that this is the reason that I can muck with Git
outside of
> Eclipse and have EGit "just work". It doesn't have to interface with a DB.
It
> just looks at the state of the filesystem and can see updates and just
> automatically refresh the view inside Eclipse. As I've seen Linus post a
few
> different times, "Git is a stupid content tracker."  It's stupid, which
makes it
> very smart. ;-)
> 
> > On Thursday, July 21, 2011 07:59:43 pm brett lentz wrote:
> >> Ok... I've made a few small commits with EGit, and I think I'm
> >> getting the hang of the interface. It's a bit clumsy, but it seems to
> >> do everything I expect. The EGit user guide is a fairly lengthy
> >> document, but as Stefan noted earlier, it's got a lot of important
> >> details that will help you learn the interface:
> >> http://wiki.eclipse.org/EGit/User_Guide
> >
> > The main issue I have with the document is that if you are potential
> > user of git most likely you do not need snapshots of each dialog, but
> > better explanations and FAQs.
> >
> > It is like the assumption of Microsoft (in the beginning) that admins
> > would prefer day-by-day work using a GUI.
> >
> 
> Agreed. The screenshots aren't super-helpful and a few are even outdated.
> 
> But, that's the way they chose to write their docs.
> 
> >>
> >> Next...
> >>
> >> Also, in your git configs (usually a .gitconfig file in your home
> >> directory), it's very handy to default to always rebasing incoming
> >> changes. Merge commits are supposed to be meaningful, but the default
> >> behavior is to always merge incoming changes (and create a merge
> >> commit for them). The tradeoff here is that rebasing changes the
> >> commit history, which is potentially dangerous and less obvious than
> >> adding a bunch of extraneous merge commits every time you do a pull.
> >
> > Now you lost me: First you suggest to always rebase incoming changings
> > and then you claim that it is potentially dangerous. Why should I
> > choose such an option?
> 
> Rebasing is changing the ordering of the commit history. It's an
incredibly
> important and powerful feature, but changing history is one of those
topics
> that's traditionally very scary to users. And, yes, I've seen a number of
> "OMG! Rebasing ate my baby!" blog posts from users who have misused or
> misunderstood the feature.
> 
> It's the one feature that trips people up the most because it's a
completely
> foreign concept if you're coming from CVS/SVN.
> 
> My point was, it's not the default behavior for good reason. However, for
the
> simple "git pull" operation, it tends to be the best option (once you
> understand how it works) because it keeps the commit history cleaner and
> separates the "update from upstream" and "merge your local work" steps
> into two discrete actions. This separation makes it more clear when the
> rebase of upstream changes causes a merge conflict and when your local
> changes are causing the merge conflict.
> 
> This is one of those areas in which; unlike CVS/SVN, where you can get
away
> with not caring about the tool's internals; it is very helpful to have
some
> knowledge of _how_ Git works because it helps you do more advanced
> things with the repository.
> 
> >
> > More seriously:
> > This is set in the branching dialog for each branch. Given the
> > documentation egit should use the default from .gitconfig for new
> > branches, the egit default is merging.
> >
> > http://wiki.eclipse.org/EGit/User_Guide#Branching
> >
> > The connection is then set for the tracking relationship (rebase or
> > merge on
> > pull) and it seems that this cannot be changed via UI (maybe by
> > setting a property in the git explorer view).
> >
> > see here
> >
> http://wiki.eclipse.org/EGit/User_Guide#Pulling_New_Changes_from_Upst
> r
> > eam_Branch
> >
> > And the link above has a critical reminder for Windows user:
> > There is an existing bug such that WIndows users should avoid "git
> > pull" on the command line if using egit.
> >
> 
> Yep. We're going to need to learn platform-specific issues with the new
tool.
> My main machines are running Linux or Mac OS X. I've got an old Windows
> machine I use occasionally, but not often.
> 
> > Hope it will soon all be sorted out.
> 
> Yes. Unfortunately, this is one of the down sides to EGit. For better or
worse,
> they decided to use a complete re-implementation of Git in Java (JGit)
> instead of just hooking into the pre-existing tools and libraries. It's
not the
> choice I'd have made, but that's what they went with. I'm certain it'll
get
> better over time. Judging by the mailing list, the project is under active
> development, so we should see fixes relatively soon. The project has
already
> come a long way in the last year (when we opted for CVS->SVN instead of
> CVS->Git) and I'm confident these issues will be sorted relatively soon.
> 
> > Stefan
> >
> 
> ---Brett.
> 
>
----------------------------------------------------------------------------
--
> 5 Ways to Improve & Secure Unified Communications Unified
> Communications promises greater efficiencies for business. UC can improve
> internal communications as well as offer faster, more efficient ways to
> interact with customers and streamline customer service. Learn more!
> http://www.accelacomm.com/jaw/sfnl/114/51426253/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Git troubleshooting

[brett l. <bre...@gm...>]

On Thu, Jul 21, 2011 at 3:38 PM, Erik Vos <eri...@xs...> wrote:
> It seems to me that Egit is not yet mature in all respects.
> For instance, the errors I have got are much better explained on the command
> line than they are in Egit.
> But we'll have to live with it.
>
> Do you have an example of how to configure --rebase in .gitconfig?
>
> Erik.
>


(Trimming the other thread bits for brevity's sake).

There was another post in this thread that included the syntax. You
want the [branch] portion below...

My full .gitconfig looks like this:

[blentz@blentzmac ~] (master %)$ cat ~/.gitconfig
[user]
        name = Brett Lentz
        email = bre...@gm...

[color]
        diff = auto
        status = auto
        branch = auto
        interactive = auto
        ui = true
        pager = true

[color "branch"]
        current = yellow reverse
        local = yellow
        remote = green

[color "diff"]
        meta = yellow bold
        frag = magenta bold
        old = red bold
        new = green bold

[color "status"]
        added = yellow
        changed = green
        untracked = cyan

[core]
        pager = less -FRSX
        whitespace = fix,-indent-with-non-tab,trailing-space,cr-at-eol

[alias]
	ci = commit
	ch = cherry-pick -x
	co = checkout
	br = branch -v
	st = status
	tag = tag -a

[branch]
	autosetuprebase = always

[merge]
	tool = vimdiff

[receive]
	denyDeleteCurrent = warn

Re: [Rails-devel] Git troubleshooting

[Phil D. <de...@gm...>]

On 21 July 2011 20:27, brett lentz <bre...@gm...> wrote:
> Yes. Unfortunately, this is one of the down sides to EGit. For better
> or worse, they decided to use a complete re-implementation of Git in
> Java (JGit) instead of just hooking into the pre-existing tools and
> libraries. It's not the choice I'd have made, but that's what they
> went with. I'm certain it'll get better over time. Judging by the
> mailing list, the project is under active development, so we should
> see fixes relatively soon. The project has already come a long way in
> the last year (when we opted for CVS->SVN instead of CVS->Git) and I'm
> confident these issues will be sorted relatively soon.

If you are using IDEA instead of Eclipse, that does use the standard
Git client.  I've managed to pull the source locally but still finding
time to go over the git documents and understand exactly what I need
to understand.  Thankfully I don't have commit rights, this is
probably for the best :)

Phil

Re: [Rails-devel] Git troubleshooting

[brett l. <bre...@gm...>]

On Fri, Jul 22, 2011 at 7:02 AM, Phil Davies <de...@gm...> wrote:
> On 21 July 2011 20:27, brett lentz <bre...@gm...> wrote:
>> Yes. Unfortunately, this is one of the down sides to EGit. For better
>> or worse, they decided to use a complete re-implementation of Git in
>> Java (JGit) instead of just hooking into the pre-existing tools and
>> libraries. It's not the choice I'd have made, but that's what they
>> went with. I'm certain it'll get better over time. Judging by the
>> mailing list, the project is under active development, so we should
>> see fixes relatively soon. The project has already come a long way in
>> the last year (when we opted for CVS->SVN instead of CVS->Git) and I'm
>> confident these issues will be sorted relatively soon.
>
> If you are using IDEA instead of Eclipse, that does use the standard
> Git client.  I've managed to pull the source locally but still finding
> time to go over the git documents and understand exactly what I need
> to understand.  Thankfully I don't have commit rights, this is
> probably for the best :)
>
> Phil

Yep, your workflow is much simpler:

1. Do work in a topic branch, committing as usual.
2. "git format-patch" when you're ready.
3. Post patches to this list. ;-)


---Brett.

Re: [Rails-devel] Git troubleshooting

[Erik V. <eri...@xs...>]

Good, I have recloned the repository and done a few commits.  Seems to work
so far.
One thing is a bit curious: after the push I need to do a pull to get my
local status fully updated (in Egit as well as in the GitBash CLI).
I suppose that's the way it is...

So far I have only worked in and committed to the master branch. I suppose
that's part of why I got into problems earlier.  I probably need to educate
myself on this aspect....


The commits revert Brett's Tag change that have I protested against, and I
have added some hopefully helpful comments to clarify the original code.

I have also found why that code exists in Tag.  The game option
"UnlimitedTopTrains" is parametrized with a value "D" to allow it to be
displayed as "Unlimited D-trains".
This way we don't need a separate name and corresponding entry in
LocalizedText.properties for each different train type for which that option
is used.

To make that parameter persistent, this option is saved with the name
"UnlimitedTopTrains_D". To find its value, the code must therefore find a
saved option name that starts with the unparametrized name, and that's what
happens in that code.  So it's not obsolete at all.

And if this code does find a value, the 'if' condition value has changed
between its first and second check, so these ifs cannot be merged.

Erik.

> -----Original Message-----
> From: brett lentz [mailto:bre...@gm...]
> Sent: Thursday, July 21, 2011 8:00 PM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Git troubleshooting
> 
> Ok... I've made a few small commits with EGit, and I think I'm getting the
> hang of the interface. It's a bit clumsy, but it seems to do everything I
expect.
> The EGit user guide is a fairly lengthy document, but as Stefan noted
earlier,
> it's got a lot of important details that will help you learn the
interface:
> http://wiki.eclipse.org/EGit/User_Guide
> 
> I think everyone should probably take a step back. I have a feeling we
tried
> to run before we learned to walk. ;-)
> 
> Set aside the work you've done, do a clean clone of the repo in a new
> location following the EGit User Guide. Then, find some small one-line
> change to make. Commit it, push it, as directed by the User Guide.
> Let's try to get everyone to commit and successfully push a few small
> changes before we try to bite off anything bigger. Once we've got a few
> pushes and pulls done, we can come back to the bigger pieces of work that
> are being done.
> 
> Next...
> 
> Also, in your git configs (usually a .gitconfig file in your home
directory), it's
> very handy to default to always rebasing incoming changes. Merge commits
> are supposed to be meaningful, but the default behavior is to always merge
> incoming changes (and create a merge commit for them). The tradeoff here
> is that rebasing changes the commit history, which is potentially
dangerous
> and less obvious than adding a bunch of extraneous merge commits every
> time you do a pull.
> 
> You can configure certain branches to always do this without the --rebase
> flag:
> 
> # make `git pull` on master always use rebase $ git config
> branch.master.rebase true You can also set up a global option to set the
last
> property for every new tracked branch:
> 
> # setup rebase for every tracking branch $ git config --global
> branch.autosetuprebase always
> 
> The .gitconfig is an ini-style file, so the above is also represented as
this if you
> want to update the file directly:
> 
> [branch]
>    autosetuprebase = always
> 
> 
> Finally...
> 
> I'm happy to continue lending support as y'all run into troubles. It took
me a
> while to fully acclimate to Git's workflow, too. It's different, but very
> powerful once we get past the first few hurdles.
> :-)
> 
> ---Brett.
> 
>
----------------------------------------------------------------------------
--
> 5 Ways to Improve & Secure Unified Communications Unified
> Communications promises greater efficiencies for business. UC can improve
> internal communications as well as offer faster, more efficient ways to
> interact with customers and streamline customer service. Learn more!
> http://www.accelacomm.com/jaw/sfnl/114/51426253/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Git troubleshooting

[brett l. <bre...@gm...>]

That makes a *lot* more sense.

I suspect there's probably an easier way to achieve the same result,
but I'll save that for a later discussion. ;-)

I'm happy to see the issues with Git are starting to be sorted out. It
sounds like the Windows implementation is lagging behind the other
platforms, but is still usable.

---Brett.



On Fri, Jul 22, 2011 at 12:25 PM, Erik Vos <eri...@xs...> wrote:
> Good, I have recloned the repository and done a few commits.  Seems to work
> so far.
> One thing is a bit curious: after the push I need to do a pull to get my
> local status fully updated (in Egit as well as in the GitBash CLI).
> I suppose that's the way it is...
>
> So far I have only worked in and committed to the master branch. I suppose
> that's part of why I got into problems earlier.  I probably need to educate
> myself on this aspect....
>
>
> The commits revert Brett's Tag change that have I protested against, and I
> have added some hopefully helpful comments to clarify the original code.
>
> I have also found why that code exists in Tag.  The game option
> "UnlimitedTopTrains" is parametrized with a value "D" to allow it to be
> displayed as "Unlimited D-trains".
> This way we don't need a separate name and corresponding entry in
> LocalizedText.properties for each different train type for which that option
> is used.
>
> To make that parameter persistent, this option is saved with the name
> "UnlimitedTopTrains_D". To find its value, the code must therefore find a
> saved option name that starts with the unparametrized name, and that's what
> happens in that code.  So it's not obsolete at all.
>
> And if this code does find a value, the 'if' condition value has changed
> between its first and second check, so these ifs cannot be merged.
>
> Erik.
>
>> -----Original Message-----
>> From: brett lentz [mailto:bre...@gm...]
>> Sent: Thursday, July 21, 2011 8:00 PM
>> To: Development list for Rails: an 18xx game
>> Subject: Re: [Rails-devel] Git troubleshooting
>>
>> Ok... I've made a few small commits with EGit, and I think I'm getting the
>> hang of the interface. It's a bit clumsy, but it seems to do everything I
> expect.
>> The EGit user guide is a fairly lengthy document, but as Stefan noted
> earlier,
>> it's got a lot of important details that will help you learn the
> interface:
>> http://wiki.eclipse.org/EGit/User_Guide
>>
>> I think everyone should probably take a step back. I have a feeling we
> tried
>> to run before we learned to walk. ;-)
>>
>> Set aside the work you've done, do a clean clone of the repo in a new
>> location following the EGit User Guide. Then, find some small one-line
>> change to make. Commit it, push it, as directed by the User Guide.
>> Let's try to get everyone to commit and successfully push a few small
>> changes before we try to bite off anything bigger. Once we've got a few
>> pushes and pulls done, we can come back to the bigger pieces of work that
>> are being done.
>>
>> Next...
>>
>> Also, in your git configs (usually a .gitconfig file in your home
> directory), it's
>> very handy to default to always rebasing incoming changes. Merge commits
>> are supposed to be meaningful, but the default behavior is to always merge
>> incoming changes (and create a merge commit for them). The tradeoff here
>> is that rebasing changes the commit history, which is potentially
> dangerous
>> and less obvious than adding a bunch of extraneous merge commits every
>> time you do a pull.
>>
>> You can configure certain branches to always do this without the --rebase
>> flag:
>>
>> # make `git pull` on master always use rebase $ git config
>> branch.master.rebase true You can also set up a global option to set the
> last
>> property for every new tracked branch:
>>
>> # setup rebase for every tracking branch $ git config --global
>> branch.autosetuprebase always
>>
>> The .gitconfig is an ini-style file, so the above is also represented as
> this if you
>> want to update the file directly:
>>
>> [branch]
>>    autosetuprebase = always
>>
>>
>> Finally...
>>
>> I'm happy to continue lending support as y'all run into troubles. It took
> me a
>> while to fully acclimate to Git's workflow, too. It's different, but very
>> powerful once we get past the first few hurdles.
>> :-)
>>
>> ---Brett.
>>
>>
> ----------------------------------------------------------------------------
> --
>> 5 Ways to Improve & Secure Unified Communications Unified
>> Communications promises greater efficiencies for business. UC can improve
>> internal communications as well as offer faster, more efficient ways to
>> interact with customers and streamline customer service. Learn more!
>> http://www.accelacomm.com/jaw/sfnl/114/51426253/
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
> 10 Tips for Better Web Security
> Learn 10 ways to better secure your business today. Topics covered include:
> Web security, SSL, hacker attacks & Denial of Service (DoS), private keys,
> security Microsoft Exchange, secure Instant Messaging, and much more.
> http://www.accelacomm.com/jaw/sfnl/114/51426210/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Git troubleshooting

[Stefan F. <ste...@we...>]

Even after the few days I love the easy switch between branches. It is much 
easier to simply test if things worked before your change, how the code looked 
like at the latest tag etc. Overall I can already see an improvement.

And I agree that it seems a bit strange that egit pretends to not knowing that 
the remote repo you pushed to is not at the same commit like the repo you 
pushed from and you still have to pull from there to get that information.

One observation for egit however is: If there is uncommitted code in a branch 
and you switch to another branch where the local changes are compatible (thus 
the files you edited have the same version in the two branches) the local 
changes simply carry over. 
Only after a commit before the switch the files revert to the state of the 
other branch as expected.

It makes sense from a git point of view, but it still can surprise you first.
If the files you have edited in the other branch are not compatible egit 
raises a warning, that the switch will delete your local uncommitted changes.

Stefan


On Friday, July 22, 2011 09:49:41 pm brett lentz wrote:
> That makes a *lot* more sense.
> 
> I suspect there's probably an easier way to achieve the same result,
> but I'll save that for a later discussion. ;-)
> 
> I'm happy to see the issues with Git are starting to be sorted out. It
> sounds like the Windows implementation is lagging behind the other
> platforms, but is still usable.
> 
> ---Brett.
> 
> On Fri, Jul 22, 2011 at 12:25 PM, Erik Vos <eri...@xs...> wrote:
> > Good, I have recloned the repository and done a few commits.  Seems to
> > work so far.
> > One thing is a bit curious: after the push I need to do a pull to get my
> > local status fully updated (in Egit as well as in the GitBash CLI).
> > I suppose that's the way it is...
> > 
> > So far I have only worked in and committed to the master branch. I
> > suppose that's part of why I got into problems earlier.  I probably need
> > to educate myself on this aspect....
> > 
> > 
> > The commits revert Brett's Tag change that have I protested against, and
> > I have added some hopefully helpful comments to clarify the original
> > code.
> > 
> > I have also found why that code exists in Tag.  The game option
> > "UnlimitedTopTrains" is parametrized with a value "D" to allow it to be
> > displayed as "Unlimited D-trains".
> > This way we don't need a separate name and corresponding entry in
> > LocalizedText.properties for each different train type for which that
> > option is used.
> > 
> > To make that parameter persistent, this option is saved with the name
> > "UnlimitedTopTrains_D". To find its value, the code must therefore find a
> > saved option name that starts with the unparametrized name, and that's
> > what happens in that code.  So it's not obsolete at all.
> > 
> > And if this code does find a value, the 'if' condition value has changed
> > between its first and second check, so these ifs cannot be merged.
> > 
> > Erik.
> > 
> >> -----Original Message-----
> >> From: brett lentz [mailto:bre...@gm...]
> >> Sent: Thursday, July 21, 2011 8:00 PM
> >> To: Development list for Rails: an 18xx game
> >> Subject: Re: [Rails-devel] Git troubleshooting
> >> 
> >> Ok... I've made a few small commits with EGit, and I think I'm getting
> >> the hang of the interface. It's a bit clumsy, but it seems to do
> >> everything I
> > 
> > expect.
> > 
> >> The EGit user guide is a fairly lengthy document, but as Stefan noted
> > 
> > earlier,
> > 
> >> it's got a lot of important details that will help you learn the
> > 
> > interface:
> >> http://wiki.eclipse.org/EGit/User_Guide
> >> 
> >> I think everyone should probably take a step back. I have a feeling we
> > 
> > tried
> > 
> >> to run before we learned to walk. ;-)
> >> 
> >> Set aside the work you've done, do a clean clone of the repo in a new
> >> location following the EGit User Guide. Then, find some small one-line
> >> change to make. Commit it, push it, as directed by the User Guide.
> >> Let's try to get everyone to commit and successfully push a few small
> >> changes before we try to bite off anything bigger. Once we've got a few
> >> pushes and pulls done, we can come back to the bigger pieces of work
> >> that are being done.
> >> 
> >> Next...
> >> 
> >> Also, in your git configs (usually a .gitconfig file in your home
> > 
> > directory), it's
> > 
> >> very handy to default to always rebasing incoming changes. Merge commits
> >> are supposed to be meaningful, but the default behavior is to always
> >> merge incoming changes (and create a merge commit for them). The
> >> tradeoff here is that rebasing changes the commit history, which is
> >> potentially
> > 
> > dangerous
> > 
> >> and less obvious than adding a bunch of extraneous merge commits every
> >> time you do a pull.
> >> 
> >> You can configure certain branches to always do this without the
> >> --rebase flag:
> >> 
> >> # make `git pull` on master always use rebase $ git config
> >> branch.master.rebase true You can also set up a global option to set the
> > 
> > last
> > 
> >> property for every new tracked branch:
> >> 
> >> # setup rebase for every tracking branch $ git config --global
> >> branch.autosetuprebase always
> >> 
> >> The .gitconfig is an ini-style file, so the above is also represented as
> > 
> > this if you
> > 
> >> want to update the file directly:
> >> 
> >> [branch]
> >>    autosetuprebase = always
> >> 
> >> 
> >> Finally...
> >> 
> >> I'm happy to continue lending support as y'all run into troubles. It
> >> took
> > 
> > me a
> > 
> >> while to fully acclimate to Git's workflow, too. It's different, but
> >> very powerful once we get past the first few hurdles.
> >> 
> >> :-)
> >> 
> >> ---Brett.
> > 
> > -------------------------------------------------------------------------
> > --- --
> > 
> >> 5 Ways to Improve & Secure Unified Communications Unified
> >> Communications promises greater efficiencies for business. UC can
> >> improve internal communications as well as offer faster, more efficient
> >> ways to interact with customers and streamline customer service. Learn
> >> more! http://www.accelacomm.com/jaw/sfnl/114/51426253/
> >> _______________________________________________
> >> Rails-devel mailing list
> >> Rai...@li...
> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> > 
> > -------------------------------------------------------------------------
> > ----- 10 Tips for Better Web Security
> > Learn 10 ways to better secure your business today. Topics covered
> > include: Web security, SSL, hacker attacks & Denial of Service (DoS),
> > private keys, security Microsoft Exchange, secure Instant Messaging, and
> > much more. http://www.accelacomm.com/jaw/sfnl/114/51426210/
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> ---------------------------------------------------------------------------
> --- 10 Tips for Better Web Security
> Learn 10 ways to better secure your business today. Topics covered include:
> Web security, SSL, hacker attacks & Denial of Service (DoS), private keys,
> security Microsoft Exchange, secure Instant Messaging, and much more.
> http://www.accelacomm.com/jaw/sfnl/114/51426210/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel