Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Well, the way they apply patches sucks.

    Apparently just doing a simple fast forward merge is not cool enough, so a cherry pick with a signoff is done instead, meaning that your contributer now has to do a git reset --hard or they will run git pull and accidentally create a merge commit merging their changes with... you guessed it, their changes. Great =P

    Please just use git remote add foo git://github.com/foo/project.git and then git remote update and git merge. It's just as easy, and actually works.

    • You seem to be assuming you're always going to be pulling in all their changes, in which case a merge might be better, but otherwise a cherry-pick and sign off is correct. They could detect that you're asking for all changes and do a merge, sounds like simple a feature request to me. And hey, here it is [github.com].

      Worrying about the fiddly technical details of how they do their merge, fiddly technical details which could change tomorrow, fiddly technical details which really don't have that big an impact, is missing

      • fiddly technical details is an understatement. anybody who wants to contribute a simple patch will need to learn how to use one of git's scariest commands the next time they try to contribute.

        At least in my experience cherry picks are definitely *not* the common behavior.

        Thus only real use the fork queue has is to list the pending commits, and for that git log --decorate --all is at least IMHO more useful (well, actually I use gitx for that, but whatever).

        • You're the first I've heard mention this problem, and I cherry pick all the time. *shrug*