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]

Message-Id: <5D90D82F-662F-4DF4-891A-90A4FA69A84E@mac.com>
Date:	Fri, 20 Oct 2006 03:30:23 -0400
From:	Kyle Moffett <mrmacman_g4@....com>
To:	Pierre Ossman <drzeus-list@...eus.cx>
Cc:	Linus Torvalds <torvalds@...l.org>, Andrew Morton <akpm@...l.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: Git training wheels for the pimple faced maintainer

On Oct 20, 2006, at 02:34:54, Pierre Ossman wrote:
> 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

Not quite.  diffstat doesn't understand renames and such, you want to  
use something more like this:

git diff -M --stat --summary master..for-linus
git log --pretty=short master..for-linus | git shortlog

As an example, if you rename foo/bar/baz.c to foo/bar/quux.c and  
change a few lines, you'll get something like this:

foo/bar/{baz.c => quux.c}  | 8 +--

It similarly makes renames between directories look nice.

>> 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?

Yes

>> 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?

Well, sorta.  If it's a pseudo-published development and you actually  
_don't_ _care_ what the old history was (because it was broken or  
incorrect or one of the patches got corrupted during import) then go  
ahead and wipe it out.  On the other hand if you have random people  
pulling from your published tree then you can't safely git-rebase or  
cg-admin-rewrite-hist or similar.  Luckily GIT will just complain  
about a discontinuous history as opposed to losing data.

Cheers,
Kyle Moffett


-
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/