kernel/git - git - PowerEL Git System

17776 Commits

6 Branches

36 Tags

131 MiB

Tree: be18f4b899

Commit Graph

Author	SHA1	Message	Date
Junio C Hamano	b67b9612e1	diff.c: output correct index lines for a split diff A patch that changes the filetype (e.g. regular file to symlink) of a path must be split into a deletion event followed by a creation event, which means that we need to have two independent metainfo lines for each. However, the code reused the single set of metainfo lines. As the blob object names recorded on the index lines are usually not used nor validated on the receiving end, this is not an issue with normal use of the resulting patch. However, when accepting a binary patch to delete a blob, git-apply verified that the postimage blob object name on the index line is 0{40}, hence a patch that deletes a regular file blob that records binary contents to create a blob with different filetype (e.g. a symbolic link) failed to apply. "git am -3" also uses the blob object names recorded on the index line, so it would also misbehave when synthesizing a preimage tree. This moves the code to generate metainfo lines around, so that two independent sets of metainfo lines are used for the split halves. Additional tests by Jeff King. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	16 years ago
Junio C Hamano	5be60078c9	Rewrite "git-frotz" to "git frotz" This uses the remove-dashes target to replace "git-frotz" to "git frotz". Signed-off-by: Junio C Hamano <gitster@pobox.com>	18 years ago
Eric Wong	8641fb24ee	typechange tests for git apply (currently failing) I've found that git apply is incapable of handling patches involving object type changes to the same path. Of course git itself is perfectly capable of making commits that generate these changes, as it only tracks trees states. It's just that the diffs between them are less useful if they can't be applied. Some of these are rare, but I've hit one of them (file becoming a symlink) recently in real-world usage, and was inspired to find more potential breakages :) I'm not sure when I'll have time to fix these myself and I'm not very familiar with the apply code. So if someone could get some or all of these cases working, they would be my hero :) Some of these are what I would refer to as corner-cases from hell. Most (if not all) other systems fail some of these. In fact, they aren't even capable of representing most of these changes in their histories; much less being able to handle patches to that effect. Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago

Author

SHA1

Message

Date

Junio C Hamano

b67b9612e1

diff.c: output correct index lines for a split diff

A patch that changes the filetype (e.g. regular file to symlink) of a path
must be split into a deletion event followed by a creation event, which
means that we need to have two independent metainfo lines for each.
However, the code reused the single set of metainfo lines.

As the blob object names recorded on the index lines are usually not used
nor validated on the receiving end, this is not an issue with normal use
of the resulting patch.  However, when accepting a binary patch to delete
a blob, git-apply verified that the postimage blob object name on the
index line is 0{40}, hence a patch that deletes a regular file blob that
records binary contents to create a blob with different filetype (e.g. a
symbolic link) failed to apply.  "git am -3" also uses the blob object
names recorded on the index line, so it would also misbehave when
synthesizing a preimage tree.

This moves the code to generate metainfo lines around, so that two
independent sets of metainfo lines are used for the split halves.

Additional tests by Jeff King.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

16 years ago

Junio C Hamano

5be60078c9

Rewrite "git-frotz" to "git frotz"

This uses the remove-dashes target to replace "git-frotz" to "git frotz".

Signed-off-by: Junio C Hamano <gitster@pobox.com>

18 years ago

Eric Wong

8641fb24ee

typechange tests for git apply (currently failing)

I've found that git apply is incapable of handling patches
involving object type changes to the same path.

Of course git itself is perfectly capable of making commits that
generate these changes, as it only tracks trees states.  It's
just that the diffs between them are less useful if they can't
be applied.

Some of these are rare, but I've hit one of them (file becoming
a symlink) recently in real-world usage, and was inspired to
find more potential breakages :)

I'm not sure when I'll have time to fix these myself and I'm not
very familiar with the apply code.   So if someone could get
some or all of these cases working, they would be my hero :)

Some of these are what I would refer to as corner-cases from
hell.  Most (if not all) other systems fail some of these.  In
fact, they aren't even capable of representing most of these
changes in their histories; much less being able to handle
patches to that effect.

Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>

19 years ago

3 Commits (be18f4b899a94ff51ff3c621822500579cf6df6a)