Use the new git-rev-parse "--[no-]flags" in "git diff".
This allows you to do
git diff v2.6.12..v2.6.13-rc1 drivers/pcmcia
to see the diff between v2.6.12 and v2.6.13-rc1 as limited by the
filename argument.
This allows you to do
git diff v2.6.12..v2.6.13-rc1 drivers/pcmcia
to see the diff between v2.6.12 and v2.6.13-rc1 as limited by the
filename argument.
Add "--flags" and "--no-flags" arguments to git-rev-parse
The scripts that use this (notably "git diff") will want to split up
flags and file arguments.
The scripts that use this (notably "git diff") will want to split up
flags and file arguments.
Remove insane overlapping bit ranges from epoch.c
..and move the DUPCHECK to rev-list.c since both the merge-order and the
upcoming topo-sort get confused by dups.
..and move the DUPCHECK to rev-list.c since both the merge-order and the
upcoming topo-sort get confused by dups.
Clean up commit insertion in git-rev-list
Jon wants the commits in a different order for merge-order.
Jon wants the commits in a different order for merge-order.
Make "insert_by_date()" match "commit_list_insert()"
Same argument order, same return type. This allows us to use a function
pointer to choose one over the other.
Same argument order, same return type. This allows us to use a function
pointer to choose one over the other.
[PATCH] Change the sed seperator in t/t6000-lib.sh.
This trivial patch removes the semicolon as the sed seperator in the t/t6000-lib.sh test script
and replaces it with white space. This makes BSD sed(1) much happier.
Signed-off-by: Mark Allen <mrallen1@yahoo.com>
Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This trivial patch removes the semicolon as the sed seperator in the t/t6000-lib.sh test script
and replaces it with white space. This makes BSD sed(1) much happier.
Signed-off-by: Mark Allen <mrallen1@yahoo.com>
Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
[PATCH] Introduce unit tests for git-rev-list --bisect
This patch introduces some unit tests for the git-rev-list --bisect functionality.
Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This patch introduces some unit tests for the git-rev-list --bisect functionality.
Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
[PATCH] Factor out useful test case infrastructure from t/t6001... into t/t6000-lib.sh
Functions that are useful to other t6xxx testcases are moved into t6000-lib.sh
To use these functions in a test case, use a test-case pre-amble like:
. ./test-lib.sh
. ../t6000-lib.sh # t6xxx specific functions
Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Functions that are useful to other t6xxx testcases are moved into t6000-lib.sh
To use these functions in a test case, use a test-case pre-amble like:
. ./test-lib.sh
. ../t6000-lib.sh # t6xxx specific functions
Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
[PATCH] Fix fd leak in git-cvsimport-script
Remember to close temporary file
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Remember to close temporary file
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
[PATCH] sha1_file.c;prepare_packed_git_one() - fix DIR leak
The function calls opendir() without a matching closedir().
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The function calls opendir() without a matching closedir().
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Merge master.kernel.org:/pub/scm/gitk/gitk
Fix up path-cleanup in git_path() properly
GIT_DIR=. ends up being what some of the pack senders use, and we
sometimes messed up when cleaning up the path, ie a ".//HEAD" was
cleaned up into "/HEAD", not "HEAD" like it should be.
We should do some other cleanup, and probably also verify that symlinks
don't point to outside the git area.
GIT_DIR=. ends up being what some of the pack senders use, and we
sometimes messed up when cleaning up the path, ie a ".//HEAD" was
cleaned up into "/HEAD", not "HEAD" like it should be.
We should do some other cleanup, and probably also verify that symlinks
don't point to outside the git area.
Increase the number of possible heads requested from git-upload-pack
Now that git-clone-pack exists, we actually have somebody requesting
more than just a single head in a pack. So allow the Jeff's of this
world to clone things with tens of heads.
Now that git-clone-pack exists, we actually have somebody requesting
more than just a single head in a pack. So allow the Jeff's of this
world to clone things with tens of heads.
Add a "git-show-index" helper that shows the contents of a pack index
This was invaluable for debugging the zero-sized compression issue, and
might be useful for scripting too, if people want to see the contents of
a pack.
This was invaluable for debugging the zero-sized compression issue, and
might be useful for scripting too, if people want to see the contents of
a pack.
Don't special-case a zero-sized compression.
zlib actually writes a header for that case, and while ignoring that
header will get us the right data, it will also end up messing up our
stream position. So we actually want zlib to "uncompress" even an empty
object.
zlib actually writes a header for that case, and while ignoring that
header will get us the right data, it will also end up messing up our
stream position. So we actually want zlib to "uncompress" even an empty
object.
Make "git clone" use the new git-clone-pack
Add "git-clone-pack" program to help with "git clone"
Fix silly thinko in "head_ref()"
It did a "for_each_ref()" in addition to the HEAD case, which was a
left-over from an early broken test.
It did a "for_each_ref()" in addition to the HEAD case, which was a
left-over from an early broken test.
Move "get_ack()" to common git_connect functions
git-clone-pack will want it too. Soon.
git-clone-pack will want it too. Soon.
Remove multi-head support from fetch-pack
It was a misguided attempt to mix fetching and cloning. I'll make
a separate clone thing.
It was a misguided attempt to mix fetching and cloning. I'll make
a separate clone thing.
Remove unnecessary usage of strncmp() in git-rev-list arg parsing.
Not only is it unnecessary, it incorrectly allows extraneous characters
at the end of the argument.
Junio noticed the --merge-order thing, and Jon points out that if we fix
that one, we should fix --show-breaks too.
Not only is it unnecessary, it incorrectly allows extraneous characters
at the end of the argument.
Junio noticed the --merge-order thing, and Jon points out that if we fix
that one, we should fix --show-breaks too.
Merge head 'cvs2git' of netz.smurf.noris.de/git/git
Work around git-http-pull breakage in git-fetch-script
Need to add a final slash. And make it verbose by default, since it's
so slow that otherwise people will think it's died.
Need to add a final slash. And make it verbose by default, since it's
so slow that otherwise people will think it's died.
git-fetch-script: use git-fetch-pack for local and ssh fetches.
Also, clean it up a lot.
Also, clean it up a lot.
Add "git_path()" and "head_ref()" helper functions.
"git_path()" returns a static pathname pointer into the git directory
using a printf-like format specifier.
"head_ref()" works like "for_each_ref()", except for just the HEAD.
"git_path()" returns a static pathname pointer into the git directory
using a printf-like format specifier.
"head_ref()" works like "for_each_ref()", except for just the HEAD.
Merge with Linus' current tree
Merge ... www.liacs.nl/~sverdool/git.git#cvs2git
cvsimport: getopt accepted a -q option (undocumented and unused).
Removed.
Removed.
git-cvsimport-script: move working directory forward
If HEAD happened to point to a cvs branch, move the
working directory forward to the tip of the branch.
Additionally, if master and "origin" are equal,
move master forward to new origin first.
If HEAD happened to point to a cvs branch, move the
working directory forward to the tip of the branch.
Additionally, if master and "origin" are equal,
move master forward to new origin first.
git-rev-list: make sure the output is sorted by recency
We didn't sort the refs by date, so if you had multiple refs, the end
result would not be properly sorted.
We didn't sort the refs by date, so if you had multiple refs, the end
result would not be properly sorted.
Make rev-list flush the stdio buffers after each rev.
We'd rather get the revisions in a slow but timely manner than
have to wait for them.
We'd rather get the revisions in a slow but timely manner than
have to wait for them.
Make git-fetch-pack actually do all the unpacking etc.
It returns the result SHA1 on stdout, so you can do
remote=$(git-fetch-pack host:dir branchname)
and it will unpack the objects and "remote" will be the SHA1 name of the
branch on the other side. You can then save that off, or merge it, or
whatever.
It returns the result SHA1 on stdout, so you can do
remote=$(git-fetch-pack host:dir branchname)
and it will unpack the objects and "remote" will be the SHA1 name of the
branch on the other side. You can then save that off, or merge it, or
whatever.
Make git-fetch-pack and git-upload-pack negotiate needs/haves fully
Now the only piece missing is actually generating the pack-file.
Now the only piece missing is actually generating the pack-file.
Clean up output of "for_each_ref()" when GIT_DIR is "."
Remove the "./" at the head, it just looks much nicer.
Remove the "./" at the head, it just looks much nicer.
git-cvsimport-script: remove unused variable
Commit first cut at "git-fetch-pack"
It's meant to be used by "git fetch" for the local and ssh case.
It doesn't actually do the fetching now, but it does discover the common
commit point.
It's meant to be used by "git fetch" for the local and ssh case.
It doesn't actually do the fetching now, but it does discover the common
commit point.
Move ref path matching to connect.c library
It's a generic thing for matching refs from the other side.
It's a generic thing for matching refs from the other side.
Factor out the ssh connection stuff from send-pack.c
I want to use it for git-fetch-pack too.
I want to use it for git-fetch-pack too.
git-cvsimport-script: more error handling
[PATCH] Fixup t/t5300 unit tests broken by 5f3de58ff85c49620ae2a1722d8d4d37c881a054
This patch fixes up the t/t5300 unit tests which were broken by the changes in:
Make the name of a pack-file depend on the objects packed there-in.
Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This patch fixes up the t/t5300 unit tests which were broken by the changes in:
Make the name of a pack-file depend on the objects packed there-in.
Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
git-cvsimport-script: provide direct support for cvsps -z option
git-cvsimport-script: update cvsps cache instead of rebuilding it
Updating the cache is sufficient for most purposes.
If users really want to rebuild the cache, they can specify
the option themselves.
Updating the cache is sufficient for most purposes.
If users really want to rebuild the cache, they can specify
the option themselves.
git-cvsimport-script: fix branch switching
Previous patch broke branch switching.
Previous patch broke branch switching.
git-cvsimport-script: use private index.
git-rev-parse: support show sha1 names for pack entries
This is actually subtly wrong. If a short match is found in the object
directory, but would _also_ match another SHA1 ID in a pack (or it shows
in one pack but not another), we'll never have done the pack lookup, and
we think it's unique.
I can't find it in myself to care. You really want to use enough of a
SHA1 that there is never any ambiguity.
This is actually subtly wrong. If a short match is found in the object
directory, but would _also_ match another SHA1 ID in a pack (or it shows
in one pack but not another), we'll never have done the pack lookup, and
we think it's unique.
I can't find it in myself to care. You really want to use enough of a
SHA1 that there is never any ambiguity.
Make git-rev-parse support cogito-style "short hex names"
Currently only for unpacked objects, but the infrastructure
is there to do it for packed objects too.
Currently only for unpacked objects, but the infrastructure
is there to do it for packed objects too.
git-cvsimport-script: leave working directory alone.
Make the name of a pack-file depend on the objects packed there-in.
This means that the .git/objects/pack directory is also rsync'able,
since the filenames created there-in are either unique or refer to the
same data.
Otherwise you might not be able to pull from a directory that is partly
packed without having to worry about missing objects due to pack-file
name clashes.
This means that the .git/objects/pack directory is also rsync'able,
since the filenames created there-in are either unique or refer to the
same data.
Otherwise you might not be able to pull from a directory that is partly
packed without having to worry about missing objects due to pack-file
name clashes.
git-cvsimport-script: typo head -> heads
Add "git-prune-packed" that removes objects that exist in a pack.
This, together with "git repack" can be used to clean up unpacked
git archives.
This, together with "git repack" can be used to clean up unpacked
git archives.
Add "git repack" command that does an incremental pack
Add "--non-empty" flag to git-pack-objects
It skips writing the pack-file if it ends up being empty.
It skips writing the pack-file if it ends up being empty.
"git rev-list --unpacked" shows only unpacked commits
More infrastructure to do efficient incremental packs.
More infrastructure to do efficient incremental packs.
Add "--incremental" flag to git-pack-objects
It won't add an object that is already in a pack to the new pack.
It won't add an object that is already in a pack to the new pack.
Add "--all" flag to rev-parse that shows all refs
And make git-rev-list just silently ignore non-commit refs if we're not
asking for all objects.
And make git-rev-list just silently ignore non-commit refs if we're not
asking for all objects.
Add "has_sha1_pack()" function to query whether the object is available in a pack
We'll want this for incremental packing.
We'll want this for incremental packing.
Make git-fsck-cache check HEAD integrity
In particular, check that it's a symlink, and points to refs/heads/. We
depend on that these days not only for "git checkout", but also because
fsck and others only check for references in the .git/refs/
subdirectory, not things like HEAD itself.
In particular, check that it's a symlink, and points to refs/heads/. We
depend on that these days not only for "git checkout", but also because
fsck and others only check for references in the .git/refs/
subdirectory, not things like HEAD itself.
Fix sparse warnings.
Mainly making a lot of local functions and variables be marked "static",
but there was a "zero as NULL" warning in there too.
Mainly making a lot of local functions and variables be marked "static",
but there was a "zero as NULL" warning in there too.
cvsimport: Missing tests for verbosity flag.
Fix up header file dependencies and add sparse checking rules
We're pretty sparse-clean already, thanks to earlier efforts, but some
things inevitably creep in.
We're pretty sparse-clean already, thanks to earlier efforts, but some
things inevitably creep in.
Fix up "for_each_ref()" to be more usable, and use it in git-fsck-cache
It needed to take the GIT_DIR information into account, something that
the original receive-pack usage just never cared about.
It needed to take the GIT_DIR information into account, something that
the original receive-pack usage just never cared about.
Fix gcc warning in send-pack.c
send_pack() was declared to return "int" (although nobody cared), but
didn't actually return anything.
send_pack() was declared to return "int" (although nobody cared), but
didn't actually return anything.
Avoid gcc warnings in sha1_file.c
A couple of bogus "might be used undefined" warnings are avoided
by moving the initializations unnecessarily early.
A couple of bogus "might be used undefined" warnings are avoided
by moving the initializations unnecessarily early.
Support :ext: access method.
Honour CVS_SERVER.
git-cvsimport-script: clean up documentation
Remove documentation of irrelevant "type" option.
Signed-off-by: Sven Verdoolaege <skimo@kotnet.org>
Remove documentation of irrelevant "type" option.
Signed-off-by: Sven Verdoolaege <skimo@kotnet.org>
Make specification of CVS module to convert optional.
If we're inside a checked out CVS repository, there is
no need to explicitly specify the module as it is
available in CVS/Repository.
Also read CVS/Root if it's available and -d is not specified.
Finally, explicitly pass root to cvsps as CVS/Root takes
precedence over CVSROOT.
Signed-off-by: Sven Verdoolaege <skimo@kotnet.org>
If we're inside a checked out CVS repository, there is
no need to explicitly specify the module as it is
available in CVS/Repository.
Also read CVS/Root if it's available and -d is not specified.
Finally, explicitly pass root to cvsps as CVS/Root takes
precedence over CVSROOT.
Signed-off-by: Sven Verdoolaege <skimo@kotnet.org>
Fixed a typo in Documentation/git-cvsimport-script.txt.
Generalize the "show each ref" code in receice-pack
This turns it into a generic "do xyz for each ref" library function.
This turns it into a generic "do xyz for each ref" library function.
[PATCH] Show more details of packfile with verify-pack -v.
This implements show_pack_info() function used in verify-pack
command when -v flag is used to obtain something like
unpack-objects used to give when it was first written.
It shows the following for each non-deltified object found in
the pack:
SHA1 type size offset
For deltified objects, it shows this instead:
SHA1 type size offset depth base_sha1
In order to get the output in the order that appear in the pack
file for debugging purposes, you can do this:
$ git-verify-pack -v packfile | sort -n -k 4,4
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This implements show_pack_info() function used in verify-pack
command when -v flag is used to obtain something like
unpack-objects used to give when it was first written.
It shows the following for each non-deltified object found in
the pack:
SHA1 type size offset
For deltified objects, it shows this instead:
SHA1 type size offset depth base_sha1
In order to get the output in the order that appear in the pack
file for debugging purposes, you can do this:
$ git-verify-pack -v packfile | sort -n -k 4,4
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
[PATCH] verify-pack updates.
Nico pointed out that having verify_pack.c and verify-pack.c was
confusing. Rename verify_pack.c to pack-check.c as suggested,
and enhances the verification done quite a bit.
- Built-in sha1_file unpacking knows that a base object of a
deltified object _must_ be in the same pack, and takes
advantage of that fact.
- Earlier verify-pack command only checked the SHA1 sum for the
entire pack file and did not look into its contents. It now
checks everything idx file claims to have unpacks correctly.
- It now has a hook to give more detailed information for
objects contained in the pack under -v flag.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Nico pointed out that having verify_pack.c and verify-pack.c was
confusing. Rename verify_pack.c to pack-check.c as suggested,
and enhances the verification done quite a bit.
- Built-in sha1_file unpacking knows that a base object of a
deltified object _must_ be in the same pack, and takes
advantage of that fact.
- Earlier verify-pack command only checked the SHA1 sum for the
entire pack file and did not look into its contents. It now
checks everything idx file claims to have unpacks correctly.
- It now has a hook to give more detailed information for
objects contained in the pack under -v flag.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
[PATCH] Avoid unnecessarily inflating and interpreting delta
This teaches packed_delta_info() that it only needs to look at
the type of the base object to figure out both type and size of
a deltified object. This saves quite a many calls to inflate()
when dealing with a deep delta chain.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This teaches packed_delta_info() that it only needs to look at
the type of the base object to figure out both type and size of
a deltified object. This saves quite a many calls to inflate()
when dealing with a deep delta chain.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
cvsimport: add documentation.
cvsimport: Added option '-p': pass options to cvsps
Added option '-x' to cvsps call
Added option '-x' to cvsps call
cvsimport: Exit if an existing repository doesn't have the right branch.
cvs import: Strip whitespace at the end of the log entry
for compatibility with old cvs2git.
for compatibility with old cvs2git.
Do ref matching on the sender side rather than on receiver
This makes the receiver always send a full list of valid refs, which
will allow us to do better packs, as well as handle creation of new
refs. Eventually. Right now we just moved the matching and enabled it.
So now you can do
git-send-pack host:path branch1 branch2
to only send branches "branch1" and "branch2".
This makes the receiver always send a full list of valid refs, which
will allow us to do better packs, as well as handle creation of new
refs. Eventually. Right now we just moved the matching and enabled it.
So now you can do
git-send-pack host:path branch1 branch2
to only send branches "branch1" and "branch2".
Add support for "forcing" a ref on the remote side
A "old ref" of all zeroes is considered a "don't care" ref, and allows
us to say "write the new ref regardless of what the old ref contained
(or even if it existed at all)".
This allows (if git-send-pack were to do it) creating new refs, and
fixing up old ones.
A "old ref" of all zeroes is considered a "don't care" ref, and allows
us to say "write the new ref regardless of what the old ref contained
(or even if it existed at all)".
This allows (if git-send-pack were to do it) creating new refs, and
fixing up old ones.
git-send-pack: actually send the object pack
This concludes this lesson. I've actually successfully sent an update
using the git-send-pack command.
Probably tons of work still to do, and nasty debugging, but it's now
actually potentially useful.
This concludes this lesson. I've actually successfully sent an update
using the git-send-pack command.
Probably tons of work still to do, and nasty debugging, but it's now
actually potentially useful.
git-receive-pack: implement ref switch command handling
After unpacking the object pack successfully, we go through the list of
refs, and verify that they still contain their expected values. Then we
replace them with the new ones.
After unpacking the object pack successfully, we go through the list of
refs, and verify that they still contain their expected values. Then we
replace them with the new ones.
cvsimport: perform string comparison on "HEAD"
git-cvsimport-script: Removed redundant @old and @new clear.
git-cvsimport-script: Remove setting Sticky; it may cause problems
cvs import: Call git-update-cache multiple times
instead of with a too-long argument list.
instead of with a too-long argument list.
Add comment on what send-pack still needs to do
Me tired.
Me tired.
git-receive-pack: start parsing ref update commands
We don't act on them yet, but we parse them.
We don't act on them yet, but we parse them.
Slow but steady progress on git pack receive/send
git-send-pack: start parsing local/remote reference differences
Right now it just shows which refs it picks up, and whether they are
the same or changed on the remote end. Getting there..
Right now it just shows which refs it picks up, and whether they are
the same or changed on the remote end. Getting there..
Turn on optimization again
It got turned off by mistake just because I had been doing debugging,
and committed the Makefile that had other changes ...
It got turned off by mistake just because I had been doing debugging,
and committed the Makefile that had other changes ...
[PATCH] Remove unnecessary sort from t6001 testcase
This patch removes an unnecessary sort from the t6001 testcase.
Sorts were previously necessary when testing non --merge-order cases
because the output order wasn't entirely deterministic unless commit
date was fixed.
However, commit dates are now fixed, so the need for a sort has
disappeared. So the sort has been removed.
Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This patch removes an unnecessary sort from the t6001 testcase.
Sorts were previously necessary when testing non --merge-order cases
because the output order wasn't entirely deterministic unless commit
date was fixed.
However, commit dates are now fixed, so the need for a sort has
disappeared. So the sort has been removed.
Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
[PATCH] Fix broken t6001 test case
This fix fixes a t/t6001 test case break that was hidden by a bug in the
test case infrastructure.
Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This fix fixes a t/t6001 test case break that was hidden by a bug in the
test case infrastructure.
Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
[PATCH] Demonstrate broken t6001 test case function
Junio discovered a problem where an actual test case break was hidden
because pipelines are not handled properly by the test infrastructure in
t6001.
This patch fixes the broken infrastructure (and demonstrates the break
explicitly).
A subsequent patch in this series will fix the test case so that it
doesn't fail.
Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Junio discovered a problem where an actual test case break was hidden
because pipelines are not handled properly by the test infrastructure in
t6001.
This patch fixes the broken infrastructure (and demonstrates the break
explicitly).
A subsequent patch in this series will fix the test case so that it
doesn't fail.
Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
[PATCH] Fix for git-rev-list --merge-order B ^A (A,B share common base) [rev 2]
This patch makes --merge-order produce the same list as git-rev-list
without --merge-order specified.
In particular, if the graph looks like this:
A
| B
|/
C
|
D
The both git-rev-list B ^A and git-rev-list --merge-order will produce B.
The unit tests have been changed to reflect the fact that the prune
points are now formally part of the start list that is used to perform
the --merge-order sort.
That is: git-rev-list --merge-order A ^D used to produce
= A
| C
It now produces:
^ A
| C
Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This patch makes --merge-order produce the same list as git-rev-list
without --merge-order specified.
In particular, if the graph looks like this:
A
| B
|/
C
|
D
The both git-rev-list B ^A and git-rev-list --merge-order will produce B.
The unit tests have been changed to reflect the fact that the prune
points are now formally part of the start list that is used to perform
the --merge-order sort.
That is: git-rev-list --merge-order A ^D used to produce
= A
| C
It now produces:
^ A
| C
Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
[PATCH] Test case that demonstrates problem with --merge-order ^ processing
Added a test case that shows that --merge-order doesn't produce the
correct result in the following case.
A
|
| B
|/
C
|
D
git-rev-list --merge-order A ^B should produce just A. Instead
it produces BCD.
A subsequent patch will fix this defect.
Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Added a test case that shows that --merge-order doesn't produce the
correct result in the following case.
A
|
| B
|/
C
|
D
git-rev-list --merge-order A ^B should produce just A. Instead
it produces BCD.
A subsequent patch will fix this defect.
Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Make send/receive-pack be closer to doing something interesting
Start of "git-send-pack", the local part of sending off a pack
Like git-receive-pack, this is only partway done.
Like git-receive-pack, this is only partway done.
Add first cut at "git-receive-pack"
It's not working yet, but it's at the point where I want to be able to
track my changes. The theory of operation is that this is the "remote"
side of a "git push". It can tell us what references the remote side
has, receives out reference update commands and a pack-file, and can
execute the unpacking command.
It's not working yet, but it's at the point where I want to be able to
track my changes. The theory of operation is that this is the "remote"
side of a "git push". It can tell us what references the remote side
has, receives out reference update commands and a pack-file, and can
execute the unpacking command.
Remove bogus dup commit warning with --merge-order
It makes gitk unhappy, and besides, non-merge-order doesn't complain, so
why do it here..
It makes gitk unhappy, and besides, non-merge-order doesn't complain, so
why do it here..
Teach git-rev-list about non-commit objects
Now you can give git-rev-list tags, trees and blobs, and it will do the
proper reachability for them all. Knock wood.
Of course, you need the "--objects" flag to do anything but plain
commits.
Now you can give git-rev-list tags, trees and blobs, and it will do the
proper reachability for them all. Knock wood.
Of course, you need the "--objects" flag to do anything but plain
commits.
Prepare git-rev-list for tracking tag objects too
We want to be able to just say "give a difference between these
objects", rather than limiting it to commits only. This isn't there
yet, but it sets things up to be a bit easier.
We want to be able to just say "give a difference between these
objects", rather than limiting it to commits only. This isn't there
yet, but it sets things up to be a bit easier.