[1+1=2]

OneAndOneIs2

Tines

In response to: A year of Convict Conditioning

Tines [Visitor]
Well I'm impressed xxx
PermalinkPermalink 09/24/14 @ 19:39
Raco

In response to: Linux != Windows feedback

Raco [Visitor]
Great article. Now someone should write "Ubuntu is not Linux".
PermalinkPermalink 08/02/13 @ 12:57
Rajeev

In response to: Linux != Windows feedback

Rajeev [Visitor]
I recently installed Ubuntu after reading a lot about Linux & this is my third re-install. I really liked the article. I am a computer guy at heart and have also written programs. But i am not geek, i don't have the brains for it. But i am very much in love with Linux & i am going to use it from now on. What i would like is that the developers think about non-technical & non-geeks like me to be able to install & use Linux without much help.
PermalinkPermalink 07/19/13 @ 12:54
Åke

In response to: All change: The first week

Åke [Visitor]
Best of luck with the new house and job! I hope you and your cat'll like it there!
PermalinkPermalink 07/12/13 @ 13:00
Victoria

In response to: All change: The first week

Victoria [Visitor]
Glad you and the cat are doing well.

(And thanks for the support!)
PermalinkPermalink 07/12/13 @ 00:31
Hari

In response to: All change: The first week

Hari [Member]
Wow, your life has changed a lot. And yes, I've read about your past changes of career too and hope this move works out well.
PermalinkPermalink 07/09/13 @ 10:27
oneandoneis2

In response to: All change: The first week

oneandoneis2 [Member]
Oh, I'm already on git-svn, but it's not proving quite as straightforward as I'd have liked - I'm still not clear on why. Possibly they've done something weird with their branches..

So far I've used the git checkout as a kind of read-only place to look through history. I'm hoping to move up to actually making commits with it soon, tho.
PermalinkPermalink 07/08/13 @ 12:35
Anonymous

In response to: All change: The first week

Anonymous [Visitor]
Use the git-svn tunnel to make your work easier. It's fully transparent, no one needs ever know that you run git on your workstation.
PermalinkPermalink 07/08/13 @ 12:26
CEDA-3

In response to: On a roll with Milla

CEDA-3 [Visitor]
Quite insightful. This has saved me hours of searching. Thanks for sharing.
PermalinkPermalink 06/28/13 @ 16:51
Bruce Dawson

In response to: Nothing to hide?

Bruce Dawson [Visitor]
The other problem with "nothing to hide" is that it ignores valid reasons that other people might have to hide things. Governments opress and push around and spy on all sorts of groups (muslims, pro-union activists, Martin Luther King, etc.) and privacy protections help to protect these people from unwarranted spying.

Remember McCarthy? He ruined the lives of many good people, and excessive government spying would have made him even more powerful.

There are legitimate reasons to want privacy. If we all take our privacy more seriously then we support those who need privacy more than we do.
PermalinkPermalink 06/25/13 @ 23:26
Hari

In response to: Nothing to hide?

Hari [Member]
Excellent post. Well, privacy is so important I cannot downplay its importance. You have expressed in words what we've always felt instinctively.

I feel the only way to protect our privacy is to decentralize government once and for all. It is something politicians will always oppose because they lose control, but really local self-government with limited jurisdiction and the natural checks and balances of small-scale democracy is the only answer to the problem today.

Democracy at the large scale, where government is large and all-encompassing is nothing but Authoritarianism by the ballot system every four or five years.
PermalinkPermalink 06/14/13 @ 03:09
independent_forever

In response to: Nothing to hide?

independent_forever [Visitor]
well said...I am guilty of saying "I have nothing to hide" but what do you about a government which is simply disregarding and pushing aside our laws and making them up or changing them as they go? It's hard to combat such a behemoth by simply voting...what can people truly do to stop this insanity? People assume the American Revolution could only happen once...I'd say, a time may be coming and sooner than we think where revolution is possible and it will be our own government which precipitates it by its own irresponsible and tyrannical actions...hope I am wrong but it is a path we can definitely see at the moment. Let us all hope this country decides it a path they prefer to abandon. Peace~
PermalinkPermalink 06/11/13 @ 16:58
Carles

In response to: Nothing to hide?

Carles [Visitor]
I couldn't have said it better..
PermalinkPermalink 06/11/13 @ 01:40
oneandoneis2

In response to: Learning, interrupted

oneandoneis2 [Member]
@Hari - The theory was always fine, it was applying it by remembering the syntax and remembering the gotchas etc. that was the problem. Flashcards are almost as good as practical application, which makes them really good for situations where it's hard to do regular practical application.

@Terv - in this particular instance, it was the Head First book from O'Reilly, which I found to be a pretty good "C basics" book. I'm also partway through 21st Century C, K&R C, and one or two others.

It's possible that I may need to reduce the number of books I have in play at a given time, now I come to think of it :)
PermalinkPermalink 06/07/13 @ 12:16
Terv

In response to: Learning, interrupted

Terv [Visitor]
Out of curiosity, what book on C was that?
PermalinkPermalink 06/07/13 @ 12:06
hari

In response to: Learning, interrupted

hari [Visitor]
The only aid to memory is practical application of knowledge. Once you apply a particular piece of theory in practice, it stays long with you.

The problem with Haskell is that you seldom write actual everyday useful software with it. So much of the Haskell exercises seem like they are theory puzzles. If you get down and actually write a non-trivial app in Haskell, I bet your knowledge would grow rapidly and you won't find yourself needed to memorize things.

Also, that's how I learnt Python. Not theoritically but writing actual programs. Without practical application of knowledge, theory tends to fade away from the deep recesses of memory and you need to keep re-learning.

I'm finding that true of most things, actually. As a lawyer, I can tell you memorizing statute books are tough unless you keep practising in that area of law regularly enough.
PermalinkPermalink 06/07/13 @ 10:31
Bachti

In response to: Linux != Windows feedback

Bachti [Visitor]
Thank you for this instructive and detailed article.

There is one thing where I disagree with you: I find Ctrl+X, Ctrl+C and Ctrl+V quite easy to remember (and "intuitive", if you want to say so), because C is in "copy", X looks like something crossed off and V like the sign for inserting something. And then all three letters are side by side on the keyboard which may have been the main reason for choosing them.
PermalinkPermalink 06/05/13 @ 14:39
Spencer Young

In response to: Linux != Windows feedback

Spencer Young [Visitor]
You totally got the point of the facts regarding users who change from Windows to Linux. Your article definitely has the required objectivity to inform about all facts you need to know about if you want to change to Linux. It’s not to convince anybody and it’s not even slightly offending.

Respectfully,

S.Y.
PermalinkPermalink 06/05/13 @ 12:40
sudobah

In response to: The helpful thing about Linux..

sudobah [Visitor]
Ah, how wonderously hard we work at being lazy. Definitally done this before.
PermalinkPermalink 06/02/13 @ 04:35
sulami

In response to: The helpful thing about Linux..

sulami [Visitor]
I usually do this to turn off my PC when already lying in bed.
PermalinkPermalink 05/29/13 @ 11:12
Manoj

In response to: Linux != Windows feedback

Manoj [Visitor]
Wow... what a explanation.. awesome awesome... great great examples..
PermalinkPermalink 05/24/13 @ 19:44
oneandoneis2

In response to: Git prompt: Tell me more

oneandoneis2 [Member]
..you appear to have forgotten the link you intended to add? :)
PermalinkPermalink 05/17/13 @ 08:41
oneandoneis2

In response to: Quicksort golf

oneandoneis2 [Member]
heh :) Nice
PermalinkPermalink 05/17/13 @ 08:41
Carlo

In response to: Git prompt: Tell me more

Carlo [Visitor]
Instead of writing a C prompt, you could give this a try, even if it's written in Python, it works pretty good for my needs.
PermalinkPermalink 05/17/13 @ 08:21
Francis

In response to: Quicksort golf

Francis [Visitor]
golf, you say?

sub quicksort {
@_ and return (
quicksort (grep { $_ < $_[0] } @_),
grep ({ $_ == $_[0] } @_),
quicksort (grep { $_ > $_[0] } @_)
);
();
}


I suppose that's technically at least four lines.
PermalinkPermalink 05/17/13 @ 00:39
oneandoneis2

In response to: Quicksort golf

oneandoneis2 [Member]
Misses the point a bit :P
PermalinkPermalink 05/16/13 @ 20:23
pdh

In response to: Quicksort golf

pdh [Visitor]
one line
sort @array
:p
PermalinkPermalink 05/16/13 @ 20:14
Chankey Pathak

In response to: Quicksort golf

Chankey Pathak [Visitor]
Good one. Perl is beautiful. I rember writing quicksort program in C and that went too big.
PermalinkPermalink 05/16/13 @ 17:43
oneandoneis2

In response to: Please, stay away from rebase

oneandoneis2 [Member]
@csirac2 - yeah, rebase -i to make things easier for somebody to pull your work is potentially what I'd do.

I'd draw a clear distinction between "rebasing because somebody else has changed the same code as you & you want to resolve the conflicts so nobody else has to" and "rebasing when somebody else has changes unrelated code and you're just doing it for the sake of it" though.

@everyone else - sorry, I'm tired of the constant cherry-picking of a single point I've made, removing all context, and then arguing with a point I'm not making. So whilst further (constructive) comments are welcome, I'm not going to be addressing further comments here. Catch me on irc if you really want to discuss - I'm 'djh' in #git

If you want to learn more about Git, I thoroughly recommend Pro Git
PermalinkPermalink 05/02/13 @ 08:40
Vincent Povirk

In response to: Please, stay away from rebase

Vincent Povirk [Visitor]
> rebasing made it look like dev B had ignored prior art and was therefore at fault, whereas a merge would have kept the history intact and made it apparent that both devs had done the Right Thing at the time.

It doesn't matter if it was the right thing at the time dev B wrote his patch. No one cares what the world was like when he wrote it, because the world has moved on since then. What matters is the state of the world when dev B published his code, and he had a responsibility to make sure it worked at that time. Had he done a merge, the reviewer might not have caught the problem, because that problem would have been introduced by a merge commit with no conflicts and would not have shown up in his patch.

> Completely disagree - you can & should "commit early, commit often" and that means committing incomplete code. You should NOT then rebase away all your intermediate steps - that's useful history that will allow somebody to track back and understand why a piece fo code is that way it is that you blow away for no reason other than some abstract "cleanliness"

You absolutely should squish any intermediate steps at which the project is broken, to make things easier for people who need to bisect the project later. Of course, ideally for a large feature you'd have some intermediate steps that DON'T BREAK THE PROJECT, which are useful for understanding your changeset and shouldn't be squished away.

> If you don't squash commits, you can look back and see that a year ago you went through a dozen iterations to fix a problem whereas this time you solved it in just one - yay progress! If you rebased last year's fix into one to "clean up" your interim steps, you've just lost all that useful knowledge.

I think this gets at the heart of the disagreement: when you read your project's history, you want something different from what we who prefer rebases want. You want a complete record of the project's history and every contributor's history, even if those contributors had to fix bugs, redesign their code, or make changes at a maintainer's request before publishing their code. The rebasers, however, are only interested in the history of the project as a whole and find the individual contributors' histories to be not just irrelevant but actually counter-productive. We don't care that you got better at avoiding false starts since last year; we just don't want to see your false starts in our bisects. Therefore, we ask people to throw away their mistakes, false starts, and original topology before publishing, so that we don't have such irrelevant and counter-productive information in our projects' histories.
PermalinkPermalink 05/01/13 @ 22:19
Remmelt

In response to: Please, stay away from rebase

Remmelt [Visitor]
Some thoughts.

1) I'm working on a team with seven members pushing to origin. If no-one would pull --rebase, this would quickly lead to a veritable spiderweb of branches. There is a trade off between some abstract "completeness" and a clean history line. There is value in knowing how you develop and how you improve over time, but - for us - at the cost of speed of development. For us, I fear your method would result in loads of branches, since we're also using the git flow method, resulting in a loss of overview (which means I would have to fix it...) How does this Keep It Simple?

2) In scrum theory, tasks should be small. In practice it's not always feasible to break things up into bite sized chunks. Tasks might take longer than a single day, sometimes even days. In the mean time, intermediate code is not pushed on the develop branch. This means that this intermediate code is not continuously integrated. Yes, code should be perfect the first time, and sometimes errors do sneak in. The CI evangelists tell me to push at least once a day or I'm not practicing "real" CI. It is not feasible to set up CI tracks for every developer, release and feature branch, besides develop.

This leads me to think that there is a middle road. Our current MO is pull --rebase so there is less overhead and more clearness in the branches department, especially on origin. Plus, we get the added benefit of having our code tested every night. For "features" we use branches. Feature branches could and probably should be used more often.

Still, an interesting look at rebasing. It's always good to think about why we do the things we do, find a good reason and stick with t or change if one cannot be found.
PermalinkPermalink 05/01/13 @ 21:37
csirac2

In response to: Please, stay away from rebase

csirac2 [Visitor]
FWIW I think Darren Garvey is completely correct. I rarely use git rebase -i on small internal stuff, but contributing to open-source projects seems to be where I find it most useful. You're in there because something is broken, it's code you use but are unfamiliar with, and it takes a bit of a journey to fix a problem and update the tests. This is git, we've been conditioning ourselves to commit more - hours or less between each commit! We no longer fear commits. Commits are our friends. I almost always commit working code, or working tests, but sometimes there's a lag between both working simultaneously - especially if I need to move away from the task for a while (for example).

However, for the sake of your pull request/patches getting accepted in a timley manner, you need the cleanest, simplest history that your newfound reviewers/collaborators can reasonably be subjected to.

I've certainly seen "your branch is too noisy, can you clean it up" type comments - but never have I seen anything to the effect of "your 3 commits have confusing dates, I'd rather all 8 original commits, including that revert and both merges please".

This should be a really clear case for rebase -i, especially in those situations where the final solution to a problem is much smaller in changes than the sum of the new contributor's exploratory journey - a journey which adds nothing for the reviewer, given that the mistakes or dead-ends are probably obvious noise to them.
PermalinkPermalink 05/01/13 @ 18:17
oneandoneis2

In response to: Please, stay away from rebase

oneandoneis2 [Member]
@Foo - I'm not going to sugar-coat it, what you describe is appallingly bad practice and you might as well stop bothering with a VCS if you're going to blow away your history like that. Seriously, it's that bad.
PermalinkPermalink 05/01/13 @ 17:35
oneandoneis2

In response to: Please, stay away from rebase

oneandoneis2 [Member]
> If you commit regularly then there will be incomplete commits in there..

So far so good

> ..that need rebasing.

Completely disagree - you can & should "commit early, commit often" and that means committing incomplete code. You should NOT then rebase away all your intermediate steps - that's useful history that will allow somebody to track back and understand why a piece fo code is that way it is that you blow away for no reason other than some abstract "cleanliness"

> committing regularly and rebasing later is a great way of seeing how you develop

No, it's the opposite - if you rebase away all the interim steps, you've just *lost* the ability to look back at how you developed.

If you don't squash commits, you can look back and see that a year ago you went through a dozen iterations to fix a problem whereas this time you solved it in just one - yay progress! If you rebased last year's fix into one to "clean up" your interim steps, you've just lost all that useful knowledge.

> no-one should have to wade through it on a public branch.

Again, the argument that seeing the sum total of a change is somehow difficult when it's in multiple commits: If you want a single at-a-glance "what changed", just get the diff between the start and the end - this is trivial. If you rebase all your commits into one, you can never break it back down again - this loses history and is bad.

Keep your options open: Keep your history.
PermalinkPermalink 05/01/13 @ 17:33
Foo

In response to: Please, stay away from rebase

Foo [Visitor]
I'm not sure to understand your ire with commit squashing in Git.

When I create a new feature in a program, I will create a new branch, do the work in small steps with a commit at each intermediate step, and then squash the intermediate commits into an "atomic" one that represents the feature I added. This makes sense functionally IMHO.
PermalinkPermalink 05/01/13 @ 17:09
Darren Garvey

In response to: Please, stay away from rebase

Darren Garvey [Visitor]
You have some valid points, but you've gone too far the other way to prove your point.

Rebasing is very useful, just don't abuse it. I think your arguments here are only valid for "git pull --rebase" and aren't at all relevant to "git rebase -i". That may have been your intention, but by the end of the post, you're talking about rebase in general.

You're arguing that a rebasing-heavy workflow is ignoring the awesome power that git branching / merging gives, but that's not always true. Git is also great for committing regularly. If you commit regularly then there will be incomplete commits in there that need rebasing. Sometimes I might split what initially looks like a controversial design decision into a separate commit and decide later (before pushing) that it's perfectly fine and the separate commit isn't necessary.

Other times, there are several design iterations in a commit history when developing something non-trivial. It's good to have that iteration saved in git and leave it on a branch somewhere, but no-one should have to wade through it on a public branch.

I guess this isn't a problem if you're always following a waterfall process, or never iterate an idea, or never make any mistakes, or never want to code first, ammend commit messages later.

> Don't fix the symptom by rebasing endlessly, figure out your problem. And you do have a problem, because not only are you writing crap code, but you're committing it as well!

You're using the wrong term there. What you should say is "but you're /pushing/ it as well". There's absolutely nothing wrong with committing broken or fugly code as long as you don't push it.* In fact, I find knowing I can rebase means that if I see a problem, I can fix it right there and then knowing I can move it away from my branch later. Being able to do partial commits isn't always appropriate.

Plus, committing regularly and rebasing later is a great way of seeing how you develop. Seeing that evidence and reorganising it is a really useful way of learning how to code in a more logical and partitioned way. Without rebase, I'd be basically using a subversion client that can branch and merge really well. IMHO, that's missing out on a whole load of heavenly glories.

* If you do it too often, then you're probably wasting time - "Screw up now, fix up later" - as you say. There are other times it's useful, eg. switching branches while in the middle of something else.
PermalinkPermalink 05/01/13 @ 17:04
oneandoneis2

In response to: Protip: Enable !$

oneandoneis2 [Member]
Depends on your setup - Alt-period may instead result in a ® being printed in your terminal.

It all depends what's set up to be your Meta key - sometimes Alt is, other times you need Esc.
PermalinkPermalink 05/01/13 @ 15:06
oneandoneis2

In response to: Please, stay away from rebase

oneandoneis2 [Member]
> I hope you don’t mind me chiming in so late

Not at all

> wouldn’t the timestamp then absolve dev B

Sure, if you want to put the onus onto the reviewer of trekking back through non-chronologically-ordered history every time they see a bug on the offchance that they find a justification for it. But the whole point of the "rebase for the reviewer" argument is that rebasing makes the reviewer's life easier.

> The fact that you consider a cleaner history not good enough reason...

No, you're missing my point: If you use git properly, you get a tidy history without needing to rebase. This comes back to the point I keep making: Rebasing is a crutch that stops you learning how to use git properly. I address this very clearly in the post.

I don't maintain a "messy but accurate" history. I maintain a tidy and accurate history. As can anyone else if they put down rebase long enough to learn how.

> perhaps if you actually illustrate how frequent rebasing is ... the product of bad coding

Seriously?

You honestly need me to explain why being able to write something right the first time is better than only being able to write something that then requires re-writing later?

Or why it's better to take off your muddy shoes before walking through the house than to walk across and then mop up afterwards?

Frequent rebasing is the mindset of "Screw up now, fix up later". It's unnecessary and it's more work than just doing it properly.
PermalinkPermalink 05/01/13 @ 15:02
sromanov

In response to: Protip: Enable !$

sromanov [Visitor]
>> Try pressing escape, then period.

Alt + period does the same trick, but is a bit faster, since you don't need to release Alt to cycle through list of last arguments
PermalinkPermalink 05/01/13 @ 14:45
Alfonso

In response to: Please, stay away from rebase

Alfonso [Visitor]
Hello, Dominic. I hope you don’t mind me chiming in so late after the discussion has died down…

I see the problem you illustrated in your last comment, but wouldn’t the timestamp then absolve dev B? Sure, the history makes it look like his changes were applied *after* dev A’s refactoring, but a quick glance at the timestamp reveals that his commit containing the $c call was written before the refactoring. It’s not as if rebase completely eradicated any evidence that it went down that way. In fact, what you call a flaw in rebase (the fact that the timestamp is preserved, even though a new commit date is created) actually provides the same “solution” to this problem as merge does: in both cases, you get to see when dev B’s offending commit was created. And like you said: a merge would not have avoided the inconsistency, so merge has nothing more than your preference going for it.

Your example also ignores the likeliness that a code reviewer in a team that allows rebasing (or even, you know, a reviewer who is aware of the existence of rebase and how commit histories work) will consider that a commit may have been rebased and thus will look for evidence of this. If you’re worried about someone *incorrectly accusing* dev B of being sloppy, then you don’t have a rebase/merge controversy, you have an ignorant ass making remarks based on a misread of the available information (information that is, again, available whether you rebase or merge).

You mischaracterize frequent rebasing when you compare it to “lying for no reason”. There is very good reason, for those of us who prefer to deliver a clean commit history. The fact that you consider a cleaner history not good enough reason is a question of personal preference, and while there is nothing inherently wrong with that opinion, it is just that—an opinion.

I also find your assertion that the frequent use of rebase is necessarily the product of problematic coding to be baseless and poisoning the well. And the last two paragraphs of your latest comment comprise a circular argument: frequent rebases are a sign that you don’t know what you’re doing, but you won’t know what you’re doing until you realize that frequent rebases are a sign that you don’t know what you’re doing. No disrespect, but perhaps if you actually illustrate how frequent rebasing is necessarily —or even very likely— the product of bad coding, then your assertion will cease to be conjecture and your last two paragraphs will at least have a way out of their little circle.

IMO, teams (or public repo admins) should determine what works best for their workflow, their philosophy, the nature of their project, and whether it will be public or not.
PermalinkPermalink 05/01/13 @ 14:33
Remmelt

In response to: Protip: Enable !$

Remmelt [Visitor]
Ouch. Sorry.
PermalinkPermalink 05/01/13 @ 14:14
oneandoneis2

In response to: Protip: Enable !$

oneandoneis2 [Member]
..like I mentioned in the post, you mean? :)
PermalinkPermalink 05/01/13 @ 13:57
Remmelt

In response to: Protip: Enable !$

Remmelt [Visitor]
Try pressing escape, then period.

This will insert the last argument from the last command at your cursor and is less key presses.
PermalinkPermalink 05/01/13 @ 13:00
oneandoneis2

In response to: Please, stay away from rebase

oneandoneis2 [Member]
Sigh.

Note to the people telling me I shouldn't advocate "banning" rebase - please read the post *I* wrote: the one that explicitly says that rebasing should be considered a "power tool" for experienced git users; not a tool used by people who don't understand it; and not a tool that should be removed.

@Alex: re. interactive rebase to squash commits for review - I'm very much against it. If the reviewer doesn't want the minutiae, he can just do something like "git diff start-commit end-commit". Squashing them with rebase destroys your ability to view the history atomically.

@Vincent - the "test your code before commit" is a possible solution for somebody who persistently commits buggy code and is trying to avoid it. Not something I would advocate the average user doing for every commit.

I stand by the "review your diff before commit" though - I've seen too many lousy commits caused by people who just commit everything without first making sure they know what they're about to commit. All manner of leaked TODO's, debugs, and outright "This should never have been committed" junk gets in because people don't look at their diff before committing it.

To the people who keep saying "rebasing isn't lying, it's just editing your commits" - this is on a par with saying "I wasn't lying, I just wasn't telling the truth". Rebasing says your work was based off a commit that it simply wasn't. Its entire raison d'etre is to lie about history.

A really simple example from my own experience: Our main code repo uses the Catalyst framework. A lot of stuff gets stored in $c->{stash}. Sometimes, enough is being called from it that somebody will do "$stash = $c->{stash}" as a micro-optimisation to cut down on typing.

So we had dev A set one function to use $stash, and he dutifully refactored all the code to remove the $c version - as is correct procedure to keep our code consistent.

And then there was dev B, who added a block of code to the same function, and used the $c call because that was what was in place when he wrote it.

Then when dev B came to merge his changes, he rebased it onto dev A's work. There were no clashes, as he was simply adding a new block.

He then sent his code into review & it got red-penned because he'd used $c->{stash} when he clearly should have used $stash - because that's what the rest of the function did, as could be clearly seen *in his own commit*

Sure, merging wouldn't have stopped the inconsistency from being introduced. But rebasing made it look like dev B had ignored prior art and was therefore at fault, whereas a merge would have kept the history intact and made it apparent that both devs had done the Right Thing at the time.

This is a trivial example that caused absolutely no actual bugs or problems. But it illustrates the point: Because history was re-written via rebase, it was no longer accurate.

Rebasing makes your history lie. That's how it works. It's what it does. It is a tool that exists specifically to allow you to make your history lie.

And as I point out in the post, the occasional lie for the right reasons is perfectly acceptable. Lying continually for no good reason is not.

Rebase when it makes sense to do so. Do not rebase when it doesn't. And until you know git well enough to be certain when rebasing does make sense, don't use it.

That last paragraph sums up the whole point of the post. Not "Never rebase", not "Rebase is always bad" - rebase is fine, when *used correctly*. It's just that most of the uses advocated for it are *not* correct, so until you can spot them, avoid them.
PermalinkPermalink 05/01/13 @ 09:28
Matt Briggs

In response to: Please, stay away from rebase

Matt Briggs [Visitor]
I work on a team of 14 devs, all committing to the same git repo. Without rebasing feature branches, the history is completely unreadable, a tangled mass of lines crossing over each other.

We always do --no-ff merges back to master after a rebase. this doesn't flatten the history, and gives a single merge commit that is revertable. (and also gives meaningful history). So instead of linear, things look more like this

|\
| |
| |
|/
|\
| |
I/


You still lose what point the code branched at the time the dev started working on it (in practice I don't think that is something I have ever cared about), but what you get is a readable history, even with the gigantic team.
PermalinkPermalink 05/01/13 @ 06:15
Matthew

In response to: Please, stay away from rebase

Matthew [Visitor]
Your argument about timestamps is flawed IMHO. Yes, rebasing doesn't preserve a chronological history, but this causing problems during bisection is a code smell itself. Your discussion implies that you noticed the issue pre-rebasing and are then bisecting a post-rebased tree. You should never, ever, ever be rebasing commits that have been pushed to production (which I'm assuming is the only environment from which you'll get bug reports of the form "things broke on Tuesday"). If you noticed a bug on a dev branch, your tests that detected this should give you the commit ID.
PermalinkPermalink 05/01/13 @ 05:41
Vincent Povirk

In response to: Please, stay away from rebase

Vincent Povirk [Visitor]
I agree that everyone should be using branches more.

"Test and review your code before you commit it!" This is a terrible idea because the other thing everyone should be using more is commits. I would say that, at a minimum, every time you have code that is known to do at least one thing correctly, and is different from the code that was in your repo, you should commit before you make any further changes. Otherwise, when you break that one thing that you knew worked, you won't have any diffs to consult when you're trying to figure out why.

Dividing your work into logical, small but self-contained steps is a very good thing, because that makes your changes easier to review, easier to understand, and (if they're truly self-contained) better for bisecting. Such things cannot always be easily split given a single diff; you may need some lines of code in intermediate stages that aren't exactly present in either version. And you may not be able to publish your changes until the patch set becomes fairly large; perhaps you're laying groundwork for a new feature but you won't be sure that your groundwork supports it well until that feature is almost done. What that means is that you can easily be in a situation where you have to go back and change something, and you need a rebase because splitting your changes doesn't make sense. (I'd argue that the threshold for that is 2 commits, because splitting requires me to duplicate work that I might do wrong the second time, and makes it difficult for me to test the intermediate versions.)

The so-called "timestamp problem" is a case of confusing UI. All commits, including rebased commits, have a correct and chronological commit timestamp (unless you manually change yours for some reason), but the author timestamp, which is preserved by rebase, tends to be shown more prominently. So that's not an inherent problem with rebase and could have been avoided with foreknowledge (but is imo a problem with the UI, not the users).

Here are some use cases for rebase you might not have considered:

* Contributing to a project that requires a linear history with small, self-contained commits, such as Wine. Obviously, rebase is required in this case, but then you have to ask whether such a requirement is sensible. I believe it is, because Wine regresses often (it has to, because we can't test every Windows program every time we want to make a commit, and they make a lot of assumptions about the API), and that means people bisect it often. Having a history filled with merges, large changes, or changes that are not self-contained would make the bisects more difficult and the results less useful for various reasons that I won't go into here.
* Contributing to a project that uses SVN. I will take your word that it's possible for SVN to branch and merge, but if you're a Git user you probably want to just use git-svn which demands a linear history when you try to push changes to it.
* Bisecting a merge of upstream into a true long-lived fork. If you have a bug that can only be tested in the fork, the only way to bisect is to rebase all of the changes in the merge (i.e. the right parent of the merge) on top of the previous revision of the fork (the left parent of the merge). Rebasing to update a long-lived fork is, of course, a terrible idea that causes all sorts of problems, so you have to do the rebase only when needed for a bisect.

Personally, I avoid "git pull" in all of its forms. To do updates I use:

$ git fetch
$ git merge --ff-only origin/master

But with an alias for merge --ff-only so I don't have to type that out all the time. I might be willing to support git pull if it could be made to do the equivalent.

Merge --ff-only will fail if I have local changes, committed or not. I can then decide what to do from there. Maybe the changes are in a feature branch that I forgot I had been working in, and the correct action is to commit anything remaining as a WIP and switch back to master. Maybe it's some debugging code I forgot I had left in place. Maybe it's a patch I had applied using 'git am' or reverted for testing. The odds of me actually remembering that my tree is dirty before I update are pretty low (the most common exception being updates following failed pushes), so there's no way I can prepare git ahead of time for that situation.

But my real problem with git pull (with or without --rebase) is that it hides things from users that can harm them later. If you have a local commit in your tree that you don't know about (you forgot, you did something stupid that you didn't know would produce a commit, or you don't know what a commit is because you're not a developer and you're just doing what you were told so you can test the latest version or a project or do a bisect or whatever), git pull will silently keep that commit around. (I say "silently". It actually does tell you, but the command succeeds, and git tends to tell you a lot of things that aren't important and/or have some obscure meaning that you only understand if you really know git. So people aren't going to notice that the output of 'git pull' is slightly different than it used to be, especially if they're not experienced with git.) If you're lucky, this will end when it conflicts, and maybe you'll even figure out how to resolve it without cloning again. If not, you will form the impression that git is a terrible and unreliable piece of software, and you'll never want to use it again. If you're unlucky, it'll cause some other problem that will be blamed on the project rather than the local update.

Sure, pull is fine if you know what you're doing, but we need to design guides and tutorials with new users in mind, some of whom will never bother to learn more. For those who do, fetch && fast-forward isn't a bad habit and at worst may be slightly less convenient than pull.
PermalinkPermalink 05/01/13 @ 03:23
Krzysztof Hasinski

In response to: Please, stay away from rebase

Krzysztof Hasinski [Visitor]
Linus himself mentioned that you shouldn't merge until you really mean it and know what you merge.

Editing history is an important part of git local commit functionality.

Timestamps aren't important as git maintains another set of timestamps which are rewritten when `rebase`ing.

Avoiding bad commits just to avoid rebases is ridiculous.

I say it again - editing LOCAL history is an important feature in git that makes it a great tool. You can experiment, test, save and rearrange your work so you push good code with clean history.

Avoiding rebases is similar to using subversion with better merges. This is git, use it! ;) If you never rebase and always merge it means you broke bisects, code reviews and basic readability.
PermalinkPermalink 05/01/13 @ 00:44
Mike Perdide

In response to: Please, stay away from rebase

Mike Perdide [Visitor]
I agree with you: branches are cheap, branches are awesome, let's use more of them! Yay! But that does not make it a could reason to dismiss pull/rebasing altogether.

The other argument against rebase you're giving is: your don't know what was added when. I disagree: that's what CommitDates are made for. In every repo I work on, if I want to know at which point some code was added to master, I just need to look at the history and the commit dates. I don't see where the trouble lies. The date a commit was originally authored is irrelevant: it's the date this commit came into production that is.

You write that although the history will be messy and convoluted, at least it won't be a pile of lies like what the "Bad Rebase Guys" are doing. What's the point of having a history you can't read? Having a clean history makes it easier to see when a commit came into production.

Rebasing common history is an absolute no-no, don't get me wrong. But rebasing your commits on top of the current master before making a pull request is a courtesy to the dev who is going to review and merge your code. Why should he be the one to solve cataclysmic conflicts in dozens of files, just because you started a branch months ago and didn't keep up with the common work?

A clean history is a great tool to look back on a project, and rebasing is a part of that.

(FYI, our team works with branches and pull requests, and the merger does a pull --rebase on his master, then a git merge --no-ff of the branch, before pushing. That way all the commits related to a branch/feature are separated from the rest when displayed in a graphical history viewer).
PermalinkPermalink 05/01/13 @ 00:02
Braden Shepherdson

In response to: Please, stay away from rebase

Braden Shepherdson [Visitor]
Chronological order matters less than you think. Git log shows commits in their order of committing to the repo (aka topological order, following the parent chain), which is precisely what you want when you're looking for good and bad commits from Tuesday. git log --before and friends use the commit time, not the authorship timestamp that git log prints. Try it.

You could use git log --before=<1am Wednesday> and git log --before=<1am Tuesday> to get good and bad commits to feed to git bisect. Just ignore their timestamps.

I will concede that seeing the inconsistent timestamps is annoying, and I don't know why one can't pass an option to git log so it will show the commit times too/instead. Git's user interface leaves a lot to be desired, film at 11.

Rebase is a useful tool and this weakness is not enough to be worth banning it. It helps when dusting off old pull requests and experimental branches, and when squashing multiple commits to keep them complete and self-contained. It's not necessary, but I fail to be convinced that the timestamp quirk makes them worth banning to the arcane fringes of use.
PermalinkPermalink 04/30/13 @ 23:32

[Links][icon] My links

[Icon][Icon]About Me

[Icon][Icon]About this blog

[Icon][Icon]My /. profile

[Icon][Icon]My Wishlist

[Icon]MyCommerce

[FSF Associate Member]


April 2017
Mon Tue Wed Thu Fri Sat Sun
 << <   > >>
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30

Search

User tools

XML Feeds

eXTReMe Tracker

Valid XHTML 1.0 Transitional

Valid CSS!

[Valid RSS feed]

powered by b2evolution free blog software