* Re: Updated git HOWTO for kernel hackers
From: Anton Altaparmakov @ 2005-06-23 8:01 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jeff Garzik, Linux Kernel, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0506221603120.11175@ppc970.osdl.org>
On Wed, 22 Jun 2005, Linus Torvalds wrote:
> On Wed, 22 Jun 2005, Jeff Garzik wrote:
> > 2) download a linux kernel tree for the very first time
> >
> > $ mkdir -p linux-2.6/.git
> > $ cd linux-2.6
> > $ rsync -a --delete --verbose --stats --progress \
> > rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
> > \ <- word-wrapped backslash; sigh
> > .git/
>
> Gaah. I should do a "git-clone-script" or something that does this, and
> then you could just do
>
> git clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6
>
> Anybody?
What's wrong with Pasky's cogito scripts? There is a cg-pull as well as a
cg-clone in there already. If nothing else you could just copy the
relevant scripts and rename them to git-blah...
Best regards,
Anton
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/
^ permalink raw reply
* Re: Updated git HOWTO for kernel hackers
From: Vojtech Pavlik @ 2005-06-23 8:30 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jeff Garzik, Greg KH, Linux Kernel, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0506222225010.11175@ppc970.osdl.org>
On Wed, Jun 22, 2005 at 10:58:13PM -0700, Linus Torvalds wrote:
> And thinking that "fetching a tree fetches all the tags from that tree"
> really _is_ a stupid decision. It's missing the big picture. It's missing
> the fact that tags _should_ be normal every-day things that you just use
> as "book-marks", and that the kind of big "synchronization point for many
> people" tag should actually be the _rare_ case.
>
> The fact that global tags make that private "bookmark" usage impossible
> should be a big red blinking sign saying "don't do global tags".
Maybe it'd make sense to differentiate between the two types of tags?
To have local tags which don't propagate, and global (version) tags
which do? They could live in different namespaces and thus wouldn't
interfere.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
^ permalink raw reply
* Re: Patch (apply) vs. Pull
From: Martin Langhoff @ 2005-06-23 8:47 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Daniel Barkalow, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.58.0506221504370.2353@ppc970.osdl.org>
On 6/23/05, Linus Torvalds <torvalds@osdl.org> wrote:
> I've been doing unified diffs for a _loong_ time, and I edit patches in my
> sleep. The rules for line numbers etc are really quite simple, and yes, I
> do edit patches before I apply them.
We often do unified diff editing when dealing with merge conflicts. It
isn't too hard once you've got the hang of it, usually the hard thing
is resolving the conflict in the first place.
Emacs has a diff editing mode that is really good:
http://wiki.gnuarch.org/Process_20_2a_2erej_20files
cheers,
martin
^ permalink raw reply
* Re: Patch (apply) vs. Pull
From: Martin Langhoff @ 2005-06-23 8:36 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Darrin Thompson, git
In-Reply-To: <Pine.LNX.4.58.0506211452110.2353@ppc970.osdl.org>
On 6/22/05, Linus Torvalds <torvalds@osdl.org> wrote:
> Btw, I'd like to help automate the 6-7 stage with a different kind of
> merge logic.
(...)
> - get the different HEAD info set up, and save the original head in
> ORIG_HEAD, the way "git resolve" does for real merges:
>
> : ${GIT_DIR=.git}
>
> orig=$(git-rev-parse HEAD)
> new=$(git-rev-parse FETCH_HEAD)
> common=$(git-merge-base $orig $new)
>
> echo $orig > $GIT_DIR/ORIG_HEAD
>
> - fast-forward to the new HEAD. We'll want to re-base everything off
> that. If that fails, exit out - we've got dirty state
>
> git-read-tree -m -u $orig $new && exit 1
>
> - for each commit that we had in our old tree but not in the common part,
> try to re-base it:
>
> > FAILED_TO_CHERRYPICK
> for i in $(git-rev-list $orig ^$common)
> do
> git-cherry-pick $i ||
> (echo $i >> FAILED_TO_CHERRYPICK)
> done
> if [ -s FAILED_TO_CHERRYPICK ]; then
> echo Some commits could not be cherry-picked, check by hand:
> cat FAILED_TO_CHERRYPICK
> fi
Re-base and replay local history is an approach I've been using
successfully with Arch (though it takes literally ages). Ideally, the
process should be able to be restarted after one call to
git-cherry-pick fails. It is usually a handful of patches in a series
of a few hundred that will break, usually because it's been fed
upstream. You want to resolve the conflict and resume somehow.
> and here the "git-cherry-pick" thing is just a script that basically takes
> an old commit ID, and tries to re-apply it as a patch (with author data
> and commit messages, of course) on top of the current head. It would
> basically be nothing more than a "git-diff-tree $1" followed by tryign to
> figure out whether it had already been applied or whether it can be
> applied now.
>
> What do you think?
Sounds great.
It might be useful to provide it a "skip" list, so that it skips
applying selected patches (that have presumably made it upstream).
And perhaps --stop-at <commit-sha> so that if a large replay fails or
yields a broken tree (not at the git level, but at the /does it
compile and run/ level), I can throw away the temporary repo where I'm
working and try again in shorter batches, stopping at "strategical"
points.
cheers,
martin
^ permalink raw reply
* Re: Updated git HOWTO for kernel hackers
From: Martin Langhoff @ 2005-06-23 8:18 UTC (permalink / raw)
To: Petr Baudis
Cc: Linus Torvalds, Jeff Garzik, Greg KH, Linux Kernel,
Git Mailing List
In-Reply-To: <20050623073845.GA5204@pasky.ji.cz>
On 6/23/05, Petr Baudis <pasky@ucw.cz> wrote:
> I think there should simply be two namespaces - public tags and private
> tags. Private tags for stuff like "broken", "merged", or "funnychange".
I guess that public tags would also probably be in a different
location from the actual tree. With the split Linus advocates, several
people could be publishing sets of "public" tags, as well as having
the official tags hosted separately from the .git repo.
cheers,
martin
^ permalink raw reply
* [RFC] Order of push/pull file transfers
From: Russell King @ 2005-06-23 10:12 UTC (permalink / raw)
To: git
Hi,
I'd like to start a discussion on the ordering of the various git files
being transferred.
Last night, I pulled Linus' kernel tree from k.o, but Linus was in the
middle of pushing an update to it. The way cogito works, it grabs the
HEAD first, and then rsyncs the objects.
However, this retrieved the updated HEAD, and only some of the objects.
cogito happily tried to merge the result, and failed. A later pull
and git-fsck-cache confirmed everything was fine _in this instance_.
Therefore, may I suggest the following two changes in the way git
works:
1. a push updates HEAD only after the rsync/upload of all objects is
complete. This means that any pull will not try to update to the
new head with a partial object tree.
2. a pull only tries to fetch objects if HEAD has been updated since
the last pull.
This gives a pull-er an additional safety margin which ensures that
merges will not be attempted when a simultaneous pull and push occurs
at the same time.
--
Russell King
^ permalink raw reply
* Re: Patch (apply) vs. Pull
From: Catalin Marinas @ 2005-06-23 12:10 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Linus Torvalds, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.21.0506230025420.30848-100000@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> wrote:
> I think that you'll get better results out of "merge with top" + "commit
> with old commit info, but not listing old commit as a parent". At least,
> that's what StGIT is doing, IIRC, and using merge instead of patch seems
> like it'll make the remaining 1% a lot more pleasant.
Actually StGIT still lists the old commit as the 2nd parent since I
want to implement a log command which can also show only the commits
against a single patch. If this 2nd parent would not be stored,
pushing a patch onto the stack when its base was changed would reset
all the history for that patch.
Of course, there are other ways of doing this like storing all the
commit ids in a file but I found this to be the simplest.
--
Catalin
^ permalink raw reply
* Re: Updated git HOWTO for kernel hackers
From: Dave Airlie @ 2005-06-23 12:25 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Linux Kernel, Git Mailing List
In-Reply-To: <42B9E536.60704@pobox.com>
> jgarzik helper scripts, not in official git distribution:
> http://www.kernel.org/pub/linux/kernel/people/jgarzik/git-new-branch
> http://www.kernel.org/pub/linux/kernel/people/jgarzik/git-changes-script
>
Do you have some sort of magic bk-make-sum type util at all...
For sending trees to Linus I used to run bk-make-sum and gcapatch and
then just throw my own stuff in the top of the mail ....
I'm being lazy I probably could write it myself, but bk-make-sum was a
very useful script for me...
Dave.
^ permalink raw reply
* Re: Updated git HOWTO for kernel hackers
From: Horst von Brand @ 2005-06-23 14:31 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Linus Torvalds, Greg KH, Linux Kernel, Git Mailing List
In-Reply-To: <42BA45B1.7060207@pobox.com>
Jeff Garzik <jgarzik@pobox.com> said:
> Linus Torvalds wrote:
> > rsync -r --ignore-existing repo/refs/tags/ .git/refs/tags/
> >
> > See? What's your complaint with just doing that?
>
> No complaint with that operation. The complaint is that it's an
> additional operation. Re-read what Greg said:
>
> > Is there some reason why git doesn't pull the
> > tags in properly when doing a merge? Chris and I just hit this when I
> > pulled his 2.6.12.1 tree and and was wondering where the tag went.
>
> Multiple users -- not just me -- would prefer that git-pull-script
> pulled the tags, too.
>
> Suggested solution: add '--tags' to git-pull-script
> (git-fetch-script?), which calls
> rsync -r --ignore-existing repo/refs/tags/ .git/refs/tags/
I don't think either is really a solution. IMHO there should be a
distinction between "official tags" (that get passed around together with
everything else) and "private tags" for everybodys own home use (that could
be passed around, but only explicitly). Plus the possibility to erase,
move, &c private tags, and perhaps upgrade them to official status (thus
setting them in stone).
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
^ permalink raw reply
* Re: Updated git HOWTO for kernel hackers
From: Linus Torvalds @ 2005-06-23 15:29 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Linux Kernel, Git Mailing List
In-Reply-To: <42BA5F6F.9090406@pobox.com>
On Thu, 23 Jun 2005, Jeff Garzik wrote:
>
> Linus Torvalds wrote:
> > (Of course, since the rsync protocol doesn't know anything about git
> > consistency, if the mirroring is half-way, you'll end up with something
> > less than wonderful, and confusing. Details, details)
>
> Would it make sense to add an fsck step to git-clone-script?
Well, it's going to be slow. Of course, it's not as slow as pulling the
stuff over a DSL line or whatever, but still..
I think I need to make something that just verifies the top <n> commits or
whatever - I need that for "pull" anyway, so that you can do a
git fsck ORIG_HEAD..
and it will fsck only the new stuff that arrived as a result of the pull.
And we need to improve the git-ssh-pull/git-http-pull scripts so that they
do pipelined requests: right now it's usually a lot faster to do "rsync"
than it is to do git-ssh-pull (unless you do a small pull), because even
though the rsync ends up needing to compare the full directory contents,
it then transfers the data much faster.
Linus
^ permalink raw reply
* Re: Updated git HOWTO for kernel hackers
From: Linus Torvalds @ 2005-06-23 16:06 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Linux Kernel, Git Mailing List
In-Reply-To: <42BA6177.8060202@pobox.com>
On Thu, 23 Jun 2005, Jeff Garzik wrote:
>
> Chuckle. What does one call a Freudian slip, in computer-land?
A "Knuthian slip"?
> WARNING: You have previously called git-changes-script quite ugly (not
> surprising), and this 'git log x..y' will probably replace it in my
> usage, long term.
Even short-term, you could actually make it prettier.
You can actually use git across multiple directories by setting the
GIT_ALTERNATE_OBJECT_DIRECTORIES environment variable to point to the
alternate ones, so you should be able to do a "compare with remote" with
something like this:
export GIT_ALTERNATE_OBJECT_DIRECTORIES=$remote/.git/objects
remote_head=$(cat $remote/.git/HEAD)
git log $remote_head..
which should literally give a nice log of what is in your HEAD but not in
$remote_head. And if you want to see it the other way? Just change the
last line to
git log HEAD..$remote_head
and voila, you're done.
The nice thing about this approach is that this works with other git
programs too, ie you can replace "git log" with "gitk", and suddenly you
see graphically the commits that are in your tree but not in the remote
HEAD or vice versa.
Yeah, yeah, totally untested and maybe I'm talking through by *ss, but it
should work in theory.
Linus
^ permalink raw reply
* Re: 'dotest' fails, patch(1) succeeds
From: Linus Torvalds @ 2005-06-23 16:22 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Git Mailing List
In-Reply-To: <42BA66C1.30400@pobox.com>
On Thu, 23 Jun 2005, Jeff Garzik wrote:
>
> Trying to use git-tools' "dotest" script to merge an mbox into a kernel
> git repo failed, but patch(1) was OK with it:
>
> [jgarzik@pretzel netdev-2.6]$ dotest /g/tmp/mbox
>
> Applying 'e1000: fix spinlock bug'
>
> fatal: corrupt patch at line 10
You have a corrupt patch, and "git-apply" not only tells you so, it tells
you _exactly_ where it is:
In particular, it has whitespace damage at line 10:
1 --- linux-2.6.12-clean/drivers/net/e1000/e1000_main.c 2005-06-17 12:48:29.000000000 -0700
2 +++ linux-2.6.12/drivers/net/e1000/e1000_main.c 2005-06-21 10:42:29.000000000 -0700
3 @@ -2307,6 +2307,7 @@ e1000_xmit_frame(struct sk_buff *skb, st
4 tso = e1000_tso(adapter, skb);
5 if (tso < 0) {
6 dev_kfree_skb_any(skb);
7 + spin_unlock_irqrestore(&adapter->tx_lock, flags);
8 return NETDEV_TX_OK;
9 }
10
And take a close look. That line should have _one_ space on it (the space
that says "neither new nor old"), and it's totally empty (well, now in my
email it has "10 " on it, of course ;)
Btw, you have another problem: you should add a "---" marker to before the
patch header, otherwise your commit message will have the "diff -urpN"
thing in it. To the "dotest" scripts, "---" is the thing that says "here
ends the message and the patch begins".
(The line numbers from "git-apply" will also start at that --- point, so
if you add a "---" just above the "diff" line, you'd get "line 12" being
the corrupt one)
Linus
^ permalink raw reply
* Re: Patch (apply) vs. Pull
From: Daniel Barkalow @ 2005-06-23 16:45 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.58.0506222258290.11175@ppc970.osdl.org>
On Wed, 22 Jun 2005, Linus Torvalds wrote:
> On Thu, 23 Jun 2005, Daniel Barkalow wrote:
>
> > > In fact, you could probably replace every run of contiguous whitespace
> > > with a single space, and then you'd not have to worry about whitespace
> > > differences either. That would be very simple to do, and quite workable: I
> > > certainly think it sounds more reliable than just hoping that people
> > > always pass on a "patch ID" in their emails..
> >
> > That's actually quite plausible. The only case it wouldn't handle is when
> > you actually discard parts, and I'm not sure at this point what other
> > people should see there.
>
> Yes. One small note of warning: different "diff" algorithms may under some
> (mostly unlikely) circumstances result in different patches for the
> difference between the same two files. So when comparin SHA1's of diffs
> this way, you should also hopefully have the same diff generation
> algorithm.
I think that, if we care much about the hashes of diffs, we should hash
the diff that's being applied, not hash a regenerated diff (unless, of
course, the diff that's being applied has been modified in hash-relevant
ways, in which case it's not going to match anything anyway).
GNU diff sometimes generates patches which are really terrible to try to
read, because it finds some line of punctuation from a removed block that
matches a line in an added block and interleaves unrelated content. It
would be nice to not have to worry about confusion if there's a mismatch.
Wouldn't the only case where this would be a problem be if we had the
committer apply the patch, generate a diff, hash it, and stick the hash in
the commit? The no-cache version has the diffs for hashing done by the
same person with the same program, and the hash-the-applied-patch version
has the hashes done on the same patch.
> > > Yeah. It probably works well in 99% of the cases to just do a simple
> > > "export as patch" + "apply on top with old commit message, author and
> > > author-date".
> >
> > I think that you'll get better results out of "merge with top" + "commit
> > with old commit info, but not listing old commit as a parent".
>
> If I understand you correctly, that assumes that you followed the whole
> chain, though, and that there was no cherry-picking.
I think that the whole-chain case is sufficiently common to make special
and extra smooth; developers will be making their history forwards every
day, and only cherry-picking on occasion.
This is also still in the developer's messy history, and I don't think
those commits are really worth much as history or organization (although
they're wonderful as checkpointing). The cherry-picking there will
generally be content-based rather than commit-based, and will mostly be
picking out hunks to form a clean patch sequence to replace the history.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Patch (apply) vs. Pull
From: Daniel Barkalow @ 2005-06-23 17:05 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Linus Torvalds, Junio C Hamano, git
In-Reply-To: <tnxr7et9su7.fsf@arm.com>
On Thu, 23 Jun 2005, Catalin Marinas wrote:
> Actually StGIT still lists the old commit as the 2nd parent since I
> want to implement a log command which can also show only the commits
> against a single patch. If this 2nd parent would not be stored,
> pushing a patch onto the stack when its base was changed would reset
> all the history for that patch.
I think that it's important to avoid having the array of "rebased the
patch" commits be reachable from the final series if that series is going
to be merged into the mainline at the end.
If you want to keep the history of a patch, you should be able to do it by
rebasing that history as well as the latest patch, so you'd get a
two-parent commit with two rebased parents when you rebased a two-parent
commit.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Patch (apply) vs. Pull
From: Linus Torvalds @ 2005-06-23 18:43 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.21.0506231149460.30848-100000@iabervon.org>
On Thu, 23 Jun 2005, Daniel Barkalow wrote:
>
> I think that, if we care much about the hashes of diffs, we should hash
> the diff that's being applied, not hash a regenerated diff (unless, of
> course, the diff that's being applied has been modified in hash-relevant
> ways, in which case it's not going to match anything anyway).
But this whole algorithm depends on comparing two git commits, so we don't
actually _have_ a diff: we must generate it ourselves from the commits we
have in the history (ie we'd compare the commit we're "moving forward"
with each commit that we're moving it forward past - in order to see
whether it's already been applied).
Now, we control both of these patch generations, so in that sense it's
easy to just make sure we generate both diffs the same way, but I just
wanted to point this fact out.
> Wouldn't the only case where this would be a problem be if we had the
> committer apply the patch, generate a diff, hash it, and stick the hash in
> the commit?
Right, that would mean that we don't control the hash generation at both
points, and would make it fundamentally harder. But since the whole point
is that we should be able to generate the ID _without_ it actually being
stored away anywhere, this hash approach should work fine.
> I think that the whole-chain case is sufficiently common to make special
> and extra smooth; developers will be making their history forwards every
> day, and only cherry-picking on occasion.
I'm not convinced. I think a _lot_ of people would want to do re-ordering
of patches, combining them, and cherry-picking them if they just had a
good way to do that.
That would then be a good way of cleaning up messy history too. Just prune
the old tree once you've moved it forward.
Linus
^ permalink raw reply
* Re: Patch (apply) vs. Pull
From: Daniel Barkalow @ 2005-06-23 19:59 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.58.0506231137440.11175@ppc970.osdl.org>
On Thu, 23 Jun 2005, Linus Torvalds wrote:
> Right, that would mean that we don't control the hash generation at both
> points, and would make it fundamentally harder. But since the whole point
> is that we should be able to generate the ID _without_ it actually being
> stored away anywhere, this hash approach should work fine.
("We" in this case being the developer checking whether the patch went in,
not the maintainer)
We'll need to see if the performance is okay this way, both in terms of
time spent searching for the patch you're checking on and in terms of
recognizing the patch as being the same. No point in designing anything
more complex until we determine if we can't just recognize it already.
> > I think that the whole-chain case is sufficiently common to make special
> > and extra smooth; developers will be making their history forwards every
> > day, and only cherry-picking on occasion.
>
> I'm not convinced. I think a _lot_ of people would want to do re-ordering
> of patches, combining them, and cherry-picking them if they just had a
> good way to do that.
Oh, I think they'd want to do that. I just don't think they'd want to do
it as often as they want to update their tree for changes in mainline,
just because no one developer will do more work than the rest of the
developers combined. And it's worthwhile, because you need to use
diff/patch for the complex cases, and can use diff3 for the simple case,
and you need diff3 if you want the system to treat "everything in patch 5
is already in the new base" as success rather than conflict.
(This is, incidentally, the case that drives me crazy about arch: if I
make a change in one working directory, copy that change into another
working directory, commit it from one of those directories, and update in
the other, I get a reject, and I then have to figure out if the changes
were actually the same or if one of them has further modifications.)
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Patch (apply) vs. Pull
From: Linus Torvalds @ 2005-06-23 22:20 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.21.0506231522080.30848-100000@iabervon.org>
On Thu, 23 Jun 2005, Daniel Barkalow wrote:
>
> On Thu, 23 Jun 2005, Linus Torvalds wrote:
> >
> > Right, that would mean that we don't control the hash generation at both
> > points, and would make it fundamentally harder. But since the whole point
> > is that we should be able to generate the ID _without_ it actually being
> > stored away anywhere, this hash approach should work fine.
>
> ("We" in this case being the developer checking whether the patch went in,
> not the maintainer)
Yes.
> We'll need to see if the performance is okay this way, both in terms of
> time spent searching for the patch you're checking on and in terms of
> recognizing the patch as being the same. No point in designing anything
> more complex until we determine if we can't just recognize it already.
Actually, this is a _very_ efficient check to do, because I'm just
incredibly smart.
What you do is to download the current git tree (give it a while to mirror
out, actually), and you get a magic "git-patch-id" program.
Now, the reason this is very efficient is magical. Let's say that you have
my tree as branch "linus", and you have your own tree (branch "daniel"),
and you want to see what commits are in both (but are not the _same_
commit - you just wonder if they have the same diff). That's a big clue
that you should drop your copy, because I applied it as a diff.
What you do is simply:
git-whatchanged -p linus..daniel | git-patch-id | sort > daniel-patch-id
git-whatchanged -p daniel..linus | git-patch-id | sort > linus-patch-id
join -j 1 linus-patch-id daniel-patch-id
and you're done. You've just created a list of commits that have the same
patch ID (and it will list the patch ID _and_ the two commit ID's, just
to be really nice about it).
It's all totally linear in number of patches involved (yeah, the "sort" is
obviously reall NlogN, and technically the git-rev-list between the two
trees _could_ be more than linear, but in practice they are very cheap and
very close to linear anyway).
It's also obviously totally untested, but hey, I always write perfect
code, so what could _possibly_ go wrong..
Linus
^ permalink raw reply
* Re: Patch (apply) vs. Pull
From: Linus Torvalds @ 2005-06-23 22:49 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, Git Mailing List, Andrew Morton
In-Reply-To: <Pine.LNX.4.58.0506231510370.11175@ppc970.osdl.org>
On Thu, 23 Jun 2005, Linus Torvalds wrote:
>
> It's also obviously totally untested, but hey, I always write perfect
> code, so what could _possibly_ go wrong..
Actually, for once it actually does work.
Doing this for the whole current git kernel history shows the following
patch ID's that are duplicates:
- fix ia64 syscall auditing:
0d9a1c0b1d4009f81f1c3d558961cc1eaf89c43d 3ac3ed555bec5b1f92bb22cb94823a0e99d0f320
0d9a1c0b1d4009f81f1c3d558961cc1eaf89c43d 446b8831f5acf2076fa58a66286789eb84f3df2c
- remove outdated print_* functions:
1a830d81e7580b55eb0d445a5bf43920e1dba211 1409277c4aad2e87ad27b2b8a6901ce78eaf8081
1a830d81e7580b55eb0d445a5bf43920e1dba211 db9dff366ba78085d0323364fadbf09bec0e77ee
- zfcp: add point-2-point support:
3969795b9b61425ef7e7ac52e9576203dc1ca71a 6f71d9bc025b02a8cbc2be83b0226a7043a507a5
3969795b9b61425ef7e7ac52e9576203dc1ca71a 91bbfbda8d41f834c70c47d6f8c95245c90019e5
- ppc32: add 405EP cpu_spec entry:
59a8f295cf4c44cae74db41699392dc22db64df1 7fbdf1a23be1837b8bc5bcec096015ca99e00aa7
59a8f295cf4c44cae74db41699392dc22db64df1 ad95d6098dd1e94a09d2a1fdf39fd8281fcd8958
59a8f295cf4c44cae74db41699392dc22db64df1 beb9e1c3f32a0f878765c7c1142f91083739c5bd
- Convert i2o to compat_ioctl:
6ab2bc457d0a736d97f26f2ca75666bb981fdc42 83363ea074504f9005e28cd6209923637bb74de5
6ab2bc457d0a736d97f26f2ca75666bb981fdc42 f4c2c15b930b23edaa633b09fe3f4c01b4ecce9f
- ppc32: Fix Alsa PowerMac driver on old machines:
7c82fcb20679f5c24c8db37b6dc554bf841744e9 5218064c885af5c49e380d09d54f3cc86891a580
7c82fcb20679f5c24c8db37b6dc554bf841744e9 9ae250d175e1cbff82223ce2c07897c790c5b948
- scsi: remove unused scsi_cmnd->internal_timeout field
883a1e3ca52a071eaf9d53e66d13b250c6d60942 97665e9c22991401dc56968619c6b8b9c09f3268
883a1e3ca52a071eaf9d53e66d13b250c6d60942 d3a933dc9851e74581f9f4c8e703e77901ae8d01
- scsi: remove meaningless scsi_cmnd->serial_number_at_timeout field:
8d3c15861cc08388e610940506255d3a19109aee 84011ae88da62a20b3ae7b48e2ae3b1ef0fc810a
8d3c15861cc08388e610940506255d3a19109aee c6295cdf656de63d6d1123def71daba6cd91939c
- kill old EH constants:
9b0f17e44f99618902fa0cdc5cd73711060f3650 0db7157ca47e21c7623a59e710b807ad06fce161
9b0f17e44f99618902fa0cdc5cd73711060f3650 2bc474c3646efba67bdc83b7fc7d8ee7562e0106
- input: Fix fast scrolling scancodes in atkbd.c:
bb6b1e4d2d979e1cccf96d0dd494f608d5143bee 5212dd58e67e4b8009107d69a9de45dd2e687496
bb6b1e4d2d979e1cccf96d0dd494f608d5143bee 7d6064d44bc79e328f2794ee7322ba2676511e2b
- scsi: add DID_REQUEUE to the error handling:
c62473f1990c475b087fee7280a1b2e9b9589bc5 686579d95d48c713bdb7008cc76af8398219e687
c62473f1990c475b087fee7280a1b2e9b9589bc5 bf341919dbc1fbcbb565fb3224c840760ebd9f85
- consolidate timeout defintions in scsi.h:
d56aa0d90bced261ddf3b58038fca3cbff59a189 0890d74f295be849032fd4390ee00422dfda83b1
d56aa0d90bced261ddf3b58038fca3cbff59a189 b6651129cc27d56a9cbefcb5f713cea7706fd6b7
- kill gratitious includes of major.h:
e938d763a9c231acbf93f1140c911cbec447c89d 5523662c4cd585b892811d7bb3e25d9a787e19b3
e938d763a9c231acbf93f1140c911cbec447c89d b453257f057b834fdf9f4a6ad6133598b79bd982
- drivers/scsi/sym53c416.c: fix a wrong check:
eb2d067160e40137cd00590e59e800dd09c4f62f 380c3877ae5de888cfb7a59990b9aee5a415295f
eb2d067160e40137cd00590e59e800dd09c4f62f b6f0b0d016a254ff583fec26f2c9e21c1ae2fdf3
- ultrastor: fix compile failure:
ed19cee5e4439c92e4e711fe1c10569b58415c46 4e33bd874bce8b3df2ab52538db59730196383c3
ed19cee5e4439c92e4e711fe1c10569b58415c46 69aa3f71580990f39e387d96ed1001d2f5fb04b1
- qla trivial iomem annotation:
ff16fe82338d2dd7d8baf6a3b38780e0eac2b1f0 766f2fa170e65948053b06c6106c8dc8526c3e14
ff16fe82338d2dd7d8baf6a3b38780e0eac2b1f0 93fc4294fc112ce4e518a3f62dea8681dc39d9cf
where the first number is the patch ID, the the second number is the
commit ID.
What's interesting to note here is the following:
- it actually did find duplicates in the current kernel that had just
merged perfectly and come in through two different trees.
It's also interesting to note that while most of them had largely the
same commit message (ie they clearly got applied from the same emailed
diff), the algorithm doesn't even look at that one, and thus the fact
that some had extra comments ("I have tested this patch and have seen
no problems with it.") others had not just different sign-offs (due to
the different paths they took), but different authors noted.
Ie this really doesn't care at all about how the patch came there, it
just notices that the patch is identical to some other patch.
- it didn't have a single false positive (the above is the full list of
duplicate patch ID's - I just did a
git-whatchanged -p | git-patch-id | LANG=C sort > sorted-patch-list
followed by
cut -d' ' -f1 sorted-patch-list | uniq -d | join -j 1 - sorted-patch-list
and then when you have that list, you can check the commits themselves
with
cut -d' ' -f2 dup-list | git-diff-tree --pretty -p --stdin | less -S
and verify the output.
- it actually found the patch that got incorrectly applied _three_times_
("ppc32: add 405EP cpu_spec entry") because it continued to apply, and
thus Andrew's scripts didn't notice it.
In other words, this "check patch ID's" thing is not only efficient, it
actually seems to work. It literally checked the last 2+ months of kernel
history (2788 patches) for duplicate patches in just under a minute, and
might be useful to Andrew etc as a way to see "yup, that patch got
applied".
Doing the same for just the difference between two branches is pretty much
instantaneous. You can basically check ~50 patches a second using this.
Linus
^ permalink raw reply
* [PATCH 0/2] Finishing touches for pull "-w ref"
From: Junio C Hamano @ 2005-06-23 23:18 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
I'll be sending these two patches to add finishing touches to
"-w ref" support.
[PATCH 1/2] Add a bit of developer documentation to pull.h
[PATCH 2/2] http-pull: documentation updates.
^ permalink raw reply
* [PATCH 0/2] D/F conflicts fixes.
From: Junio C Hamano @ 2005-06-23 23:20 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
I'll be sending these two patches.
[PATCH 1/2] Add more tests for read-tree --emu23.
[PATCH 2/2] Fix oversimplified optimization for add_cache_entry().
^ permalink raw reply
* [PATCH 0/3] Rebasing for "individual developer" usage
From: Junio C Hamano @ 2005-06-23 23:21 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Darrin Thompson, git
In-Reply-To: <Pine.LNX.4.58.0506211452110.2353@ppc970.osdl.org>
>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:
LT> Something like this...
LT> What do you think?
I'll be sending these three patches as my answer to that question.
[PATCH 1/3] git-commit-script: get commit message from an existing one.
[PATCH 2/3] git-cherry: find commits not merged upstream.
[PATCH 3/3] git-rebase-script: rebase local commits to new upstream head.
^ permalink raw reply
* [PATCH 1/2] Add a bit of developer documentation to pull.h
From: Junio C Hamano @ 2005-06-23 23:23 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <7vfyv8fyqn.fsf@assigned-by-dhcp.cox.net>
Describe what to implement in fetch() and fetch_ref() for
pull backend writers a bit better.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
pull.h | 21 +++++++++++++++------
1 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/pull.h b/pull.h
--- a/pull.h
+++ b/pull.h
@@ -1,24 +1,33 @@
#ifndef PULL_H
#define PULL_H
-/** To be provided by the particular implementation. **/
+/*
+ * Fetch object given SHA1 from the remote, and store it locally under
+ * GIT_OBJECT_DIRECTORY. Return 0 on success, -1 on failure. To be
+ * provided by the particular implementation.
+ */
extern int fetch(unsigned char *sha1);
+/*
+ * Fetch ref (relative to $GIT_DIR/refs) from the remote, and store
+ * the 20-byte SHA1 in sha1. Return 0 on success, -1 on failure. To
+ * be provided by the particular implementation.
+ */
extern int fetch_ref(char *ref, unsigned char *sha1);
-/** If set, the ref filename to write the target value to. **/
+/* If set, the ref filename to write the target value to. */
extern const char *write_ref;
-/** If set, the hash that the current value of write_ref must be. **/
+/* If set, the hash that the current value of write_ref must be. */
extern const unsigned char *current_ref;
-/** Set to fetch the target tree. */
+/* Set to fetch the target tree. */
extern int get_tree;
-/** Set to fetch the commit history. */
+/* Set to fetch the commit history. */
extern int get_history;
-/** Set to fetch the trees in the commit history. **/
+/* Set to fetch the trees in the commit history. */
extern int get_all;
/* Set to zero to skip the check for delta object base;
------------
^ permalink raw reply
* [PATCH 2/2] http-pull: documentation updates.
From: Junio C Hamano @ 2005-06-23 23:23 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <7vfyv8fyqn.fsf@assigned-by-dhcp.cox.net>
Describe -w option.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Documentation/git-http-pull.txt | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-http-pull.txt b/Documentation/git-http-pull.txt
--- a/Documentation/git-http-pull.txt
+++ b/Documentation/git-http-pull.txt
@@ -9,7 +9,7 @@ git-http-pull - Downloads a remote GIT r
SYNOPSIS
--------
-'git-http-pull' [-c] [-t] [-a] [-v] [-d] [--recover] commit-id url
+'git-http-pull' [-c] [-t] [-a] [-d] [-v] [-w filename] [--recover] commit-id url
DESCRIPTION
-----------
@@ -30,7 +30,9 @@ Downloads a remote GIT repository via HT
usual, to recover after earlier pull that was interrupted.
-v::
Report what is downloaded.
-
+-w::
+ Writes the commit-id into the filename under $GIT_DIR/refs/ on
+ the local end after the transfer is complete.
Author
------
------------
^ permalink raw reply
* [PATCH 1/2] Add more tests for read-tree --emu23.
From: Junio C Hamano @ 2005-06-23 23:25 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <7vaclgfynv.fsf@assigned-by-dhcp.cox.net>
This adds more tests for --emu23. One is to show how it can
carry forward more local changes than the straightforward
two-way fast forward, and another is to show the recent
overeager optimization of directory/file conflict check broke
things, which will be fixed in the next commit.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
t/t1001-read-tree-m-2way.sh | 70 +++++++++++++++++++++++++---
t/t1005-read-tree-m-2way-emu23.sh | 94 ++++++++++++++++++++++++++++++++++---
2 files changed, 150 insertions(+), 14 deletions(-)
diff --git a/t/t1001-read-tree-m-2way.sh b/t/t1001-read-tree-m-2way.sh
--- a/t/t1001-read-tree-m-2way.sh
+++ b/t/t1001-read-tree-m-2way.sh
@@ -29,7 +29,6 @@ read_tree_twoway () {
_x40='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]'
_x40="$_x40$_x40$_x40$_x40$_x40$_x40$_x40$_x40"
compare_change () {
- cat current
sed -n >current \
-e '/^--- /d; /^+++ /d; /^@@ /d;' \
-e 's/^\([-+][0-7][0-7][0-7][0-7][0-7][0-7]\) '"$_x40"' /\1 X /p' \
@@ -51,11 +50,22 @@ check_cache_at () {
esac
}
+cat >bozbar-old <<\EOF
+This is a sample file used in two-way fast forward merge
+tests. Its second line ends with a magic word bozbar
+which will be modified by the merged head to gnusto.
+It has some extra lines so that external tools can
+successfully merge independent changes made to later
+lines (such as this one), avoiding line conflicts.
+EOF
+
+sed -e 's/bozbar/gnusto (earlier bozbar)/' bozbar-old >bozbar-new
+
test_expect_success \
setup \
'echo frotz >frotz &&
echo nitfol >nitfol &&
- echo bozbar >bozbar &&
+ cat bozbar-old >bozbar &&
echo rezrov >rezrov &&
echo yomin >yomin &&
git-update-cache --add nitfol bozbar rezrov &&
@@ -63,7 +73,7 @@ test_expect_success \
echo treeH $treeH &&
git-ls-tree $treeH &&
- echo gnusto >bozbar &&
+ cat bozbar-new >bozbar &&
git-update-cache --add frotz bozbar --force-remove rezrov &&
git-ls-files --stage >M.out &&
treeM=`git-write-tree` &&
@@ -86,6 +96,8 @@ echo '+100644 X 0 yomin' >expected
test_expect_success \
'4 - carry forward local addition.' \
'rm -f .git/index &&
+ git-read-tree $treeH &&
+ git-checkout-cache -u -f -q -a &&
git-update-cache --add yomin &&
read_tree_twoway $treeH $treeM &&
git-ls-files --stage >4.out || exit
@@ -96,6 +108,8 @@ test_expect_success \
test_expect_success \
'5 - carry forward local addition.' \
'rm -f .git/index &&
+ git-read-tree $treeH &&
+ git-checkout-cache -u -f -q -a &&
echo yomin >yomin &&
git-update-cache --add yomin &&
echo yomin yomin >yomin &&
@@ -108,6 +122,8 @@ test_expect_success \
test_expect_success \
'6 - local addition already has the same.' \
'rm -f .git/index &&
+ git-read-tree $treeH &&
+ git-checkout-cache -u -f -q -a &&
git-update-cache --add frotz &&
read_tree_twoway $treeH $treeM &&
git-ls-files --stage >6.out &&
@@ -117,6 +133,8 @@ test_expect_success \
test_expect_success \
'7 - local addition already has the same.' \
'rm -f .git/index &&
+ git-read-tree $treeH &&
+ git-checkout-cache -u -f -q -a &&
echo frotz >frotz &&
git-update-cache --add frotz &&
echo frotz frotz >frotz &&
@@ -128,6 +146,8 @@ test_expect_success \
test_expect_success \
'8 - conflicting addition.' \
'rm -f .git/index &&
+ git-read-tree $treeH &&
+ git-checkout-cache -u -f -q -a &&
echo frotz frotz >frotz &&
git-update-cache --add frotz &&
if read_tree_twoway $treeH $treeM; then false; else :; fi'
@@ -135,6 +155,8 @@ test_expect_success \
test_expect_success \
'9 - conflicting addition.' \
'rm -f .git/index &&
+ git-read-tree $treeH &&
+ git-checkout-cache -u -f -q -a &&
echo frotz frotz >frotz &&
git-update-cache --add frotz &&
echo frotz >frotz &&
@@ -143,6 +165,8 @@ test_expect_success \
test_expect_success \
'10 - path removed.' \
'rm -f .git/index &&
+ git-read-tree $treeH &&
+ git-checkout-cache -u -f -q -a &&
echo rezrov >rezrov &&
git-update-cache --add rezrov &&
read_tree_twoway $treeH $treeM &&
@@ -152,6 +176,8 @@ test_expect_success \
test_expect_success \
'11 - dirty path removed.' \
'rm -f .git/index &&
+ git-read-tree $treeH &&
+ git-checkout-cache -u -f -q -a &&
echo rezrov >rezrov &&
git-update-cache --add rezrov &&
echo rezrov rezrov >rezrov &&
@@ -160,6 +186,8 @@ test_expect_success \
test_expect_success \
'12 - unmatching local changes being removed.' \
'rm -f .git/index &&
+ git-read-tree $treeH &&
+ git-checkout-cache -u -f -q -a &&
echo rezrov rezrov >rezrov &&
git-update-cache --add rezrov &&
if read_tree_twoway $treeH $treeM; then false; else :; fi'
@@ -167,6 +195,8 @@ test_expect_success \
test_expect_success \
'13 - unmatching local changes being removed.' \
'rm -f .git/index &&
+ git-read-tree $treeH &&
+ git-checkout-cache -u -f -q -a &&
echo rezrov rezrov >rezrov &&
git-update-cache --add rezrov &&
echo rezrov >rezrov &&
@@ -180,6 +210,8 @@ EOF
test_expect_success \
'14 - unchanged in two heads.' \
'rm -f .git/index &&
+ git-read-tree $treeH &&
+ git-checkout-cache -u -f -q -a &&
echo nitfol nitfol >nitfol &&
git-update-cache --add nitfol &&
read_tree_twoway $treeH $treeM &&
@@ -191,6 +223,8 @@ test_expect_success \
test_expect_success \
'15 - unchanged in two heads.' \
'rm -f .git/index &&
+ git-read-tree $treeH &&
+ git-checkout-cache -u -f -q -a &&
echo nitfol nitfol >nitfol &&
git-update-cache --add nitfol &&
echo nitfol nitfol nitfol >nitfol &&
@@ -203,6 +237,8 @@ test_expect_success \
test_expect_success \
'16 - conflicting local change.' \
'rm -f .git/index &&
+ git-read-tree $treeH &&
+ git-checkout-cache -u -f -q -a &&
echo bozbar bozbar >bozbar &&
git-update-cache --add bozbar &&
if read_tree_twoway $treeH $treeM; then false; else :; fi'
@@ -210,6 +246,8 @@ test_expect_success \
test_expect_success \
'17 - conflicting local change.' \
'rm -f .git/index &&
+ git-read-tree $treeH &&
+ git-checkout-cache -u -f -q -a &&
echo bozbar bozbar >bozbar &&
git-update-cache --add bozbar &&
echo bozbar bozbar bozbar >bozbar &&
@@ -218,7 +256,9 @@ test_expect_success \
test_expect_success \
'18 - local change already having a good result.' \
'rm -f .git/index &&
- echo gnusto >bozbar &&
+ git-read-tree $treeH &&
+ git-checkout-cache -u -f -q -a &&
+ cat bozbar-new >bozbar &&
git-update-cache --add bozbar &&
read_tree_twoway $treeH $treeM &&
git-ls-files --stage >18.out &&
@@ -228,7 +268,9 @@ test_expect_success \
test_expect_success \
'19 - local change already having a good result, further modified.' \
'rm -f .git/index &&
- echo gnusto >bozbar &&
+ git-read-tree $treeH &&
+ git-checkout-cache -u -f -q -a &&
+ cat bozbar-new >bozbar &&
git-update-cache --add bozbar &&
echo gnusto gnusto >bozbar &&
read_tree_twoway $treeH $treeM &&
@@ -239,7 +281,9 @@ test_expect_success \
test_expect_success \
'20 - no local change, use new tree.' \
'rm -f .git/index &&
- echo bozbar >bozbar &&
+ git-read-tree $treeH &&
+ git-checkout-cache -u -f -q -a &&
+ cat bozbar-old >bozbar &&
git-update-cache --add bozbar &&
read_tree_twoway $treeH $treeM &&
git-ls-files --stage >20.out &&
@@ -249,11 +293,23 @@ test_expect_success \
test_expect_success \
'21 - no local change, dirty cache.' \
'rm -f .git/index &&
- echo bozbar >bozbar &&
+ git-read-tree $treeH &&
+ git-checkout-cache -u -f -q -a &&
+ cat bozbar-old >bozbar &&
git-update-cache --add bozbar &&
echo gnusto gnusto >bozbar &&
if read_tree_twoway $treeH $treeM; then false; else :; fi'
+# This fails with straight two-way fast forward.
+test_expect_success \
+ '22 - local change cache updated.' \
+ 'rm -f .git/index &&
+ git-read-tree $treeH &&
+ git-checkout-cache -u -f -q -a &&
+ sed -e "s/such as/SUCH AS/" bozbar-old >bozbar &&
+ git-update-cache --add bozbar &&
+ if read_tree_twoway $treeH $treeM; then false; else :; fi'
+
# Also make sure we did not break DF vs DF/DF case.
test_expect_success \
'DF vs DF/DF case setup.' \
diff --git a/t/t1005-read-tree-m-2way-emu23.sh b/t/t1005-read-tree-m-2way-emu23.sh
--- a/t/t1005-read-tree-m-2way-emu23.sh
+++ b/t/t1005-read-tree-m-2way-emu23.sh
@@ -32,7 +32,6 @@ read_tree_twoway () {
_x40='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]'
_x40="$_x40$_x40$_x40$_x40$_x40$_x40$_x40$_x40"
compare_change () {
- cat current
sed -n >current \
-e '/^--- /d; /^+++ /d; /^@@ /d;' \
-e 's/^\([-+][0-7][0-7][0-7][0-7][0-7][0-7]\) '"$_x40"' /\1 X /p' \
@@ -60,11 +59,22 @@ check_stages () {
diff -u expected_stages current_stages
}
+cat >bozbar-old <<\EOF
+This is a sample file used in two-way fast forward merge
+tests. Its second line ends with a magic word bozbar
+which will be modified by the merged head to gnusto.
+It has some extra lines so that external tools can
+successfully merge independent changes made to later
+lines (such as this one), avoiding line conflicts.
+EOF
+
+sed -e 's/bozbar/gnusto (earlier bozbar)/' bozbar-old >bozbar-new
+
test_expect_success \
setup \
'echo frotz >frotz &&
echo nitfol >nitfol &&
- echo bozbar >bozbar &&
+ cat bozbar-old >bozbar &&
echo rezrov >rezrov &&
echo yomin >yomin &&
git-update-cache --add nitfol bozbar rezrov &&
@@ -72,7 +82,7 @@ test_expect_success \
echo treeH $treeH &&
git-ls-tree $treeH &&
- echo gnusto >bozbar &&
+ cat bozbar-new >bozbar &&
git-update-cache --add frotz bozbar --force-remove rezrov &&
git-ls-files --stage >M.out &&
treeM=`git-write-tree` &&
@@ -106,6 +116,8 @@ echo '+100644 X 0 yomin' >expected
test_expect_success \
'4 - carry forward local addition.' \
'rm -f .git/index &&
+ git-read-tree $treeH &&
+ git-checkout-cache -u -f -q -a &&
git-update-cache --add yomin &&
read_tree_twoway $treeH $treeM &&
git-ls-files --stage >4.out || exit
@@ -118,6 +130,8 @@ test_expect_success \
test_expect_success \
'5 - carry forward local addition.' \
'rm -f .git/index &&
+ git-read-tree $treeH &&
+ git-checkout-cache -u -f -q -a &&
echo yomin >yomin &&
git-update-cache --add yomin &&
echo yomin yomin >yomin &&
@@ -132,6 +146,8 @@ test_expect_success \
test_expect_success \
'6 - local addition already has the same.' \
'rm -f .git/index &&
+ git-read-tree $treeH &&
+ git-checkout-cache -u -f -q -a &&
git-update-cache --add frotz &&
read_tree_twoway $treeH $treeM &&
git-ls-files --stage >6.out &&
@@ -143,6 +159,8 @@ test_expect_success \
test_expect_success \
'7 - local addition already has the same.' \
'rm -f .git/index &&
+ git-read-tree $treeH &&
+ git-checkout-cache -u -f -q -a &&
echo frotz >frotz &&
git-update-cache --add frotz &&
echo frotz frotz >frotz &&
@@ -154,6 +172,8 @@ test_expect_success \
test_expect_success \
'8 - conflicting addition.' \
'rm -f .git/index &&
+ git-read-tree $treeH &&
+ git-checkout-cache -u -f -q -a &&
echo frotz frotz >frotz &&
git-update-cache --add frotz &&
if read_tree_twoway $treeH $treeM; then false; else :; fi'
@@ -161,6 +181,8 @@ test_expect_success \
test_expect_success \
'9 - conflicting addition.' \
'rm -f .git/index &&
+ git-read-tree $treeH &&
+ git-checkout-cache -u -f -q -a &&
echo frotz frotz >frotz &&
git-update-cache --add frotz &&
echo frotz >frotz &&
@@ -169,6 +191,8 @@ test_expect_success \
test_expect_success \
'10 - path removed.' \
'rm -f .git/index &&
+ git-read-tree $treeH &&
+ git-checkout-cache -u -f -q -a &&
echo rezrov >rezrov &&
git-update-cache --add rezrov &&
read_tree_twoway $treeH $treeM &&
@@ -178,6 +202,8 @@ test_expect_success \
test_expect_success \
'11 - dirty path removed.' \
'rm -f .git/index &&
+ git-read-tree $treeH &&
+ git-checkout-cache -u -f -q -a &&
echo rezrov >rezrov &&
git-update-cache --add rezrov &&
echo rezrov rezrov >rezrov &&
@@ -186,6 +212,8 @@ test_expect_success \
test_expect_success \
'12 - unmatching local changes being removed.' \
'rm -f .git/index &&
+ git-read-tree $treeH &&
+ git-checkout-cache -u -f -q -a &&
echo rezrov rezrov >rezrov &&
git-update-cache --add rezrov &&
if read_tree_twoway $treeH $treeM; then false; else :; fi'
@@ -193,6 +221,8 @@ test_expect_success \
test_expect_success \
'13 - unmatching local changes being removed.' \
'rm -f .git/index &&
+ git-read-tree $treeH &&
+ git-checkout-cache -u -f -q -a &&
echo rezrov rezrov >rezrov &&
git-update-cache --add rezrov &&
echo rezrov >rezrov &&
@@ -206,6 +236,8 @@ EOF
test_expect_success \
'14 - unchanged in two heads.' \
'rm -f .git/index &&
+ git-read-tree $treeH &&
+ git-checkout-cache -u -f -q -a &&
echo nitfol nitfol >nitfol &&
git-update-cache --add nitfol &&
read_tree_twoway $treeH $treeM &&
@@ -217,6 +249,8 @@ test_expect_success \
test_expect_success \
'15 - unchanged in two heads.' \
'rm -f .git/index &&
+ git-read-tree $treeH &&
+ git-checkout-cache -u -f -q -a &&
echo nitfol nitfol >nitfol &&
git-update-cache --add nitfol &&
echo nitfol nitfol nitfol >nitfol &&
@@ -233,6 +267,8 @@ test_expect_success \
test_expect_success \
'16 - conflicting local change.' \
'rm -f .git/index &&
+ git-read-tree $treeH &&
+ git-checkout-cache -u -f -q -a &&
echo bozbar bozbar >bozbar &&
git-update-cache --add bozbar &&
git-read-tree --emu23 $treeH $treeM &&
@@ -249,6 +285,8 @@ EOF
test_expect_success \
'17 - conflicting local change.' \
'rm -f .git/index &&
+ git-read-tree $treeH &&
+ git-checkout-cache -u -f -q -a &&
echo bozbar bozbar >bozbar &&
git-update-cache --add bozbar &&
echo bozbar bozbar bozbar >bozbar &&
@@ -257,7 +295,9 @@ test_expect_success \
test_expect_success \
'18 - local change already having a good result.' \
'rm -f .git/index &&
- echo gnusto >bozbar &&
+ git-read-tree $treeH &&
+ git-checkout-cache -u -f -q -a &&
+ cat bozbar-new >bozbar &&
git-update-cache --add bozbar &&
read_tree_twoway $treeH $treeM &&
git-ls-files --stage >18.out &&
@@ -267,7 +307,9 @@ test_expect_success \
test_expect_success \
'19 - local change already having a good result, further modified.' \
'rm -f .git/index &&
- echo gnusto >bozbar &&
+ git-read-tree $treeH &&
+ git-checkout-cache -u -f -q -a &&
+ cat bozbar-new >bozbar &&
git-update-cache --add bozbar &&
echo gnusto gnusto >bozbar &&
read_tree_twoway $treeH $treeM &&
@@ -278,7 +320,9 @@ test_expect_success \
test_expect_success \
'20 - no local change, use new tree.' \
'rm -f .git/index &&
- echo bozbar >bozbar &&
+ git-read-tree $treeH &&
+ git-checkout-cache -u -f -q -a &&
+ cat bozbar-old >bozbar &&
git-update-cache --add bozbar &&
read_tree_twoway $treeH $treeM &&
git-ls-files --stage >20.out &&
@@ -288,11 +332,31 @@ test_expect_success \
test_expect_success \
'21 - no local change, dirty cache.' \
'rm -f .git/index &&
- echo bozbar >bozbar &&
+ git-read-tree $treeH &&
+ git-checkout-cache -u -f -q -a &&
+ cat bozbar-old >bozbar &&
git-update-cache --add bozbar &&
echo gnusto gnusto >bozbar &&
if read_tree_twoway $treeH $treeM; then false; else :; fi'
+echo '-100644 X 0 bozbar
++100644 X 0 bozbar' >expected
+
+# This fails with straight two-way fast forward, but emu23
+# can merge them.
+test_expect_success \
+ '22 - local change cache updated.' \
+ 'rm -f .git/index &&
+ git-read-tree $treeH &&
+ git-checkout-cache -u -f -q -a &&
+ sed -e "s/such as/SUCH AS/" bozbar-old >bozbar &&
+ git-update-cache --add bozbar &&
+ read_tree_twoway $treeH $treeM &&
+ git-ls-files --stage >22.out || exit
+ diff -u M.out 22.out >22diff.out
+ compare_change 22diff.out &&
+ check_cache_at bozbar clean'
+
# Also make sure we did not break DF vs DF/DF case.
test_expect_success \
'DF vs DF/DF case setup.' \
@@ -324,4 +388,20 @@ test_expect_success \
check_cache_at DF/DF clean && # different from pure 2-way
:'
+# Emu23 can grok I having more than H. Make sure we did not
+# botch the conflict tests (Linus code botches this test).
+test_expect_success \
+ 'DF vs DF/DF case test (#2).' \
+ 'rm -f .git/index &&
+ rm -fr DF &&
+ mkdir DF &&
+ echo DF/DF >DF/DF &&
+ git-update-cache --add DF/DF &&
+ # This should fail because I and H have a conflict
+ # at DF.
+ if git-read-tree --emu23 $treeDF $treeDFDF
+ then true ;# should be false
+ else false ;# should be true
+ fi'
+
test_done
------------
^ permalink raw reply
* [PATCH 1/3] git-commit-script: get commit message from an existing one.
From: Junio C Hamano @ 2005-06-23 23:27 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <7v4qbofym7.fsf_-_@assigned-by-dhcp.cox.net>
With -m flag specified, git-commit-script takes the commit
message along with author information from an existing commit.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
*** Linus, I suspect that date.c mishandles the raw date; I am
*** consistently getting 7 hours off and my machine runs in
*** US/Pacific (-0700) timezone.
git-commit-script | 75 +++++++++++++++++++++++++++++++++++++++++++++++------
1 files changed, 67 insertions(+), 8 deletions(-)
diff --git a/git-commit-script b/git-commit-script
--- a/git-commit-script
+++ b/git-commit-script
@@ -1,12 +1,37 @@
#!/bin/sh
+#
+# Copyright (c) 2005 Linus Torvalds
+#
+
+usage () {
+ echo 'git commit [-m existing-commit] [<path>...]'
+ exit 1
+}
+
: ${GIT_DIR=.git}
-if [ ! -d $GIT_DIR ]; then
+if [ ! -d "$GIT_DIR" ]; then
echo Not a git directory 1>&2
exit 1
fi
+while case "$#" in 0) break ;; esac
+do
+ case "$1" in
+ -m) shift
+ case "$#" in
+ 0) usage ;;
+ *) use_commit=`git-rev-parse "$1"` ||
+ exit ;;
+ esac
+ ;;
+ *) break
+ ;;
+ esac
+ shift
+done
+
git-update-cache -q --refresh -- "$@" || exit 1
PARENTS="-p HEAD"
-if [ ! -r $GIT_DIR/HEAD ]; then
+if [ ! -r "$GIT_DIR/HEAD" ]; then
if [ -z "$(git-ls-files)" ]; then
echo Nothing to commit 1>&2
exit 1
@@ -20,7 +45,7 @@ if [ ! -r $GIT_DIR/HEAD ]; then
) > .editmsg
PARENTS=""
else
- if [ -f $GIT_DIR/MERGE_HEAD ]; then
+ if [ -f "$GIT_DIR/MERGE_HEAD" ]; then
echo "#"
echo "# It looks like your may be committing a MERGE."
echo "# If this is not correct, please remove the file"
@@ -28,8 +53,38 @@ else
echo "# and try again"
echo "#"
PARENTS="-p HEAD -p MERGE_HEAD"
- fi > .editmsg
- git-status-script >> .editmsg
+ elif test "$use_commit" != ""
+ then
+ pick_author_script='
+ /^author /{
+ h
+ s/^author \([^<]*\) <[^>]*> .*$/\1/
+ s/'\''/'\''\'\'\''/g
+ s/.*/GIT_AUTHOR_NAME='\''&'\''/p
+
+ g
+ s/^author [^<]* <\([^>]*\)> .*$/\1/
+ s/'\''/'\''\'\'\''/g
+ s/.*/GIT_AUTHOR_EMAIL='\''&'\''/p
+
+ g
+ s/^author [^<]* <[^>]*> \(.*\)$/\1/
+ s/'\''/'\''\'\'\''/g
+ s/.*/GIT_AUTHOR_DATE='\''&'\''/p
+
+ q
+ }
+ '
+ set_author_env=`git-cat-file commit "$use_commit" |
+ sed -ne "$pick_author_script"`
+ eval "$set_author_env"
+ export GIT_AUTHOR_NAME
+ export GIT_AUTHOR_EMAIL
+ export GIT_AUTHOR_DATE
+ git-cat-file commit "$use_commit" |
+ sed -e '1,/^$/d'
+ fi >.editmsg
+ git-status-script >>.editmsg
fi
if [ "$?" != "0" ]
then
@@ -37,13 +92,17 @@ then
rm .editmsg
exit 1
fi
-${VISUAL:-${EDITOR:-vi}} .editmsg
+case "$use_commit" in
+'')
+ ${VISUAL:-${EDITOR:-vi}} .editmsg
+ ;;
+esac
grep -v '^#' < .editmsg | git-stripspace > .cmitmsg
[ -s .cmitmsg ] &&
tree=$(git-write-tree) &&
commit=$(cat .cmitmsg | git-commit-tree $tree $PARENTS) &&
- echo $commit > $GIT_DIR/HEAD &&
- rm -f -- $GIT_DIR/MERGE_HEAD
+ echo $commit > "$GIT_DIR/HEAD" &&
+ rm -f -- "$GIT_DIR/MERGE_HEAD"
ret="$?"
rm -f .cmitmsg .editmsg
exit "$ret"
------------
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox