* Re: Updated git HOWTO for kernel hackers
From: Dave Jones @ 2005-06-22 22:40 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Linux Kernel, Git Mailing List
In-Reply-To: <42B9E536.60704@pobox.com>
On Wed, Jun 22, 2005 at 06:24:54PM -0400, Jeff Garzik wrote:
>
> Things in git-land are moving at lightning speed, and usability has
> improved a lot since my post a month ago: http://lkml.org/lkml/2005/5/26/11
>
>
>
> 1) installing git
>
> git requires bootstrapping, since you must have git installed in order
> to check out git.git (git repo), and linux-2.6.git (kernel repo). I
> have put together a bootstrap tarball of today's git repository.
>
> Download tarball from:
> http://www.kernel.org/pub/linux/kernel/people/jgarzik/git-20050622.tar.bz2
<blatant self-promotion>
daily snapshots (refreshed once an hour) are available at:
http://www.codemonkey.org.uk/projects/git-snapshots/git/
</blatant self-promotion>
> tarball build-deps: zlib, libcurl, libcrypto (openssl)
>
> install tarball: unpack && make && sudo make prefix=/usr/local install
the sudo thing isn't necessary. make install by itself installs it
in ~/bin/ just fine.
> After reading the rest of this document, come back and update your copy
> of git to the latest:
> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/git.git
See above, which allows you to skip this step ;)
Dave
^ permalink raw reply
* Updated git HOWTO for kernel hackers
From: Jeff Garzik @ 2005-06-22 22:24 UTC (permalink / raw)
To: Linux Kernel; +Cc: Git Mailing List
Things in git-land are moving at lightning speed, and usability has
improved a lot since my post a month ago: http://lkml.org/lkml/2005/5/26/11
1) installing git
git requires bootstrapping, since you must have git installed in order
to check out git.git (git repo), and linux-2.6.git (kernel repo). I
have put together a bootstrap tarball of today's git repository.
Download tarball from:
http://www.kernel.org/pub/linux/kernel/people/jgarzik/git-20050622.tar.bz2
tarball build-deps: zlib, libcurl, libcrypto (openssl)
install tarball: unpack && make && sudo make prefix=/usr/local install
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
After reading the rest of this document, come back and update your copy
of git to the latest:
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/git.git
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/
3) update local kernel tree to latest 2.6.x upstream ("fast-forward merge")
$ cd linux-2.6
$ git-pull-script \
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
4) check out files from the git repository into the working directory
$ git checkout -f
5) check in your own modifications (e.g. do some hacking, or apply a patch)
# go to repo
$ cd linux-2.6
# make some modifications
$ patch -sp1 < /tmp/my.patch
$ diffstat -p1 < /tmp/my.patch
# NOTE: add '--add' and/or '--remove' if files were added or removed
$ git-update-cache <list of all files changed>
# check in changes
$ git commit
6) List all changes in working dir, in diff format.
$ git-diff-cache -p HEAD
7) List all changesets (i.e. show each cset's description text) in local
branch of local tree, that are not present in remote tree.
$ cd my-kernel-tree-2.6
$ git-changes-script -L ../linux-2.6 | less
8) List all changesets:
$ git-whatchanged
9) apply all patches in a Berkeley mbox-format file
First, download and add to your PATH Linus's git tools:
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/git-tools.git
$ cd my-kernel-tree-2.6
$ dotest /path/to/mbox # yes, Linus has no taste in naming scripts
10) don't forget to download tags from time to time.
git-pull-script only downloads sha1-indexed object data, and the
requested remote head. This misses updates to the .git/refs/tags/ and
.git/refs/heads directories. It is advisable to update your kernel .git
directories periodically with a full rsync command, to make sure you got
everything:
$ 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/
11) list all branches, such as those found in my netdev-2.6 or
libata-dev trees.
Download
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
or
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
$ cd netdev-2.6
$ ls .git/refs/heads/
{ these are the current netdev-2.6 branches }
> 8139cp forcedeth master qeth smc91x we18
> 8139too-iomap for-linus natsemi r8169 smc91x-eeprom wifi
> airo hdlc ns83820 register-netdev starfire
> atmel ieee80211 orinoco remove-drivers tlan
> chelsio iff-running orinoco-hch sis900 veth
> dm9000 janitor ppp skge viro
12) make desired branch current in working directory
$ git checkout -f $branch
13) create a new branch, and make it current
$ cp .git/refs/heads/master .git/refs/heads/my-new-branch-name
$ git checkout -f my-new-branch-name
14) examine which branch is current
$ ls -l .git/HEAD
15) undo all local modifications (same as checkout):
$ git checkout -f
16) obtain a diff between current branch, and master branch
In most trees WITH BRANCHES, .git/refs/heads/master contains the current
'vanilla' upstream tree, for easy diffing and merging. (in trees
without branches, 'master' simply contains your latest changes)
$ git-diff-tree -p master HEAD
^ permalink raw reply
* Re: Patch (apply) vs. Pull
From: Linus Torvalds @ 2005-06-22 22:21 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.21.0506221654550.30848-100000@iabervon.org>
On Wed, 22 Jun 2005, Daniel Barkalow wrote:
>
> Do you actually modify patches before applying them, rather than applying
> them and the fixing the resulting files? I've never managed to modify
> content in a patch (aside from dropping hunks) without upsetting patch.
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.
The most common form of editing is just removing single fragments, or
fixing up whitespace. Quite often people send me patches that don't even
apply, because whitespace got corrupted either because their mailer ate
it, or simply because they cut-and-pasted the patch. So I end up fixing
things up, and the end result may not actually match the original one
byte-for-byte, even if it matches visually.
Similarly, the "remove patch fragments" is often because somebody mixes up
two things in a patch, and I decide to take one of them but there's some
problem with the other. Sometimes that patch fragment thing means that I
have to edit even within one fragment, and fix up the patch line-counters
etc.
NOTE! This is "rare" in the sense that it doesn't happen for most patches,
but that said, I get a _lot_ of patches, and it's not rare in the sense
that it doesn't happen weekly.
So for example, I did one such edit just Monday in the "sparse" project,
where Peter Jones sent me a patch that added parsing for a lot of new gcc
attributes (good), but he had also done some other things that weren't
quite ready yet (bad). And because they were easy to separate out in the
patch, I just did it right there instead of asking him to do it for me and
re-sending.
> If you apply them and then fix things, the ID (and for that matter, the
> hash) will be safely conveyed from my system to yours and available for
> the commit to mention.
I don't want crap in my code. I disagree very strongly with people who say
that "you can just fix it later". That's not how people work, and worst of
all, not only does it not get fixed up, even _if_ it is fixed up the wrong
version inevitably ends up showing up somewhere else, just because
somebody ended up using the original patch.
So I want things to be cleaned up before they hit the tree, rather than
have a really dirty history. A dirty history just makes it harder to read,
and I don't believe in a second that it's "closer to reality" like some
people claim.
I don't believe anybody wants to see the "true" history. If they did, we'd
be logging keystrokes, and sending all of that around. Nope, people want
(and need, in order to be able to follow it) an "idealized" history.
> I believe there are separate issues here:
>
> 1. pure history rewriting: maintainer merges a developer's
> intermediate head; developer generates a new history in which
> everything later is based on the new mainline.
> 2. patches: changes are transferred as diffs over SMTP instead of trees
> inside git.
> 3. cherry-picking: maintainer applies some set of changes from a
> developer which is not merging a head the developer created.
>
> I think (1) is easily handled as a merge script that goes through a series
> of commits and makes a new series out of merging each of them, rather than
> merging the last of them only.
Yes. And I think (1) is pretty useful on its own, and that git could
support that with a nice helper script.
> I think (2) should be as transparent as possible, and, in cases where
> there was no cherry-picking, be equivalent in the system's behavior to the
> result of pull and merge (with the possibility for various cleanup
> happening on top of or along with the merge in either method).
I really see patches as something totally different than merging. I
literally see them as a way to move between different systems.
For example, the git model just doesn't work very well for "fluid"
development: git ends up setting history entirely in stone, which means
that you can't fix up mistakes later. And this is where patches come in:
they work as a way to transfer the information, while at the same time
totally breaking the connection with the original messy tree.
So I really think our view on what "patches" are is very fundamentally
different. I don't think SMTP is a good medium for merges: BK actually
supports that with "bk send" (or something like that) and I refused to use
it. It was a "worst of both worlds" thing.
> The tricky part is (3), which is currently only possible by going outside
> of git. But I think that this is something to tackle separately from
> (1) and (2) (where (2) does not involve doing (3)).
I think the cherry-picking kind of goes hand in hand with 1/2, though.
Patches are really the perfect form of cherry-picking, exactly because
they do _not_ imply a very strong ordering or even a very strong
dependency on the state of the rest of the sources. So patches end up
being the perfect medium for cherry-picking, and SMTP ends up being one of
the best ways to transport them and let them evolve.
And then (1) ends up often being the way the patches actually get
generated in the first place. So these things are intertwined, I think.
Linus
^ permalink raw reply
* Re: Patch (apply) vs. Pull
From: Daniel Barkalow @ 2005-06-22 21:54 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.58.0506221315201.2353@ppc970.osdl.org>
On Wed, 22 Jun 2005, Linus Torvalds wrote:
> I do realize that people use patch ID's inside various companies already,
> because it's a nice way to track things. But the fact is, especially with
> the patch going outside the SCM (which is the whole _point_ here, after
> all), any modifications will make that ID be dubious.
If this were done within the system, the maintainer would merge a commit
from the author, commit, fix up the whitespace, commit, and push out the
result. The developer then sees that the head was merged, and that
whitespace changes were applied on top of that.
The benefit to an ID that doesn't get changed is that the developer (or
the developer's scripts) can tell that the patch is an ancestor of the new
base tree, which is really important information about maintainer
intent: the remnant in this case is a revert of the maintainer's
changes to the patch, not an independant but conflicting patch.
> And if it _isn't_ modified, then the ID is pointless - you might as well
> use the SHA1 of the patch itself as its ID, ie not use an explicit ID at
> all.
My thought was actually to use the hash as the ID, and add headers for
"this patch is a descendant of <other-ID>" as it gets tweaked.
But even in the case where the patch is not modified, the developer can't
retrieve the hash of the applied patch, because it may have applied with
fuzz, in which case diffing the parent's tree with the tree wouldn't
generate a byte-for-byte identical patch. So it would be worth having the
commit store the hash of the submitted patch in a header anyway.
> So I think introducing extra ID's in the process only creates the
> possibility for more confusion. Either the patch is unmodified (and the ID
> is not needed in the first place) or the patch is modified (and the ID
> doesn't convey that).
Do you actually modify patches before applying them, rather than applying
them and the fixing the resulting files? I've never managed to modify
content in a patch (aside from dropping hunks) without upsetting patch. If
you apply them and then fix things, the ID (and for that matter, the
hash) will be safely conveyed from my system to yours and available for
the commit to mention.
> Which of course is ok, but it's _not_ what I'm interested in if we're
> discussing trying to make git itself have some support for "end-developer
> merges" (re-write history) as opposed to "maintainer merges" (merge
> history).
I believe there are separate issues here:
1. pure history rewriting: maintainer merges a developer's
intermediate head; developer generates a new history in which
everything later is based on the new mainline.
2. patches: changes are transferred as diffs over SMTP instead of trees
inside git.
3. cherry-picking: maintainer applies some set of changes from a
developer which is not merging a head the developer created.
I think (1) is easily handled as a merge script that goes through a series
of commits and makes a new series out of merging each of them, rather than
merging the last of them only.
I think (2) should be as transparent as possible, and, in cases where
there was no cherry-picking, be equivalent in the system's behavior to the
result of pull and merge (with the possibility for various cleanup
happening on top of or along with the merge in either method).
The tricky part is (3), which is currently only possible by going outside
of git. But I think that this is something to tackle separately from
(1) and (2) (where (2) does not involve doing (3)).
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* The coolest merge EVER!
From: Linus Torvalds @ 2005-06-22 21:46 UTC (permalink / raw)
To: Git Mailing List
Ok, Junio had some cool octopus merges, but I just one-upped him.
I just merged the "gitk" repository into git, and I did it as a real git
merge, which means that I actually retained all the original gitk
repository information intact. IOW, it's not a "import the data" thing,
it's literally a merge of the two trees, and the result has two roots.
Now, the advantage of this kind of merge is that Paul's original gitk
repository is totally unaffected by it, yet because I now have his history
(and the exact same objects), the normal kind of git merge should work
fine for me to continue to import Paul's work - we have the common parent
needed to resolve all differences.
Now, I don't know how often this ends up being actually used in practice,
but at least in theory this is a totally generic thing, where you create a
"union" of two git trees. I did the union merge manually, but in theory it
should be easy to automate, with simply something like
git fetch <project-to-union-merge>
GIT_INDEX_FILE=.git/tmp-index git-read-tree FETCH_HEAD
GIT_INDEX_FILE=.git/tmp-index git-checkout-cache -a -u
git-update-cache --add -- (GIT_INDEX_FILE=.git/tmp-index git-ls-files)
cp .git/FETCH_HEAD .git/MERGE_HEAD
git commit
(this is not exactly how I did it, but that's just because I'd never done
this before so I didn't think it through and I had some stupid extra steps
in between that were unnecessary).
Of course, in order for the union merge to work, the namespaces have to be
fit on top of each other with no clashes, otherwise future merges will be
quite painful. In the case of gitk, Paul's repository only tracked that
single file, so that wasn't a problem.
Anyway, you shouldn't notice anything new, except for the fact that "gitk"
now gets automatically included with the base git distribution. And the
git repository has two roots, but hey, git itself doesn't care.
Linus
^ permalink raw reply
* Re: Patch (apply) vs. Pull
From: Linus Torvalds @ 2005-06-22 20:22 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.21.0506221350130.30848-100000@iabervon.org>
On Wed, 22 Jun 2005, Daniel Barkalow wrote:
>
> If each patch is given an ID by the author (not committer) which is
> preserved across various later modifications, we could at least recognize
> which patch it was.
I really don't like it.
I do realize that people use patch ID's inside various companies already,
because it's a nice way to track things. But the fact is, especially with
the patch going outside the SCM (which is the whole _point_ here, after
all), any modifications will make that ID be dubious.
And if it _isn't_ modified, then the ID is pointless - you might as well
use the SHA1 of the patch itself as its ID, ie not use an explicit ID at
all.
So I think introducing extra ID's in the process only creates the
possibility for more confusion. Either the patch is unmodified (and the ID
is not needed in the first place) or the patch is modified (and the ID
doesn't convey that). Not to mention the fact that the ID then becomes
just another thing that can get corrupted or lost or just plain mistakenly
edited from another patch..
So while I do accept ID's in my workflow (the XFS guys use them to track
commits between their own internal system and the kernel releases), I
really don't like it as a primary mechanism. I think it's useful for
specific projects, but any such usefulness is exactly the fact that then
the tracking of the ID's is totally outside of git itself or any of the
processes of git users.
Which of course is ok, but it's _not_ what I'm interested in if we're
discussing trying to make git itself have some support for "end-developer
merges" (re-write history) as opposed to "maintainer merges" (merge
history).
Linus
^ permalink raw reply
* Re: Patch (apply) vs. Pull
From: Daniel Barkalow @ 2005-06-22 20:08 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.58.0506221009120.2353@ppc970.osdl.org>
On Wed, 22 Jun 2005, Linus Torvalds wrote:
> Anyway, it's not a trivial problem. You can search for patch matches in
> the patch history, but the thing is, that will fail whenever a patch was
> edited for whitespace etc (which does end up happening often enough to
> matter). The same goes even more for the commit messages (I routinely not
> only add my sign-off, of course, but also fix typo's I notice and often
> end up reformatting whitespace).
If each patch is given an ID by the author (not committer) which is
preserved across various later modifications, we could at least recognize
which patch it was. Then we could present the author with the information
that the patch was accepted and was modified, and give the author the
option of replacing it in the series with one that reverts some or all of
the modifications (including re-adding dropped portions). I don't see any
reason that it would be better to search for similarity rather than just
having things explicitly tagged (I think, although I'm not sure, that
authors will care about the difference between someone applying an
alternative patch and someone applying the author's patch with
modifications.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* git testsuite failures
From: David S. Miller @ 2005-06-22 19:18 UTC (permalink / raw)
To: git
There are test cases failing in the testsuite over the
past few days, is this expected?
*** t6001-rev-list-merge-order.sh ***
...
* FAIL 3: simple merge order check_output simple-merge-order git-rev-list --merge-order --show-breaks HEAD
* FAIL 4: two diamonds merge order (g6) check_output two-diamonds-merge-order-g6 git-rev-list --merge-order --show-breaks g4
...
* FAIL 8: cross-epoch, head at l5, prune at l1 check_output cross-epoch-head-at-l5-prune-at-l1 git-rev-list --merge-order l5 ^l1
* FAIL 9: duplicated head arguments check_output duplicated-head-arguments git-rev-list --merge-order l5 l5 ^l1
...
* FAIL 20: max-count 10 - merge order check_output max-count-10-merge-order git-rev-list --merge-order --show-breaks --max-count=10 l5
...
* FAIL 23: --max-age=c3, --merge-order check_output max-age-c3-merge-order git-rev-list --merge-order --max-age=51148811 l5
...
^ permalink raw reply
* Re: Patch (apply) vs. Pull
From: Linus Torvalds @ 2005-06-22 17:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmzpihi6x.fsf@assigned-by-dhcp.cox.net>
On Wed, 22 Jun 2005, Junio C Hamano wrote:
>
> Having said that, one automation I would benefit from is to
> automatically find patches that _have_ been accepted and drop
> them from my snapshot pool --- that part should be very easy to
> automate and I have not done so primarily because I _am_ lazy.
> I could call it git-cherry-drop ;-).
Andrew Morton does all of this with quilt, and it ends up being very
effective. Of course, the kernel has had almost 15 years of people making
it more and more modular, so the kernel really gets rejects very seldom
indeed, and it would probably not work as well for other projects
(including git) that tend to have tighter couplings, if for no other
reason than the fact that they are usually smaller.
Anyway, it's not a trivial problem. You can search for patch matches in
the patch history, but the thing is, that will fail whenever a patch was
edited for whitespace etc (which does end up happening often enough to
matter). The same goes even more for the commit messages (I routinely not
only add my sign-off, of course, but also fix typo's I notice and often
end up reformatting whitespace).
So at the very least, you'd have to have a fuzzy search (but exact enough
that you'd see if a part of a patch was dropped etc).
Linus
^ permalink raw reply
* Re: Patch (apply) vs. Pull
From: Catalin Marinas @ 2005-06-22 17:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Darrin Thompson, git
In-Reply-To: <7vbr61j631.fsf@assigned-by-dhcp.cox.net>
Have a look at StGIT for this, it might help.
Junio C Hamano <junkio@cox.net> wrote:
> FYI, here is what I have been doing:
>
> (1) Start from Linus HEAD.
>
> (2) Repeat develop-and-commit cycle.
Gather the related commits into an StGIT patch. It's actually easier
to only update a set of existing patches, similar to the quilt way.
stg new patch1
modify...
stg commit
modify...
stg commit
stg push/pop/new
etc.
> (3) Run "git format-patch" (not in Linus tree) to generate
> patches.
stg export. The problem with this one is that it doesn't preserve any
of the commit information but it can be adapted (though I'm not sure
it is worth since the patch won't be that readable).
> (4) Send them out and wait to see which one sticks.
>
> (5) Pull from Linus.
>
> (6) Throw away my HEAD, making Linus HEAD my HEAD, while
> preserving changes I have made since I forked from him. I
> use "jit-rewind" for this.
stg pop -a. This will remove all your changes grouped in stgit
patches. The HEAD is now Linus' old HEAD. Pull/merge will advance the
HEAD to Linus' latest HEAD.
> (7) Examine patches that Linus rejected, and apply ones that I
> still consider good, making one commit per patch. I use
> "jit-patch" and "jit-commit -m" for this.
stg push -a. This step will do a diff3 between the current HEAD and
the top of the patch as the two branches, and the bottom of the patch
as an ancestor.
If the patch was merged unmodified, stgit detects this and warns you
that the patch is now empty (it detects it even if a file contains
other modifications apart from yours). If you modified it in the
meantime or the Linus modified it when merged (or some other third
party patch modifies yours), you will get a conflict you can resolve.
> (8) Go back to step 2.
--
Catalin
^ permalink raw reply
* Re: Patch (apply) vs. Pull
From: Darrin Thompson @ 2005-06-22 16:23 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.58.0506211452110.2353@ppc970.osdl.org>
On Tue, 2005-06-21 at 15:09 -0700, Linus Torvalds wrote:
> However, as you point out, it's not necessarily the best kind of merge for
> the "individual developer" standpoint. Most individual developers don't
> necessarily want to merge their work, rather they want to "bring it
> forward" to the current tip. And I think git could help with that too.
>
That's a good way to put it.
> 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?
Here are two desirable things the might be tough to reconcile:
- The merging mechanism might benefit from knowing that your commit was
really originally my commit _if_ my history is relevant to the merge and
present.
- The rest of the world does _not_ want to have to keep my commits on
hand just to follow the mainline.
I imagine if those could be reconciled you'd hit a sweet spot.
A mechanism where those two were true might also provide better hooks
for knowing other things. For instance, which of these particular
commits of mine are not in the mainline tree?
Perhaps your mainline commit might refer to my humble commit as some
kind of sibling. You don't need to have it to follow the mainline, but
the data is there if it helps anybody.
--
Darrin
^ permalink raw reply
* Re: Patch (apply) vs. Pull
From: Catalin Marinas @ 2005-06-22 9:56 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Darrin Thompson, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.21.0506211337400.30848-100000@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> wrote:
> On Mon, 20 Jun 2005, Darrin Thompson wrote:
>> Would it make sense to come up with a way to make an emailed series of
>> patches represent a series of commits? Could patches still be
>> cherrypicked?
While you could cherry-pick a changeset generated by a commit
(i.e. the diff between the commit's tree and its parent), I found this
not to always be convenient. For example, a fix might need more than
one commit but there is no way to know how they relate and which
changesets to cherry-pick, unless somebody tells you exactly.
> Commits are fundamentally resistant to cherrypicking, because they give
> the state of the tree rather than expressing changes in that
> state. Long-term, I think that something like StGIT should be integrated
> into the system and deal with generating the HEAD you get after getting
> patches in.
With StGIT, you can gather many related commits into a patch. This
patch (i.e. a series of related commits) could be pulled into your
tree and pushed onto your stack of patches. StGIT should also allow
one to upgrade the pulled patch and re-applied onto the stack.
Thanks to Daniel's suggestion for multiple heads support, StGIT will
(in a future release) support pulling changes from a remote tree
together with the patch series information. After this is done,
applying patches from different branch (head) would be quite simple.
One problem is patch dependency tracking (i.e. you cannot push a patch
onto the stack if it expects a certain patch to be already
applied). Darcs does this by checking whether two patches can be
commuted. I have to think a bit more about how StGIT could handle
this.
--
Catalin
^ permalink raw reply
* Re: Patch (apply) vs. Pull
From: Junio C Hamano @ 2005-06-22 9:08 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0506211452110.2353@ppc970.osdl.org>
>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:
LT> and here the "git-cherry-pick" thing is just a script that basically takes
LT> an old commit ID, and tries to re-apply it as a patch (with author data
LT> and commit messages, of course) on top of the current head. It would
LT> basically be nothing more than a "git-diff-tree $1" followed by tryign to
LT> figure out whether it had already been applied or whether it can be
LT> applied now.
LT> What do you think?
What you outlined is essentially what I already do by using
jit-rewind, followed by a repeated use of (jit-patch and
jit-commit with -m flag). The reason I have not automated the
"repeat" part is _not_ because I am lazy, but because typically
the rejected things really need manual intervention, not for
mechanical (read: merge conflict) reasons, but for semantic
reasons, when some patches are accepted while some others are
not. Especially if I am not the sole supplier of patches to
your tree, my older patches usually need not just rebasing but
_rethinking_, so I myself do not find need for automating things
further that much from what I already have.
Having said that, one automation I would benefit from is to
automatically find patches that _have_ been accepted and drop
them from my snapshot pool --- that part should be very easy to
automate and I have not done so primarily because I _am_ lazy.
I could call it git-cherry-drop ;-).
^ permalink raw reply
* Re: [PATCH] link in gitweb rss feed
From: Kay Sievers @ 2005-06-22 9:25 UTC (permalink / raw)
To: Erik van Konijnenburg; +Cc: Git Mailing List
In-Reply-To: <20050615174148.C3099@banaan.localdomain>
On Wed, Jun 15, 2005 at 05:41:48PM +0200, Erik van Konijnenburg wrote:
> The following patch makes the site name in an RSS
> feedreader for a gitweb project refer to the summary
> page for the the project, the same place where you picked
> up the feed in the first place. This seems more consistent
> than linking to the overview of all projects where the
> link used to up. Changed the link in OPML feed accordingly;
> this used to end up in the full log rather than the summary.
>
> Patch was made against version 220 as shipped in Debian,
> and applies (with offset) to your version 221.
Should be installed with the last update on kernel.org.
Thanks,
Kay
^ permalink raw reply
* [PATCH] local-pull: implement fetch_ref()
From: Junio C Hamano @ 2005-06-22 8:52 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Daniel Barkalow, git
In-Reply-To: <Pine.LNX.4.21.0506212043540.30848-100000@iabervon.org>
This makes "-w ref" usable for git-local-pull.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Documentation/git-local-pull.txt | 7 +++++--
local-pull.c | 31 ++++++++++++++++++++++++++++---
2 files changed, 33 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-local-pull.txt b/Documentation/git-local-pull.txt
--- a/Documentation/git-local-pull.txt
+++ b/Documentation/git-local-pull.txt
@@ -9,7 +9,7 @@ git-local-pull - Duplicates another GIT
SYNOPSIS
--------
-'git-local-pull' [-c] [-t] [-a] [-l] [-s] [-n] [-v] [-d] [--recover] commit-id path
+'git-local-pull' [-c] [-t] [-a] [-d] [-v] [-w filename] [--recover] [-l] [-s] [-n] commit-id path
DESCRIPTION
-----------
@@ -32,10 +32,13 @@ OPTIONS
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
------
-Written by Linus Torvalds <torvalds@osdl.org>
+Written by Junio C Hamano <junkio@cox.net>
Documentation
--------------
diff --git a/local-pull.c b/local-pull.c
--- a/local-pull.c
+++ b/local-pull.c
@@ -9,7 +9,7 @@ static int use_link = 0;
static int use_symlink = 0;
static int use_filecopy = 1;
-static char *path;
+static char *path; /* "Remote" git repository */
int fetch(unsigned char *sha1)
{
@@ -75,11 +75,34 @@ int fetch(unsigned char *sha1)
int fetch_ref(char *ref, unsigned char *sha1)
{
- return -1;
+ static int ref_name_start = -1;
+ static char filename[PATH_MAX];
+ static char hex[41];
+ int ifd;
+
+ if (ref_name_start < 0) {
+ sprintf(filename, "%s/refs/", path);
+ ref_name_start = strlen(filename);
+ }
+ strcpy(filename + ref_name_start, ref);
+ ifd = open(filename, O_RDONLY);
+ if (ifd < 0) {
+ close(ifd);
+ fprintf(stderr, "cannot open %s\n", filename);
+ return -1;
+ }
+ if (read(ifd, hex, 40) != 40 || get_sha1_hex(hex, sha1)) {
+ close(ifd);
+ fprintf(stderr, "cannot read from %s\n", filename);
+ return -1;
+ }
+ close(ifd);
+ pull_say("ref %s\n", sha1_to_hex(sha1));
+ return 0;
}
static const char *local_pull_usage =
-"git-local-pull [-c] [-t] [-a] [-l] [-s] [-n] [-v] [-d] [--recover] commit-id path";
+"git-local-pull [-c] [-t] [-a] [-d] [-v] [-w filename] [--recover] [-l] [-s] [-n] commit-id path";
/*
* By default we only use file copy.
@@ -114,6 +137,8 @@ int main(int argc, char **argv)
use_filecopy = 0;
else if (argv[arg][1] == 'v')
get_verbosely = 1;
+ else if (argv[arg][1] == 'w')
+ write_ref = argv[++arg];
else
usage(local_pull_usage);
arg++;
------------------------------------------------
^ permalink raw reply
* Re: Patch (apply) vs. Pull
From: Junio C Hamano @ 2005-06-22 8:47 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.21.0506211337400.30848-100000@iabervon.org>
>>>>> "DB" == Daniel Barkalow <barkalow@iabervon.org> writes:
DB> On Mon, 20 Jun 2005, Darrin Thompson wrote:
>> On Mon, 2005-06-20 at 10:22 -0700, Junio C Hamano wrote:
>> > (6) Throw away my HEAD, making Linus HEAD my HEAD, while
>> > preserving changes I have made since I forked from him. I
>> > use "jit-rewind" for this.
>>
>> When you say it that way it sounds so _bad_. :-)
DB> The reason is actually that he has to end up with a different history,
Exactly. I _want_ to, not just _have_ to, end up with a
different history.
^ permalink raw reply
* git-prune-script eats data
From: Jeff Garzik @ 2005-06-22 0:51 UTC (permalink / raw)
To: Git Mailing List
Ok, I have a reproducible case (at least for me), of git-prune-script
munching data. I'll just give reproduction instructions (everyone
reading this can do what I did), and some output at the end.
$ cd /repos
$ mkdir libata-dev-test/.git
$ cd libata-dev-test
$ cp -al ../linux-2.6/.git/objects .git/
$ rsync -az --verbose --delete \
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git/
.git/ # word-wrapped from previous line
$ git-checkout-script -f
$ git-fsck-cache
dangling commit 1b142a71f3b131317489edf806abfab4c347476c
dangling commit 51a7f407d9b600e3278449a12135a21ffb0791a2
dangling commit eb93f3e7284204379444137a660b64f9dbd2ec04
dangling commit fcf604172829176bc618663e8387c8943ff88b66
NOTE: These dangling commits are NORMAL -- stuff that really does need
pruning.
$ git-prune-script
$ git-fsck-cache
error: cannot map sha1 file c39ae07f393806ccf406ef966e9a15afc43cc36a
bad object in tag 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c
bad sha1 entry '5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c'
$ rsync -az --verbose --delete \
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git/
.git/ # word-wrapped from previous line
# this second invocation downloads a TON of objects,
# most/all of which are in the vanilla linux-2.6 tree
# and should not have been pruned
^ permalink raw reply
* [PATCH] Pull refs by HTTP
From: Daniel Barkalow @ 2005-06-22 0:45 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds
This adds support for refs to http-pull, both the -w option and reading
the target from a served file.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Index: http-pull.c
===================================================================
--- b6a510708036fe29a19c33472f5c0b746e2d26d7/http-pull.c (mode:100644 sha1:f49525c00228b5db9dc2fbd4860883887bb7dbad)
+++ bc8b6802c7004e93b812698bd699c3548906653b/http-pull.c (mode:100644 sha1:ec53dad8efbe6e7734b75eaba8821ac290a5abbb)
@@ -16,6 +16,23 @@
static int local;
static int zret;
+struct buffer
+{
+ size_t posn;
+ size_t size;
+ void *buffer;
+};
+
+static size_t fwrite_buffer(void *ptr, size_t eltsize, size_t nmemb,
+ struct buffer *buffer) {
+ size_t size = eltsize * nmemb;
+ if (size > buffer->size - buffer->posn)
+ size = buffer->size - buffer->posn;
+ memcpy(buffer->buffer + buffer->posn, ptr, size);
+ buffer->posn += size;
+ return size;
+}
+
static size_t fwrite_sha1_file(void *ptr, size_t eltsize, size_t nmemb,
void *data) {
unsigned char expn[4096];
@@ -94,7 +111,32 @@
int fetch_ref(char *ref, unsigned char *sha1)
{
- return -1;
+ char *url, *posn;
+ char hex[42];
+ struct buffer buffer;
+ buffer.size = 41;
+ buffer.posn = 0;
+ buffer.buffer = hex;
+ hex[41] = '\0';
+
+ curl_easy_setopt(curl, CURLOPT_FILE, &buffer);
+ curl_easy_setopt(curl, CURLOPT_WRITEFUNCTION, fwrite_buffer);
+
+ url = xmalloc(strlen(base) + 6 + strlen(ref));
+ strcpy(url, base);
+ posn = url + strlen(base);
+ strcpy(posn, "refs/");
+ posn += 5;
+ strcpy(posn, ref);
+
+ curl_easy_setopt(curl, CURLOPT_URL, url);
+
+ if (curl_easy_perform(curl))
+ return error("Couldn't get %s for %s\n", url, ref);
+
+ hex[40] = '\0';
+ get_sha1_hex(hex, sha1);
+ return 0;
}
int main(int argc, char **argv)
@@ -118,11 +160,14 @@
get_history = 1;
} else if (argv[arg][1] == 'v') {
get_verbosely = 1;
+ } else if (argv[arg][1] == 'w') {
+ write_ref = argv[arg + 1];
+ arg++;
}
arg++;
}
if (argc < arg + 2) {
- usage("git-http-pull [-c] [-t] [-a] [-d] [-v] [--recover] commit-id url");
+ usage("git-http-pull [-c] [-t] [-a] [-d] [-v] [--recover] [-w ref] commit-id url");
return 1;
}
commit_id = argv[arg];
^ permalink raw reply
* [PATCH 2/2] Pull misc objects
From: Daniel Barkalow @ 2005-06-22 0:35 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds
In-Reply-To: <Pine.LNX.4.21.0506212029190.30848-100000@iabervon.org>
Make pull fetch whatever is specified, parse it to figure out what it is, and
then process it appropriately. This also supports getting tag objects, and
getting whatever they tag.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Index: pull.c
===================================================================
--- d0df139324abdbf701ffcae26e43bcb0350c270e/pull.c (mode:100644 sha1:e70fc02f3bf5b6c626a138d6d76d819fab76f0c8)
+++ b6a510708036fe29a19c33472f5c0b746e2d26d7/pull.c (mode:100644 sha1:91d9db6c7b1be84e7a5fe21c5194fbf22dadc8cb)
@@ -3,6 +3,8 @@
#include "cache.h"
#include "commit.h"
#include "tree.h"
+#include "tag.h"
+#include "blob.h"
#include "refs.h"
const char *write_ref = NULL;
@@ -57,6 +59,8 @@
return status;
}
+static int process_unknown(unsigned char *sha1);
+
static int process_tree(unsigned char *sha1)
{
struct tree *tree = lookup_tree(sha1);
@@ -115,6 +119,35 @@
return 0;
}
+static int process_tag(unsigned char *sha1)
+{
+ struct tag *obj = lookup_tag(sha1);
+
+ if (parse_tag(obj))
+ return -1;
+ return process_unknown(obj->tagged->sha1);
+}
+
+static int process_unknown(unsigned char *sha1)
+{
+ struct object *obj;
+ if (make_sure_we_have_it("object", sha1))
+ return -1;
+ obj = parse_object(sha1);
+ if (!obj)
+ return error("Unable to parse object %s", sha1_to_hex(sha1));
+ if (obj->type == commit_type)
+ return process_commit(sha1);
+ if (obj->type == tree_type)
+ return process_tree(sha1);
+ if (obj->type == blob_type)
+ return 0;
+ if (obj->type == tag_type)
+ return process_tag(sha1);
+ return error("Unable to determine requirement of type %s for %s",
+ obj->type, sha1_to_hex(sha1));
+}
+
static int interpret_target(char *target, unsigned char *sha1)
{
if (!get_sha1_hex(target, sha1))
@@ -142,7 +175,7 @@
if (interpret_target(target, sha1))
return error("Could not interpret %s as something to pull",
target);
- if (process_commit(sha1))
+ if (process_unknown(sha1))
return -1;
if (write_ref) {
^ permalink raw reply
* [PATCH 1/2] Parse tags for absent objects
From: Daniel Barkalow @ 2005-06-22 0:35 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds
In-Reply-To: <Pine.LNX.4.21.0506212029190.30848-100000@iabervon.org>
Handle parsing a tag for a non-present object. This adds a function to lookup
an object with lookup_* for * in a string, so that it can get the right storage
based on the "type" line in the tag.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Index: object.c
===================================================================
--- 5760644db3f9cb044c99aa0f9ce4fc8d4eb76da1/object.c (mode:100644 sha1:5e8378857028afeb4d1cd91c0de26c8414e137de)
+++ d0df139324abdbf701ffcae26e43bcb0350c270e/object.c (mode:100644 sha1:21f872ee163e9eeff1a52854791c5b96a2ec2ceb)
@@ -98,6 +98,22 @@
}
}
+struct object *lookup_object_type(const unsigned char *sha1, const char *type)
+{
+ if (!strcmp(type, blob_type)) {
+ return &lookup_blob(sha1)->object;
+ } else if (!strcmp(type, tree_type)) {
+ return &lookup_tree(sha1)->object;
+ } else if (!strcmp(type, commit_type)) {
+ return &lookup_commit(sha1)->object;
+ } else if (!strcmp(type, tag_type)) {
+ return &lookup_tag(sha1)->object;
+ } else {
+ error("Unknown type %s", type);
+ return NULL;
+ }
+}
+
struct object *parse_object(const unsigned char *sha1)
{
unsigned long mapsize;
Index: object.h
===================================================================
--- 5760644db3f9cb044c99aa0f9ce4fc8d4eb76da1/object.h (mode:100644 sha1:ca455d57117af5f15e83b791a336351b43af6716)
+++ d0df139324abdbf701ffcae26e43bcb0350c270e/object.h (mode:100644 sha1:1bd59ac6fcf7798e02c2474e630c282f022eff10)
@@ -21,8 +21,12 @@
extern int nr_objs;
extern struct object **objs;
+/** Internal only **/
struct object *lookup_object(const unsigned char *sha1);
+/** Returns the object, having looked it up as being the given type. **/
+struct object *lookup_object_type(const unsigned char *sha1, const char *type);
+
void created_object(const unsigned char *sha1, struct object *obj);
/** Returns the object, having parsed it to find out what it is. **/
Index: tag.c
===================================================================
--- 5760644db3f9cb044c99aa0f9ce4fc8d4eb76da1/tag.c (mode:100644 sha1:4041af2572a4427a03bc8955137b7d2211f9d770)
+++ d0df139324abdbf701ffcae26e43bcb0350c270e/tag.c (mode:100644 sha1:2b25fc0e1dc53234e38e8ed8fdc1cb99fa4fd84a)
@@ -28,6 +28,7 @@
int typelen, taglen;
unsigned char object[20];
const char *type_line, *tag_line, *sig_line;
+ char type[20];
if (item->object.parsed)
return 0;
@@ -38,10 +39,6 @@
if (memcmp("object ", data, 7) || get_sha1_hex(data + 7, object))
return -1;
- item->tagged = parse_object(object);
- if (item->tagged)
- add_ref(&item->object, item->tagged);
-
type_line = data + 48;
if (memcmp("\ntype ", type_line-1, 6))
return -1;
@@ -58,11 +55,17 @@
typelen = tag_line - type_line - strlen("type \n");
if (typelen >= 20)
return -1;
+ memcpy(type, type_line + 5, typelen);
+ type[typelen] = '\0';
taglen = sig_line - tag_line - strlen("tag \n");
item->tag = xmalloc(taglen + 1);
memcpy(item->tag, tag_line + 4, taglen);
item->tag[taglen] = '\0';
+ item->tagged = lookup_object_type(object, type);
+ if (item->tagged)
+ add_ref(&item->object, item->tagged);
+
return 0;
}
^ permalink raw reply
* [PATCH 0/2] Pull objects of various types
From: Daniel Barkalow @ 2005-06-22 0:33 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds
This series handles pulling objects of various types, rather than just
commits. In order to support pulling tags (the interesting case), it is
necessary to support getting the struct object for the tagged object when
the tagged object isn't available.
1: Support getting a valid struct object for the absent object tagged by
a tag file.
2: Support processing objects of unknown type in pull.c
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Patch (apply) vs. Pull
From: Linus Torvalds @ 2005-06-21 22:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Darrin Thompson, git
In-Reply-To: <7vbr61j631.fsf@assigned-by-dhcp.cox.net>
On Mon, 20 Jun 2005, Junio C Hamano wrote:
>
> FYI, here is what I have been doing:
>
> (1) Start from Linus HEAD.
>
> (2) Repeat develop-and-commit cycle.
>
> (3) Run "git format-patch" (not in Linus tree) to generate
> patches.
>
> (4) Send them out and wait to see which one sticks.
>
> (5) Pull from Linus.
>
> (6) Throw away my HEAD, making Linus HEAD my HEAD, while
> preserving changes I have made since I forked from him. I
> use "jit-rewind" for this.
>
> (7) Examine patches that Linus rejected, and apply ones that I
> still consider good, making one commit per patch. I use
> "jit-patch" and "jit-commit -m" for this.
>
> (8) Go back to step 2.
Btw, I'd like to help automate the 6-7 stage with a different kind of
merge logic.
The current "real merge" is the global history merge, and that's the kind
that I personally want to use, since that's what makes sense from a
"project lead" standpoint and for the people around me in the kernel space
that are project leaders of their own.
However, as you point out, it's not necessarily the best kind of merge for
the "individual developer" standpoint. Most individual developers don't
necessarily want to merge their work, rather they want to "bring it
forward" to the current tip. And I think git could help with that too.
It would be somewhat akin to the current git-merge-script, but instead of
merging it based on the common parent, it would instead try to re-base all
the local commits from the common parent onwards on top of the new remote
head. That often makes more sense from the standpoint of a individual
developer who wants to update his work to the remote head.
Something like this (this assumes FETCH_HEAD is the remote head that we
just fetched with "git fetch xxx" and that we want to re-base to):
- 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
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?
Linus
^ permalink raw reply
* Re: ORIG_HEAD
From: Linus Torvalds @ 2005-06-21 21:06 UTC (permalink / raw)
To: David S. Miller; +Cc: git
In-Reply-To: <20050620.221055.71088925.davem@davemloft.net>
On Mon, 20 Jun 2005, David S. Miller wrote:
>
> Is there a really good reason why git-pull-script runs are deleting
> that file now?
No. I've cleaned it up a bit, and codified the stuff we leave around.
I also changed "git fetch" to write FETCH_HEAD instead of MERGE_HEAD,
because that's obviously what it is (it's perfectly fine to fetch things
for other reasons, like just checking what somebody else has, and you
might not ever intend to merge it anyway).
Linus
^ permalink raw reply
* [PATCH] Fix several gcc4 signedness warnings
From: Mika Kukkonen @ 2005-06-21 20:04 UTC (permalink / raw)
To: torvalds; +Cc: git
Here is a patch that fixes several gcc4 warnings about different signedness,
all between char and unsigned char. I tried to keep the patch minimal
so resertod to casts in three places.
Signed-off-by: Mika Kukkonen <mikukkon@iki.fi>
mkdelta.c | 12 ++++++------
pull.c | 2 +-
sha1_file.c | 4 ++--
ssh-push.c | 2 +-
tar-tree.c | 4 ++--
5 files changed, 12 insertions(+), 12 deletions(-)
Index: git/sha1_file.c
===================================================================
--- git.orig/sha1_file.c
+++ git/sha1_file.c
@@ -332,7 +332,7 @@ int unpack_sha1_header(z_stream *stream,
void *unpack_sha1_rest(z_stream *stream, void *buffer, unsigned long size)
{
int bytes = strlen(buffer) + 1;
- char *buf = xmalloc(1+size);
+ unsigned char *buf = xmalloc(1+size);
memcpy(buf, buffer + bytes, stream->total_out - bytes);
bytes = stream->total_out - bytes;
@@ -472,7 +472,7 @@ int sha1_file_size(const unsigned char *
* The initial part of the delta starts at delta_data_head +
* 20. Borrow code from patch-delta to read the result size.
*/
- data = hdr + strlen(hdr) + 1 + 20;
+ data = (unsigned char *)(hdr + strlen(hdr) + 1 + 20);
/* Skip over the source size; we are not interested in
* it and we cannot verify it because we do not want
Index: git/ssh-push.c
===================================================================
--- git.orig/ssh-push.c
+++ git/ssh-push.c
@@ -8,7 +8,7 @@ unsigned char remote_version = 0;
int serve_object(int fd_in, int fd_out) {
ssize_t size;
int posn = 0;
- char sha1[20];
+ unsigned char sha1[20];
unsigned long objsize;
void *buf;
signed char remote;
Index: git/pull.c
===================================================================
--- git.orig/pull.c
+++ git/pull.c
@@ -49,7 +49,7 @@ static int make_sure_we_have_it(const ch
return 0;
if (get_delta) {
- char delta_sha1[20];
+ unsigned char delta_sha1[20];
status = sha1_delta_base(sha1, delta_sha1);
if (0 < status)
status = make_sure_we_have_it(what, delta_sha1);
Index: git/tar-tree.c
===================================================================
--- git.orig/tar-tree.c
+++ git/tar-tree.c
@@ -430,8 +430,8 @@ int main(int argc, char **argv)
if (!archive_time)
archive_time = time(NULL);
if (basedir)
- write_header("0", TYPEFLAG_DIR, NULL, NULL, basedir, 040755,
- NULL, 0);
+ write_header((unsigned char *)"0", TYPEFLAG_DIR, NULL, NULL,
+ basedir, 040755, NULL, 0);
traverse_tree(buffer, size, NULL);
free(buffer);
write_trailer();
Index: git/mkdelta.c
===================================================================
--- git.orig/mkdelta.c
+++ git/mkdelta.c
@@ -36,10 +36,10 @@ static int replace_object(char *buf, uns
return 0;
}
-static void *create_object(char *buf, unsigned long len, char *hdr, int hdrlen,
- unsigned long *retsize)
+static void *create_object(unsigned char *buf, unsigned long len,
+ char *hdr, int hdrlen, unsigned long *retsize)
{
- char *compressed;
+ unsigned char *compressed;
unsigned long size;
z_stream stream;
@@ -54,7 +54,7 @@ static void *create_object(char *buf, un
stream.avail_out = size;
/* First header.. */
- stream.next_in = hdr;
+ stream.next_in = (unsigned char *)hdr;
stream.avail_in = hdrlen;
while (deflate(&stream, 0) == Z_OK)
/* nothing */;
@@ -69,7 +69,7 @@ static void *create_object(char *buf, un
return compressed;
}
-static int restore_original_object(char *buf, unsigned long len,
+static int restore_original_object(unsigned char *buf, unsigned long len,
char *type, unsigned char *sha1)
{
char hdr[50];
@@ -84,7 +84,7 @@ static int restore_original_object(char
return ret;
}
-static void *create_delta_object(char *buf, unsigned long len,
+static void *create_delta_object(unsigned char *buf, unsigned long len,
unsigned char *sha1_ref, unsigned long *size)
{
char hdr[50];
^ permalink raw reply
* Re: Patch (apply) vs. Pull
From: Daniel Barkalow @ 2005-06-21 18:02 UTC (permalink / raw)
To: Darrin Thompson; +Cc: Junio C Hamano, git
In-Reply-To: <1119308502.3926.18.camel@localhost.localdomain>
On Mon, 20 Jun 2005, Darrin Thompson wrote:
> On Mon, 2005-06-20 at 10:22 -0700, Junio C Hamano wrote:
> > (6) Throw away my HEAD, making Linus HEAD my HEAD, while
> > preserving changes I have made since I forked from him. I
> > use "jit-rewind" for this.
>
> When you say it that way it sounds so _bad_. :-)
The reason is actually that he has to end up with a different history,
which is the history of the project mainline, rather than the history of
his tree. He could, of course, follow his own history, but then
communication with people who use a different history becomes difficult.
> Would it make sense to come up with a way to make an emailed series of
> patches represent a series of commits? Could patches still be
> cherrypicked?
Commits are fundamentally resistant to cherrypicking, because they give
the state of the tree rather than expressing changes in that
state. Long-term, I think that something like StGIT should be integrated
into the system and deal with generating the HEAD you get after getting
patches in.
-Daniel
*This .sig left intentionally blank*
^ 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