Re: [Rails-devel] Branching (was: Rails 1.5.1 available)

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

The short answer: If the stash isn't the right tool, just commit the
work, then change branches.

The slightly longer answer:  As long as your changes remain
unpublished, you can do pretty much whatever you want to your change
history. Once it's published, if you revise the history, it screws up
everyone pulling from that tree. The big thing to remember is that git
cares about *history*, not individual files or bits of code or
anything else.

So, if you commit unfinished work to your local branch and want to
come back later and finish it...  you can, with 'git commit --amend'.

Also, many of git's commands have an "--interactive" flag that allows
you to get very fine grained about what stuff is committed in which
order.

---Brett.



On Tue, Oct 11, 2011 at 6:33 AM, Erik Vos <eri...@xs...> wrote:
> Small changes and fixes I'm currently doing directly in the master branch.
> For more substantial work I create local branches, that I merge into master
> before pushing to the repo.
>
> I have one problem with branching, though: you can't switch branches easily
> if you have uncommitted work.  And I don't like creating commits for small
> bits and pieces.
>
> I know you can use 'git stash' to put away uncommitted work (index
> included), but git stash does not seem to honour .gitignore.  Or perhaps its
> Egit's handling of 'git add'.
> Yesterday I tried stashing for the first time, and 'git stash pop' failed on
> 18xx.log files that are included in my ignore files. (I think these logs are
> created by JUnit test runs. Perhaps I have just badly configured my log
> location).
>
> At least one would expect that the index would be saved when switching
> branches, but that does not seem to be the case. And stashing is a hassle.
> This is my only major gripe with Git so far.
>
> Erik.
>
>> -----Original Message-----
>> From: Stefan Frey [mailto:ste...@we...]
>> > IMO, it's easier to leave master as the lineage of stable changes and
>> > do any new development in (usually local) branches that can be merged
>> > into the stable trunk when they're ready.
>> >
>> > In git, branches and tags are both very very cheap (and fast), unlike
>> > SVN. So, if you want to have all development happen in master, then
>> > branch off for stable releases, we can do that too.
>>
>> Substantial changes have still should be done inside separate branches,
> like
>> my start of refactoring some parts in the Rails 2.0 branch.
>> Stefan
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2d-oct
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>