Merge branch 'ra/email'
* ra/email:
send-email: Add --cc
send-email: Add some options for controlling how addresses are automatically added to the cc: list.
* ra/email:
send-email: Add --cc
send-email: Add some options for controlling how addresses are automatically added to the cc: list.
Merge branch 'jc/commit'
* jc/commit:
git-commit: Now --only semantics is the default.
* jc/commit:
git-commit: Now --only semantics is the default.
Merge branch 'jc/rebase'
* jc/rebase:
rebase: allow a hook to refuse rebasing.
* jc/rebase:
rebase: allow a hook to refuse rebasing.
Merge branch 'jc/nostat'
* jc/nostat:
cache_name_compare() compares name and stage, nothing else.
* jc/nostat:
cache_name_compare() compares name and stage, nothing else.
send-email: Add --cc
Since Junio used this in an example, and I've personally tried to use it, I
suppose the option should actually exist.
Signed-off-by: Ryan Anderson <ryan@michonline.com>
Since Junio used this in an example, and I've personally tried to use it, I
suppose the option should actually exist.
Signed-off-by: Ryan Anderson <ryan@michonline.com>
send-email: Add some options for controlling how addresses are automatically added to the cc: list.
Signed-off-by: Ryan Anderson <ryan@michonline.com>
Signed-off-by: Ryan Anderson <ryan@michonline.com>
rebase: allow a hook to refuse rebasing.
This lets a hook to interfere a rebase and help prevent certain
branches from being rebased by mistake. A sample hook to show
how to prevent a topic branch that has already been merged into
publish branch.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This lets a hook to interfere a rebase and help prevent certain
branches from being rebased by mistake. A sample hook to show
how to prevent a topic branch that has already been merged into
publish branch.
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-commit: Now --only semantics is the default.
This changes the "git commit paths..." to default to --only
semantics from traditional --include semantics, as agreed on the
list.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This changes the "git commit paths..." to default to --only
semantics from traditional --include semantics, as agreed on the
list.
Signed-off-by: Junio C Hamano <junkio@cox.net>
cache_name_compare() compares name and stage, nothing else.
The code was a bit unclear in expressing what it wants to compare.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The code was a bit unclear in expressing what it wants to compare.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Merge branch 'master'
* master:
GIT 1.2.0
Fix "test: unexpected operator" on bsd
* master:
GIT 1.2.0
Fix "test: unexpected operator" on bsd
GIT 1.2.0
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Fix "test: unexpected operator" on bsd
This fixes the same issue as a previous fix by Alex Riesen does.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This fixes the same issue as a previous fix by Alex Riesen does.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Merge branch 'pb/bisect'
* pb/bisect:
Properly git-bisect reset after bisecting from non-master head
git-commit: show dirtiness including index.
Make pack-objects chattier.
* pb/bisect:
Properly git-bisect reset after bisecting from non-master head
git-commit: show dirtiness including index.
Make pack-objects chattier.
Properly git-bisect reset after bisecting from non-master head
git-bisect reset without an argument would return to master even
if the bisecting started at a non-master branch. This patch makes
it save the original branch name to .git/head-name and restore it
afterwards.
This is also compatible with Cogito and cg-seek, so cg-status will
show that we are seeked on the bisect branch and cg-reset will
properly restore the original branch.
git-bisect start will refuse to work if it is not on a bisect but
.git/head-name exists; this is to protect against conflicts with
other seeking tools.
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-bisect reset without an argument would return to master even
if the bisecting started at a non-master branch. This patch makes
it save the original branch name to .git/head-name and restore it
afterwards.
This is also compatible with Cogito and cg-seek, so cg-status will
show that we are seeked on the bisect branch and cg-reset will
properly restore the original branch.
git-bisect start will refuse to work if it is not on a bisect but
.git/head-name exists; this is to protect against conflicts with
other seeking tools.
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-commit: show dirtiness including index.
Earlier, when we switched a branch we used diff-files to show
paths that are dirty in the working tree. But we allow switching
branches with updated index ("read-tree -m -u $old $new" works that
way), and only showing paths that have differences in the working
tree but not paths that are different in index was confusing.
This shows both as modified from the top commit of the branch we
just have switched to.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Earlier, when we switched a branch we used diff-files to show
paths that are dirty in the working tree. But we allow switching
branches with updated index ("read-tree -m -u $old $new" works that
way), and only showing paths that have differences in the working
tree but not paths that are different in index was confusing.
This shows both as modified from the top commit of the branch we
just have switched to.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Make pack-objects chattier.
You could give -q to squelch it, but currently no tool does it.
This would make 'git clone host:repo here' over ssh not silent
again.
Signed-off-by: Junio C Hamano <junkio@cox.net>
You could give -q to squelch it, but currently no tool does it.
This would make 'git clone host:repo here' over ssh not silent
again.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Merge branch 'master'
* master:
avoid echo -e, there are systems where it does not work
fix "test: 2: unexpected operator" on bsd
Fix object re-hashing
hashtable-based objects: minimum fixups.
Use a hashtable for objects instead of a sorted list
* master:
avoid echo -e, there are systems where it does not work
fix "test: 2: unexpected operator" on bsd
Fix object re-hashing
hashtable-based objects: minimum fixups.
Use a hashtable for objects instead of a sorted list
avoid echo -e, there are systems where it does not work
FreeBSD 4.11 being one example: the built-in echo doesn't have -e,
and the installed /bin/echo does not do "-e" as well.
"printf" works, laking just "\e" and "\xAB'.
Signed-off-by: Junio C Hamano <junkio@cox.net>
FreeBSD 4.11 being one example: the built-in echo doesn't have -e,
and the installed /bin/echo does not do "-e" as well.
"printf" works, laking just "\e" and "\xAB'.
Signed-off-by: Junio C Hamano <junkio@cox.net>
fix "test: 2: unexpected operator" on bsd
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Fix object re-hashing
The hashed object lookup had a subtle bug in re-hashing: it did
for (i = 0; i < count; i++)
if (objs[i]) {
.. rehash ..
where "count" was the old hash couny. Oon the face of it is obvious, since
it clearly re-hashes all the old objects.
However, it's wrong.
If the last old hash entry before re-hashing was in use (or became in use
by the re-hashing), then when re-hashing could have inserted an object
into the hash entries with idx >= count due to overflow. When we then
rehash the last old entry, that old entry might become empty, which means
that the overflow entries should be re-hashed again.
In other words, the loop has to be fixed to either traverse the whole
array, rather than just the old count.
(There's room for a slight optimization: instead of counting all the way
up, we can break when we see the first empty slot that is above the old
"count". At that point we know we don't have any collissions that we might
have to fix up any more. This patch only does the trivial fix)
[jc: with trivial fix on trivial fix]
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The hashed object lookup had a subtle bug in re-hashing: it did
for (i = 0; i < count; i++)
if (objs[i]) {
.. rehash ..
where "count" was the old hash couny. Oon the face of it is obvious, since
it clearly re-hashes all the old objects.
However, it's wrong.
If the last old hash entry before re-hashing was in use (or became in use
by the re-hashing), then when re-hashing could have inserted an object
into the hash entries with idx >= count due to overflow. When we then
rehash the last old entry, that old entry might become empty, which means
that the overflow entries should be re-hashed again.
In other words, the loop has to be fixed to either traverse the whole
array, rather than just the old count.
(There's room for a slight optimization: instead of counting all the way
up, we can break when we see the first empty slot that is above the old
"count". At that point we know we don't have any collissions that we might
have to fix up any more. This patch only does the trivial fix)
[jc: with trivial fix on trivial fix]
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
hashtable-based objects: minimum fixups.
Calling hashtable_index from find_object before objs is created
would result in division by zero failure. Avoid it.
Also the given object name may not be aligned suitably for
unsigned int; avoid dereferencing casted pointer.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Calling hashtable_index from find_object before objs is created
would result in division by zero failure. Avoid it.
Also the given object name may not be aligned suitably for
unsigned int; avoid dereferencing casted pointer.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Use a hashtable for objects instead of a sorted list
In a simple test, this brings down the CPU time from 47 sec to 22 sec.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
In a simple test, this brings down the CPU time from 47 sec to 22 sec.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Merge branch 'master'
* master:
Add howto about separating topics.
Merge branch 'pb/repo'
Add support for explicit type specifiers when calling git-repo-config
Merge branch 'jc/fixdiff'
diff-tree: do not default to -c
Avoid using "git-var -l" until it gets fixed.
t5500: adjust to change in pack-object reporting behaviour.
Only call git-rerere if $GIT_DIR/rr-cache exists.
Use a relative path for SVN importing
fetch-clone progress: finishing touches.
Fix fetch-clone in the presense of signals
Make "git clone" pack-fetching download statistics better
Make "git clone" less of a deathly quiet experience
* master:
Add howto about separating topics.
Merge branch 'pb/repo'
Add support for explicit type specifiers when calling git-repo-config
Merge branch 'jc/fixdiff'
diff-tree: do not default to -c
Avoid using "git-var -l" until it gets fixed.
t5500: adjust to change in pack-object reporting behaviour.
Only call git-rerere if $GIT_DIR/rr-cache exists.
Use a relative path for SVN importing
fetch-clone progress: finishing touches.
Fix fetch-clone in the presense of signals
Make "git clone" pack-fetching download statistics better
Make "git clone" less of a deathly quiet experience
Add howto about separating topics.
This howto consists of a footnote from an email by JC to the git
mailing list (<7vfyms0x4p.fsf@assigned-by-dhcp.cox.net>).
Signed-off-by: Kent Engstrom <kent@lysator.liu.se>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This howto consists of a footnote from an email by JC to the git
mailing list (<7vfyms0x4p.fsf@assigned-by-dhcp.cox.net>).
Signed-off-by: Kent Engstrom <kent@lysator.liu.se>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Merge branch 'pb/repo'
* pb/repo:
Add support for explicit type specifiers when calling git-repo-config
* pb/repo:
Add support for explicit type specifiers when calling git-repo-config
Merge branch 'jc/fixdiff'
* jc/fixdiff:
diff-tree: do not default to -c
* jc/fixdiff:
diff-tree: do not default to -c
Avoid using "git-var -l" until it gets fixed.
This is to be nicer to people with unusable GECOS field.
"git-var -l" is currently broken in that when used by a user who
does not have a usable GECOS field and has not corrected it by
exporting GIT_COMMITTER_NAME environment variable it dies when
it tries to output GIT_COMMITTER_IDENT (same thing for AUTHOR).
"git-pull" used "git-var -l" only because it needed to get a
configuration variable before "git-repo-config --get" was
introduced. Use the latter tool designed exactly for this
purpose.
"git-sh-setup" used "git-var GIT_AUTHOR_IDENT" without actually
wanting to use its value. The only purpose was to cause the
command to check and barf if the repository format version
recorded in the $GIT_DIR/config file is too new for us to deal
with correctly. Instead, use "repo-config --get" on a random
property and see if it die()s, and check if the exit status is
128 (comes from die -- missing variable is reported with exit
status 1, so we can tell that case apart).
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is to be nicer to people with unusable GECOS field.
"git-var -l" is currently broken in that when used by a user who
does not have a usable GECOS field and has not corrected it by
exporting GIT_COMMITTER_NAME environment variable it dies when
it tries to output GIT_COMMITTER_IDENT (same thing for AUTHOR).
"git-pull" used "git-var -l" only because it needed to get a
configuration variable before "git-repo-config --get" was
introduced. Use the latter tool designed exactly for this
purpose.
"git-sh-setup" used "git-var GIT_AUTHOR_IDENT" without actually
wanting to use its value. The only purpose was to cause the
command to check and barf if the repository format version
recorded in the $GIT_DIR/config file is too new for us to deal
with correctly. Instead, use "repo-config --get" on a random
property and see if it die()s, and check if the exit status is
128 (comes from die -- missing variable is reported with exit
status 1, so we can tell that case apart).
Signed-off-by: Junio C Hamano <junkio@cox.net>
Merge branch 'jc/nostat'
* jc/nostat:
"assume unchanged" git: documentation.
ls-files: split "show-valid-bit" into a different option.
* jc/nostat:
"assume unchanged" git: documentation.
ls-files: split "show-valid-bit" into a different option.
"assume unchanged" git: documentation.
This updates documentation to describe the "assume unchanged"
behaviour.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This updates documentation to describe the "assume unchanged"
behaviour.
Signed-off-by: Junio C Hamano <junkio@cox.net>
ls-files: split "show-valid-bit" into a different option.
To preserve compatibility with scripts that expect uppercase
letters to be shown, do not make '-t' to unconditionally show
the valid bit. Introduce '-v' option for that.
Signed-off-by: Junio C Hamano <junkio@cox.net>
To preserve compatibility with scripts that expect uppercase
letters to be shown, do not make '-t' to unconditionally show
the valid bit. Introduce '-v' option for that.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add support for explicit type specifiers when calling git-repo-config
Currently, git-repo-config will just return the raw value of option
as specified in the config file; this makes things difficult for scripts
calling it, especially if the value is supposed to be boolean.
This patch makes it possible to ask git-repo-config to check if the option
is of the given type (int or bool) and write out the value in its
canonical form. If you do not pass --int or --bool, the behaviour stays
unchanged and the raw value is emitted.
This also incidentally fixes the segfault when option with no value is
encountered.
[jc: tweaked the option parsing a bit to make it easier to see
that the patch does not change anything but the type stuff in
the diff output. Also changed to avoid "foo ? : bar" construct. ]
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Currently, git-repo-config will just return the raw value of option
as specified in the config file; this makes things difficult for scripts
calling it, especially if the value is supposed to be boolean.
This patch makes it possible to ask git-repo-config to check if the option
is of the given type (int or bool) and write out the value in its
canonical form. If you do not pass --int or --bool, the behaviour stays
unchanged and the raw value is emitted.
This also incidentally fixes the segfault when option with no value is
encountered.
[jc: tweaked the option parsing a bit to make it easier to see
that the patch does not change anything but the type stuff in
the diff output. Also changed to avoid "foo ? : bar" construct. ]
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
diff-tree: do not default to -c
Marco says it breaks qgit. This makes the flags a bit more
orthogonal.
$ git-diff-tree -r --abbrev ca18
No output from this command because you asked to skip merge by
not having -m there.
$ git-diff-tree -r -m --abbrev ca18
ca182053c7710a286d72102f4576cf32e0dafcfb
:100644 100644 538d21d... 59042d1... M Makefile
:100644 100644 410b758... 6c47c3a... M entry.c
ca182053c7710a286d72102f4576cf32e0dafcfb
:100644 100644 30479b4... 59042d1... M Makefile
The same "independent sets of diff" as before without -c.
$ git-diff-tree -r -m -c --abbrev ca18
ca182053c7710a286d72102f4576cf32e0dafcfb
::100644 100644 100644 538d21d... 30479b4... 59042d1... MM Makefile
Combined.
$ git-diff-tree -r -c --abbrev ca18
ca182053c7710a286d72102f4576cf32e0dafcfb
::100644 100644 100644 538d21d... 30479b4... 59042d1... MM Makefile
Asking for combined without -m does not make sense, so -c
implies -m.
We need to supply -c as default to whatchanged, which is a
one-liner.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Marco says it breaks qgit. This makes the flags a bit more
orthogonal.
$ git-diff-tree -r --abbrev ca18
No output from this command because you asked to skip merge by
not having -m there.
$ git-diff-tree -r -m --abbrev ca18
ca182053c7710a286d72102f4576cf32e0dafcfb
:100644 100644 538d21d... 59042d1... M Makefile
:100644 100644 410b758... 6c47c3a... M entry.c
ca182053c7710a286d72102f4576cf32e0dafcfb
:100644 100644 30479b4... 59042d1... M Makefile
The same "independent sets of diff" as before without -c.
$ git-diff-tree -r -m -c --abbrev ca18
ca182053c7710a286d72102f4576cf32e0dafcfb
::100644 100644 100644 538d21d... 30479b4... 59042d1... MM Makefile
Combined.
$ git-diff-tree -r -c --abbrev ca18
ca182053c7710a286d72102f4576cf32e0dafcfb
::100644 100644 100644 538d21d... 30479b4... 59042d1... MM Makefile
Asking for combined without -m does not make sense, so -c
implies -m.
We need to supply -c as default to whatchanged, which is a
one-liner.
Signed-off-by: Junio C Hamano <junkio@cox.net>
t5500: adjust to change in pack-object reporting behaviour.
Now pack-object is not as chatty when its stderr is not connected
to a terminal, so the test needs to be adjusted for that.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Now pack-object is not as chatty when its stderr is not connected
to a terminal, so the test needs to be adjusted for that.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Only call git-rerere if $GIT_DIR/rr-cache exists.
Johannes noticed that git-rerere depends on Digest.pm, and if
one does not use the command, one can live without it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Johannes noticed that git-rerere depends on Digest.pm, and if
one does not use the command, one can live without it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Use a relative path for SVN importing
The absolute path (with the leading slash) breaks SVN importing,
because it then looks for /trunk/... instead of /svn/trunk/...
(in my case, the repository URL was https://servername/svn/)
Signed-off-by: Christian Biesinger <cbiesinger@web.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The absolute path (with the leading slash) breaks SVN importing,
because it then looks for /trunk/... instead of /svn/trunk/...
(in my case, the repository URL was https://servername/svn/)
Signed-off-by: Christian Biesinger <cbiesinger@web.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
fetch-clone progress: finishing touches.
This makes fetch-pack also report the progress of packing part.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This makes fetch-pack also report the progress of packing part.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Fix fetch-clone in the presense of signals
We shouldn't fail a fetch just because a signal might have interrupted
the read.
Normally, we don't install any signal handlers, so EINTR really shouldn't
happen. That said, really old versions of Linux will interrupt an
interruptible system call even for signals that turn out to be ignored
(SIGWINCH is the classic example - resizing your xterm would cause it).
The same might well be true elsewhere too.
Also, since receive_keep_pack() doesn't control the caller, it can't know
that no signal handlers exist.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We shouldn't fail a fetch just because a signal might have interrupted
the read.
Normally, we don't install any signal handlers, so EINTR really shouldn't
happen. That said, really old versions of Linux will interrupt an
interruptible system call even for signals that turn out to be ignored
(SIGWINCH is the classic example - resizing your xterm would cause it).
The same might well be true elsewhere too.
Also, since receive_keep_pack() doesn't control the caller, it can't know
that no signal handlers exist.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Make "git clone" pack-fetching download statistics better
Average it out over a few events to make the numbers stable, and fix the
silly usec->binary-ms conversion.
Yeah, yeah, it's arguably eye-candy to keep the user calm, but let's do
that right.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Average it out over a few events to make the numbers stable, and fix the
silly usec->binary-ms conversion.
Yeah, yeah, it's arguably eye-candy to keep the user calm, but let's do
that right.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Make "git clone" less of a deathly quiet experience
It used to be that "git-unpack-objects" would give nice percentages, but
now that we don't unpack the initial clone pack any more, it doesn't. And
I'd love to do that nice percentage view in the pack objects downloader
too, but the thing doesn't even read the pack header, much less know how
much it's going to get, so I was lazy and didn't.
Instead, it at least prints out how much data it's gotten, and what the
packing speed is. Which makes the user realize that it's actually doing
something useful instead of sitting there silently (and if the recipient
knows how large the final result is, he can at least make a guess about
when it migt be done).
So with this patch, I get something like this on my DSL line:
[torvalds@g5 ~]$ time git clone master.kernel.org:/pub/scm/linux/kernel/git/torvalds/linux-2.6 clone-test
Packing 188543 objects
48.398MB (154 kB/s)
where even the speed approximation seems to be roughtly correct (even
though my algorithm is a truly stupid one, and only really gives "speed in
the last half second or so").
Anyway, _something_ like this is definitely needed. It could certainly be
better (if it showed the same kind of thing that git-unpack-objects did,
that would be much nicer, but would require parsing the object stream as
it comes in). But this is big step forward, I think.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
It used to be that "git-unpack-objects" would give nice percentages, but
now that we don't unpack the initial clone pack any more, it doesn't. And
I'd love to do that nice percentage view in the pack objects downloader
too, but the thing doesn't even read the pack header, much less know how
much it's going to get, so I was lazy and didn't.
Instead, it at least prints out how much data it's gotten, and what the
packing speed is. Which makes the user realize that it's actually doing
something useful instead of sitting there silently (and if the recipient
knows how large the final result is, he can at least make a guess about
when it migt be done).
So with this patch, I get something like this on my DSL line:
[torvalds@g5 ~]$ time git clone master.kernel.org:/pub/scm/linux/kernel/git/torvalds/linux-2.6 clone-test
Packing 188543 objects
48.398MB (154 kB/s)
where even the speed approximation seems to be roughtly correct (even
though my algorithm is a truly stupid one, and only really gives "speed in
the last half second or so").
Anyway, _something_ like this is definitely needed. It could certainly be
better (if it showed the same kind of thing that git-unpack-objects did,
that would be much nicer, but would require parsing the object stream as
it comes in). But this is big step forward, I think.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Merge branch 'master'
* master:
Define GIT_(AUTHOR|COMMITTER)_(NAME|EMAIL) to known values.
Merge branch 'lt/diff-tree'
git-commit -v: have patch at the end.
* master:
Define GIT_(AUTHOR|COMMITTER)_(NAME|EMAIL) to known values.
Merge branch 'lt/diff-tree'
git-commit -v: have patch at the end.
Define GIT_(AUTHOR|COMMITTER)_(NAME|EMAIL) to known values.
Without these, running tests with an account with empty gecos
field would fail.
We might want to loosen error from "git-var -l" (but not
"git-var GIT_AUTHOR_NAME") later, but that is more or less an
independent issue.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Without these, running tests with an account with empty gecos
field would fail.
We might want to loosen error from "git-var -l" (but not
"git-var GIT_AUTHOR_NAME") later, but that is more or less an
independent issue.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Merge branch 'lt/diff-tree'
* lt/diff-tree:
combine-diff: Record diff status a bit more faithfully
find_unique_abbrev() simplification.
combine-diff: move formatting logic to show_combined_diff()
combined-diff: use diffcore before intersecting paths.
diff-tree -c raw output
* lt/diff-tree:
combine-diff: Record diff status a bit more faithfully
find_unique_abbrev() simplification.
combine-diff: move formatting logic to show_combined_diff()
combined-diff: use diffcore before intersecting paths.
diff-tree -c raw output
git-commit -v: have patch at the end.
It was pointed out that otherwise more important summary
information prefixed with '#' would become prone to be missed.
Also instead of chopping at the first '^---$' line, stop at the
first 'diff --git a/' line.
Signed-off-by: Junio C Hamano <junkio@cox.net>
It was pointed out that otherwise more important summary
information prefixed with '#' would become prone to be missed.
Also instead of chopping at the first '^---$' line, stop at the
first 'diff --git a/' line.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Merge branch 'master'
* master:
rev-list: default to abbreviate merge parent names under --pretty.
delta micro optimization
count-delta.c: comment fixes
Merge branch 'jc/empty-commit'
* master:
rev-list: default to abbreviate merge parent names under --pretty.
delta micro optimization
count-delta.c: comment fixes
Merge branch 'jc/empty-commit'
rev-list: default to abbreviate merge parent names under --pretty.
When we prettyprint commit log messages, merge parent names were
often very long and there was no way to abbreviate it.
This changes them to be abbreviated by default, and non-default
abbreviations can be specified with --no-abbrev or --abbrev=<n>
options.
Note that this affects only the prettyprinted parent names. The
output from --show-parents is meant for machine consumption and
is not affected by this flag.
When we prettyprint commit log messages, merge parent names were
often very long and there was no way to abbreviate it.
This changes them to be abbreviated by default, and non-default
abbreviations can be specified with --no-abbrev or --abbrev=<n>
options.
Note that this affects only the prettyprinted parent names. The
output from --show-parents is meant for machine consumption and
is not affected by this flag.
delta micro optimization
My kernel work habit made me look at the generated assembly for the
delta code, and one obvious albeit small improvement is this patch.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
My kernel work habit made me look at the generated assembly for the
delta code, and one obvious albeit small improvement is this patch.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
count-delta.c: comment fixes
There was a stale comment that explains why the old code could
undercount when delta data copied things around inside detination
buffer. We do not use that kind of delta, so the comment does
not apply.
There was a stale comment that explains why the old code could
undercount when delta data copied things around inside detination
buffer. We do not use that kind of delta, so the comment does
not apply.
Merge branch 'jc/empty-commit'
* jc/empty-commit:
t6000: fix a careless test library add-on.
Do not allow empty name or email.
* jc/empty-commit:
t6000: fix a careless test library add-on.
Do not allow empty name or email.
Merge branch 'lt/diff-tree'
* lt/diff-tree:
combine-diff: Record diff status a bit more faithfully
find_unique_abbrev() simplification.
* lt/diff-tree:
combine-diff: Record diff status a bit more faithfully
find_unique_abbrev() simplification.
combine-diff: Record diff status a bit more faithfully
This shows "new file mode XXXX" and "deleted file mode XXXX"
lines like two-way diff-patch output does, by checking the
status from each parent.
The diff-raw output for combined diff is made a bit uglier by
showing diff status letters with each parent. While most of the
case you would see "MM" in the output, an Evil Merge that
touches a path that was added by inheriting from one parent is
possible and it would be shown like these:
$ git-diff-tree --abbrev -c HEAD
2d7ca89675eb8888b0b88a91102f096d4471f09f
::000000 000000 100644 0000000... 0000000... 31dd686... AA b
::000000 100644 100644 0000000... 6c884ae... c6d4fa8... AM d
::100644 100644 100644 4f7cbe7... f8c295c... 19d5d80... RR e
Signed-off-by: Junio C Hamano <junkio@cox.net>
This shows "new file mode XXXX" and "deleted file mode XXXX"
lines like two-way diff-patch output does, by checking the
status from each parent.
The diff-raw output for combined diff is made a bit uglier by
showing diff status letters with each parent. While most of the
case you would see "MM" in the output, an Evil Merge that
touches a path that was added by inheriting from one parent is
possible and it would be shown like these:
$ git-diff-tree --abbrev -c HEAD
2d7ca89675eb8888b0b88a91102f096d4471f09f
::000000 000000 100644 0000000... 0000000... 31dd686... AA b
::000000 100644 100644 0000000... 6c884ae... c6d4fa8... AM d
::100644 100644 100644 4f7cbe7... f8c295c... 19d5d80... RR e
Signed-off-by: Junio C Hamano <junkio@cox.net>
find_unique_abbrev() simplification.
Earlier it did not grok the 0{40} SHA1 very well, but what it
needed to do was to find the shortest 0{N} that is not used as a
valid object name to be consistent with the way names of valid
objects are abbreviated. This makes some users simpler.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Earlier it did not grok the 0{40} SHA1 very well, but what it
needed to do was to find the shortest 0{N} that is not used as a
valid object name to be consistent with the way names of valid
objects are abbreviated. This makes some users simpler.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Merge branch 'jc/status'
* jc/status:
git-status -v
* jc/status:
git-status -v
git-status -v
This revamps the git-status command to take the same set of
parameters as git commit. It gives a preview of what is being
committed with that command. With -v flag, it shows the diff
output between the HEAD commit and the index that would be
committed if these flags were given to git-commit command.
git-commit also acquires -v flag (it used to mean "verify" but
that is the default anyway and there is --no-verify to turn it
off, so not much is lost), which uses the updated git-status -v
to seed the commit log buffer. This is handy for writing a log
message while reviewing the changes one last time.
Now, git-commit and git-status are internally share the same
implementation.
Unlike previous git-commit change, this uses a temporary index
to prepare the index file that would become the real index file
after a successful commit, and moves it to the real index file
once the commit is actually made. This makes it safer than the
previous scheme, which stashed away the original index file and
restored it after an aborted commit.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This revamps the git-status command to take the same set of
parameters as git commit. It gives a preview of what is being
committed with that command. With -v flag, it shows the diff
output between the HEAD commit and the index that would be
committed if these flags were given to git-commit command.
git-commit also acquires -v flag (it used to mean "verify" but
that is the default anyway and there is --no-verify to turn it
off, so not much is lost), which uses the updated git-status -v
to seed the commit log buffer. This is handy for writing a log
message while reviewing the changes one last time.
Now, git-commit and git-status are internally share the same
implementation.
Unlike previous git-commit change, this uses a temporary index
to prepare the index file that would become the real index file
after a successful commit, and moves it to the real index file
once the commit is actually made. This makes it safer than the
previous scheme, which stashed away the original index file and
restored it after an aborted commit.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Merge branch 'master'
* master:
Merge branch 'jc/ls-files-o'
count-delta.c: Match the delta data semantics change in version 3.
remove delta-against-self bit
stat() for existence in safe_create_leading_directories()
call git_config() after setup_git_directory()
Add --diff-filter= documentation paragraph
* master:
Merge branch 'jc/ls-files-o'
count-delta.c: Match the delta data semantics change in version 3.
remove delta-against-self bit
stat() for existence in safe_create_leading_directories()
call git_config() after setup_git_directory()
Add --diff-filter= documentation paragraph
Merge branch 'jc/ls-files-o'
* jc/ls-files-o:
ls-files: honour per-directory ignore file from higher directories.
* jc/ls-files-o:
ls-files: honour per-directory ignore file from higher directories.
Merge branch 'lt/diff-tree'
* lt/diff-tree:
combine-diff: move formatting logic to show_combined_diff()
combined-diff: use diffcore before intersecting paths.
diff-tree -c raw output
* lt/diff-tree:
combine-diff: move formatting logic to show_combined_diff()
combined-diff: use diffcore before intersecting paths.
diff-tree -c raw output
count-delta.c: Match the delta data semantics change in version 3.
This matches the count_delta() logic to the change previous
commit introduces to patch_delta().
Signed-off-by: Junio C Hamano <junkio@cox.net>
This matches the count_delta() logic to the change previous
commit introduces to patch_delta().
Signed-off-by: Junio C Hamano <junkio@cox.net>
remove delta-against-self bit
After experimenting with code to add the ability to encode a delta
against part of the deltified file, it turns out that resulting packs
are _bigger_ than when this ability is not used. The raw delta output
might be smaller, but it doesn't compress as well using gzip with a
negative net saving on average.
Said bit would in fact be more useful to allow for encoding the copying
of chunks larger than 64KB providing more savings with large files.
This will correspond to packs version 3.
While the current code still produces packs version 2, it is made future
proof so pack versions 2 and 3 are accepted. Any pack version 2 are
compatible with version 3 since the redefined bit was never used before.
When enough time has passed, code to use that bit to produce version 3
packs could be added.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
After experimenting with code to add the ability to encode a delta
against part of the deltified file, it turns out that resulting packs
are _bigger_ than when this ability is not used. The raw delta output
might be smaller, but it doesn't compress as well using gzip with a
negative net saving on average.
Said bit would in fact be more useful to allow for encoding the copying
of chunks larger than 64KB providing more savings with large files.
This will correspond to packs version 3.
While the current code still produces packs version 2, it is made future
proof so pack versions 2 and 3 are accepted. Any pack version 2 are
compatible with version 3 since the redefined bit was never used before.
When enough time has passed, code to use that bit to produce version 3
packs could be added.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
stat() for existence in safe_create_leading_directories()
Use stat() to explicitly check for existence rather than
relying on the non-portable EEXIST error in sha1_file.c's
safe_create_leading_directories(). There certainly are
optimizations possible, but then the code becomes almost
the same as that in coreutil's lib/mkdir-p.c.
Other uses of EEXIST seem ok. Tested on Solaris 8, AIX 5.2L,
and a few Linux versions. AIX has some unrelated (I think)
failures right now; I haven't tried many recent gits there.
Anyone have an old Ultrix box to break everything? ;)
Also remove extraneous #includes. Everything's already in
git-compat-util.h, included through cache.h.
Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Use stat() to explicitly check for existence rather than
relying on the non-portable EEXIST error in sha1_file.c's
safe_create_leading_directories(). There certainly are
optimizations possible, but then the code becomes almost
the same as that in coreutil's lib/mkdir-p.c.
Other uses of EEXIST seem ok. Tested on Solaris 8, AIX 5.2L,
and a few Linux versions. AIX has some unrelated (I think)
failures right now; I haven't tried many recent gits there.
Anyone have an old Ultrix box to break everything? ;)
Also remove extraneous #includes. Everything's already in
git-compat-util.h, included through cache.h.
Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
combine-diff: move formatting logic to show_combined_diff()
This way, diff-files can make use of it. Also implement the
full suite of what diff_flush_raw() supports just for
consistency. With this, 'diff-tree -c -r --name-status' would
show what is expected.
There is no way to get the historical output (useful for
debugging and low-level Plumbing work) anymore, so tentatively
it makes '-m' to mean "do not combine and show individual diffs
with parents".
diff-files matches diff-tree to produce raw output for -c. For
textual combined diff, use -p -c.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This way, diff-files can make use of it. Also implement the
full suite of what diff_flush_raw() supports just for
consistency. With this, 'diff-tree -c -r --name-status' would
show what is expected.
There is no way to get the historical output (useful for
debugging and low-level Plumbing work) anymore, so tentatively
it makes '-m' to mean "do not combine and show individual diffs
with parents".
diff-files matches diff-tree to produce raw output for -c. For
textual combined diff, use -p -c.
Signed-off-by: Junio C Hamano <junkio@cox.net>
call git_config() after setup_git_directory()
If you call setup_git_directory() to work from a subdirectory,
that should be run first before running git_config(). Otherwise
you would not read the configuration file from the correct place.
Signed-off-by: Junio C Hamano <junkio@cox.net>
If you call setup_git_directory() to work from a subdirectory,
that should be run first before running git_config(). Otherwise
you would not read the configuration file from the correct place.
Signed-off-by: Junio C Hamano <junkio@cox.net>
combined-diff: use diffcore before intersecting paths.
This is needed to make "diff-tree -c -M" to work semi-sensibly.
Otherwise rename detection, pickaxe and friends would never be
invoked.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is needed to make "diff-tree -c -M" to work semi-sensibly.
Otherwise rename detection, pickaxe and friends would never be
invoked.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add --diff-filter= documentation paragraph
Signed-off-by: Jon Loeliger <jdl@jdl.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Jon Loeliger <jdl@jdl.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
diff-tree -c raw output
NOTE! This makes "-c" be the default, which effectively means that merges
are never ignored any more, and "-m" is a no-op. So it changes semantics.
I would also like to make "--cc" the default if you do patches, but didn't
actually do that.
The raw output format is not wonderfully pretty, but it's distinguishable
from a "normal patch" in that a normal patch with just one parent has just
one colon at the beginning, while a multi-parent raw diff has <n> colons
for <n> parents.
So now, in the kernel, when you do
git-diff-tree cce0cac125623f9b68f25dd1350f6d616220a8dd
(to see the manual ARM merge that had a conflict in arch/arm/Kconfig), you
get
cce0cac125623f9b68f25dd1350f6d616220a8dd
::100644 100644 100644 4a63a8e2e45247a11c068c6ed66c6e7aba29ddd9 77eee38762d69d3de95ae45dd9278df9b8225e2c 2f61726d2f4b636f6e66696700dbf71a59dad287 arch/arm/Kconfig
ie you see two colons (two parents), then three modes (parent modes
followed by result mode), then three sha1s (parent sha1s followed by
result sha1).
Which is pretty close to the normal raw diff output.
Cool/stupid exercise:
$ git-whatchanged | grep '^::' | cut -f2- | sort |
uniq -c | sort -n | less -S
will show which files have needed the most file-level merge conflict
resolution. Useful? Probably not. But kind of interesting.
For the kernel, it's
....
10 arch/ia64/Kconfig
11 drivers/scsi/Kconfig
12 drivers/net/Makefile
17 include/linux/libata.h
18 include/linux/pci_ids.h
23 drivers/net/Kconfig
24 drivers/scsi/libata-scsi.c
28 drivers/scsi/libata-core.c
43 MAINTAINERS
Signed-off-by: Junio C Hamano <junkio@cox.net>
NOTE! This makes "-c" be the default, which effectively means that merges
are never ignored any more, and "-m" is a no-op. So it changes semantics.
I would also like to make "--cc" the default if you do patches, but didn't
actually do that.
The raw output format is not wonderfully pretty, but it's distinguishable
from a "normal patch" in that a normal patch with just one parent has just
one colon at the beginning, while a multi-parent raw diff has <n> colons
for <n> parents.
So now, in the kernel, when you do
git-diff-tree cce0cac125623f9b68f25dd1350f6d616220a8dd
(to see the manual ARM merge that had a conflict in arch/arm/Kconfig), you
get
cce0cac125623f9b68f25dd1350f6d616220a8dd
::100644 100644 100644 4a63a8e2e45247a11c068c6ed66c6e7aba29ddd9 77eee38762d69d3de95ae45dd9278df9b8225e2c 2f61726d2f4b636f6e66696700dbf71a59dad287 arch/arm/Kconfig
ie you see two colons (two parents), then three modes (parent modes
followed by result mode), then three sha1s (parent sha1s followed by
result sha1).
Which is pretty close to the normal raw diff output.
Cool/stupid exercise:
$ git-whatchanged | grep '^::' | cut -f2- | sort |
uniq -c | sort -n | less -S
will show which files have needed the most file-level merge conflict
resolution. Useful? Probably not. But kind of interesting.
For the kernel, it's
....
10 arch/ia64/Kconfig
11 drivers/scsi/Kconfig
12 drivers/net/Makefile
17 include/linux/libata.h
18 include/linux/pci_ids.h
23 drivers/net/Kconfig
24 drivers/scsi/libata-scsi.c
28 drivers/scsi/libata-core.c
43 MAINTAINERS
Signed-off-by: Junio C Hamano <junkio@cox.net>
Merge branch 'jc/nostat'
* jc/nostat:
"Assume unchanged" git: --really-refresh fix.
* jc/nostat:
"Assume unchanged" git: --really-refresh fix.
"Assume unchanged" git: --really-refresh fix.
The earlier round failed to make --really-refresh to mark
up-to-date index entry to valid again due to a trivial thinko.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The earlier round failed to make --really-refresh to mark
up-to-date index entry to valid again due to a trivial thinko.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Merge branch 'jc/ls-files-o'
* jc/ls-files-o:
ls-files: honour per-directory ignore file from higher directories.
* jc/ls-files-o:
ls-files: honour per-directory ignore file from higher directories.
ls-files: honour per-directory ignore file from higher directories.
When git-ls-files -o --exclude-per-directory=.gitignore is run
from a subdirectory, it did not read from .gitignore from its
parent directory. Reading from them makes output from these two
commands consistent:
$ git ls-files -o --exclude-per-directory=.gitignore Documentation
$ cd Documentation &&
git ls-files -o --exclude-per-directory=.gitignore
Signed-off-by: Junio C Hamano <junkio@cox.net>
When git-ls-files -o --exclude-per-directory=.gitignore is run
from a subdirectory, it did not read from .gitignore from its
parent directory. Reading from them makes output from these two
commands consistent:
$ git ls-files -o --exclude-per-directory=.gitignore Documentation
$ cd Documentation &&
git ls-files -o --exclude-per-directory=.gitignore
Signed-off-by: Junio C Hamano <junkio@cox.net>
Merge branches 'jc/nostat' and 'jc/empty-commit'
* jc/nostat:
ls-files: debugging aid for CE_VALID changes.
"Assume unchanged" git: do not set CE_VALID with --refresh
"Assume unchanged" git
* jc/empty-commit:
t6000: fix a careless test library add-on.
Do not allow empty name or email.
* jc/nostat:
ls-files: debugging aid for CE_VALID changes.
"Assume unchanged" git: do not set CE_VALID with --refresh
"Assume unchanged" git
* jc/empty-commit:
t6000: fix a careless test library add-on.
Do not allow empty name or email.
t6000: fix a careless test library add-on.
It tried to "restore" GIT_AUTHOR_EMAIL environment variable but
the variable started out as unset, so ended up setting it to an
empty string. This is now caught as an error.
Signed-off-by: Junio C Hamano <junkio@cox.net>
It tried to "restore" GIT_AUTHOR_EMAIL environment variable but
the variable started out as unset, so ended up setting it to an
empty string. This is now caught as an error.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Do not allow empty name or email.
Instead of silently allowing to create a bogus commit that lacks
information by mistake, complain loudly and die.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Instead of silently allowing to create a bogus commit that lacks
information by mistake, complain loudly and die.
Signed-off-by: Junio C Hamano <junkio@cox.net>
ls-files: debugging aid for CE_VALID changes.
This is not really part of the proposed updates for CE_VALID,
but with this change, ls-files -t shows CE_VALID paths with
lowercase tag letters instead of the usual uppercase. Useful
for checking out what is going on.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is not really part of the proposed updates for CE_VALID,
but with this change, ls-files -t shows CE_VALID paths with
lowercase tag letters instead of the usual uppercase. Useful
for checking out what is going on.
Signed-off-by: Junio C Hamano <junkio@cox.net>
"Assume unchanged" git: do not set CE_VALID with --refresh
When working with automatic assume-unchanged mode using
core.ignorestat, setting CE_VALID after --refresh makes things
more cumbersome to use. Consider this scenario:
(1) the working tree is on a filesystem with slow lstat(2).
The user sets core.ignorestat = true.
(2) "git checkout" to switch to a different branch (or initial
checkout) updates all paths and the index starts out with
"all clean".
(3) The user knows she wants to edit certain paths. She uses
update-index --no-assume-unchanged (we could call it --edit;
the name is inmaterial) to mark these paths and starts
editing.
(4) After editing half of the paths marked to be edited, she
runs "git status". This runs "update-index --refresh" to
reduce the false hits from diff-files.
(5) Now the other half of the paths, since she has not changed
them, are found to match the index, and CE_VALID is set on
them again.
For this reason, this commit makes update-index --refresh not to
set CE_VALID even after the path without CE_VALID are verified
to be up to date. The user still can run --really-refresh to
force lstat() to match the index entries to the reality.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When working with automatic assume-unchanged mode using
core.ignorestat, setting CE_VALID after --refresh makes things
more cumbersome to use. Consider this scenario:
(1) the working tree is on a filesystem with slow lstat(2).
The user sets core.ignorestat = true.
(2) "git checkout" to switch to a different branch (or initial
checkout) updates all paths and the index starts out with
"all clean".
(3) The user knows she wants to edit certain paths. She uses
update-index --no-assume-unchanged (we could call it --edit;
the name is inmaterial) to mark these paths and starts
editing.
(4) After editing half of the paths marked to be edited, she
runs "git status". This runs "update-index --refresh" to
reduce the false hits from diff-files.
(5) Now the other half of the paths, since she has not changed
them, are found to match the index, and CE_VALID is set on
them again.
For this reason, this commit makes update-index --refresh not to
set CE_VALID even after the path without CE_VALID are verified
to be up to date. The user still can run --really-refresh to
force lstat() to match the index entries to the reality.
Signed-off-by: Junio C Hamano <junkio@cox.net>
"Assume unchanged" git
This adds "assume unchanged" logic, started by this message in the list
discussion recently:
<Pine.LNX.4.64.0601311807470.7301@g5.osdl.org>
This is a workaround for filesystems that do not have lstat()
that is quick enough for the index mechanism to take advantage
of. On the paths marked as "assumed to be unchanged", the user
needs to explicitly use update-index to register the object name
to be in the next commit.
You can use two new options to update-index to set and reset the
CE_VALID bit:
git-update-index --assume-unchanged path...
git-update-index --no-assume-unchanged path...
These forms manipulate only the CE_VALID bit; it does not change
the object name recorded in the index file. Nor they add a new
entry to the index.
When the configuration variable "core.ignorestat = true" is set,
the index entries are marked with CE_VALID bit automatically
after:
- update-index to explicitly register the current object name to the
index file.
- when update-index --refresh finds the path to be up-to-date.
- when tools like read-tree -u and apply --index update the working
tree file and register the current object name to the index file.
The flag is dropped upon read-tree that does not check out the index
entry. This happens regardless of the core.ignorestat settings.
Index entries marked with CE_VALID bit are assumed to be
unchanged most of the time. However, there are cases that
CE_VALID bit is ignored for the sake of safety and usability:
- while "git-read-tree -m" or git-apply need to make sure
that the paths involved in the merge do not have local
modifications. This sacrifices performance for safety.
- when git-checkout-index -f -q -u -a tries to see if it needs
to checkout the paths. Otherwise you can never check
anything out ;-).
- when git-update-index --really-refresh (a new flag) tries to
see if the index entry is up to date. You can start with
everything marked as CE_VALID and run this once to drop
CE_VALID bit for paths that are modified.
Most notably, "update-index --refresh" honours CE_VALID and does
not actively stat, so after you modified a file in the working
tree, update-index --refresh would not notice until you tell the
index about it with "git-update-index path" or "git-update-index
--no-assume-unchanged path".
This version is not expected to be perfect. I think diff
between index and/or tree and working files may need some
adjustment, and there probably needs other cases we should
automatically unmark paths that are marked to be CE_VALID.
But the basics seem to work, and ready to be tested by people
who asked for this feature.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This adds "assume unchanged" logic, started by this message in the list
discussion recently:
<Pine.LNX.4.64.0601311807470.7301@g5.osdl.org>
This is a workaround for filesystems that do not have lstat()
that is quick enough for the index mechanism to take advantage
of. On the paths marked as "assumed to be unchanged", the user
needs to explicitly use update-index to register the object name
to be in the next commit.
You can use two new options to update-index to set and reset the
CE_VALID bit:
git-update-index --assume-unchanged path...
git-update-index --no-assume-unchanged path...
These forms manipulate only the CE_VALID bit; it does not change
the object name recorded in the index file. Nor they add a new
entry to the index.
When the configuration variable "core.ignorestat = true" is set,
the index entries are marked with CE_VALID bit automatically
after:
- update-index to explicitly register the current object name to the
index file.
- when update-index --refresh finds the path to be up-to-date.
- when tools like read-tree -u and apply --index update the working
tree file and register the current object name to the index file.
The flag is dropped upon read-tree that does not check out the index
entry. This happens regardless of the core.ignorestat settings.
Index entries marked with CE_VALID bit are assumed to be
unchanged most of the time. However, there are cases that
CE_VALID bit is ignored for the sake of safety and usability:
- while "git-read-tree -m" or git-apply need to make sure
that the paths involved in the merge do not have local
modifications. This sacrifices performance for safety.
- when git-checkout-index -f -q -u -a tries to see if it needs
to checkout the paths. Otherwise you can never check
anything out ;-).
- when git-update-index --really-refresh (a new flag) tries to
see if the index entry is up to date. You can start with
everything marked as CE_VALID and run this once to drop
CE_VALID bit for paths that are modified.
Most notably, "update-index --refresh" honours CE_VALID and does
not actively stat, so after you modified a file in the working
tree, update-index --refresh would not notice until you tell the
index about it with "git-update-index path" or "git-update-index
--no-assume-unchanged path".
This version is not expected to be perfect. I think diff
between index and/or tree and working files may need some
adjustment, and there probably needs other cases we should
automatically unmark paths that are marked to be CE_VALID.
But the basics seem to work, and ready to be tested by people
who asked for this feature.
Signed-off-by: Junio C Hamano <junkio@cox.net>
.gitignore git-rerere and config.mak
Signed-off-by: Andreas Ericsson <ae@op5.se>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Andreas Ericsson <ae@op5.se>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Fix "git diff a..b" breakage
The "--cc" implies "-p", but without the recursive part.
Linus
Signed-off-by: Junio C Hamano <junkio@cox.net>
The "--cc" implies "-p", but without the recursive part.
Linus
Signed-off-by: Junio C Hamano <junkio@cox.net>
Basic documentation for git-show
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Document git-diff-tree --always
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
http-fetch: Abort requests for objects which arrived in packs
In fetch_object, there's a call to release an object request if the
object mysteriously arrived, say in a pack. Unfortunately, the fetch
attempt for this object might already be in progress, and we'll leak the
descriptor. Instead, try to tidy away the request.
Signed-off-by: Mark Wooding <mdw@distorted.org.uk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
In fetch_object, there's a call to release an object request if the
object mysteriously arrived, say in a pack. Unfortunately, the fetch
attempt for this object might already be in progress, and we'll leak the
descriptor. Instead, try to tidy away the request.
Signed-off-by: Mark Wooding <mdw@distorted.org.uk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
format-patch: Remove last vestiges of --mbox option
Don't mention it in docs or --help output.
Remove mbox, date and author variables from git-format-patch.sh.
Use DESCRIPTION text from man-page to update LONG_USAGE output. It's
a bit silly to have two texts saying the same thing in different words,
and I'm too lazy to update both.
Signed-off-by: Andreas Ericsson <ae@op5.se>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Don't mention it in docs or --help output.
Remove mbox, date and author variables from git-format-patch.sh.
Use DESCRIPTION text from man-page to update LONG_USAGE output. It's
a bit silly to have two texts saying the same thing in different words,
and I'm too lazy to update both.
Signed-off-by: Andreas Ericsson <ae@op5.se>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Merge git://git.kernel.org/pub/scm/gitk/gitk
* git://git.kernel.org/pub/scm/gitk/gitk:
gitk: Use git-diff-tree --cc for showing the diffs for merges
gitk: Add braces around if expressions
* git://git.kernel.org/pub/scm/gitk/gitk:
gitk: Use git-diff-tree --cc for showing the diffs for merges
gitk: Add braces around if expressions
git-commit: finishing touches.
Introduce --only flag to allow the new "partial commit"
semantics when paths are specified. The default is still the
traditional --include semantics. Once peoples' fingers and
scripts that want the traditional behaviour are updated to
explicitly say --include, we could change it to either default
to --only, or refuse to operate without either --only/--include
when paths are specified.
This also fixes a couple of bugs in the previous round. Namely:
- forgot to save/restore index in some cases.
- forgot to use the temporary index to show status when '--only
paths...' semantics was used.
- --author did not take precedence when reusing an existing
commit.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Introduce --only flag to allow the new "partial commit"
semantics when paths are specified. The default is still the
traditional --include semantics. Once peoples' fingers and
scripts that want the traditional behaviour are updated to
explicitly say --include, we could change it to either default
to --only, or refuse to operate without either --only/--include
when paths are specified.
This also fixes a couple of bugs in the previous round. Namely:
- forgot to save/restore index in some cases.
- forgot to use the temporary index to show status when '--only
paths...' semantics was used.
- --author did not take precedence when reusing an existing
commit.
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-commit: revamp the git-commit semantics.
- "git commit" without _any_ parameter keeps the traditional
behaviour. It commits the current index.
We commit the whole index even when this form is run from a
subdirectory.
- "git commit --include paths..." (or "git commit -i paths...")
is equivalent to:
git update-index --remove paths...
git commit
- "git commit paths..." acquires a new semantics. This is an
incompatible change that needs user training, which I am
still a bit reluctant to swallow, but enough people seem to
have complained that it is confusing to them. It
1. refuses to run if $GIT_DIR/MERGE_HEAD exists, and reminds
trained git users that the traditional semantics now needs
-i flag.
2. refuses to run if named paths... are different in HEAD and
the index (ditto about reminding). Added paths are OK.
3. reads HEAD commit into a temporary index file.
4. updates named paths... from the working tree in this
temporary index.
5. does the same updates of the paths... from the working
tree to the real index.
6. makes a commit using the temporary index that has the
current HEAD as the parent, and updates the HEAD with this
new commit.
- "git commit --all" can run from a subdirectory, but it updates
the index with all the modified files and does a whole tree
commit.
- In all cases, when the command decides not to create a new
commit, the index is left as it was before the command is
run. This means that the two "git diff" in the following
sequence:
$ git diff
$ git commit -a
$ git diff
would show the same diff if you abort the commit process by
making the commit log message empty.
This commit also introduces much requested --author option.
$ git commit --author 'A U Thor <author@example.com>'
Signed-off-by: Junio C Hamano <junkio@cox.net>
- "git commit" without _any_ parameter keeps the traditional
behaviour. It commits the current index.
We commit the whole index even when this form is run from a
subdirectory.
- "git commit --include paths..." (or "git commit -i paths...")
is equivalent to:
git update-index --remove paths...
git commit
- "git commit paths..." acquires a new semantics. This is an
incompatible change that needs user training, which I am
still a bit reluctant to swallow, but enough people seem to
have complained that it is confusing to them. It
1. refuses to run if $GIT_DIR/MERGE_HEAD exists, and reminds
trained git users that the traditional semantics now needs
-i flag.
2. refuses to run if named paths... are different in HEAD and
the index (ditto about reminding). Added paths are OK.
3. reads HEAD commit into a temporary index file.
4. updates named paths... from the working tree in this
temporary index.
5. does the same updates of the paths... from the working
tree to the real index.
6. makes a commit using the temporary index that has the
current HEAD as the parent, and updates the HEAD with this
new commit.
- "git commit --all" can run from a subdirectory, but it updates
the index with all the modified files and does a whole tree
commit.
- In all cases, when the command decides not to create a new
commit, the index is left as it was before the command is
run. This means that the two "git diff" in the following
sequence:
$ git diff
$ git commit -a
$ git diff
would show the same diff if you abort the commit process by
making the commit log message empty.
This commit also introduces much requested --author option.
$ git commit --author 'A U Thor <author@example.com>'
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-rerere: reuse recorded resolve.
In a workflow that employs relatively long lived topic branches,
the developer sometimes needs to resolve the same conflict over
and over again until the topic branches are done (either merged
to the "release" branch, or sent out and accepted upstream).
This commit introduces a new command, "git rerere", to help this
process by recording the conflicted automerge results and
corresponding hand-resolve results on the initial manual merge,
and later by noticing the same conflicted automerge and applying
the previously recorded hand resolution using three-way merge.
Signed-off-by: Junio C Hamano <junkio@cox.net>
In a workflow that employs relatively long lived topic branches,
the developer sometimes needs to resolve the same conflict over
and over again until the topic branches are done (either merged
to the "release" branch, or sent out and accepted upstream).
This commit introduces a new command, "git rerere", to help this
process by recording the conflicted automerge results and
corresponding hand-resolve results on the initial manual merge,
and later by noticing the same conflicted automerge and applying
the previously recorded hand resolution using three-way merge.
Signed-off-by: Junio C Hamano <junkio@cox.net>
fmt-merge-msg: show summary of what is merged.
In addition to the branch names, populate the log message with
one-line description from actual commits that are being merged.
This was prompted by Len's 12-way octopus. You need to have
'merge.summary' in the configuration file to enable it:
$ git repo-config merge.summary yes
Signed-off-by: Junio C Hamano <junkio@cox.net>
In addition to the branch names, populate the log message with
one-line description from actual commits that are being merged.
This was prompted by Len's 12-way octopus. You need to have
'merge.summary' in the configuration file to enable it:
$ git repo-config merge.summary yes
Signed-off-by: Junio C Hamano <junkio@cox.net>
read-tree --aggressive
A new flag --aggressive resolves what we traditionally resolved
with external git-merge-one-file inside index while read-tree
3-way merge works.
git-merge-octopus and git-merge-resolve use this flag before
running git-merge-index with git-merge-one-file.
Signed-off-by: Junio C Hamano <junkio@cox.net>
A new flag --aggressive resolves what we traditionally resolved
with external git-merge-one-file inside index while read-tree
3-way merge works.
git-merge-octopus and git-merge-resolve use this flag before
running git-merge-index with git-merge-one-file.
Signed-off-by: Junio C Hamano <junkio@cox.net>
[PATCH] mailinfo: reset CTE after each multipart
If the first part uses quoted-printable to protect iso8859-1
name in the commit log, and the second part was plain ascii text
patchfile without even Content-Transfer-Encoding subheader, we
incorrectly tried to decode the patch as quoted printable.
Signed-off-by: Junio C Hamano <junkio@cox.net>
If the first part uses quoted-printable to protect iso8859-1
name in the commit log, and the second part was plain ascii text
patchfile without even Content-Transfer-Encoding subheader, we
incorrectly tried to decode the patch as quoted printable.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Docs: minor git-push copyediting
Minor git-push copyediting
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Minor git-push copyediting
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Docs: move git url and remotes text to separate sections
The sections on git urls and remotes files in the git-fetch,
git-pull, and git-push manpages seem long enough to be worth a
manpage section of their own.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The sections on git urls and remotes files in the git-fetch,
git-pull, and git-push manpages seem long enough to be worth a
manpage section of their own.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Docs: split up pull-fetch-param.txt
The push and pull man pages include a bunch of shared text from
pull-fetch-param.txt. This simplifies maintenance somewhat, but
there's actually quite a bit of text that applies only to one or the
other.
So, separate out the push- and pull/fetch-specific text into
pull-fetch-param.txt and git-push.txt, then include the largest chunk
of common stuff (the description of protocols and url's) from
urls.txt. That cuts some irrelevant stuff from the man pages without
making us duplicate too much.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The push and pull man pages include a bunch of shared text from
pull-fetch-param.txt. This simplifies maintenance somewhat, but
there's actually quite a bit of text that applies only to one or the
other.
So, separate out the push- and pull/fetch-specific text into
pull-fetch-param.txt and git-push.txt, then include the largest chunk
of common stuff (the description of protocols and url's) from
urls.txt. That cuts some irrelevant stuff from the man pages without
making us duplicate too much.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
combine-diff: do not punt on removed or added files.
When we remove a file, the parents' contents are all removed so
it is not that interesting to show all of them, but the fact it
was removed when all parents had it *is* unusual. When we add a
file, similarly the fact it was added when no parent wanted it
*is* unusual, and in addition the result matters, so show it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When we remove a file, the parents' contents are all removed so
it is not that interesting to show all of them, but the fact it
was removed when all parents had it *is* unusual. When we add a
file, similarly the fact it was added when no parent wanted it
*is* unusual, and in addition the result matters, so show it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
gitk: Use git-diff-tree --cc for showing the diffs for merges
This replaces a lot of code that used the result from several 2-way
diffs to generate a combined diff for a merge. Now we just use
git-diff-tree --cc and colorize the output a bit, which is a lot
simpler, and has the enormous advantage that if the diff doesn't
show quite what someone thinks it should show, I can deflect the
blame to someone else. :)
Signed-off-by: Paul Mackerras <paulus@samba.org>
This replaces a lot of code that used the result from several 2-way
diffs to generate a combined diff for a merge. Now we just use
git-diff-tree --cc and colorize the output a bit, which is a lot
simpler, and has the enormous advantage that if the diff doesn't
show quite what someone thinks it should show, I can deflect the
blame to someone else. :)
Signed-off-by: Paul Mackerras <paulus@samba.org>
gitk: Add braces around if expressions
Apparently this simplifies things for the parser/compiler and makes
it go slightly faster (since without the braces, it potentially has
to do two levels of substitutions rather than one).
Signed-off-by: Paul Mackerras <paulus@samba.org>
Apparently this simplifies things for the parser/compiler and makes
it go slightly faster (since without the braces, it potentially has
to do two levels of substitutions rather than one).
Signed-off-by: Paul Mackerras <paulus@samba.org>
combine-diff: show mode changes as well.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
combine-diff: do not send NULL to printf
When we run combined diff from working tree (diff-files --cc),
we sent NULL to printf that is returned by find_unique_abbrev().
Signed-off-by: Junio C Hamano <junkio@cox.net>
When we run combined diff from working tree (diff-files --cc),
we sent NULL to printf that is returned by find_unique_abbrev().
Signed-off-by: Junio C Hamano <junkio@cox.net>
core-tutorial: adjust to recent reality.
We still talked about HEAD symlinks but these days we use
symrefs by default.
Also 'failed/prevented' message is now gone from the merge
output.
Signed-off-by: Junio C Hamano <junkio@cox.net>
We still talked about HEAD symlinks but these days we use
symrefs by default.
Also 'failed/prevented' message is now gone from the merge
output.
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-diff: do not fall back on --cc when -[123], --ours etc. are given.
These flags ask diff with a specific unmerged stage, so it
should fall back on -p instead. Also when -c is given, we
should not do --cc.
Signed-off-by: Junio C Hamano <junkio@cox.net>
These flags ask diff with a specific unmerged stage, so it
should fall back on -p instead. Also when -c is given, we
should not do --cc.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Merge branch 'jc/diff'
* jc/diff:
git-diff-tree --stdin: show all parents.
combine-diff: remove misguided --show-empty hack.
* jc/diff:
git-diff-tree --stdin: show all parents.
combine-diff: remove misguided --show-empty hack.
Merge branches 'lt/show' and 'lt/revlist'
* lt/show:
git-show
* lt/revlist:
rev-parse lstat() workaround cleanup.
* lt/show:
git-show
* lt/revlist:
rev-parse lstat() workaround cleanup.
Merge branches 'jc/daemon' and 'mw/http'
* jc/daemon:
daemon: extend user-relative path notation.
daemon: Set SO_REUSEADDR on listening sockets.
daemon: do not forbid user relative paths unconditionally under --base-path
* mw/http:
http-fetch: Tidy control flow in process_alternate_response
http: Turn on verbose Curl messages if GIT_CURL_VERBOSE set in environment
http-fetch: Fix message reporting rename of object file.
http-fetch: Fix object list corruption in fill_active_slots().
* jc/daemon:
daemon: extend user-relative path notation.
daemon: Set SO_REUSEADDR on listening sockets.
daemon: do not forbid user relative paths unconditionally under --base-path
* mw/http:
http-fetch: Tidy control flow in process_alternate_response
http: Turn on verbose Curl messages if GIT_CURL_VERBOSE set in environment
http-fetch: Fix message reporting rename of object file.
http-fetch: Fix object list corruption in fill_active_slots().