linux-kernel - Re: Slow DOWN, please!!!

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 for Android: free password hash cracker in your pocket

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

Message-ID: <481A4CE1.2060503@gmail.com>
Date:	Thu, 01 May 2008 20:06:09 -0300
From:	Kevin Winchester <kjwinchester@...il.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
CC:	Andrew Morton <akpm@...ux-foundation.org>,
	Dmitri Vorobiev <dmitri.vorobiev@...il.com>, rjw@...k.pl,
	davem@...emloft.net, linux-kernel@...r.kernel.org,
	jirislaby@...il.com, mingo@...e.hu
Subject: Re: Slow DOWN, please!!!

Linus Torvalds wrote:
> 
> On Wed, 30 Apr 2008, Andrew Morton wrote:
>>> For busy (or lazy) people like myself, the big problem with linux-next are
>>> the frequent merge breakages, when pulling the tree stops with "you are in
>>> the middle of a merge conflict".
>> Really?  Doesn't Stephen handle all those problems?  It should be a clean
>> fetch each time?
> 
> It should indeed be a clean fetch, but I wonder if Dmitri perhaps does a 
> "git pull" - which will do the fetch, but then try to _merge_ that fetched 
> state into whatever the last base Dmitri happened to have.
> 
> Dmitry: you cannot just "git pull" on linux-next, because each version of 
> linux-next is independent of the next one. What you should do is basically
> 
> 	# Set this up just once..
> 	git remote add linux-next git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git
> 
> and then after that, you keep on just doing
> 
> 	git fetch linux-next
> 	git checkout linux-next/master
> 
> which will get you the actual objects and check out the state of that 
> remote (and then you'll normally never be on a local branch on that tree, 
> git will end up using a so-called "detached head" for this).
> 
> IOW, you should never need to do any merges, because Stephen did all those 
> in linux-next already.
> 

Just to add some emphasis here - this is something that took me a long time to figure out, and since it is the pattern for dealing with the x86 trees and with the mm git tree and with linux-next, it would help if it were documented somewhere (not that I can imagine where).  Once you know it, it becomes obvious, but try staring at a merge conflict for a while trying to figure out what to do, and it gets frustrating.  I wonder if we can guess how many testers abandon the mm git tree or the linux-next tree because of this.

It might be nice if git supported a command like git-remote-help or something that would fetch a predefined help file from a remote tree that describes the workflow for that tree.

But at least with an extra reply to this mail, it might creep higher in the google search results when looking for merge conflicts with linux-next.

-- 
Kevin Winchester

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