linux-kernel - Re: Git training wheels for the pimple faced maintainer

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 20 Oct 2006 08:34:54 +0200
From:	Pierre Ossman <drzeus-list@...eus.cx>
To:	Linus Torvalds <torvalds@...l.org>
CC:	Andrew Morton <akpm@...l.org>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: Git training wheels for the pimple faced maintainer

Linus Torvalds wrote:
> That all sounds fine. Please just check the format for the "[GIT PULL]" 
> message: Andrew pulls peoples trees on his own and largely automatically, 
> so he doesn't much care _what_ is in the tree, but I care deeply. So I 
> want the diffstat and shortlog listings, and preferably a few sentences at 
> the top of the email describing what's going on and why things are 
> happening.
>   

I'm still learning the more fancy parts of git, but I think that would be:

git diff master..for-linus | diffstat
git log master..for-list | git shortlog

right?

> I think people have seen the messages that other people send out (eg at 
> least Greg KH tends to Cc: those messages to linux-kernel, so others can 
> see what's going on too - although not all other maintainers do that).
>
> Basically, I want to know that the thing I pull makes sense for the stage 
> I'm pulling in (ie if it's after -rc1, think about trying to explain why 
> the fixes are all important bug-fixes for example), and what it affects. 
> The diffstat is part of that, but please include any other explanations 
> that seem meaningful.
>
>   

That was the basic idea. I've been looking at these kinds of messages on
LKML, trying to deduce how people do their work.

> So there's simply no point in merging from me, unless you know that there 
> are clashes due to other development, and you actually want to fix them 
> up. You will just cause unnecessary criss-cross merges if you pull from my 
> tree after you've started development, and the history gets really really 
> messy.
>   

And in order to test for conflicts, I assume I should have a "test tree"
that I merge all my local stuff in, together with your current HEAD?

> There's several ways to handle this:
>
>  - just base your work on a certain release, and ignore all the other 
>    changes. Then, when you're ready, just ask me to pull your changes. git 
>    will just merge it up to my current version, and everything will be 
>    fine. 
>
>    (Of course, once I _have_ merged your changes, if you pull at that 
>    point, you'll just fast-forward, and there will be no unnecessary 
>    back-and-forth merging)
>
>  - If you actually want your development tree to "track" my tree, I'd 
>    suggest you have your "for-linus" branch that you put the work you want 
>    to track into, and then a plain "linus" branch which tracks _my_ tree. 
>    Then you can just fetch my tree (to keep your "linus" branch 
>    up-to-date), and if you want your development branch to track those 
>    changes, you can just do a "git rebase linus" in your "for-linus" 
>    branch.
>   

If I've understood git correctly, a rebase is a big no-no once I've
published those changes as it reverts some history. Right?

>  - If you actually notice that the stuff in my tree conflicts with the 
>    stuff you develop, _then_ you obviously want to merge (you can try to 
>    "rebase" things too and fix it up durign the rebase, but merging is 
>    often easier, and at this point the merge is no longer "unnecessary 
>    noise", it's actually a real action of you doing a real merge to handle 
>    the conflict.
>
> And hey, if there is occasionally an unnecessary merge, nobody really 
> cares. So don't be _too_ worried about it. But a clean history makes 
> things simpler to track, so I'm asking people to not generate noise that 
> simply doesn't help.
>   

A load of my mind. ;)

Big thanks for all the pointers. I have my account at kernel.org, so it
won't be long until my first [GIT PULL]. Be gentle.

Rgds

-- 
     -- Pierre Ossman

  Linux kernel, MMC maintainer        http://www.kernel.org
  PulseAudio, core developer          http://pulseaudio.org
  rdesktop, core developer          http://www.rdesktop.org

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/