Udev and systemd to merge
| From: | Kay Sievers <kay-AT-vrfy.org> | |
| To: | linux-hotplug-AT-vger.kernel.org | |
| Subject: | The future of the udev source tree | |
| Date: | Tue, 3 Apr 2012 18:15:13 +0200 | |
| Message-ID: | <CAPXgP110RNdjNqJtd7w=oSbLVM9XcspM2SMD_SjE8JmktEBtbQ@mail.gmail.com> | |
| Archive‑link: | Article |
We are about to merge the udev sources into the systemd source tree. After that, the next version of systemd will continue with udev’s version numbering, i.e. jump immediately from 45 to 184. After udev is merged into the systemd tree you can still build it for usage outside of systemd systems, and we will support these builds officially. In fact, we will be supporting this for a long time since it is a necessity to make initrds (which lack systemd) work properly. Distributions not wishing to adopt systemd can build udev pretty much the same way as before, however should then use the systemd tarball instead of the udev tarball and package only what is necessary of the resulting build. Today, ‘Init’ needs to be fully hotplug-capable; udev device management and knowledge about device lifecycles is an integral part of systemd and not an isolated logic. Due to this, and to minimize our administrative workload, as well as to minimize duplication of code, and to resolve cyclic build dependencies in the core OS, we have decided to merge the two projects. The udev built from the systemd source tree will stay compatible with non-systemd init systems for a long time. This change is mostly a detail of the build scheme, rather than a change of direction or interfaces. Accordingly, the libudev API is untouched by these build infrastructure changes. For us, compatibility is key. -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Posted Apr 3, 2012 16:44 UTC (Tue)
by sztanpet (subscriber, #60731)
[Link] (1 responses)
Posted Apr 9, 2012 14:59 UTC (Mon)
by oldtomas (guest, #72579)
[Link]
Posted Apr 3, 2012 16:56 UTC (Tue)
by slashdot (guest, #22014)
[Link] (1 responses)
Seriously, it's probably a good idea.
Posted Apr 3, 2012 17:07 UTC (Tue)
by dwayne (subscriber, #17004)
[Link]
Posted Apr 3, 2012 17:02 UTC (Tue)
by cuboci (subscriber, #9641)
[Link] (3 responses)
Posted Apr 3, 2012 19:26 UTC (Tue)
by drag (guest, #31333)
[Link] (2 responses)
It's hilarious.
All we need to do now is merge Btrfs and Gnome-shell into udev and we'd be set.
Posted Apr 3, 2012 20:36 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
I think, nano would do nicely.
Posted Apr 4, 2012 14:15 UTC (Wed)
by drag (guest, #31333)
[Link]
Just rewrite Eclipse using Vala and then compile it to C and import it into the udev Git repository and that should be it. Problem solved.
Posted Apr 3, 2012 17:14 UTC (Tue)
by JEFFREY (guest, #79095)
[Link] (9 responses)
All I can do is trust that they know how to edit and prevent feature bloat. The various Linux contributers have done quite well, thus far.
Should the project be renamed 'Udevstemd?'
Posted Apr 3, 2012 17:30 UTC (Tue)
by cesarb (subscriber, #6266)
[Link] (1 responses)
Quick, someone write an email reader for systemd, to stop the progression before it's too late. ;-)
Posted Apr 4, 2012 7:24 UTC (Wed)
by dgm (subscriber, #49227)
[Link]
Posted Apr 3, 2012 17:30 UTC (Tue)
by mezcalero (subscriber, #45103)
[Link] (2 responses)
The net result will be less lines of code, simply because we can reduce duplicate code (i.e. code which exists in both projects will now be replaced by the same implementation)
Posted Apr 3, 2012 17:44 UTC (Tue)
by Pc5Y9sbv (guest, #41328)
[Link] (1 responses)
I have never dug into the Android side of things, but wonder if there is a common ground that could serve the needs of server, desktop, laptop, mobile, router, and embedded environments. I realize that is asking a lot, particularly in terms of flexibility/performance/efficiency tradeoffs, but this feels like the kind of thing that could help keep Linux from branching off indefinitely into different niche platforms... I'm not even sure if it needs kernel side effort, given the latency and efficiency issues on mobile or embedded?
Posted Apr 4, 2012 14:58 UTC (Wed)
by RCL (guest, #63264)
[Link]
So unless the common part is really simple and plain and will *never* need any refactor/improvement, don't do that. The world is built upon redundancy, which helps parallelization of efforts.
Posted Apr 3, 2012 17:39 UTC (Tue)
by marduk (subscriber, #3831)
[Link] (3 responses)
Posted Apr 3, 2012 17:44 UTC (Tue)
by JEFFREY (guest, #79095)
[Link] (2 responses)
Posted Apr 3, 2012 18:15 UTC (Tue)
by SEJeff (guest, #51588)
[Link] (1 responses)
Posted Apr 4, 2012 8:36 UTC (Wed)
by k3ninho (subscriber, #50375)
[Link]
Posted Apr 3, 2012 17:30 UTC (Tue)
by landley (guest, #6789)
[Link]
Rob
Posted Apr 3, 2012 18:55 UTC (Tue)
by grobian (guest, #83608)
[Link] (3 responses)
Posted Apr 3, 2012 22:55 UTC (Tue)
by nteon (subscriber, #53899)
[Link] (2 responses)
Posted Apr 4, 2012 10:05 UTC (Wed)
by Pawlerson (guest, #74136)
[Link] (1 responses)
Posted Apr 4, 2012 15:09 UTC (Wed)
by mathstuf (subscriber, #69389)
[Link]
Posted Apr 3, 2012 21:05 UTC (Tue)
by karim (subscriber, #114)
[Link] (4 responses)
Posted Apr 3, 2012 21:29 UTC (Tue)
by vrfy (guest, #13362)
[Link]
Posted Apr 4, 2012 0:25 UTC (Wed)
by samroberts (subscriber, #46749)
[Link] (1 responses)
Posted Apr 4, 2012 21:00 UTC (Wed)
by karim (subscriber, #114)
[Link]
Posted Apr 5, 2012 16:43 UTC (Thu)
by scientes (guest, #83068)
[Link]
Posted Apr 3, 2012 21:40 UTC (Tue)
by russell (guest, #10458)
[Link] (40 responses)
Posted Apr 3, 2012 22:31 UTC (Tue)
by tpetazzoni (subscriber, #53127)
[Link] (39 responses)
Posted Apr 3, 2012 22:41 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (33 responses)
Posted Apr 3, 2012 23:07 UTC (Tue)
by mezcalero (subscriber, #45103)
[Link] (32 responses)
Posted Apr 3, 2012 23:14 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (31 responses)
BTW, I actually wouldn't mind if something cleaned up the mess that is /etc/network in Debian and /etc/sysconfig/network* in RHEL/CentOS.
Posted Apr 4, 2012 9:06 UTC (Wed)
by Aissen (subscriber, #59976)
[Link] (30 responses)
BTW, NetworkManager should have been the one fixing this "mess" (not sure it really is a mess). Apparently it didn't work, otherwise some people wouldn't have written connman :-)
Posted Apr 4, 2012 9:52 UTC (Wed)
by hadess (subscriber, #24252)
[Link]
Connman was written because somebody was allergic to NetworkManager's use of GObject. No other reasons that I know of.
Posted Apr 4, 2012 10:22 UTC (Wed)
by cortana (subscriber, #24596)
[Link] (22 responses)
NetworkManager is actually becoming pretty awesome. It's great to be able to e.g., quickly configure my laptop for "internet connection sharing" with just a few clicks.
For the foreseeable future, I'm sticking with ifupdown on my servers though. I'm not opposed to NM taking over there; the fact that it actually checks to see whether the configurations it enacts were successfully applies means that in theory it can be much more reliable than ifupdown, which just runs ip/dhclient, etc., without checking their exit statuses. It's just not as obvious how to configure it without a GUI (there's no man page for the per-connection configuration files in /etc, nor is there any obvious replacement for ifupdown's hook scripts).
Posted Apr 4, 2012 10:52 UTC (Wed)
by lindi (subscriber, #53135)
[Link] (5 responses)
Posted Apr 4, 2012 13:46 UTC (Wed)
by drag (guest, #31333)
[Link] (4 responses)
Generally what you'd want to do for network-manager is to put your scripts into /etc/NetworkManager/dispatcher.d in the typical "if [ "$2" = "up" ]; then" style format.
To get the best benefits out of NetworkManager you want to disable all the 'legacy' configuration plugins and use keyfile. That way you can edit all your network configurations using a 'ini' file format in /etc/NetworkManager/system-connections/
The advantage to this is that you can support a much more diverse amount of network connection types with better granularity then you can through traditional distro-specific configs.
The spec for the settings can be found..
For managing it through the command line use 'nmcli'.
I wish Gnome would provide a better documentation and examples for people using network manager on a server, but oh well.
Posted Apr 4, 2012 15:04 UTC (Wed)
by mathstuf (subscriber, #69389)
[Link]
Thanks for that link. It really needs to be mentioned in the nmcli man pages.
Posted Apr 4, 2012 17:59 UTC (Wed)
by mgedmin (subscriber, #34497)
[Link] (2 responses)
I can barely manage to figure out how to list available networks ('nmcli dev wifi', really?).
Posted Apr 4, 2012 18:43 UTC (Wed)
by tzafrir (subscriber, #11501)
[Link] (1 responses)
Last time I asked, I was told adding such a thing was not a good idea (which is why the bug report is not in the NM bugzilla).
Posted Apr 4, 2012 18:52 UTC (Wed)
by drag (guest, #31333)
[Link]
Posted Apr 4, 2012 12:45 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
Most of my network configuration ends up in pre-up and post-down scripts.
Posted Apr 4, 2012 23:16 UTC (Wed)
by rleigh (guest, #14622)
[Link]
Posted Apr 4, 2012 15:01 UTC (Wed)
by mathstuf (subscriber, #69389)
[Link] (2 responses)
Unfortunately, a feature[1] (though I consider it a bug) which is a blocker for me is still present.
Basically, I'd like to be able to set a wireless network as "flaky" so that if the connection drops, NM silently retries in the background continually instead of dropping the connection and *then* trying to reconnect. NM-aware applications tend to freak out if this happens every 5 minutes or so. Another use case is when moving around and one network is out of range temporarily in the presence of another known network (personal wireless, which is vastly preferred, versus campus wireless in my case). Going between floors takes me out of range of the my wireless, but the end points are both within range. I'd like to be able to tell NM that, but AFAIK, it will drop the connection, pick up the campus wireless and then not drop it when my wireless comes back into range because the campus connection is still there.
Of course, being able to create connections with nmcli would be nice too (unless it's a recent change, I haven't found out how to give it passwords and such for new wireless networks and instead have to launch nm-applet to create the connection which can then be managed with nmcli).
Currently, I just use ifcfg scripts for connections and wpa_supplicant.conf for wireless network configuration.
[1]There's a bug open somewhere for it, but I can't find it right now.
Posted Apr 4, 2012 16:40 UTC (Wed)
by drag (guest, #31333)
[Link] (1 responses)
You edit your own keyfile and then copy it to /etc/NetworkManager/system-connections/. NetworkManager watches that directory and should pick up on changes to configs automatically.
Although it's usually easier to use the nm-applet to make something so you have a config to work on when you want to make changes in the future.
Posted Apr 4, 2012 16:46 UTC (Wed)
by mathstuf (subscriber, #69389)
[Link]
Posted Apr 5, 2012 16:49 UTC (Thu)
by scientes (guest, #83068)
[Link] (10 responses)
can i share over ethernet, as opposed to just wireless? If so, I guess I missed that functionality, I had alot of pain trying to do it myself while still having networkmanager work.
Posted Apr 6, 2012 12:20 UTC (Fri)
by cortana (subscriber, #24596)
[Link] (8 responses)
Posted Apr 6, 2012 14:39 UTC (Fri)
by Eckhart (guest, #74500)
[Link]
Posted Apr 6, 2012 19:44 UTC (Fri)
by scientes (guest, #83068)
[Link] (6 responses)
as someone that has basic understanding of the networking, and has done this manually, this makes perfect sense, the other way you talk of is confusing, and would be way less capable.
If it wasn't for ipv4 exhaustion, sharing your internet connection could as simple as turning on ipv4 packet forwarding. (now there is also address allocation issues, so DHCP) the complexity, and ever difference between upstream, and downstream, somes from Network Address Translation.
Posted Apr 6, 2012 20:02 UTC (Fri)
by cortana (subscriber, #24596)
[Link] (5 responses)
Posted Apr 6, 2012 20:23 UTC (Fri)
by scientes (guest, #83068)
[Link] (1 responses)
sure maybe the language needs to be made clearer, "share Internet to this interface?"
Posted Apr 6, 2012 20:37 UTC (Fri)
by cortana (subscriber, #24596)
[Link]
Posted Apr 6, 2012 20:39 UTC (Fri)
by khim (subscriber, #9252)
[Link] (2 responses)
Well, it'll be nice psychology study which will show just why Joe Average gets the facts backward, but this logic is obviously quite strange. Let's forget about network, routing, packets, etc. Suppose my neighbour lost electrical power and I, ever the helpful guy, want to share my grid power connection with him (electrical grid, not Internet). Now, I have two choice: Somehow when electrical grid is concerned everyone automatically assumes solution #2 is right, but for Internet they want go and try to change WAN#1 (their WAN connection)? WHY? What's so special about Internet? P.S. This phenomenon is quite obviously present because Microsoft tries to “help” here. It ALSO makes no sense to change WAN configuration when you share it even in Windows, but hey, if people en masse want to do this strange thing then this is how it should be done. As a result when you share network connection you must “alter” WAN connection, but this is illusion. When you try to “share” WAN connection in Windows WAN connection is not changed at all. Instead Windows goes and silently changes LAN connection behind your back. The end result is essentially the same as with Linux, but with a twist: in simple cases everything “just works”, but in complex cases you must imagine these behind the scenes changes and do complex dance (Ok, I need to change this network in this and that way, but this is impossible to do so I need to create fictive temporary network and change THIS, then I can delete it because it's unneeded and I can fix THAT and but this well mean that networks will be disconnected but this can be fixed later…) I hate that.
Posted Apr 6, 2012 20:54 UTC (Fri)
by scientes (guest, #83068)
[Link] (1 responses)
#2. The Linux way of electricity networking does exist in your 2nd electrical example, its called a Widow-maker or other similarly ominous names. (for good reason)
Posted Apr 6, 2012 21:25 UTC (Fri)
by khim (subscriber, #9252)
[Link]
s/Linux/Windows/ Widow-maker is used to attach to the upstream, to “WAN” power grid (this is what you “naturally expect” for some reason). This is Windows way. In Linux you share your wall outlets (you local in-house “LAN” electric network) instead. Why? WAN == WIDE area network (think city-level or even wider electrical network), LAN == LOCAL area network (think you own tiny in-house network with dozen or two plugs and few appliances). If you want to share electricity with someone you most definitely will do it using your local network (unless you have some serious reasons to use thing which is called Widow-maker or other similarly ominous names).
Posted Apr 6, 2012 14:32 UTC (Fri)
by Eckhart (guest, #74500)
[Link]
This is perfectly possible with NetworkManager. Just create a wired connection, set method to Shared, and NetworkManager will start a DHCP server on your wired connection.
Posted Apr 4, 2012 15:28 UTC (Wed)
by jond (subscriber, #37669)
[Link] (4 responses)
Indeed, "it's entirely optional" would be closer to the truth.
Posted Apr 4, 2012 16:05 UTC (Wed)
by Aissen (subscriber, #59976)
[Link] (3 responses)
Posted Apr 6, 2012 14:49 UTC (Fri)
by Eckhart (guest, #74500)
[Link] (2 responses)
Can you please explain the systemd "full integration" "drama"?
Posted Apr 6, 2012 15:26 UTC (Fri)
by Aissen (subscriber, #59976)
[Link] (1 responses)
I said "full integration" because systemd is already in debian (http://packages.qa.debian.org/s/systemd.html ), it's just not the default init. So it's integrated, but not fully since not all daemons have systemd unit files.
Posted Apr 6, 2012 16:53 UTC (Fri)
by Eckhart (guest, #74500)
[Link]
Posted Apr 4, 2012 21:23 UTC (Wed)
by iabervon (subscriber, #722)
[Link]
Posted Apr 4, 2012 0:33 UTC (Wed)
by Pc5Y9sbv (guest, #41328)
[Link]
But seriously, maybe we really need a higher level set of event and process control abstractions from the kernel, rather than building some weird monolithic macro-micro-kernel architecture (kitchensinkd on top of Linux kernel)?
Posted Apr 4, 2012 4:45 UTC (Wed)
by iabervon (subscriber, #722)
[Link] (2 responses)
Posted Apr 4, 2012 8:24 UTC (Wed)
by nowster (subscriber, #67)
[Link]
Posted Apr 4, 2012 12:28 UTC (Wed)
by njs (subscriber, #40338)
[Link]
Posted Apr 4, 2012 15:27 UTC (Wed)
by jond (subscriber, #37669)
[Link]
Posted Apr 4, 2012 9:43 UTC (Wed)
by Aissen (subscriber, #59976)
[Link] (9 responses)
History preservation would have been possible with subtree merging:
Posted Apr 4, 2012 11:35 UTC (Wed)
by mezcalero (subscriber, #45103)
[Link] (8 responses)
Posted Apr 4, 2012 11:48 UTC (Wed)
by zuki (subscriber, #41808)
[Link] (7 responses)
commit f0083e3d4eb49e11fd7e37532dc64a6e6f5d4039
added initial files.
:)
Posted Apr 4, 2012 12:51 UTC (Wed)
by yoshi314 (guest, #36190)
[Link] (6 responses)
Posted Apr 4, 2012 13:00 UTC (Wed)
by Aissen (subscriber, #59976)
[Link] (5 responses)
$ git log --follow src/udev/udevd.c
move imported udev into place
--
Posted Apr 4, 2012 14:20 UTC (Wed)
by niner (subscriber, #26151)
[Link] (4 responses)
Posted Apr 4, 2012 14:54 UTC (Wed)
by Aissen (subscriber, #59976)
[Link] (3 responses)
Posted Apr 4, 2012 20:28 UTC (Wed)
by przemoc (guest, #67594)
[Link] (2 responses)
commit ad29a9f14fa8b1932c0e418bfcf1c10ce6a35a33
merge udev/, libudev/, systemd/ files in src/; move extras/ to src/
R099 udev/udevd.c src/udevd.c
commit 3e2147858f21943d5f4a781c60f33ac22c6096ed
move imported udev into place
R099 src/udev/src/udevd.c src/udev/udevd.c
Or git is losing some traces?
$ git log --follow --name-status -- src/udev/src/udevd.c
move imported udev into place
D src/udev/src/udevd.c
It's interesting that the only history of this file is its deletion. ;-)
--
Posted Apr 4, 2012 23:26 UTC (Wed)
by geofft (subscriber, #59789)
[Link] (1 responses)
(I'm not sure this is the correct behavior, but it is the current behavior.)
Posted Apr 6, 2012 7:33 UTC (Fri)
by MaZe (subscriber, #53908)
[Link]
a commit object includes 0 or more parent hashes.
a normal two-way merge thus has 2 parent hashes.
nowhere in the merge commit metadata is the fact that it is a subtree merge recorded (nor is the subtree directory recorded)
ie. the fix would be to include not only the parent's hash, but also the subdirectory at which the parent commit is being merged.
Since the subtree merge commit does not include anything to distinguish it from a normal non-subtree merge, it is not possible to (cheaply in terms of processing power) determine that all changes happening at path X/Y/Z within the subtree parent history should actually be treated as happening at subtree/X/Y/Z.
When running something like git log across a commit, ie. across it's history, git has to look at hundreds or thousands or tens of thousands of merges, it cannot afford to devote cpu time to figuring out whether a merge commit is a subtree commit, so it assumes all of them aren't.
As a result of this, once starts looking at the parent of a subtree merge (and its parents), the assumption that the tree is rooted at / is no longer correct.
As a result:
Worse, if you have Makefile, and merge another project with a Makefile into subdirectory dir:
This could be fixed by having instead of
[for extra brownies also allow the opposite, ie. supertree merges, where you merge not commit into directory, but commit:directory into /, or even super-subtree merges, where you merge commit:directory into other_directory]
so the generic format should allow:
and all the tools should be taught to follow such parent links properly.
Unfortunately, this will not fix subtree merges performed with old versions of git, and it is a backwards incompatible change.
Udev and systemd to merge
BASICALLY NOTHING WILL CHANGE
Dependency on DBUS?
Udev and systemd to merge
You will be assimilated.
Resistance is futile.
Udev and systemd to merge
Udev and systemd to merge
Udev and systemd to merge
Udev and systemd to merge
Udev and systemd to merge
Udev and systemd to merge
Udev and systemd to merge
Udev and systemd to merge
Udev and systemd to merge
Make it a library?
Make it a library?
Udev and systemd to merge
Udev and systemd to merge
Udev and systemd to merge
Udev and systemd to merge
Udev and systemd to merge
Udev and systemd to merge
(was absolutely painless BTW)
Udev and systemd to merge
Udev and systemd to merge
Udev and systemd to merge
Udev and systemd to merge
Udev and systemd to merge
Udev and systemd to merge
Udev and systemd to merge
Udev and systemd to merge
Udev and systemd to merge
Udev and systemd to merge
Udev and systemd to merge
Udev and systemd to merge
Udev and systemd to merge
Udev and systemd to merge
It works pretty well once you know how to configure it, and if your configuration isn't too dynamic.
Udev and systemd to merge
> it really is a mess). Apparently it didn't work, otherwise some people
> wouldn't have written connman :-)
Udev and systemd to merge
Udev and systemd to merge
Udev and systemd to merge
http://projects.gnome.org/NetworkManager/developers/api/0...
http://live.gnome.org/NetworkManager
Udev and systemd to merge
> http://projects.gnome.org/NetworkManager/developers/api/0...
Udev and systemd to merge
Udev and systemd to merge
Udev and systemd to merge
Udev and systemd to merge
Udev and systemd to merge
Udev and systemd to merge
Udev and systemd to merge
Udev and systemd to merge
Udev and systemd to merge
Udev and systemd to merge
Udev and systemd to merge
A connection marked as shared will get a DHCP server and uses NAT to route traffic over the default gateway. Therefore it is perfectly possible to share your 3g connection via ethernet to a bunch of computers.
Udev and systemd to merge
Udev and systemd to merge
Udev and systemd to merge
Udev and systemd to merge
Udev and systemd to merge
It's my internet connection I want to share, so I naturally expect to set its interface, the upstream one, to 'share with other computers'; the upstream connection is what I'm sharing, and is therefore be the object in the sentence "Share my internet connection with other computers".
1. I can go find out where and how my own house itself is connected to grid and try to change that global connection. I can even succeed and survive (if I'm lucky).
or
2. I can change my local connection configuration: just plug extension cord to my wall socket and attach appliances of my neighbour to it.Udev and systemd to merge
Udev and systemd to merge
The Linux way of electricity networking does exist in your 2nd electrical example, its called a Widow-maker or other similarly ominous names. (for good reason)
the entire concept of LAN vs. WAN only propagates this confusion
Udev and systemd to merge
Udev and systemd to merge
Udev and systemd to merge
Also, previous commenter pointed out that I mixed ifplugd and ifupdown. He was right.
Udev and systemd to merge
(both "full integration" and "drama")
Udev and systemd to merge
https://lwn.net/Articles/452865/
and more recently:
https://lwn.net/Articles/484168/
Udev and systemd to merge
Udev and systemd to merge
Second system effect?
Udev and systemd to merge
What is a process launcher? Should all fork()/exec() operations be done by message passing in the future?
Udev and systemd to merge
Udev and systemd to merge
Udev and systemd to merge
Udev and systemd to merge
http://help.github.com/subtree-merge/
Udev and systemd to merge
Udev and systemd to merge
Author: Greg KH <greg@press.(none)>
Date: Tue Apr 26 20:59:47 2005 -0700
Udev and systemd to merge
Udev and systemd to merge
commit 3e2147858f21943d5f4a781c60f33ac22c6096ed
Author: Kay Sievers <kay.sievers@vrfy.org>
Date: Tue Apr 3 21:24:46 2012 +0200
And that was all. Then git blame on the same file seems to have all the history. So what should I do to have git log show me the full history ?
Udev and systemd to merge
Udev and systemd to merge
It's a weird behaviour "git log" is having here, I don't fully understand why.
Udev and systemd to merge
Author: Kay Sievers <kay.sievers@vrfy.org>
Date: Thu Jan 5 22:41:45 2012 +0100
Author: Kay Sievers <kay.sievers@vrfy.org>
Date: Tue Apr 3 21:24:46 2012 +0200
commit 3e2147858f21943d5f4a781c60f33ac22c6096ed
Author: Kay Sievers <kay.sievers@vrfy.org>
Date: Tue Apr 3 21:24:46 2012 +0200
1.7.9.1
Udev and systemd to merge
Udev and systemd to merge
initial commit having 0,
normal commits having 1,
merges having 2 or more.
a subtree two-way merge also has 2 parent hashes.
git log subtree/X/Y/Z will show changes to Z since the subtree merge
git log X/Y/Z will show changes to Z before the subtree merge
git log dir/Makefile shows changes since the subtree merge
git log Makefile shows all changes to the Makefile and changes to dir/Makefile from before the subtree merged - interspersed.
parent <hash>
information in the commit object something like
parent <hash> @ subtree
parent <hash>:directory/path @ subtree/path