Use sha1_file.c's mkdir-like routine in apply.c.
As far as I can see, create_subdirectories() in apply.c just
duplicates the functionality of safe_create_leading_directories() from
sha1_file.c. The former has a warm, fuzzy const parameter, but that's
not important.
The potential problem with EEXIST and creating directories should
never occur here, but will be removed by future
safe_create_leading_directories() changes. Other uses of EEXIST in
apply.c should be fine barring intentionally malicious behavior.
Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
As far as I can see, create_subdirectories() in apply.c just
duplicates the functionality of safe_create_leading_directories() from
sha1_file.c. The former has a warm, fuzzy const parameter, but that's
not important.
The potential problem with EEXIST and creating directories should
never occur here, but will be removed by future
safe_create_leading_directories() changes. Other uses of EEXIST in
apply.c should be fine barring intentionally malicious behavior.
Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
daemon: Provide missing argument for logerror() call.
Could cause a crash if --base-path set. Unlikely to be a security the
concern: message doesn't go to the client, so we can't leak anything
(except by dumping core), and we've already forked, so it's not a denial
of service.
Signed-off-by: Mark Wooding <mdw@distorted.org.uk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Could cause a crash if --base-path set. Unlikely to be a security the
concern: message doesn't go to the client, so we can't leak anything
(except by dumping core), and we've already forked, so it's not a denial
of service.
Signed-off-by: Mark Wooding <mdw@distorted.org.uk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-merge: Properly quote $merge_msg variable.
Otherwise it would go though shell expansion...
Signed-off-by: Junio C Hamano <junkio@cox.net>
Otherwise it would go though shell expansion...
Signed-off-by: Junio C Hamano <junkio@cox.net>
combine-diff: cleanup.
The flag on the surviving lines meant "this parent is not
different" while the parent_map flag on the lost lines meant
"this parent is different", which was confusing. So swap the
meaning of on-bit in the flag. Also more heavily comment the
code.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The flag on the surviving lines meant "this parent is not
different" while the parent_map flag on the lost lines meant
"this parent is different", which was confusing. So swap the
meaning of on-bit in the flag. Also more heavily comment the
code.
Signed-off-by: Junio C Hamano <junkio@cox.net>
combine-diff: show parent line numbers as well.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
combine-diff: add a bit more comments.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-send-email: Add --quiet to reduce some of the chatter when sending emails.
Signed-off-by: Ryan Anderson <ryan@michonline.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Ryan Anderson <ryan@michonline.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Provide a more meaningful initial "From " line when using --compose in git-send-email.
git-send-email, when used with --compose, provided the user with a mbox-format
file to edit. Some users, however, were confused by the leading, blank, "From
" line, so this change puts the value that will appear on the From: line of the
actual email on this line, along with a note that the line is ignored.
Signed-off-by: Ryan Anderson <ryan@michonline.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-send-email, when used with --compose, provided the user with a mbox-format
file to edit. Some users, however, were confused by the leading, blank, "From
" line, so this change puts the value that will appear on the From: line of the
actual email on this line, along with a note that the line is ignored.
Signed-off-by: Ryan Anderson <ryan@michonline.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
commit.c: "Merge" fix in pretty_print_commit.
Earlier, f2d4227530499db3e273ae84f30adfd4b70791c6 commit broke Merge:
lines for unabbreviated case. Do not emit extra dots if we do not
abbreviate.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Earlier, f2d4227530499db3e273ae84f30adfd4b70791c6 commit broke Merge:
lines for unabbreviated case. Do not emit extra dots if we do not
abbreviate.
Signed-off-by: Junio C Hamano <junkio@cox.net>
merge-recursive: Speed up commit graph construction
Use __slots__ to speed up construction and decrease memory consumption
of the Commit objects.
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Use __slots__ to speed up construction and decrease memory consumption
of the Commit objects.
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
Signed-off-by: Junio C Hamano <junkio@cox.net>
merge-recursive: Make use of provided bases
This makes some cases faster as we don't have to build the commit graph.
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This makes some cases faster as we don't have to build the commit graph.
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Documentation: git-diff-tree --cc also omits empty commits
A misguided attempt to show logs at all time was inserted only to
the documentation of this flag. Worse yet, it was not even implemented,
causing more confusion. Drop it.
We might want to have an option to show --pretty even when there is no
diff output, but that is applicable to all forms of diff, not just --cc.
Signed-off-by: Junio C Hamano <junkio@cox.net>
A misguided attempt to show logs at all time was inserted only to
the documentation of this flag. Worse yet, it was not even implemented,
causing more confusion. Drop it.
We might want to have an option to show --pretty even when there is no
diff output, but that is applicable to all forms of diff, not just --cc.
Signed-off-by: Junio C Hamano <junkio@cox.net>
combine-diff: fix placement of deletion.
The code misplaced a raw hunk that consists of solely deleted
lines by one line. This showed e.g. Len's 12-way octopus
(9fdb62af in the linux-2.6), kernel/power/disk.c, hunk starting
at line 95, incorrectly.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The code misplaced a raw hunk that consists of solely deleted
lines by one line. This showed e.g. Len's 12-way octopus
(9fdb62af in the linux-2.6), kernel/power/disk.c, hunk starting
at line 95, incorrectly.
Signed-off-by: Junio C Hamano <junkio@cox.net>
combine-diff: add safety check to --cc.
The earlier change implemented "only two version" check but
without checking if the change rewrites from all the parents.
This implements a check to make sure that a change introduced
by the merge from all the parents is caught to be interesting.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The earlier change implemented "only two version" check but
without checking if the change rewrites from all the parents.
This implements a check to make sure that a change introduced
by the merge from all the parents is caught to be interesting.
Signed-off-by: Junio C Hamano <junkio@cox.net>
combine-diff: update --cc "uninteresting hunks" logic.
Earlier logic was discarding hunks that has difference from only
one parent or the same difference from all but one parent. This
changes it to check if the differences on all lines are from the
same sets of parents. This discards more uninteresting hunks
and seems to match expectations more naturally.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Earlier logic was discarding hunks that has difference from only
one parent or the same difference from all but one parent. This
changes it to check if the differences on all lines are from the
same sets of parents. This discards more uninteresting hunks
and seems to match expectations more naturally.
Signed-off-by: Junio C Hamano <junkio@cox.net>
combine-diff: reuse diff from the same blob.
When dealing with an insanely large Octopus, it is possible to
optimize by noticing that more than one parents have the same
blob and avoid running diff between a parent and the merge
result by reusing an earlier result.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When dealing with an insanely large Octopus, it is possible to
optimize by noticing that more than one parents have the same
blob and avoid running diff between a parent and the merge
result by reusing an earlier result.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Allow diff and index commands to be interrupted
So far, e.g. git-update-index --refresh was basically uninterruptable
by ctrl-c, since it hooked the SIGINT handler, but that handler would
only unlink the lockfile but not actually quit. This makes it propagate
the signal to the default handler.
Note that I expected it to work without resetting the signal handler to
SIG_DFL, but without that it ended in an infinite loop of tgkill()s -
is my glibc violating SUS or what?
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
So far, e.g. git-update-index --refresh was basically uninterruptable
by ctrl-c, since it hooked the SIGINT handler, but that handler would
only unlink the lockfile but not actually quit. This makes it propagate
the signal to the default handler.
Note that I expected it to work without resetting the signal handler to
SIG_DFL, but without that it ended in an infinite loop of tgkill()s -
is my glibc violating SUS or what?
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
rev-list: omit duplicated parents.
Showing the same parent more than once for a commit does not
make much sense downstream, so stop it.
This can happen with an incorrectly made merge commit that
merges the same parent twice, but can happen in an otherwise
sane development history while squishing the history by taking
into account only commits that touch specified paths.
For example,
$ git rev-list --max-count=1 --parents addafaf -- rev-list.c
would have to show this commit ancestry graph:
.---o---.
/ \
.---*---o---.
/ 93b74bc \
---*---o---o-----o---o-----o addafaf
d8f6b34 \ /
.---o---o---.
\ /
.---*---.
3815f42
where 5 independent development tracks, only two of which have
changes in the specified paths since they forked. The last
change for the other three development tracks was done by the
same commit before they forked, and we were showing that three
times.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Showing the same parent more than once for a commit does not
make much sense downstream, so stop it.
This can happen with an incorrectly made merge commit that
merges the same parent twice, but can happen in an otherwise
sane development history while squishing the history by taking
into account only commits that touch specified paths.
For example,
$ git rev-list --max-count=1 --parents addafaf -- rev-list.c
would have to show this commit ancestry graph:
.---o---.
/ \
.---*---o---.
/ 93b74bc \
---*---o---o-----o---o-----o addafaf
d8f6b34 \ /
.---o---o---.
\ /
.---*---.
3815f42
where 5 independent development tracks, only two of which have
changes in the specified paths since they forked. The last
change for the other three development tracks was done by the
same commit before they forked, and we were showing that three
times.
Signed-off-by: Junio C Hamano <junkio@cox.net>
update-index --index-info: allow stage 0 entries.
Somehow we did not allow stuffing the index with stage 0 entries
through --index-info interface. I do not think of a reason to
forbid it offhand.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Somehow we did not allow stuffing the index with stage 0 entries
through --index-info interface. I do not think of a reason to
forbid it offhand.
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-svnimport.perl: fix for 'arg list too long...'
This fixes 'arg list too long..' problem with git-ls-files.
Note that second arg list separation loop (with 'git-update-index') is
needed since git-ls-files arguments can be directories.
Signed-off-by: Sasha Khapyorsky <sashak@voltaire.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This fixes 'arg list too long..' problem with git-ls-files.
Note that second arg list separation loop (with 'git-update-index') is
needed since git-ls-files arguments can be directories.
Signed-off-by: Sasha Khapyorsky <sashak@voltaire.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Use local structs for HTTP slot callback data
There's no need for these structures to be static, and it could potentially
cause problems down the road.
Signed-off-by: Nick Hengeveld <nickh@reactrix.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
There's no need for these structures to be static, and it could potentially
cause problems down the road.
Signed-off-by: Nick Hengeveld <nickh@reactrix.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
rev-list: allow -<n> as shorthand for --max-count=<n>
This builds on top of the previous one.
Traditionally, head(1) and tail(1) allow their line limits to be
parsed this way.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This builds on top of the previous one.
Traditionally, head(1) and tail(1) allow their line limits to be
parsed this way.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
rev-list: allow -n<n> as shorthand for --max-count=<n>
Both -n<n> and -n <n> are supported. POSIX versions of head(1) and
tail(1) allow their line limits to be parsed this way. I find
--max-count to be a commonly used option, and also similar in spirit to
head/tail, so I decided to make life easier on my worn out (and lazy :)
fingers with this patch.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Both -n<n> and -n <n> are supported. POSIX versions of head(1) and
tail(1) allow their line limits to be parsed this way. I find
--max-count to be a commonly used option, and also similar in spirit to
head/tail, so I decided to make life easier on my worn out (and lazy :)
fingers with this patch.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Make apply accept the -pNUM option like patch does.
This only applies to traditional diffs, not to git diffs.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This only applies to traditional diffs, not to git diffs.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Fix HTTP request result processing after slot reuse
Add a way to store the results of an HTTP request when a slot finishes
so the results can be processed after the slot has been reused.
Signed-off-by: Nick Hengeveld <nickh@reactrix.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add a way to store the results of an HTTP request when a slot finishes
so the results can be processed after the slot has been reused.
Signed-off-by: Nick Hengeveld <nickh@reactrix.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Make git-tar-tree use the tree_desc abstractions
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Make the "struct tree_desc" operations available to others
We have operations to "extract" and "update" a "struct tree_desc", but we
only used them in tree-diff.c and they were static to that file.
But other tree traversal functions can use them to their advantage
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We have operations to "extract" and "update" a "struct tree_desc", but we
only used them in tree-diff.c and they were static to that file.
But other tree traversal functions can use them to their advantage
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Merge branches 'bf/doc' and 'db/tartree'
documentation: cvs migration - typofix.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Use struct commit in tar-tree
It was open-coding getting the commit date from a commit.
Signed-off-by: Daniel Barkalow <barkalow@iabervon>
Signed-off-by: Junio C Hamano <junkio@cox.net>
It was open-coding getting the commit date from a commit.
Signed-off-by: Daniel Barkalow <barkalow@iabervon>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Use struct tree in tar-tree
It was using an open-coded tree parser; use a struct tree instead.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
It was using an open-coded tree parser; use a struct tree instead.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
cvs-migration documentation update
Here's some changes to the cvs-migration.txt. As usual, in my attempt
to make things clearer someone may have found I've made them less so, or
I may have just gotten something wrong; so any review is welcomed.
I can break up this sort of thing into smaller steps if preferred, the
monolothic patch is just a bit simpler for me for this sort of
thing.
I moved the material describing shared repository management from
core-tutorial.txt to cvs-migration.txt, where it seems more appropriate,
and combined two sections to eliminate some redundancy.
I also revised the earlier sections of cvs-migration.txt, mainly trying
to make it more concise.
I've left the last section of cvs-migration.txt (on CVS annotate
alternatives) alone for now.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Here's some changes to the cvs-migration.txt. As usual, in my attempt
to make things clearer someone may have found I've made them less so, or
I may have just gotten something wrong; so any review is welcomed.
I can break up this sort of thing into smaller steps if preferred, the
monolothic patch is just a bit simpler for me for this sort of
thing.
I moved the material describing shared repository management from
core-tutorial.txt to cvs-migration.txt, where it seems more appropriate,
and combined two sections to eliminate some redundancy.
I also revised the earlier sections of cvs-migration.txt, mainly trying
to make it more concise.
I've left the last section of cvs-migration.txt (on CVS annotate
alternatives) alone for now.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
cvsexportcommit: add some examples to the documentation
Updated with Randall Schwartz's suggestion.
Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Updated with Randall Schwartz's suggestion.
Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
exportcommit: replace backticks with safe_pipe_capture() or system() - initial pass
Replaced backticks with potentially troublesome unescaped input with
safe_pipe_capture().
Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Replaced backticks with potentially troublesome unescaped input with
safe_pipe_capture().
Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
cvsimport: Add -S <skipfileregex> support and -v announces files retrieved
A couple of things that seem to help importing broken CVS repos...
-S '<slash-delimited-regex>' skips files with a matching path
-v prints file name and version before fetching from cvs
Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
A couple of things that seem to help importing broken CVS repos...
-S '<slash-delimited-regex>' skips files with a matching path
-v prints file name and version before fetching from cvs
Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Merge fixes up to GIT 1.1.6
GIT 1.1.6
git push -f documentation
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-branch: Documentation fixes
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
Signed-off-by: Junio C Hamano <junkio@cox.net>
merge-recursive: Improve the error message printed when merge(1) isn't found.
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
Signed-off-by: Junio C Hamano <junkio@cox.net>
[PATCH] pre-commit sample hook: do not barf on the initial import
The example hook barfs on the initial import. Ideally it should
produce a diff from an empty tree, but for now let's stop at
squelching the bogus error message. Often an initial import
involves tons of badly formatted files from foreign SCM, so not
complaining about them like this patch does might actually be a
better idea than enforcing the "Perfect Patch" format on them.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The example hook barfs on the initial import. Ideally it should
produce a diff from an empty tree, but for now let's stop at
squelching the bogus error message. Often an initial import
involves tons of badly formatted files from foreign SCM, so not
complaining about them like this patch does might actually be a
better idea than enforcing the "Perfect Patch" format on them.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Documentation: diff -c/--cc
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
diff-files -c/--cc: combine only when both ours and theirs exist.
The previous round forgot to make sure there actually are two
versions to compare against the working tree version. Otherwise
using -c/--cc would not make much sense.
Also plug a small memory leak.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The previous round forgot to make sure there actually are two
versions to compare against the working tree version. Otherwise
using -c/--cc would not make much sense.
Also plug a small memory leak.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Merge lt/revlist,jc/diff,jc/revparse,jc/abbrev
rev-parse: make "whatchanged -- git-fetch-script" work again.
The latest update to avoid misspelled revs interfered when we
were not interested in parsing non flags or arguments not meant
for rev-list. This makes these two forms work again:
git whatchanged -- git-fetch-script
We could enable "!def" in the part this change touches to make
the above work without '--', but then it would cause misspelled
v2.6.14..v2.6.16 to be given to diff-tree and defeats the whole
point of the previous fix.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The latest update to avoid misspelled revs interfered when we
were not interested in parsing non flags or arguments not meant
for rev-list. This makes these two forms work again:
git whatchanged -- git-fetch-script
We could enable "!def" in the part this change touches to make
the above work without '--', but then it would cause misspelled
v2.6.14..v2.6.16 to be given to diff-tree and defeats the whole
point of the previous fix.
Signed-off-by: Junio C Hamano <junkio@cox.net>
diff --abbrev=<n> option fix.
Earier specifying an abbreviation shorter than minimum fell back
to full 40 letters, which was nonsense. Make it to fall back to
the minimum number (currently 4).
Signed-off-by: Junio C Hamano <junkio@cox.net>
Earier specifying an abbreviation shorter than minimum fell back
to full 40 letters, which was nonsense. Make it to fall back to
the minimum number (currently 4).
Signed-off-by: Junio C Hamano <junkio@cox.net>
pretty_print_commit: honor grafts.
When displaying Merge: lines, we used to take the real commit
parents from the commit objects. Use the parsed parents from
the commit object instead, so that we honor fake parent
information from info/grafts.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When displaying Merge: lines, we used to take the real commit
parents from the commit objects. Use the parsed parents from
the commit object instead, so that we honor fake parent
information from info/grafts.
Signed-off-by: Junio C Hamano <junkio@cox.net>
pretty_print_commit(): pass commit object instead of commit->buffer.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Rename rev-parse --abbrev to --short.
The usage of rev-parse to serve as a flag/option parser
for git-whatchanged and other commands have serious limitation
that the flags cannot be something that is supported by
rev-parse itself, and it cannot worked around easily. Since
this is rarely used "poor-man's describe", rename the option for
now as an easier workaround.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The usage of rev-parse to serve as a flag/option parser
for git-whatchanged and other commands have serious limitation
that the flags cannot be something that is supported by
rev-parse itself, and it cannot worked around easily. Since
this is rarely used "poor-man's describe", rename the option for
now as an easier workaround.
Signed-off-by: Junio C Hamano <junkio@cox.net>
rev-parse --abbrev: do not try abbrev shorter than minimum.
We do not allow abbreviation shorter than 4 letters in other
parts of the system so do not attempt to generate such.
Noticed by Uwe Zeisberger.
Signed-off-by: Junio C Hamano <junkio@cox.net>
We do not allow abbreviation shorter than 4 letters in other
parts of the system so do not attempt to generate such.
Noticed by Uwe Zeisberger.
Signed-off-by: Junio C Hamano <junkio@cox.net>
diff-tree: abbreviate merge parent object names with --abbrev --pretty.
When --abbrev is in effect, abbreviate the merge parent names
in prettyprinted output.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When --abbrev is in effect, abbreviate the merge parent names
in prettyprinted output.
Signed-off-by: Junio C Hamano <junkio@cox.net>
rev-parse: --abbrev option.
The new option behaves just like --verify, but outputs an
abbreviated object name that is unique within the repository.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The new option behaves just like --verify, but outputs an
abbreviated object name that is unique within the repository.
Signed-off-by: Junio C Hamano <junkio@cox.net>
abbrev cleanup: use symbolic constants
The minimum length of abbreviated object name was hardcoded in
different places to be 4, risking inconsistencies in the future.
Also there were three different "default abbreviation
precision". Use two C preprocessor symbols to clean up this
mess.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The minimum length of abbreviated object name was hardcoded in
different places to be 4, risking inconsistencies in the future.
Also there were three different "default abbreviation
precision". Use two C preprocessor symbols to clean up this
mess.
Signed-off-by: Junio C Hamano <junkio@cox.net>
rev-list --remove-empty: add minimum help and doc entry.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
rev-list: stop when the file disappears
The one thing I've considered doing (I really should) is to add a "stop
when you don't find the file" option to "git-rev-list". This patch does
some of the work towards that: it removes the "parent" thing when the
file disappears, so a "git annotate" could do do something like
git-rev-list --remove-empty --parents HEAD -- "$filename"
and it would get a good graph that stops when the filename disappears
(it's not perfect though: it won't remove all the unintersting commits).
It also simplifies the logic of finding tree differences a bit, at the
cost of making it a tad less efficient.
The old logic was two-phase: it would first simplify _only_ merges tree as
it traversed the tree, and then simplify the linear parts of the remainder
independently. That was pretty optimal from an efficiency standpoint
because it avoids doing any comparisons that we can see are unnecessary,
but it made it much harder to understand than it really needed to be.
The new logic is a lot more straightforward, and compares the trees as it
traverses the graph (ie everything is a single phase). That makes it much
easier to stop graph traversal at any point where a file disappears.
As an example, let's say that you have a git repository that has had a
file called "A" some time in the past. That file gets renamed to B, and
then gets renamed back again to A. The old "git-rev-list" would show two
commits: the commit that renames B to A (because it changes A) _and_ as
its parent the commit that renames A to B (because it changes A).
With the new --remove-empty flag, git-rev-list will show just the commit
that renames B to A as the "root" commit, and stop traversal there
(because that's what you want for "annotate" - you want to stop there, and
for every "root" commit you then separately see if it really is a new
file, or if the paths history disappeared because it was renamed from some
other file).
With this patch, you should be able to basically do a "poor mans 'git
annotate'" with a fairly simple loop:
push("HEAD", "$filename")
while (revision,filename = pop()) {
for each i in $(git-rev-list --parents --remove-empty $revision -- "$filename")
pseudo-parents($i) = git-rev-list parents for that line
if (pseudo-parents($i) is non-empty) {
show diff of $i against pseudo-parents
continue
}
/* See if the _real_ parents of $i had a rename */
parent($i) = real-parent($i)
if (find-rename in $parent($i)->$i)
push $parent($i), "old-name"
}
which should be doable in perl or something (doing stacks in shell is just
too painful to be worth it, so I'm not going to do this).
Anybody want to try?
Linus
The one thing I've considered doing (I really should) is to add a "stop
when you don't find the file" option to "git-rev-list". This patch does
some of the work towards that: it removes the "parent" thing when the
file disappears, so a "git annotate" could do do something like
git-rev-list --remove-empty --parents HEAD -- "$filename"
and it would get a good graph that stops when the filename disappears
(it's not perfect though: it won't remove all the unintersting commits).
It also simplifies the logic of finding tree differences a bit, at the
cost of making it a tad less efficient.
The old logic was two-phase: it would first simplify _only_ merges tree as
it traversed the tree, and then simplify the linear parts of the remainder
independently. That was pretty optimal from an efficiency standpoint
because it avoids doing any comparisons that we can see are unnecessary,
but it made it much harder to understand than it really needed to be.
The new logic is a lot more straightforward, and compares the trees as it
traverses the graph (ie everything is a single phase). That makes it much
easier to stop graph traversal at any point where a file disappears.
As an example, let's say that you have a git repository that has had a
file called "A" some time in the past. That file gets renamed to B, and
then gets renamed back again to A. The old "git-rev-list" would show two
commits: the commit that renames B to A (because it changes A) _and_ as
its parent the commit that renames A to B (because it changes A).
With the new --remove-empty flag, git-rev-list will show just the commit
that renames B to A as the "root" commit, and stop traversal there
(because that's what you want for "annotate" - you want to stop there, and
for every "root" commit you then separately see if it really is a new
file, or if the paths history disappeared because it was renamed from some
other file).
With this patch, you should be able to basically do a "poor mans 'git
annotate'" with a fairly simple loop:
push("HEAD", "$filename")
while (revision,filename = pop()) {
for each i in $(git-rev-list --parents --remove-empty $revision -- "$filename")
pseudo-parents($i) = git-rev-list parents for that line
if (pseudo-parents($i) is non-empty) {
show diff of $i against pseudo-parents
continue
}
/* See if the _real_ parents of $i had a rename */
parent($i) = real-parent($i)
if (find-rename in $parent($i)->$i)
push $parent($i), "old-name"
}
which should be doable in perl or something (doing stacks in shell is just
too painful to be worth it, so I'm not going to do this).
Anybody want to try?
Linus
diff-files: -c and --cc options.
This ports the "combined diff" to diff-files so that differences
to the working tree files since stage 2 and stage 3 are shown
the same way as combined diff output from diff-tree for the
merge commit would be shown if the current working tree files
are committed.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This ports the "combined diff" to diff-files so that differences
to the working tree files since stage 2 and stage 3 are shown
the same way as combined diff output from diff-tree for the
merge commit would be shown if the current working tree files
are committed.
Signed-off-by: Junio C Hamano <junkio@cox.net>
combine-diff: better hunk splitting.
It considered an otherwise unchanged line that had line removals
in front of it an interesting line, which caused hunks to have
one extra the trailing context line.
Signed-off-by: Junio C Hamano <junkio@cox.net>
It considered an otherwise unchanged line that had line removals
in front of it an interesting line, which caused hunks to have
one extra the trailing context line.
Signed-off-by: Junio C Hamano <junkio@cox.net>
diff-tree --cc: squelch header generation on empty patch.
Earlier round showed the commit log header and "diff --combined"
header even for paths that had no interesting hunk under --cc
flag. Move the header display logic around to squelch them.
With this, a merge that does not have any interesting merges
will not be shown with --cc option, unless -m is used at the
same time.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Earlier round showed the commit log header and "diff --combined"
header even for paths that had no interesting hunk under --cc
flag. Move the header display logic around to squelch them.
With this, a merge that does not have any interesting merges
will not be shown with --cc option, unless -m is used at the
same time.
Signed-off-by: Junio C Hamano <junkio@cox.net>
combine-diff: extend --cc logic to Octopus.
Santi Bejar points out that a hunk that changes from all the
same common parents except one is uninteresting. The earlier
round marked changes from only one parent uninteresting, but
this also marks hunks that have the same change from all but one
parent uninteresting, which is a natural extension of the
original idea to Octopus merges.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Santi Bejar points out that a hunk that changes from all the
same common parents except one is uninteresting. The earlier
round marked changes from only one parent uninteresting, but
this also marks hunks that have the same change from all but one
parent uninteresting, which is a natural extension of the
original idea to Octopus merges.
Signed-off-by: Junio C Hamano <junkio@cox.net>
combine-diff: minor output changes.
Remove extra whitespace between the change indicators and the
body text. That is more in line with the uncombined unified
diff output (pointed out by Santi Bejar).
When showing --cc, say so instead of saying just --combined.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Remove extra whitespace between the change indicators and the
body text. That is more in line with the uncombined unified
diff output (pointed out by Santi Bejar).
When showing --cc, say so instead of saying just --combined.
Signed-off-by: Junio C Hamano <junkio@cox.net>
combine-diff: fix appending at the tail of a list.
... and use the established pattern of tail initialized to point
at the head pointer for an empty list, and updated to point at
the next pointer field of the item at the tail when appending.
Signed-off-by: Junio C Hamano <junkio@cox.net>
... and use the established pattern of tail initialized to point
at the head pointer for an empty list, and updated to point at
the next pointer field of the item at the tail when appending.
Signed-off-by: Junio C Hamano <junkio@cox.net>
diff-tree --cc: denser combined diff output for a merge commit.
Building on the previous '-c' (combined) option, '--cc' option
squelches the output further by omitting hunks that consist of
difference with solely one parent.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Building on the previous '-c' (combined) option, '--cc' option
squelches the output further by omitting hunks that consist of
difference with solely one parent.
Signed-off-by: Junio C Hamano <junkio@cox.net>
diff-tree -c: show a merge commit a bit more sensibly.
A new option '-c' to diff-tree changes the way a merge commit is
displayed when generating a patch output. It shows a "combined
diff" (hence the option letter 'c'), which looks like this:
$ git-diff-tree --pretty -c -p fec9ebf1 | head -n 18
diff-tree fec9ebf... (from parents)
Merge: 0620db3... 8a263ae...
Author: Junio C Hamano <junkio@cox.net>
Date: Sun Jan 15 22:25:35 2006 -0800
Merge fixes up to GIT 1.1.3
diff --combined describe.c
@@@ +98,7 @@@
return (a_date > b_date) ? -1 : (a_date == b_date) ? 0 : 1;
}
- static void describe(char *arg)
- static void describe(struct commit *cmit, int last_one)
++ static void describe(char *arg, int last_one)
{
+ unsigned char sha1[20];
+ struct commit *cmit;
There are a few things to note about this feature:
- The '-c' option implies '-p'. It also implies '-m' halfway
in the sense that "interesting" merges are shown, but not all
merges.
- When a blob matches one of the parents, we do not show a diff
for that path at all. For a merge commit, this option shows
paths with real file-level merge (aka "interesting things").
- As a concequence of the above, an "uninteresting" merge is
not shown at all. You can use '-m' in addition to '-c' to
show the commit log for such a merge, but there will be no
combined diff output.
- Unlike "gitk", the output is monochrome.
A '-' character in the nth column means the line is from the nth
parent and does not appear in the merge result (i.e. removed
from that parent's version).
A '+' character in the nth column means the line appears in the
merge result, and the nth parent does not have that line
(i.e. added by the merge itself or inherited from another
parent).
The above example output shows that the function signature was
changed from either parents (hence two "-" lines and a "++"
line), and "unsigned char sha1[20]", prefixed by a " +", was
inherited from the first parent.
The code as sent to the list was buggy in few corner cases,
which I have fixed since then.
It does not bother to keep track of and show the line numbers
from parent commits, which it probably should.
Signed-off-by: Junio C Hamano <junkio@cox.net>
A new option '-c' to diff-tree changes the way a merge commit is
displayed when generating a patch output. It shows a "combined
diff" (hence the option letter 'c'), which looks like this:
$ git-diff-tree --pretty -c -p fec9ebf1 | head -n 18
diff-tree fec9ebf... (from parents)
Merge: 0620db3... 8a263ae...
Author: Junio C Hamano <junkio@cox.net>
Date: Sun Jan 15 22:25:35 2006 -0800
Merge fixes up to GIT 1.1.3
diff --combined describe.c
@@@ +98,7 @@@
return (a_date > b_date) ? -1 : (a_date == b_date) ? 0 : 1;
}
- static void describe(char *arg)
- static void describe(struct commit *cmit, int last_one)
++ static void describe(char *arg, int last_one)
{
+ unsigned char sha1[20];
+ struct commit *cmit;
There are a few things to note about this feature:
- The '-c' option implies '-p'. It also implies '-m' halfway
in the sense that "interesting" merges are shown, but not all
merges.
- When a blob matches one of the parents, we do not show a diff
for that path at all. For a merge commit, this option shows
paths with real file-level merge (aka "interesting things").
- As a concequence of the above, an "uninteresting" merge is
not shown at all. You can use '-m' in addition to '-c' to
show the commit log for such a merge, but there will be no
combined diff output.
- Unlike "gitk", the output is monochrome.
A '-' character in the nth column means the line is from the nth
parent and does not appear in the merge result (i.e. removed
from that parent's version).
A '+' character in the nth column means the line appears in the
merge result, and the nth parent does not have that line
(i.e. added by the merge itself or inherited from another
parent).
The above example output shows that the function signature was
changed from either parents (hence two "-" lines and a "++"
line), and "unsigned char sha1[20]", prefixed by a " +", was
inherited from the first parent.
The code as sent to the list was buggy in few corner cases,
which I have fixed since then.
It does not bother to keep track of and show the line numbers
from parent commits, which it probably should.
Signed-off-by: Junio C Hamano <junkio@cox.net>
merge: seed the commit message with list of conflicted files.
The files with conflicts need to be hand resolved, and it is a
good discipline for the committer to explain which branch was
taken and why. Pre-fill the merge message template with the
list of conflicted paths to encourage it.
This is from Linus.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The files with conflicts need to be hand resolved, and it is a
good discipline for the committer to explain which branch was
taken and why. Pre-fill the merge message template with the
list of conflicted paths to encourage it.
This is from Linus.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Merge fixes up to GIT 1.1.5
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
GIT 1.1.5
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
GIT 1.0.13
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
checkout: do not make a temporary copy of symlink target.
If the index records an insanely long symbolic link, copying
into the temporary would overflow the buffer (noticed by Mark
Wooding).
Because read_sha1_file() terminates the returned buffer with NUL
since late May 2005, there is no reason to copy it anymore.
Signed-off-by: Junio C Hamano <junkio@cox.net>
If the index records an insanely long symbolic link, copying
into the temporary would overflow the buffer (noticed by Mark
Wooding).
Because read_sha1_file() terminates the returned buffer with NUL
since late May 2005, there is no reason to copy it anymore.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add freebsd support in Makefile
Needs iconv and third party lib/headers are inside /usr/local
Signed-off-by: Alecs King <alecsk@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Needs iconv and third party lib/headers are inside /usr/local
Signed-off-by: Alecs King <alecsk@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Make GIT-VERSION-GEN tolerate missing git describe command again
Commit 5c7d3c95 broke that by making the git-describe command part of
a pipe.
Signed-off-by: Uwe Zeisberger <zeisberg@informatik.uni-freiburg.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Commit 5c7d3c95 broke that by making the git-describe command part of
a pipe.
Signed-off-by: Uwe Zeisberger <zeisberg@informatik.uni-freiburg.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Use symbolic name SHORT_NAME_AMBIGUOUS as error return value
Signed-off-by: Uwe Zeisberger <zeisberg@informatik.uni-freiburg.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Uwe Zeisberger <zeisberg@informatik.uni-freiburg.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Remove unneeded header
Signed-off-by: Uwe Zeisberger <zeisberg@informatik.uni-freiburg.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Uwe Zeisberger <zeisberg@informatik.uni-freiburg.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-fetch --upload-pack: disambiguate.
Johannes noticed the recent addition of this new flag
inadvertently took over existing --update-head-ok (-u). Require
longer abbreviation to this new option which would be needed in
a rare setup.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Johannes noticed the recent addition of this new flag
inadvertently took over existing --update-head-ok (-u). Require
longer abbreviation to this new option which would be needed in
a rare setup.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Only use a single parser for tree objects
This makes read_tree_recursive and read_tree take a struct tree
instead of a buffer. It also move the declaration of read_tree into
tree.h (where struct tree is defined), and updates ls-tree and
diff-index (the only places that presently use read_tree*()) to use
the new versions.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This makes read_tree_recursive and read_tree take a struct tree
instead of a buffer. It also move the declaration of read_tree into
tree.h (where struct tree is defined), and updates ls-tree and
diff-index (the only places that presently use read_tree*()) to use
the new versions.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add compat/unsetenv.c .
Implement a (slow) unsetenv() for older systems.
Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Implement a (slow) unsetenv() for older systems.
Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Run GIT-VERSION-GEN with $(SHELL), not sh.
Alas, not all shells named sh are capable enough to run
GIT-VERSION-GEN.
Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Alas, not all shells named sh are capable enough to run
GIT-VERSION-GEN.
Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Fix git-format-patch -s to include a Signed-off-by: line...
In the last round of bug fixes the signed-off-by line was still be
generated but it was not including a signed-off-by line :(
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
In the last round of bug fixes the signed-off-by line was still be
generated but it was not including a signed-off-by line :(
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
tests: adjust breakage by stricter rev-parse
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-whatchanged: exit out early on errors
If we get an error parsing the arguments, exit.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If we get an error parsing the arguments, exit.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Make git-rev-list and git-rev-parse argument parsing stricter
If you pass it a filename without the "--" marker to separate it from
revision information and flags, we now require that the file in question
actually exists. This makes mis-typed revision information not be silently
just considered a strange filename.
With the "--" marker, you can continue to pass in filenames that do not
actually exists - useful for querying what happened to a file that you
no longer have in the repository.
[ All scripts should use the "--" format regardless, to make things
unambiguous. So this change should not affect any existing tools ]
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If you pass it a filename without the "--" marker to separate it from
revision information and flags, we now require that the file in question
actually exists. This makes mis-typed revision information not be silently
just considered a strange filename.
With the "--" marker, you can continue to pass in filenames that do not
actually exists - useful for querying what happened to a file that you
no longer have in the repository.
[ All scripts should use the "--" format regardless, to make things
unambiguous. So this change should not affect any existing tools ]
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Merge branches 'jc/clone', 'md/env' and 'mo/path'
local push/pull env cleanup
remove environment variables relating to the current repository
before execing the 'remote' half of a local push or pull operation
[jc: the original from Matt spelled out the environment variable
names, which I changed to the preprocessor symbols defined in
cache.h. Also it missed GRAFT_ENVIRONMENT.]
Signed-off-by: Junio C Hamano <junkio@cox.net>
remove environment variables relating to the current repository
before execing the 'remote' half of a local push or pull operation
[jc: the original from Matt spelled out the environment variable
names, which I changed to the preprocessor symbols defined in
cache.h. Also it missed GRAFT_ENVIRONMENT.]
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-{fetch,peek-remote} handling of --upload-pack
git-peek-remote needs to handle a -u|--upload-pack parameter just like
git-fetch (and git-fetch has to pass it on to git-peek-remote).
(This is actually a follow-up to my previous git-fetch patch.)
Signed-off-by: Michal Ostrowski <mostrows@heater.watson.ibm.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-peek-remote needs to handle a -u|--upload-pack parameter just like
git-fetch (and git-fetch has to pass it on to git-peek-remote).
(This is actually a follow-up to my previous git-fetch patch.)
Signed-off-by: Michal Ostrowski <mostrows@heater.watson.ibm.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-fetch: pass --upload-pack to fetch-pack
Without this, there is no way to specify a remote executable when
invoking git-pull/git-fetch as there is for git-clone.
[jc: I have a mild suspicion that this is a broken environment (aka
sysadmin disservice). It may be legal to configure your sshd to
spawn named program without involving shell at all, and if your
sysadmin does so and you have your git programs under your home
directory, you would need something like this, but then I suspect
you would need such workaround everywhere, not just git. But we
have these options we can use to work around the issue, so there
is no strong reason not to reject this patch, either. ]
Signed-off-by: Michal Ostrowski <mostrows@watson.ibm.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Without this, there is no way to specify a remote executable when
invoking git-pull/git-fetch as there is for git-clone.
[jc: I have a mild suspicion that this is a broken environment (aka
sysadmin disservice). It may be legal to configure your sshd to
spawn named program without involving shell at all, and if your
sysadmin does so and you have your git programs under your home
directory, you would need something like this, but then I suspect
you would need such workaround everywhere, not just git. But we
have these options we can use to work around the issue, so there
is no strong reason not to reject this patch, either. ]
Signed-off-by: Michal Ostrowski <mostrows@watson.ibm.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
clone: do not accept more than one -o option.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
clone: do not create remotes/origin nor origin branch in a bare repository.
It is simply pointless, since no merges will ever happen in such
a repository.
Signed-off-by: Junio C Hamano <junkio@cox.net>
It is simply pointless, since no merges will ever happen in such
a repository.
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-clone: PG13 --naked option to --bare.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Don't include ../README in git.txt - make a local copy
asciidoc 7.0.4 and newer considers such includes from parent directory
unsafe.
Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
asciidoc 7.0.4 and newer considers such includes from parent directory
unsafe.
Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
sample update-hook: sanely handle a new branch head.
Instead of showing all the history since the beginning of time
leading to the the branch head, show only the changes this new
branch brings to the world.
This originally came from Linus and tested by Andreas Ericsson.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Instead of showing all the history since the beginning of time
leading to the the branch head, show only the changes this new
branch brings to the world.
This originally came from Linus and tested by Andreas Ericsson.
Signed-off-by: Junio C Hamano <junkio@cox.net>
update-hook: Major overhaul (handling tags, mainly).
This is the update hook we use in all our git-repos.
It has some improvements over the original version, namely:
* Don't send every commit since dawn of time when adding a new tag.
* When updating an annotated tag, just send the diffs since the last tag.
* Add diffstat output for 'normal' commits (top) and annotated tags (bottom).
* Block un-annotated tags in shared repos.
I'm a bit uncertain about that last one, but it demonstrates how to
disallow updates of a ref which we use, so I kept it.
Note that git-describe is needed for the "changes since last annotated tag"
thing to work.
Signed-off-by: Andreas Ericsson <ae@op5.se>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is the update hook we use in all our git-repos.
It has some improvements over the original version, namely:
* Don't send every commit since dawn of time when adding a new tag.
* When updating an annotated tag, just send the diffs since the last tag.
* Add diffstat output for 'normal' commits (top) and annotated tags (bottom).
* Block un-annotated tags in shared repos.
I'm a bit uncertain about that last one, but it demonstrates how to
disallow updates of a ref which we use, so I kept it.
Note that git-describe is needed for the "changes since last annotated tag"
thing to work.
Signed-off-by: Andreas Ericsson <ae@op5.se>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Documentation: finishing touches to the new tutorial.
We forgot to update the primary link from git.html leading to
the tutorial, and also forgot to build and install the renamed
core-tutorial document.
Signed-off-by: Junio C Hamano <junkio@cox.net>
We forgot to update the primary link from git.html leading to
the tutorial, and also forgot to build and install the renamed
core-tutorial document.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Recommend to remove unused `origin` in a shared repository.
It is a common mistake to leave an unsed `origin` branch behind
if a shared public repository was created by first cloning from
somewhere else. Subsequent `git push` into it with the default
"push all the matching ref" would push the `origin` branch from
the developer repository uselessly.
Signed-off-by: Junio C Hamano <junkio@cox.net>
It is a common mistake to leave an unsed `origin` branch behind
if a shared public repository was created by first cloning from
somewhere else. Subsequent `git push` into it with the default
"push all the matching ref" would push the `origin` branch from
the developer repository uselessly.
Signed-off-by: Junio C Hamano <junkio@cox.net>
New tutorial
The current Documentation/tutorial.txt concentrates on the lower-level
git interfaces. So it's useful to people developing alternative
porcelains, to advanced users, etc., but not so much to beginning users.
I think it makes sense for the main tutorial to address those
beginnning users, so with this patch I'm proposing that we move
Documentation/tutorial.txt to Documentation/core-tutorial.txt and
replace it by a new tutorial.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The current Documentation/tutorial.txt concentrates on the lower-level
git interfaces. So it's useful to people developing alternative
porcelains, to advanced users, etc., but not so much to beginning users.
I think it makes sense for the main tutorial to address those
beginnning users, so with this patch I'm proposing that we move
Documentation/tutorial.txt to Documentation/core-tutorial.txt and
replace it by a new tutorial.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-grep: clarification on parameters.
We forgot to make sure that there is no more than one pattern
parameter. Also when looking for files in a directory called
'--others', it passed that path limiter without preceding the
end-of-options marker '--' to underlying git-ls-files, which
misunderstood it as one of its options instead.
$ git grep --others -e Meta/Make Meta
$ git grep -o -e Meta/Make Meta
$ git grep -o Meta/Make Meta
look for a string "Meta/Make" from untracked files in Meta/
directory.
$ git grep Meta/Make --others
looks for the same string from tracked files in ./--others
directory.
On the other hand,
$ git grep -e Meta/Make --others
does not have a freestanding pattern, so everybody is parameter
and there is no path specifier. It looks for the string in all
the untracked files without any path limiter.
[jc: updated with usability enhancements and documentation
cleanups from Sean.]
Signed-off-by: Junio C Hamano <junkio@cox.net>
We forgot to make sure that there is no more than one pattern
parameter. Also when looking for files in a directory called
'--others', it passed that path limiter without preceding the
end-of-options marker '--' to underlying git-ls-files, which
misunderstood it as one of its options instead.
$ git grep --others -e Meta/Make Meta
$ git grep -o -e Meta/Make Meta
$ git grep -o Meta/Make Meta
look for a string "Meta/Make" from untracked files in Meta/
directory.
$ git grep Meta/Make --others
looks for the same string from tracked files in ./--others
directory.
On the other hand,
$ git grep -e Meta/Make --others
does not have a freestanding pattern, so everybody is parameter
and there is no path specifier. It looks for the string in all
the untracked files without any path limiter.
[jc: updated with usability enhancements and documentation
cleanups from Sean.]
Signed-off-by: Junio C Hamano <junkio@cox.net>
Undef DT_* before redefining them.
When overriding DT_* macro detection with NO_D_TYPE_IN_DIRENT (recent
Cygwin build problem, which hopefully is already fixed in their CVS
snapshot version), we define DTYPE() macro to return just "we do not
know", but still needed to use DT_* macro to avoid ifdef in the code
we use them. If the platform defines DT_* macro but with unusable
d_type, this would have resulted in us redefining these preprocessor
symbols.
Admittedly, that would be just a couple of compilation warnings, and
on Cygwin at least this particular problem is transitory (the problem
is already fixed in their CVS snapshot version), so this is a low
priority fix.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When overriding DT_* macro detection with NO_D_TYPE_IN_DIRENT (recent
Cygwin build problem, which hopefully is already fixed in their CVS
snapshot version), we define DTYPE() macro to return just "we do not
know", but still needed to use DT_* macro to avoid ifdef in the code
we use them. If the platform defines DT_* macro but with unusable
d_type, this would have resulted in us redefining these preprocessor
symbols.
Admittedly, that would be just a couple of compilation warnings, and
on Cygwin at least this particular problem is transitory (the problem
is already fixed in their CVS snapshot version), so this is a low
priority fix.
Signed-off-by: Junio C Hamano <junkio@cox.net>
t4011: "sleep 1" is not enough on FAT
This test depended on "sleep 1" to be enough to dirty the index
entry for a symlink. Alex noticed that on his Cygwin installation
"sleep 1" was sometimes not enough, and after further discussion with
Christopher Faylor, it was brought up that on FAT filesystem timestamp
granularity is 2 seconds so sleeping 1 second is not enough.
For now this patch takes an easy workaround of sleeping for 3 seconds.
Very strictly speaking, POSIX requires lstat to fill only S_IFMT part
of st_mode and st_size for symlinks, and depending on timestamp might
be considered a bug, but we depend on that anyway, so it is better to
test that.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This test depended on "sleep 1" to be enough to dirty the index
entry for a symlink. Alex noticed that on his Cygwin installation
"sleep 1" was sometimes not enough, and after further discussion with
Christopher Faylor, it was brought up that on FAT filesystem timestamp
granularity is 2 seconds so sleeping 1 second is not enough.
For now this patch takes an easy workaround of sleeping for 3 seconds.
Very strictly speaking, POSIX requires lstat to fill only S_IFMT part
of st_mode and st_size for symlinks, and depending on timestamp might
be considered a bug, but we depend on that anyway, so it is better to
test that.
Signed-off-by: Junio C Hamano <junkio@cox.net>
DT_UNKNOWN: do not fully trust existence of DT_UNKNOWN
The recent Cygwin defines DT_UNKNOWN although it does not have d_type
in struct dirent. Give an option to tell us not to use d_type on such
platforms. Hopefully this problem will be transient.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The recent Cygwin defines DT_UNKNOWN although it does not have d_type
in struct dirent. Give an option to tell us not to use d_type on such
platforms. Hopefully this problem will be transient.
Signed-off-by: Junio C Hamano <junkio@cox.net>
fsck-objects: support platforms without d_ino in struct dirent.
The d_ino field is only used for performance reasons in
fsck-objects. On a typical filesystem, i-number tends to have a
strong correlation with where the actual bits sit on the disk
platter, and we sort the entries to allow us scan things that
ought to be close together together.
If the platform lacks support for it, it is not a big deal.
Just do not use d_ino for sorting, and scan them unsorted.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The d_ino field is only used for performance reasons in
fsck-objects. On a typical filesystem, i-number tends to have a
strong correlation with where the actual bits sit on the disk
platter, and we sort the entries to allow us scan things that
ought to be close together together.
If the platform lacks support for it, it is not a big deal.
Just do not use d_ino for sorting, and scan them unsorted.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Makefile: do not assume lack of IPV6 means no sockaddr_storage.
Noticed first by Alex, that the latest Cygwin now properly has
sockaddr_storage.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Noticed first by Alex, that the latest Cygwin now properly has
sockaddr_storage.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Mention install-doc in INSTALL
I think most people will want to install the man pages as well.
[jc: incorporated Pasky's comment on not building them as root.
Some people may not want to install asciidoc/xmlto toolchain, so
redirect them to the man and html branches of the git.git
repository as well.]
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I think most people will want to install the man pages as well.
[jc: incorporated Pasky's comment on not building them as root.
Some people may not want to install asciidoc/xmlto toolchain, so
redirect them to the man and html branches of the git.git
repository as well.]
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>