On Sun, Feb 06, 2011 at 04:40:26PM +1100, Michael G Schwern wrote:
> On 2011.2.4 1:39 PM, Aaron J. Grier wrote:
> > is there a knob for me to always default git merge to --no-commit ?
[...]
> The real solution is to allow users to make errors, but quickly and
> easily detect and undo them. Thus, e
* Piers Cawley [2011-02-08 17:10]:
> On Mon, Feb 7, 2011 at 12:48 PM, Aristotle Pagaltzis wrote:
> >* Philippe Bruhat (BooK) [2011-02-07 09:50]:
> >>> You probably want this instead:
> >>>
> >>> git stash
> >>> git reset --hard HEAD^
> >>> git stash pop
> >>>
> >>> THIS is a git undo
On Mon, Feb 7, 2011 at 12:48 PM, Aristotle Pagaltzis wrote:
* Philippe Bruhat (BooK) [2011-02-07 09:50]:
> You probably want this instead:
>
> git stash
> git reset --hard HEAD^
> git stash pop
>
> THIS is a git undo button.
--mixed
Resets the index but not the working tre
On Mon, 07 Feb 2011 08:17:41 -0500, Numien wrote:
> On 02/07/2011 08:11 AM, Gert Doering wrote:
> > On Mon, Feb 07, 2011 at 10:44:46AM +, Nicholas Clark wrote:
> >> So it's time for Apple to write a version control system?
> >
> > Now that would be quite definite on the policy side of things.
On 02/07/2011 08:11 AM, Gert Doering wrote:
On Mon, Feb 07, 2011 at 10:44:46AM +, Nicholas Clark wrote:
So it's time for Apple to write a version control system?
Now that would be quite definite on the policy side of things.
OTOH, I wouldn't really like to be required to register at iTune
Hi,
On Mon, Feb 07, 2011 at 10:44:46AM +, Nicholas Clark wrote:
> So it's time for Apple to write a version control system?
Now that would be quite definite on the policy side of things.
OTOH, I wouldn't really like to be required to register at iTunes and
present a credit card before being
On 2011-02-06, at 04:10, Aristotle Pagaltzis wrote:
You probably want this instead:
git stash
git reset --hard HEAD^
git stash pop
It will move your HEAD ref back one commit and throw away the
changes from that commit, but will preserve any delta between it
and your working copy. If to
* Philippe Bruhat (BooK) [2011-02-07 09:50]:
> > You probably want this instead:
> >
> > git stash
> > git reset --hard HEAD^
> > git stash pop
> >
> > THIS is a git undo button.
>
> --mixed
> Resets the index but not the working tree (i.e., the
> changed files are preser
On Mon, Feb 07, 2011 at 10:44:46AM +, Nicholas Clark wrote:
[...]
> So it's time for Apple to write a version control system? At least that
> would have a consistent way to do it. :-)
Apple's XCode IDE currently supports CVS, Perforce and Subversion. Given the
relative similarity between those
On Mon, Feb 07, 2011 at 01:02:13AM +, Simon Wistow wrote:
[...]
> Part of the problem is that, as Nick mentioned, there's more than one way
> to do it. But the ways are generally mutually exclusive so at each company
> you go to you have to learn what their work flow is.
So git just defines me
On Mon, Feb 07, 2011 at 10:42:02AM +, Peter Corlett wrote:
> On Mon, Feb 07, 2011 at 01:02:13AM +, Simon Wistow wrote:
> [...]
> > Part of the problem is that, as Nick mentioned, there's more than one way
> > to do it. But the ways are generally mutually exclusive so at each company
> > you
On Mon, Feb 07, 2011 at 01:02:13AM +, Simon Wistow wrote:
> Sure it's nice sometimes to work offline (although how many times am I
> *actually* off line). But, you know, I had SVK for that and that worked
> fine.
>
> But seriously - I encounter more problems every week with Git than I
> th
On Sun, Feb 06, 2011 at 11:10:18AM +0100, Aristotle Pagaltzis wrote:
> * Michael G Schwern [2011-02-06 06:45]:
> > Here is your git undo button.
> >
> > [alias]
> > undo = reset --hard HEAD^
>
> Except for the `--hard`, which will throw away changes in the
> only place where git cannot recove
On Sun, Feb 06, 2011 at 03:19:21PM +0100, Marco Von Ballmoos said:
> I would have said exactly the same thing before I learned git, but
> you're missing out. It's worth learning, but it's hateful for making
> itself seem so intimidating -- and for including so few safeguards or,
> at the very le
On Sun, Feb 06, 2011 at 08:13:21PM +0100, Jarkko Hietaniemi wrote:
> On Sun, Feb 6, 2011 at 8:11 PM, Aristotle Pagaltzis wrote:
> > * Jarkko Hietaniemi [2011-02-06 11:15]:
> >> You know, it's gobbledygook like the below that makes me stay
> >> away from learning git.
> >
> > And using what instea
* Jarkko Hietaniemi [2011-02-06 11:15]:
> You know, it's gobbledygook like the below that makes me stay
> away from learning git.
And using what instead?
On Sun, Feb 6, 2011 at 8:11 PM, Aristotle Pagaltzis wrote:
> * Jarkko Hietaniemi [2011-02-06 11:15]:
>> You know, it's gobbledygook like the below that makes me stay
>> away from learning git.
>
> And using what instead?
For the past years, mostly perforce. I must be too steeped in sin
because
On Sun, Feb 6, 2011 at 7:54 PM, David Parsons wrote:
On Feb 6, 2011, at 2:13 AM, Jarkko Hietaniemi wrote:
You know, it's gobbledygook like the below that makes me stay away
from learning git.
Well, you can just ignore it. There is a pretty good SCCS in
there[*] if you peel away sever
On Feb 6, 2011, at 2:13 AM, Jarkko Hietaniemi wrote:
You know, it's gobbledygook like the below that makes me stay away
from learning git.
Well, you can just ignore it. There is a pretty good SCCS in
there[*] if you peel away several layers of self-indulgent chrome
and features fo
* Marco Von Ballmoos [2011-02-06 15:25]:
> It's nice to know that you never lose changes, but if you can't
> find them or dig them out and apply them to your branch,
> they're as good as gone to you anyway.
Yeah. I think this needs to be advertised much more loudly than
it is. One of my highest-v
On Sun, Feb 06, 2011 at 11:13:35AM +0100, Jarkko Hietaniemi wrote:
> You know, it's gobbledygook like the below that makes me stay away
> from learning git.
It's somewhat like Perl, in that "there's more than one way to do it" and
"make hard things possible". Unfortunately it missed the "make easy
On Feb 6, 2011, at 11:13 AM, Jarkko Hietaniemi wrote:
You know, it's gobbledygook like the below that makes me stay away
from learning git.
I would have said exactly the same thing before I learned git, but you're
missing out. It's worth learning, but it's hateful for making itself seem so
i
* Michael G Schwern [2011-02-06 06:45]:
> Here is your git undo button.
>
> [alias]
> undo = reset --hard HEAD^
Except for the `--hard`, which will throw away changes in the
only place where git cannot recover them: the working copy.
You probably want this instead:
git stash
git res
You know, it's gobbledygook like the below that makes me stay away
from learning git.
On Sun, Feb 6, 2011 at 11:10 AM, Aristotle Pagaltzis wrote:
* Michael G Schwern [2011-02-06 06:45]:
Here is your git undo button.
[alias]
undo = reset --hard HEAD^
Except for the `--hard`, which will
On 2011.2.4 1:39 PM, Aaron J. Grier wrote:
> is there a knob for me to always default git merge to --no-commit ?
Software and systems which try to prevent errors are hateful. They come from
the failed assumption that the user and system will realize they're going to
make an error BEFORE they make
On Thu, Feb 03, 2011 at 06:39:38PM -0800, Aaron J. Grier wrote:
[...]
> is there a knob for me to always default git merge to --no-commit ?
You can do "man git-config" just as easily as we can.
On Thu, Feb 03, 2011 at 08:31:13PM +, Peter Corlett wrote:
> Branching is trivial. It's a fancy name for copy-and-paste.
>
> Taking the many copies that have now been hacked upon in a random
> manner and consolidating them back into something coherent? That's a
> little bit harder.
PRCS defer
On Thu, Feb 03, 2011 at 12:10:46PM -0800, Aaron J. Grier wrote:
[...]
> PRCS also branched well. it was full of its own hate, including local-only
> access (no split client / server over a network), and some scrotty C++
> code that I had to patch as libstdc++ was updated. but the branching was
> gr
On Fri, Jan 28, 2011 at 04:29:21PM +, James Laver wrote:
> On Fri, Jan 28, 2011 at 03:40:45PM +, Neil Brewitt wrote:
> > Branches a tool not a hinderance
>
> You would again do well to educate yourself about git. It does
> branches better than any other VCS.
PRCS also branched well. it w
On 2011.1.29 10:44 PM, Nicholas Clark wrote:
> I can't remember what perforce does in such situations.
That's part of the healing process.
--
29. The Irish MPs are not after "Me frosted lucky charms".
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
http://ski
On Sat, Jan 29, 2011 at 06:04:42PM +1000, Michael G Schwern wrote:
> What were they doing wrong? They were using Subversion before 2008 when they
> introduced built in (and rather lame) merge tracking in 1.5. SVN existed for
> SEVEN YEARS with easy branching but difficult merging. You had to tr
On 2011.1.28 5:15 PM, H.Merijn Brand wrote:
> On Fri, 28 Jan 2011 10:03:10 +1000, Michael G Schwern
>> 1972 SCCSThe first version control system
>
> We actively used SCCS up to 2009.
Sometimes I think you work in a computer museum, but nobody told you. ;)
>> 1982 RCS The first vaguely s
On Jan 28, 2011, at 9:26 AM, David Parsons wrote:
CVS is a extra-special little snowflake. Personally, I found
that switching from CVS to "burn a nightly copy of the development
tree onto a CD" paid for itself pretty quickly, so I couldn't see
Perforce actually losing that race unless
On Jan 28, 2011, at 6:26 PM, Peter Corlett wrote:
On Fri, Jan 28, 2011 at 03:40:45PM +, Neil Brewitt wrote:
[...]
I did write a reasoned and detailed and sane response to you but when I
saw this, I lost patience and decided that you're just trolling to cover
up your own ignorance. PS Config
On Sat, Jan 29, 2011 at 01:02:09AM +0100, Abigail wrote:
[...]
> Tests are software as well. "It passes all tests" doesn't mean much.
I like to see a test fail at least once before I trust it to be a useful
indicator that some code now sucks less hard than before.
I hate software. If I wasn't rub
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/28/11 1:44 PM, Gerry Lawrence wrote:
> We were holding off on Clearcase because even the memory of it dredges
> up a soul crippling pain and agony, much like having the skin pulled of
> your body with little hooks.
>
> And that's after 10 years o
>
> On Jan 28, 2011, at 7:40 AM, Neil Brewitt wrote:
>
> I'm surprised that Clearcase hasn't gotten its own pile of
> love here. Sure, git and all of the other bitkeeper clones
> are their own tiny special snowflakes that you need to go to
> reeducation camp before you can be made pure en
On Fri, Jan 28, 2011 at 09:58:14AM +, Nicholas Clark wrote:
> On Fri, Jan 28, 2011 at 10:33:22AM +1000, Michael G Schwern wrote:
> > And I've used Aegis. I've CHAMPIONED Aegis. This was version control
> > DESIGNED around code reviews. You could not make a commit unless it built
> > ok,
> >
On Fri, 2011-01-28 at 09:58 +, Nicholas Clark wrote:
> On Fri, Jan 28, 2011 at 10:33:22AM +1000, Michael G Schwern wrote:
>
> > And I've used Aegis. I've CHAMPIONED Aegis. This was version control
> > DESIGNED around code reviews. You could not make a commit unless it built
> > ok,
> > add
Michael G Schwern wrote:
1986 CVS Now people can work on multiple files AT THE SAME TIME
1990 CVS adds branching
I recently read http://www.cs.vu.nl/~dick/CVS.html#History which
describes the early history of CVS. I found it striking that (a) it
was designed for a team of on
On Fri, 2011-01-28 at 12:59 +, David Cantrell wrote:
On Fri, Jan 28, 2011 at 10:03:10AM +1000, Michael G Schwern wrote:
> I give a lightning a talk called "Subversion Lifetime Achievement Award", the
> premise of which is that if Subversion hadn't fixed the superficial flaws in
> CVS we neve
On Fri, Jan 28, 2011 at 10:03:10AM +1000, Michael G Schwern wrote:
> I give a lightning a talk called "Subversion Lifetime Achievement Award", the
> premise of which is that if Subversion hadn't fixed the superficial flaws in
> CVS we never would have seen the fundamental flaws in the model. Dist
On Fri, Jan 28, 2011 at 01:54:18PM +0100, H.Merijn Brand wrote:
[...]
> What I end up doing is installing a post-commit hook in svn to update my
> git clone, so I at least can find back what changed where and why.
Or you could have used git-svn which hides this gaffer tape for you.
On Fri, 28 Jan 2011 12:24:05 +, Tony Finch wrote:
> On Fri, 28 Jan 2011, H.Merijn Brand wrote:
> >
> > The *only* thing I liked about p4 was the GUI. Neither git (git-gui and
> > gitk are two different GUI's that should have been one with the *same*
> > look-and-feel) not svn (doesn't have an
On Fri, 28 Jan 2011, H.Merijn Brand wrote:
>
> The *only* thing I liked about p4 was the GUI. Neither git (git-gui and
> gitk are two different GUI's that should have been one with the *same*
> look-and-feel) not svn (doesn't have any sensible GUI at all!) come
> close to the user-friendlyness of p
On Fri, Jan 28, 2011 at 10:33:22AM +1000, Michael G Schwern wrote:
> And I've used Aegis. I've CHAMPIONED Aegis. This was version control
> DESIGNED around code reviews. You could not make a commit unless it built ok,
> added tests, passed tests and the previous revision failed the new tests.
On 2011.1.28 3:10 PM, Marco Von Ballmoos wrote:
> (2) I think it's great that you wrote it, though, because it's quite nice
> and says what needs to be said for those still stuck in an older mindset.
> Your fervor (and perhaps my more hesitant one) for the new mindset will
> only backfire on you if
On Fri, 28 Jan 2011 10:03:10 +1000, Michael G Schwern
wrote:
> On 2011.1.28 12:13 AM, Peter Corlett wrote:
> > Of course, when the only tool you have is CVS, any other version control
> > system lookslike a good idea. I suspect CVS was the result of a drunken bet
> > that it wasn't possible to ma
On 2011.1.27 11:59 PM, Neil Brewitt wrote:
> Thanks for a sensible response. To be clear - I wasn't comparing with any
> other
> modern systems, just responding to the absolute slandering of a tool
You, sir, are on the wrong list.
--
Insulting our readers is part of our business model.
On 2011.1.28 4:22 AM, Marco Von Ballmoos wrote:
> We also use code reviews, so rolling back committed changes never really came
> up.
> Usually, problems were discovered only after several other commits had been
> made
> whereupon it was just easier to fix the fix and check in the new change rath
On 27 Jan 2011, at 14:47, Tony Finch wrote:
Oh man, and there was I thinking you were trying to be satirical.
I especially laughed at your advice on reverting changes.
"Boldly going forward 'cause we can't find reverse!"
Tony,
I'm always happy to present hard empirical data to hates-softwar
On Jan 27, 2011, at 3:47 PM, Tony Finch wrote:
On Thu, 27 Jan 2011, Neil Brewitt wrote:
Thanks for a sensible response. To be clear - I wasn't comparing with
any other modern systems, just responding to the absolute slandering of
a tool I've seen used very effectively by hundreds of very compe
On Thu, 27 Jan 2011, Neil Brewitt wrote:
>
> Thanks for a sensible response. To be clear - I wasn't comparing with
> any other modern systems, just responding to the absolute slandering of
> a tool I've seen used very effectively by hundreds of very competent
> developers.
Oh man, and there was I
On Fri, 2011-01-28 at 10:03 +1000, Michael G Schwern wrote:
> Of course you don't need branching, merging is hard so you've never branched.
> Of course you don't revert, reversions are hard so you don't revert. Of
> course you don't make tiny commits, every commit is inflicted on the whole
> proj
On 2011.1.28 12:13 AM, Peter Corlett wrote:
> Of course, when the only tool you have is CVS, any other version control
> system lookslike a good idea. I suspect CVS was the result of a drunken bet
> that it wasn't possible to make RCS worse.
I give a lightning a talk called "Subversion Lifetime Ac
On Thu, Jan 27, 2011 at 01:59:49PM +, Neil Brewitt wrote:
[...]
> Thanks for a sensible response. To be clear - I wasn't comparing with any
> other modern systems, just responding to the absolute slandering of a tool
> I've seen used very effectively by hundreds of very competent developers.
>
On 27 Jan 2011, at 12:50, Marco Von Ballmoos wrote:
On Jan 27, 2011, at 12:45 PM, Neil Brewitt wrote:
Nicholas,
Anyone who hates perforce is a victim of bad education or software religion.
I can't agree here. I'm a long-time user of Perforce as well and evangelized it
over other solutions
On 27 Jan 2011, at 11:49, Philip Newton wrote:
On Thu, Jan 27, 2011 at 12:45, Neil Brewitt wrote:
Reverts too difficult for you? Then don't revert changes. Use the software how
it's meant to be used.
Oh, right. I completely forgot that developers exist to serve tools
the way they're meant t
On Jan 27, 2011, at 12:45 PM, Neil Brewitt wrote:
Nicholas,
Anyone who hates perforce is a victim of bad education or software religion.
I can't agree here. I'm a long-time user of Perforce as well and evangelized it
over other solutions when it was still so clearly better. However, some of
On Thu, Jan 27, 2011 at 12:45, Neil Brewitt wrote:
> Reverts too difficult for you? Then don't revert changes. Use the software
> how it's meant to be used.
Oh, right. I completely forgot that developers exist to serve tools
the way they're meant to work, rather than developers getting tools
tha
Nicholas,
Anyone who hates perforce is a victim of bad education or software religion.
It's faster, it's safer, it's lighter. It just works.
Reverts too difficult for you? Then don't revert changes. Use the software how
it's meant to be used. In a live perforce install for twenty developers I
On Thu, Jan 27, 2011 at 01:55:34PM +1030, Martin Ebourne wrote:
> http://kb.perforce.com/article/14
>
> Yes the version control system that needs an entire chapter on how to
> revert a change, with multiple different possibilities depending how old
> the change is or whether it included new/delet
Somewhere on Shadow Earth, at Thu, Jan 27, 2011 at 12:19:28PM +1000, Michael G
Schwern wrote:
> On 2011.1.27 10:43 AM, Timothy Knox wrote:
> > Bonus hate: When I am refactoring software, I will sometimes rename a
> > variable or function or what-have-you. Before I submit the code to my
> > source
On 2011.1.27 10:43 AM, Timothy Knox wrote:
> Bonus hate: When I am refactoring software, I will sometimes rename a
> variable or function or what-have-you. Before I submit the code to my
> source repository, I'd like to ensure that I am not picking up any stray
> diffs (debugging changes, forgot to
Somewhere on Shadow Earth, at Wed, Jan 12, 2011 at 03:00:54PM +, Matthew
King wrote:
> GNU diff has an option described thusly:
>
> -I RE --ignore-matching-lines=RE
> Ignore changes whose lines all match RE.
>
> Fantastic, says you, now I can compare
To: Martin Ebourne
Cc:
Obhate mailing list software, clients, users, etc.
Matthew
On Thu, 13 Jan 2011 02:15:16 +1030, Martin Ebourne
wrote:
> On Wed, 2011-01-12 at 15:00 +, Matthew King wrote:
>> GNU diff has an option described thusly:
>>
>>-I RE --ignore-matching-lines=RE
>> Ignore changes whose lines all match RE.
>&
On Wed, 2011-01-12 at 15:00 +, Matthew King wrote:
> GNU diff has an option described thusly:
>
>-I RE --ignore-matching-lines=RE
> Ignore changes whose lines all match RE.
>
> Fantastic, says you, now I can compare two files and see only if lin
GNU diff has an option described thusly:
-I RE --ignore-matching-lines=RE
Ignore changes whose lines all match RE.
Fantastic, says you, now I can compare two files and see only if lines
which aren't comments differ by telling diff to ignore lines which
begin w
69 matches
Mail list logo
