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:	Wed, 13 Feb 2008 10:19:25 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Joe Perches <joe@...ches.com>
cc:	Greg KH <gregkh@...e.de>, David Miller <davem@...emloft.net>,
	akpm@...ux-foundation.org, linux-kernel@...r.kernel.org
Subject: Re: [GIT PATCH] split up feature-removal-schedule.txt



On Wed, 13 Feb 2008, Linus Torvalds wrote:
> 
> So in that sense, I think both MAINTAINERS and the deprecation schedule 
> are totally uninteresting. Yes, they have merge conflicts. But those merge 
> conflicts are really really easy to handle.

That, btw, includes "automatic merges" for something like a Linux-next 
tree. It's easy to just make something that says: if the merge fails, try 
to fix up these xyz files by just committing them with merge error markers 
and all".

That's fine for testing, exactly because it has no coding impact (and then 
when a _real_ merge happens, you have a human that actually resolves it).

The git script would be something like

	UNIMPORTANT_LIST=MAINTAINERS \
		Documentation/feature-removal-schedule.txt \
		...

	git pull ... ||
		git add $UNIMPORTANT_LIST &&
		git commit -m "Trivially conflicting merge"

which basically says: if the pull fails (leaving a conflicted tree), try 
to just "git add" the files on the unimportant list as-is, and then try to 
commit the merge that way instead.

Git if nothing if not scriptable, and things like this are *trivial*.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ