Specifying N revisions after the initial commit
Hi All, Please CC me as I'm not subscribed. I was hoping someone could help me with the revision shorthand to get the commit sha of a commit N commits after the initial commit. Thus far I've figured out that to get the initial commit in a repository, you can use: git rev-list --max-parents=0 HEAD but I can't figure out how to get "give me the commit sha1 of the commit immediately after the initial commit", or for some number N. I could always do something like: git rev-list HEAD | tail -2 to get both, but I was curious if there was a refspec shorthand for this that could be used. It seems that git's rev parsing is all built on going backwards in order (and probably rightfully so). Thanks in advance. josh -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Specifying N revisions after the initial commit
On Tue, Sep 22, 2015 at 2:40 PM, Konstantin Khomoutov <kostix+...@007spb.ru> wrote: > On Tue, 22 Sep 2015 14:32:19 -0400 > Josh Boyer <jwbo...@gmail.com> wrote: > >> Please CC me as I'm not subscribed. >> >> I was hoping someone could help me with the revision shorthand to get >> the commit sha of a commit N commits after the initial commit. > > What happens if right after the initial commit, there have been five > branches created -- with no common commits except for the initial one? > > That's the core limitation of the data model Git uses (and arguably any > other DVCS system): all commits form a directed acyclic graph. > The "directed" in that construct means that child commits contain a > link to their parent commit (or commits) but not vice-versa. Hm. It has been so long since I've looked at the underlying model and git has proven to be so flexible on such a variety of things that I guess I forgot it was constructed through a DAG. The --reverse parameter to git-log and git-rev-parse had left me hopeful. > Hence, given any particular commit, you're able to trace all of its > ancestry, but the reverse is not possible. That makes sense. I suppose I will have to resort to parsing output of git-rev-list or something. Thanks for the reminder. josh -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Specifying N revisions after the initial commit
On Tue, Sep 22, 2015 at 3:55 PM, Junio C Hamano <gits...@pobox.com> wrote:
> Josh Boyer <jwbo...@gmail.com> writes:
>
>> On Tue, Sep 22, 2015 at 2:40 PM, Konstantin Khomoutov
>> ...
>>> Hence, given any particular commit, you're able to trace all of its
>>> ancestry, but the reverse is not possible.
>>
>> That makes sense. I suppose I will have to resort to parsing output
>> of git-rev-list or something. Thanks for the reminder.
>
> I think Konstantin explained why it fundamentally does not make
> sense to ask "which one is the Nth one after the root". I am not
> sure how running rev-list and count its output would help, unless
> you are now solving a different problem (perhaps "find all the ones
> that are Nth after some root", which does have an answer).
Oh, context would help, yes. In the case of the tree I'm parsing, I
know for a fact that the commit history is entirely linear and will
(should) always remain so. E.g.
A - B - C - D - E - F ... {N}
So yes, finding e.g. the second commit after the root is complicated
for something resembling anything like a typical git repo, but this
isn't like that. In other words, I can cheat. Or at least I'm pretty
sure I can cheat :).
josh
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git history in a file
On Fri, Jul 24, 2015 at 8:46 AM, Andreas Schwab sch...@linux-m68k.org wrote: Josh Boyer jwbo...@fedoraproject.org writes: I'm trying to figure out how to generate a file that contains the git history and changes from one revision to another, such that when the file is applied to a different tree starting at the same ancestor, the resulting tree is identical. See git-bundle(1). Thanks. That does indeed seem like what I'm looking for. josh -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
git history in a file
Hello, I'm trying to figure out how to generate a file that contains the git history and changes from one revision to another, such that when the file is applied to a different tree starting at the same ancestor, the resulting tree is identical. E.g. git whatever v4.2-rc3..master would produce this file, and then: git apply whatever file run on a tree which is currently at 4.2-rc3 would result in an identical HEAD. Originally I thought git-format-patch would be sufficient, however it does not contain merge commits and the resulting commit shas seem like they would be inaccurate. Is there a way to do this? I realize one could just git fetch/pull from tree A to tree B, but the usecase here is more complicated. Please CC me on replies as I am not subscribed. josh -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: patch-2.7.3 no longer applies relative symbolic link patches
[Adding Junio's correct email address. Sigh.] On Mon, Jan 26, 2015 at 11:29 AM, Josh Boyer jwbo...@fedoraproject.org wrote: Hi, I went to do the Fedora 3.19-rc6 build this morning and it failed in our buildsystem with: + '[' '!' -f /builddir/build/SOURCES/patch-3.19-rc6.xz ']' + case $patch in + unxz + patch -p1 -F1 -s symbolic link target '../../../../../include/dt-bindings' is invalid error: Bad exit status from /var/tmp/rpm-tmp.mWE3ZL (%prep) That is coming from the hunk in patch-3.19-rc6.xz that creates the symbolic link from arch/arm64/boot/dts/include/dt-bindings to include/dt-bindings. Oddly enough, patch-3.19-rc5.xz contains the same hunk and it built fine last week. Digging in, it seems that upstream patch has decided that relative symlinks are forbidden now as part of a fix for CVE-2015-1196. You can find the relevant bugs here: https://bugzilla.redhat.com/show_bug.cgi?id=1185928 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775901#13 Aside from locally modifying patch-3.19-rc6.xz, I'm not sure what else to do. I thought I would send a heads up since anyone that is using patch-2.7.3 is probably going to run into this issue. josh -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
patch-2.7.3 no longer applies relative symbolic link patches
Hi, I went to do the Fedora 3.19-rc6 build this morning and it failed in our buildsystem with: + '[' '!' -f /builddir/build/SOURCES/patch-3.19-rc6.xz ']' + case $patch in + unxz + patch -p1 -F1 -s symbolic link target '../../../../../include/dt-bindings' is invalid error: Bad exit status from /var/tmp/rpm-tmp.mWE3ZL (%prep) That is coming from the hunk in patch-3.19-rc6.xz that creates the symbolic link from arch/arm64/boot/dts/include/dt-bindings to include/dt-bindings. Oddly enough, patch-3.19-rc5.xz contains the same hunk and it built fine last week. Digging in, it seems that upstream patch has decided that relative symlinks are forbidden now as part of a fix for CVE-2015-1196. You can find the relevant bugs here: https://bugzilla.redhat.com/show_bug.cgi?id=1185928 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775901#13 Aside from locally modifying patch-3.19-rc6.xz, I'm not sure what else to do. I thought I would send a heads up since anyone that is using patch-2.7.3 is probably going to run into this issue. josh -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: patch-2.7.3 no longer applies relative symbolic link patches
On Mon, Jan 26, 2015 at 4:30 PM, Linus Torvalds torva...@linux-foundation.org wrote: On Mon, Jan 26, 2015 at 1:07 PM, Josh Boyer jwbo...@fedoraproject.org wrote: Or did I miss a way that git-apply can take a git patch and apply it to a tree that isn't a git repo? Exactly. git apply works as a straight patch replacement outside of a git repository. It doesn't actually need a git tree to work. Ah. I had somehow missed that entirely. Good to know for future reference. (Of course, git apply is _not_ a patch replacement in the general sense. It only applies context diffs - preferentially git style ones - so no old-style patches etc need apply. And it's not replacement-compatible in a syntax sense either, in that while many of the options are the same, not all are etc etc). Sure. Though for the Fedora kernel builds, we tend to use git formatted patches only anyway. I might play around with this and see how it works as the normal way to apply things. josh -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: patch-2.7.3 no longer applies relative symbolic link patches
On Mon, Jan 26, 2015 at 3:44 PM, Linus Torvalds torva...@linux-foundation.org wrote: On Mon, Jan 26, 2015 at 8:32 AM, Josh Boyer jwbo...@fedoraproject.org wrote: I went to do the Fedora 3.19-rc6 build this morning and it failed in our buildsystem with: + '[' '!' -f /builddir/build/SOURCES/patch-3.19-rc6.xz ']' + case $patch in + unxz + patch -p1 -F1 -s symbolic link target '../../../../../include/dt-bindings' is invalid error: Bad exit status from /var/tmp/rpm-tmp.mWE3ZL (%prep) Ugh. I don't see anything we can do about this on the git side, and I do kind of understand why 'patch' would be worried about '..' files. In a perfect world, patch would parse the filename and see that it stays within the directory structure of the project, but that is a rather harder thing to do than just say no dot-dot files. The short-term fix is likely to just use git apply instead of patch. Well, that's one fix anyway. I just removed the hunk from the local copy of patch-3.19-rc6.xz and added the symlink manually. See why below. The long-term fix? I dunno. I don't see us not using symlinks, and a quick check says that every *single* symlink we have in the kernel source tree is one that points to a different directory using .. format. And while I could imagine that patch ends up counting the dot-dot entries and checking that it's all inside the same tree it is patching, I could also easily see patch *not* doing that. So using git apply _might_ end up being the long-term fix too. It could, but from a distro perspective that requires either doing 'untar linux-3.N.tar.xz; cd linux-3.N; git add .; git apply patch-3.N+1-rcX' , or just using a git tree to begin with, which then makes all of this unnecessary anyway. Creating a git repo from a tarball for each build is kind of silly. Some might say not just using a git tree to build from to begin with in 2015 is also kind of silly. Or did I miss a way that git-apply can take a git patch and apply it to a tree that isn't a git repo? I suspect that if patch cannot apply even old-style kernel patches due to the symlinks we have in the tree, and people end up having to use git apply for them, I might end up starting to just use rename-patches (ie using git diff -M) for the kernel. I'm kind of wondering why we'd generate patches at all if you have to apply them to a git repo, but maybe people like doing things the old-fashioned way just for the hell of it. I've considered that for a while already, because patch _does_ kind of understand them these days, although I think it gets the cross-rename case wrong because it fundamentally works on a file-by-file basis. But if patch just ends up not working at all, the argument for trying to maintain backwards compatibility gets really weak. Yeah. I mostly wanted to give people a heads up on the issue. I'm sure it's going to impact more than just the kernel. I think for us it's mostly limited to the -rcX patches, because once the tarball for the final release is out the symlink should be created by tar just fine. josh -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
