bisect: use "$GIT_DIR/BISECT_START" to check if we are bisecting
It seems simpler and safer to use the BISECT_START file everywhere
to decide if we are bisecting or not, instead of using it in some
places and BISECT_NAMES in other places.
In commit 6459c7c6786aa9bda0c7a095c9db66c36da0e5f0 (Nov 18 2007,
Bisect: use "$GIT_DIR/BISECT_NAMES" to check if we are bisecting.),
we decided to use BISECT_NAMES but code changed a lot and we now
have to check BISECT_START first in the "bisect_start" function
anyway.
This patch also makes things a little bit safer by creating
the BISECT_START file first and deleting it last, and also by
adding checks in "bisect_clean_state".
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It seems simpler and safer to use the BISECT_START file everywhere
to decide if we are bisecting or not, instead of using it in some
places and BISECT_NAMES in other places.
In commit 6459c7c6786aa9bda0c7a095c9db66c36da0e5f0 (Nov 18 2007,
Bisect: use "$GIT_DIR/BISECT_NAMES" to check if we are bisecting.),
we decided to use BISECT_NAMES but code changed a lot and we now
have to check BISECT_START first in the "bisect_start" function
anyway.
This patch also makes things a little bit safer by creating
the BISECT_START file first and deleting it last, and also by
adding checks in "bisect_clean_state".
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin-fetch.c (store_updated_refs): Honor update_local_ref() return value
Sync with builtin-fetch--tool.c where append_fetch_head()
honors update_local_ref() return value.
This fixes non fast forward fetch exit status,
http://bugzilla.altlinux.org/show_bug.cgi?id=15037
Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Sync with builtin-fetch--tool.c where append_fetch_head()
honors update_local_ref() return value.
This fixes non fast forward fetch exit status,
http://bugzilla.altlinux.org/show_bug.cgi?id=15037
Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
fix sha1_pack_index_name()
An earlier commit 633f43e (Remove redundant code, eliminate one static
variable, 2008-05-24) had a thinko (perhaps an eyeno) that broke
sha1_pack_index_name() function. One symptom of this was that the http
walker is now completely broken.
This should fix it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
An earlier commit 633f43e (Remove redundant code, eliminate one static
variable, 2008-05-24) had a thinko (perhaps an eyeno) that broke
sha1_pack_index_name() function. One symptom of this was that the http
walker is now completely broken.
This should fix it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Git::cat_blob: allow using an empty blob to fix git-svn breakage
Recent "git-svn optimization" series introduced Git::cat_blob() subroutine
whose interface was broken in that it returned the size of the blob but
signalled an error by returning 0. You can never use an empty blob with
such an interface.
This fixes the interface to return a negative value to signal an error.
Reported by Björn Steinbrink.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Recent "git-svn optimization" series introduced Git::cat_blob() subroutine
whose interface was broken in that it returned the size of the blob but
signalled an error by returning 0. You can never use an empty blob with
such an interface.
This fixes the interface to return a negative value to signal an error.
Reported by Björn Steinbrink.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t5100: Avoid filename "nul"
There are broken filesystems that cannot have a file whose name is "nul"
anywhere on it. Rename the test file to make ourselves more portable.
Noticed by Mark Levedahl.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There are broken filesystems that cannot have a file whose name is "nul"
anywhere on it. Rename the test file to make ourselves more portable.
Noticed by Mark Levedahl.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge 1.5.5.3 in
GIT 1.5.5.3
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit --interactive: properly update the index before commiting
When adding files through git commit --interactive, and 'quit'
afterwards, the message in the editor of the commit message indicates
that many (maybe all) files are deleted from the tree. Dismissing that
and running git commit afterwards does the right thing. This commit
fixes git commit --interactive to properly update the index before
commiting.
Reported by Jiří Paleček through
http://bugs.debian.org/480429
Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When adding files through git commit --interactive, and 'quit'
afterwards, the message in the editor of the commit message indicates
that many (maybe all) files are deleted from the tree. Dismissing that
and running git commit afterwards does the right thing. This commit
fixes git commit --interactive to properly update the index before
commiting.
Reported by Jiří Paleček through
http://bugs.debian.org/480429
Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
gitweb: only display "next" links in logs if there is a next page
There was a bug in the implementation of the "next" links in
format_paging_nav (for log and shortlog), which caused the next links
to always be displayed, even if there is no next page. This fixes it.
Signed-off-by: Lea Wiemann <LeWiemann@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There was a bug in the implementation of the "next" links in
format_paging_nav (for log and shortlog), which caused the next links
to always be displayed, even if there is no next page. This fixes it.
Signed-off-by: Lea Wiemann <LeWiemann@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Revert "filter-branch: subdirectory filter needs --full-history"
This reverts commit cfabd6eee1745cfec58cfcb794ce8847e43b888a. I had
implemented it without understanding what --full-history does. Consider
this history:
C--M--N
/ / /
A--B /
\ /
D-/
where B and C modify a path, X, in the same way so that the result is
identical, and D does not modify it at all. With the path limiter X and
without --full-history this is simplified to
A--B
i.e. only one of the paths via B or C is chosen. I had assumed that
--full-history would keep both paths like this
C--M
/ /
A--B
removing the path via D; but in fact it keeps the entire history.
Currently, git does not have the capability to simplify to this
intermediary case. However, the other extreme to keep the entire history
is not wanted either in usual cases. I think we can expect that histories
like the above are rare, and in the usual cases we want a simplified
history. So let's remove --full-history again.
(Concerning t7003, subsequent tests depend on what the test case sets up,
so we can't just back out the entire test case.)
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This reverts commit cfabd6eee1745cfec58cfcb794ce8847e43b888a. I had
implemented it without understanding what --full-history does. Consider
this history:
C--M--N
/ / /
A--B /
\ /
D-/
where B and C modify a path, X, in the same way so that the result is
identical, and D does not modify it at all. With the path limiter X and
without --full-history this is simplified to
A--B
i.e. only one of the paths via B or C is chosen. I had assumed that
--full-history would keep both paths like this
C--M
/ /
A--B
removing the path via D; but in fact it keeps the entire history.
Currently, git does not have the capability to simplify to this
intermediary case. However, the other extreme to keep the entire history
is not wanted either in usual cases. I think we can expect that histories
like the above are rare, and in the usual cases we want a simplified
history. So let's remove --full-history again.
(Concerning t7003, subsequent tests depend on what the test case sets up,
so we can't just back out the entire test case.)
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Documentation/git-bundle.txt: fix synopsis
The <git-rev-list args> are mandatory to git bundle create, not
optional. The usage output of git bundle is already right on this.
Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The <git-rev-list args> are mandatory to git bundle create, not
optional. The usage output of git bundle is already right on this.
Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
clone: make sure we support the transport type
If we use an unsupported transport (e.g., http when curl
support is not compiled in), transport_get reports an error
to the user, but we still get a transport object. We need to
manually check and abort the clone process at that point, or
we end up with a segfault.
Noticed by Thomas Rast.
Signed-off-by: Jeff King <peff@peff.net>
Acked-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If we use an unsupported transport (e.g., http when curl
support is not compiled in), transport_get reports an error
to the user, but we still get a transport object. We need to
manually check and abort the clone process at that point, or
we end up with a segfault.
Noticed by Thomas Rast.
Signed-off-by: Jeff King <peff@peff.net>
Acked-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t5700-clone-reference: Quote $U
The new "trash directory" bites again.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The new "trash directory" bites again.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add some tests for git update-ref -d
Signed-off-by: Karl Hasselström <kha@treskal.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Karl Hasselström <kha@treskal.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'jc/diff-no-no-index'
* jc/diff-no-no-index:
git diff --no-index: default to page like other diff frontends
git-diff: allow --no-index semantics a bit more
"git diff": do not ignore index without --no-index
diff-files: do not play --no-index games
tests: do not use implicit "git diff --no-index"
* jc/diff-no-no-index:
git diff --no-index: default to page like other diff frontends
git-diff: allow --no-index semantics a bit more
"git diff": do not ignore index without --no-index
diff-files: do not play --no-index games
tests: do not use implicit "git diff --no-index"
git diff --no-index: default to page like other diff frontends
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-diff: allow --no-index semantics a bit more
Even when inside a git work tree, if two paths are given and at least one
is clearly outside the work tree, it cannot be a request to diff a tracked
path anyway; allow such an invocation to use --no-index semantics.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Even when inside a git work tree, if two paths are given and at least one
is clearly outside the work tree, it cannot be a request to diff a tracked
path anyway; allow such an invocation to use --no-index semantics.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'maint'
* maint:
Documentation: fix graph in git-rev-parse.txt
show-branch --current: do not barf on detached HEAD
* maint:
Documentation: fix graph in git-rev-parse.txt
show-branch --current: do not barf on detached HEAD
Merge branch 'gp/bisect-fix' into maint
* gp/bisect-fix:
bisect: print an error message when "git rev-list --bisect-vars" fails
git-bisect.sh: don't accidentally override existing branch "bisect"
* gp/bisect-fix:
bisect: print an error message when "git rev-list --bisect-vars" fails
git-bisect.sh: don't accidentally override existing branch "bisect"
Merge git://repo.or.cz/git-gui
* git://repo.or.cz/git-gui:
git-gui: Vertically align textboxes with labels
git-gui: Handle workdir detection when CYGWIN=nowinsymlinks
git-gui: Add a --trace command line option
* git://repo.or.cz/git-gui:
git-gui: Vertically align textboxes with labels
git-gui: Handle workdir detection when CYGWIN=nowinsymlinks
git-gui: Add a --trace command line option
Documentation: fix graph in git-rev-parse.txt
Preformatted html and man pages show a mangled graph, caused by a
backslash.
Commit f1ec6b22a8c1ab1cca0f1875f85aea5d2434e5a6 fixed this same issue,
but it seems that new versions of the Asciidoc toolchain changed their
behaviour.
Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Preformatted html and man pages show a mangled graph, caused by a
backslash.
Commit f1ec6b22a8c1ab1cca0f1875f85aea5d2434e5a6 fixed this same issue,
but it seems that new versions of the Asciidoc toolchain changed their
behaviour.
Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-gui: Vertically align textboxes with labels
In git-gui after clicking either on 'Create New Repository' or
'Open Existing Repository' the form elements aren't centered like
they are pretty much everywhere else in the app. At least when ran
on a mac, haven't checked on other platforms.
Using grid instead of pack seems to fix this.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
In git-gui after clicking either on 'Create New Repository' or
'Open Existing Repository' the form elements aren't centered like
they are pretty much everywhere else in the app. At least when ran
on a mac, haven't checked on other platforms.
Using grid instead of pack seems to fix this.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
show-branch --current: do not barf on detached HEAD
The code assumed that there always is the current branch, but the result
from resolve_ref() on detached HEAD does not even start with "refs/heads/".
Originally noticed and fixed by Stephan Beyer.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The code assumed that there always is the current branch, but the result
from resolve_ref() on detached HEAD does not even start with "refs/heads/".
Originally noticed and fixed by Stephan Beyer.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Makefile: fix dependency on wt-status.h
Noticed by Hannes, reported by Dscho.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Noticed by Hannes, reported by Dscho.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
hg-to-git: add --verbose option
This patch adds an option to make hg-to-git quiet by default. Note:
it only suppresses those messages that would be printed when everything
was up-to-date.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Acked-by: Stelian Pop <stelian@popies.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch adds an option to make hg-to-git quiet by default. Note:
it only suppresses those messages that would be printed when everything
was up-to-date.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Acked-by: Stelian Pop <stelian@popies.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Documentation/git.txt: link to 1.5.5.2 documentation.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'maint'
* maint:
builtin-fast-export: Only output a single parent per line
Release Notes for 1.5.5.2
Conflicts:
RelNotes
* maint:
builtin-fast-export: Only output a single parent per line
Release Notes for 1.5.5.2
Conflicts:
RelNotes
Merge branch 'jk/maint-send-email-compose' into maint
* jk/maint-send-email-compose:
send-email: rfc2047-quote subject lines with non-ascii characters
send-email: specify content-type of --compose body
* jk/maint-send-email-compose:
send-email: rfc2047-quote subject lines with non-ascii characters
send-email: specify content-type of --compose body
Merge branch 'hb/maint-send-email-quote-recipients' into maint
* hb/maint-send-email-quote-recipients:
Fix recipient santitization
* hb/maint-send-email-quote-recipients:
Fix recipient santitization
Merge branch 'maint-1.5.4' into maint
* maint-1.5.4:
builtin-fast-export: Only output a single parent per line
* maint-1.5.4:
builtin-fast-export: Only output a single parent per line
builtin-fast-export: Only output a single parent per line
According to the git-fast-import man-page, you can only put a single
committish per merge: line, like this:
merge :10
merge :11
However, git-fast-export puts all parents on a single line, like this:
merge :10 :11
This changes fast-export to output a single parent per line. Otherwise
neither git-fast-import nor bzr-fast-import can read its output.
[jc: fix-up to remove excess LF in the output that makes fast-import barf]
Signed-off-by: Pieter de Bie <pdebie@ai.rug.nl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
According to the git-fast-import man-page, you can only put a single
committish per merge: line, like this:
merge :10
merge :11
However, git-fast-export puts all parents on a single line, like this:
merge :10 :11
This changes fast-export to output a single parent per line. Otherwise
neither git-fast-import nor bzr-fast-import can read its output.
[jc: fix-up to remove excess LF in the output that makes fast-import barf]
Signed-off-by: Pieter de Bie <pdebie@ai.rug.nl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Release Notes for 1.5.5.2
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Ignore no-op changes in paranoid update hook
If the hook gets invoked with identical old and new ids there
is no change taking place. We probably should not have been
called, but instead of failing silently allow the no-op.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If the hook gets invoked with identical old and new ids there
is no change taking place. We probably should not have been
called, but instead of failing silently allow the no-op.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Don't load missing ACL files in paranoid update hook
If a user or group ACL file does not exist in the current tip
revision of the acl repository we will get an error from cat-file
when we ask for that blob as it cannot be resolved. A quick look
at the history by rev-list can tell us if there is a path there
or not.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If a user or group ACL file does not exist in the current tip
revision of the acl repository we will get an error from cat-file
when we ask for that blob as it cannot be resolved. A quick look
at the history by rev-list can tell us if there is a path there
or not.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Don't diff empty tree on branch creation in paranoid update hook
Listing all files in a branch during branch creation is silly;
the user's file-level ACLs probably don't mean anything at this
point. We now treat the base case of 0{40} as an empty diff,
as this happens only when the user is creating the branch and
there are file level ACLs that diff against the old value of
the branch.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Listing all files in a branch during branch creation is silly;
the user's file-level ACLs probably don't mean anything at this
point. We now treat the base case of 0{40} as an empty diff,
as this happens only when the user is creating the branch and
there are file level ACLs that diff against the old value of
the branch.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
log --pretty: do not accept bogus "--prettyshort"
... nor bogus "format.pretty = '=short'". Both are syntax errors.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
... nor bogus "format.pretty = '=short'". Both are syntax errors.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
log --graph: do not accept log --graphbogus
An obvious fix to the argument parser.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
An obvious fix to the argument parser.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Update draft release notes for 1.5.6
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'js/config-cb'
* js/config-cb:
Provide git_config with a callback-data parameter
Conflicts:
builtin-add.c
builtin-cat-file.c
* js/config-cb:
Provide git_config with a callback-data parameter
Conflicts:
builtin-add.c
builtin-cat-file.c
Merge branch 'as/graph'
* as/graph:
get_revision(): honor the topo_order flag for boundary commits
Fix output of "git log --graph --boundary"
log --graph --left-right: show left/right information in place of '*'
graph API: don't print branch lines for uninteresting merge parents
graph API: fix graph mis-alignment after uninteresting commits
* as/graph:
get_revision(): honor the topo_order flag for boundary commits
Fix output of "git log --graph --boundary"
log --graph --left-right: show left/right information in place of '*'
graph API: don't print branch lines for uninteresting merge parents
graph API: fix graph mis-alignment after uninteresting commits
Merge branch 'js/mailinfo'
* js/mailinfo:
mailsplit: minor clean-up in read_line_with_nul()
mailinfo: apply the same fix not to lose NULs in BASE64 and QP codepaths
mailsplit and mailinfo: gracefully handle NUL characters
* js/mailinfo:
mailsplit: minor clean-up in read_line_with_nul()
mailinfo: apply the same fix not to lose NULs in BASE64 and QP codepaths
mailsplit and mailinfo: gracefully handle NUL characters
Merge branch 'jc/add-n-u'
* jc/add-n-u:
Make git add -n and git -u -n output consistent
"git-add -n -u" should not add but just report
Conflicts:
builtin-add.c
builtin-mv.c
cache.h
read-cache.c
* jc/add-n-u:
Make git add -n and git -u -n output consistent
"git-add -n -u" should not add but just report
Conflicts:
builtin-add.c
builtin-mv.c
cache.h
read-cache.c
Merge branch 'ar/t6031'
* ar/t6031:
Fix t6031 on filesystems without working exec bit
* ar/t6031:
Fix t6031 on filesystems without working exec bit
Merge branch 'db/clone-in-c'
* db/clone-in-c:
Add test for cloning with "--reference" repo being a subset of source repo
Add a test for another combination of --reference
Test that --reference actually suppresses fetching referenced objects
clone: fall back to copying if hardlinking fails
builtin-clone.c: Need to closedir() in copy_or_link_directory()
builtin-clone: fix initial checkout
Build in clone
Provide API access to init_db()
Add a function to set a non-default work tree
Allow for having for_each_ref() list extra refs
Have a constant extern refspec for "--tags"
Add a library function to add an alternate to the alternates file
Add a lockfile function to append to a file
Mark the list of refs to fetch as const
Conflicts:
cache.h
t/t5700-clone-reference.sh
* db/clone-in-c:
Add test for cloning with "--reference" repo being a subset of source repo
Add a test for another combination of --reference
Test that --reference actually suppresses fetching referenced objects
clone: fall back to copying if hardlinking fails
builtin-clone.c: Need to closedir() in copy_or_link_directory()
builtin-clone: fix initial checkout
Build in clone
Provide API access to init_db()
Add a function to set a non-default work tree
Allow for having for_each_ref() list extra refs
Have a constant extern refspec for "--tags"
Add a library function to add an alternate to the alternates file
Add a lockfile function to append to a file
Mark the list of refs to fetch as const
Conflicts:
cache.h
t/t5700-clone-reference.sh
Merge branch 'jc/apply-whitespace'
* jc/apply-whitespace:
builtin-apply: do not declare patch is creation when we do not know it
builtin-apply: accept patch to an empty file
builtin-apply: typofix
* jc/apply-whitespace:
builtin-apply: do not declare patch is creation when we do not know it
builtin-apply: accept patch to an empty file
builtin-apply: typofix
Merge branch 'jc/unpack-trees-reword'
* jc/unpack-trees-reword:
unpack-trees: allow Porcelain to give different error messages
* jc/unpack-trees-reword:
unpack-trees: allow Porcelain to give different error messages
Merge branch 'ar/batch-cat'
* ar/batch-cat:
change quoting in test t1006-cat-file.sh
builtin-cat-file.c: use parse_options()
git-svn: Speed up fetch
Git.pm: Add hash_and_insert_object and cat_blob
Git.pm: Add command_bidi_pipe and command_close_bidi_pipe
git-hash-object: Add --stdin-paths option
Add more tests for git hash-object
Move git-hash-object tests from t5303 to t1007
git-cat-file: Add --batch option
git-cat-file: Add --batch-check option
git-cat-file: Make option parsing a little more flexible
git-cat-file: Small refactor of cmd_cat_file
Add tests for git cat-file
* ar/batch-cat:
change quoting in test t1006-cat-file.sh
builtin-cat-file.c: use parse_options()
git-svn: Speed up fetch
Git.pm: Add hash_and_insert_object and cat_blob
Git.pm: Add command_bidi_pipe and command_close_bidi_pipe
git-hash-object: Add --stdin-paths option
Add more tests for git hash-object
Move git-hash-object tests from t5303 to t1007
git-cat-file: Add --batch option
git-cat-file: Add --batch-check option
git-cat-file: Make option parsing a little more flexible
git-cat-file: Small refactor of cmd_cat_file
Add tests for git cat-file
Merge branch 'cc/bisect'
* cc/bisect:
bisect: use a detached HEAD to bisect
bisect: trap critical errors in "bisect_start"
bisect: fix left over "BISECT_START" file when starting with junk rev
bisect: add test cases to check that "git bisect start" is atomic
* cc/bisect:
bisect: use a detached HEAD to bisect
bisect: trap critical errors in "bisect_start"
bisect: fix left over "BISECT_START" file when starting with junk rev
bisect: add test cases to check that "git bisect start" is atomic
Merge branch 'ap/svn'
* ap/svn:
git-svn: add test for --add-author-from and --use-log-author
git-svn: add documentation for --add-author-from option.
git-svn: Add --add-author-from option.
git-svn: add documentation for --use-log-author option.
* ap/svn:
git-svn: add test for --add-author-from and --use-log-author
git-svn: add documentation for --add-author-from option.
git-svn: Add --add-author-from option.
git-svn: add documentation for --use-log-author option.
Merge branch 'js/cvsexportcommit'
* js/cvsexportcommit:
cvsexportcommit: introduce -W for shared working trees (between Git and CVS)
cvsexportcommit: chomp only removes trailing whitespace
Conflicts:
git-cvsexportcommit.perl
* js/cvsexportcommit:
cvsexportcommit: introduce -W for shared working trees (between Git and CVS)
cvsexportcommit: chomp only removes trailing whitespace
Conflicts:
git-cvsexportcommit.perl
Merge branch 'js/ignore-submodule'
* js/ignore-submodule:
Ignore dirty submodule states during rebase and stash
Teach update-index about --ignore-submodules
diff options: Introduce --ignore-submodules
* js/ignore-submodule:
Ignore dirty submodule states during rebase and stash
Teach update-index about --ignore-submodules
diff options: Introduce --ignore-submodules
Merge branch 'mo/cvsserver'
* mo/cvsserver:
Documentation: Fix skipped section level
git-cvsserver: add ability to guess -kb from contents
implement gitcvs.usecrlfattr
git-cvsserver: add mechanism for managing working tree and current directory
* mo/cvsserver:
Documentation: Fix skipped section level
git-cvsserver: add ability to guess -kb from contents
implement gitcvs.usecrlfattr
git-cvsserver: add mechanism for managing working tree and current directory
mailsplit: minor clean-up in read_line_with_nul()
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
mailinfo: apply the same fix not to lose NULs in BASE64 and QP codepaths
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
mailsplit and mailinfo: gracefully handle NUL characters
The function fgets() has a big problem with NUL characters: it reads
them, but nobody will know if the NUL comes from the file stream, or
was appended at the end of the line.
So implement a custom read_line_with_nul() function.
Noticed by Tommy Thorn.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The function fgets() has a big problem with NUL characters: it reads
them, but nobody will know if the NUL comes from the file stream, or
was appended at the end of the line.
So implement a custom read_line_with_nul() function.
Noticed by Tommy Thorn.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
http-push: remove remote locks on exit signals
If locks are not cleaned up the repository is inaccessible for 10 minutes.
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If locks are not cleaned up the repository is inaccessible for 10 minutes.
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Reset the signal being handled
This did not cause any problems, because remove_lock_file_on_signal is
only registered for SIGINT.
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This did not cause any problems, because remove_lock_file_on_signal is
only registered for SIGINT.
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Make git-cvsimport remove ['s from tags, as bad_ref_char doesn't allow them.
Signed-off-by: Paul Oliver <puzza007@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Paul Oliver <puzza007@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
get_revision(): honor the topo_order flag for boundary commits
Now get_revision() sorts the boundary commits when topo_order is set.
Since sort_in_topological_order() takes a struct commit_list, it first
places the boundary commits into revs->commits.
Signed-off-by: Adam Simpkins <adam@adamsimpkins.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Now get_revision() sorts the boundary commits when topo_order is set.
Since sort_in_topological_order() takes a struct commit_list, it first
places the boundary commits into revs->commits.
Signed-off-by: Adam Simpkins <adam@adamsimpkins.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Fix output of "git log --graph --boundary"
Previously the graphing API wasn't aware of the revs->boundary flag, and
it always assumed that commits marked UNINTERESTING would not be
displayed. As a result, the boundary commits were printed at the end of
the log output, but they didn't have any branch lines connecting them to
their children in the graph.
There was also another bug in the get_revision() code that caused
graph_update() to be called twice on the first boundary commit. This
caused the graph API to think that a commit had been skipped, and print
a "..." line in the output.
Signed-off-by: Adam Simpkins <adam@adamsimpkins.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Previously the graphing API wasn't aware of the revs->boundary flag, and
it always assumed that commits marked UNINTERESTING would not be
displayed. As a result, the boundary commits were printed at the end of
the log output, but they didn't have any branch lines connecting them to
their children in the graph.
There was also another bug in the get_revision() code that caused
graph_update() to be called twice on the first boundary commit. This
caused the graph API to think that a commit had been skipped, and print
a "..." line in the output.
Signed-off-by: Adam Simpkins <adam@adamsimpkins.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
log --graph --left-right: show left/right information in place of '*'
With the --graph option, the graph already outputs 'o' instead of '*'
for boundary commits. Make it emit '<' or '>' when --left-right is
specified.
(This change also disables the '^' prefix for UNINTERESTING commits.
The graph code currently doesn't print anything special for these
commits, since it assumes no UNINTERESTING, non-BOUNDARY commits are
displayed. This is potentially a bug if UNINTERESTING non-BOUNDARY
commits can actually be displayed via some code path.)
[jc: squashed the left-right change from Dscho and Adam's fixup into one]
Signed-off-by: Adam Simpkins <adam@adamsimpkins.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
With the --graph option, the graph already outputs 'o' instead of '*'
for boundary commits. Make it emit '<' or '>' when --left-right is
specified.
(This change also disables the '^' prefix for UNINTERESTING commits.
The graph code currently doesn't print anything special for these
commits, since it assumes no UNINTERESTING, non-BOUNDARY commits are
displayed. This is potentially a bug if UNINTERESTING non-BOUNDARY
commits can actually be displayed via some code path.)
[jc: squashed the left-right change from Dscho and Adam's fixup into one]
Signed-off-by: Adam Simpkins <adam@adamsimpkins.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
graph API: don't print branch lines for uninteresting merge parents
Previously, the graphing code printed lines coming out of a merge commit
for all of its parents, even if some of them were uninteresting. Now it
only prints lines for interesting commits.
For example, for a merge commit where only the first parent is
interesting, the code now prints:
* merge commit
* interesting child
instead of:
M merge commit
|\
* interesting child
Signed-off-by: Adam Simpkins <adam@adamsimpkins.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Previously, the graphing code printed lines coming out of a merge commit
for all of its parents, even if some of them were uninteresting. Now it
only prints lines for interesting commits.
For example, for a merge commit where only the first parent is
interesting, the code now prints:
* merge commit
* interesting child
instead of:
M merge commit
|\
* interesting child
Signed-off-by: Adam Simpkins <adam@adamsimpkins.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
graph API: fix graph mis-alignment after uninteresting commits
The graphing code had a bug that caused it to output branch lines
incorrectly after ignoring an uninteresting commit. When computing how
to match up the branch lines from the current commit to the next one, it
forgot to take into account that it needed to initially start with 2
empty spaces where the missing commit would have gone.
So, instead of drawing this,
| * | <- Commit with uninteresting parent
| /
* |
It used to incorrectly draw this:
| * | <- Commit with uninteresting parent
* |
Signed-off-by: Adam Simpkins <adam@adamsimpkins.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The graphing code had a bug that caused it to output branch lines
incorrectly after ignoring an uninteresting commit. When computing how
to match up the branch lines from the current commit to the next one, it
forgot to take into account that it needed to initially start with 2
empty spaces where the missing commit would have gone.
So, instead of drawing this,
| * | <- Commit with uninteresting parent
| /
* |
It used to incorrectly draw this:
| * | <- Commit with uninteresting parent
* |
Signed-off-by: Adam Simpkins <adam@adamsimpkins.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Documentation: convert tutorials to man pages
This patch renames the following documents and at the same time converts
them to the man page format:
cvs-migration.txt -> gitcvs-migration.txt
tutorial.txt -> gittutorial.txt
tutorial-2.txt -> gittutorial-2.txt
These new man pages are put in section 7, and other documents that reference
the above ones are change accordingly.
[jc: with help from Nanako to clean things up]
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch renames the following documents and at the same time converts
them to the man page format:
cvs-migration.txt -> gitcvs-migration.txt
tutorial.txt -> gittutorial.txt
tutorial-2.txt -> gittutorial-2.txt
These new man pages are put in section 7, and other documents that reference
the above ones are change accordingly.
[jc: with help from Nanako to clean things up]
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
CodingGuidelines: Add a note to avoid assignments inside if()
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Remove redundant code, eliminate one static variable
Signed-off-by: Heikki Orsila <heikki.orsila@iki.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Heikki Orsila <heikki.orsila@iki.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git diff": do not ignore index without --no-index
Even if "foo" and/or "bar" does not exist in index, "git diff foo bar"
should not change behaviour drastically from "git diff foo bar baz" or
"git diff foo". A feature that "sometimes works and is handy" is an
unreliable cute hack.
"git diff foo bar" outside a git repository continues to work as a more
colourful alternative to "diff -u" as before.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Even if "foo" and/or "bar" does not exist in index, "git diff foo bar"
should not change behaviour drastically from "git diff foo bar baz" or
"git diff foo". A feature that "sometimes works and is handy" is an
unreliable cute hack.
"git diff foo bar" outside a git repository continues to work as a more
colourful alternative to "diff -u" as before.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
diff-files: do not play --no-index games
Being able to say "git diff A B" outside a git repository and getting a
colourful version of "diff -u A B" may be nice, but such a cute hack
should not give bogus results to scripts that want to give two paths,
either or both of which happen to have been removed from the work tree,
to "git diff-files".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Being able to say "git diff A B" outside a git repository and getting a
colourful version of "diff -u A B" may be nice, but such a cute hack
should not give bogus results to scripts that want to give two paths,
either or both of which happen to have been removed from the work tree,
to "git diff-files".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
tests: do not use implicit "git diff --no-index"
As a general principle, we should not use "git diff" to validate the
results of what git command that is being tested has done. We would not
know if we are testing the command in question, or locating a bug in the
cute hack of "git diff --no-index".
Rather use test_cmp for that purpose.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
As a general principle, we should not use "git diff" to validate the
results of what git command that is being tested has done. We would not
know if we are testing the command in question, or locating a bug in the
cute hack of "git diff --no-index".
Rather use test_cmp for that purpose.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge git://git.kernel.org/pub/scm/gitk/gitk
* git://git.kernel.org/pub/scm/gitk/gitk:
gitk: Fix bug introduced by "gitk: Fix "wrong # coordinates" error on reload"
gitk: Fix bug where current row number display stops working
gitk: Move es.po where it belongs
gitk: Fix "wrong # coordinates" error on reload
* git://git.kernel.org/pub/scm/gitk/gitk:
gitk: Fix bug introduced by "gitk: Fix "wrong # coordinates" error on reload"
gitk: Fix bug where current row number display stops working
gitk: Move es.po where it belongs
gitk: Fix "wrong # coordinates" error on reload
Merge branch 'pb/push'
* pb/push:
add special "matching refs" refspec
* pb/push:
add special "matching refs" refspec
Merge branch 'bc/repack'
* bc/repack:
Documentation/git-repack.txt: document new -A behaviour
let pack-objects do the writing of unreachable objects as loose objects
add a force_object_loose() function
builtin-gc.c: deprecate --prune, it now really has no effect
git-gc: always use -A when manually repacking
repack: modify behavior of -A option to leave unreferenced objects unpacked
Conflicts:
builtin-pack-objects.c
* bc/repack:
Documentation/git-repack.txt: document new -A behaviour
let pack-objects do the writing of unreachable objects as loose objects
add a force_object_loose() function
builtin-gc.c: deprecate --prune, it now really has no effect
git-gc: always use -A when manually repacking
repack: modify behavior of -A option to leave unreferenced objects unpacked
Conflicts:
builtin-pack-objects.c
Merge branch 'sp/ignorecase'
* sp/ignorecase:
t0050: Fix merge test on case sensitive file systems
t0050: Add test for case insensitive add
t0050: Set core.ignorecase case to activate case insensitivity
t0050: Test autodetect core.ignorecase
git-init: autodetect core.ignorecase
* sp/ignorecase:
t0050: Fix merge test on case sensitive file systems
t0050: Add test for case insensitive add
t0050: Set core.ignorecase case to activate case insensitivity
t0050: Test autodetect core.ignorecase
git-init: autodetect core.ignorecase
Merge branch 'maint'
* maint:
rev-parse --symbolic-full-name: don't print '^' if SHA1 is not a ref
Add missing "short" alternative to --date in rev-list-options.txt
git-show.txt: Not very stubby these days.
Clarify repack -n documentation
* maint:
rev-parse --symbolic-full-name: don't print '^' if SHA1 is not a ref
Add missing "short" alternative to --date in rev-list-options.txt
git-show.txt: Not very stubby these days.
Clarify repack -n documentation
Add log.date config variable
log.date config variable sets the default date-time mode for the log
command. Setting log.date value is similar to using git log's --date
option.
Signed-off-by: Heikki Orsila <heikki.orsila@iki.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
log.date config variable sets the default date-time mode for the log
command. Setting log.date value is similar to using git log's --date
option.
Signed-off-by: Heikki Orsila <heikki.orsila@iki.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'maint-1.5.4' into maint
* maint-1.5.4:
rev-parse --symbolic-full-name: don't print '^' if SHA1 is not a ref
* maint-1.5.4:
rev-parse --symbolic-full-name: don't print '^' if SHA1 is not a ref
rev-parse --symbolic-full-name: don't print '^' if SHA1 is not a ref
The intention of --symbolic-full-name is to not print anything if a
revision is not an exact ref. But this command:
$ git-rev-parse --symbolic-full-name --not master~1
still emitted a sole '^' to stdout (provided that there's no other ref at
master~1). This fixes it.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The intention of --symbolic-full-name is to not print anything if a
revision is not an exact ref. But this command:
$ git-rev-parse --symbolic-full-name --not master~1
still emitted a sole '^' to stdout (provided that there's no other ref at
master~1). This fixes it.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Make git add -n and git -u -n output consistent
Output format from "git add -n $path" lists path to blobs that are going
to be added on a single line, separated with SP. On the other hand, the
suggested "git add -u -n" shows one path per line, like "add '<file>'\n".
Of course, these two are inconsistent.
Plain "git add -n" can afford to only say names of paths, as all it does
is to add (update). However, "git add -u" needs to be able to express
"remove" somehow. So if we need to have them formatted the same way, we
need to unify with the "git add -n -u" format. Incidentally, this is
consistent with how 'update-index' says it.
This changes the output from "git add -n $paths" but as a general
principle, output from Porcelain commands is a fair game for improvements
and not for script consumption.
Signed-off-by: Gustaf Hendeby <hendeby@isy.liu.se>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Output format from "git add -n $path" lists path to blobs that are going
to be added on a single line, separated with SP. On the other hand, the
suggested "git add -u -n" shows one path per line, like "add '<file>'\n".
Of course, these two are inconsistent.
Plain "git add -n" can afford to only say names of paths, as all it does
is to add (update). However, "git add -u" needs to be able to express
"remove" somehow. So if we need to have them formatted the same way, we
need to unify with the "git add -n -u" format. Incidentally, this is
consistent with how 'update-index' says it.
This changes the output from "git add -n $paths" but as a general
principle, output from Porcelain commands is a fair game for improvements
and not for script consumption.
Signed-off-by: Gustaf Hendeby <hendeby@isy.liu.se>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
change quoting in test t1006-cat-file.sh
Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin-cat-file.c: use parse_options()
This simplifies the option parsing.
Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This simplifies the option parsing.
Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-svn: Speed up fetch
We were spending a lot of time forking/execing git-cat-file and
git-hash-object. We now maintain a global Git repository object in order to use
Git.pm's more efficient hash_and_insert_object and cat_blob methods.
Signed-off-by: Adam Roben <aroben@apple.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We were spending a lot of time forking/execing git-cat-file and
git-hash-object. We now maintain a global Git repository object in order to use
Git.pm's more efficient hash_and_insert_object and cat_blob methods.
Signed-off-by: Adam Roben <aroben@apple.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Git.pm: Add hash_and_insert_object and cat_blob
These functions are more efficient ways of executing `git hash-object -w` and
`git cat-file blob` when you are dealing with many files/objects.
Signed-off-by: Adam Roben <aroben@apple.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These functions are more efficient ways of executing `git hash-object -w` and
`git cat-file blob` when you are dealing with many files/objects.
Signed-off-by: Adam Roben <aroben@apple.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Git.pm: Add command_bidi_pipe and command_close_bidi_pipe
command_bidi_pipe hands back the stdin and stdout file handles from the
executed command. command_close_bidi_pipe closes these handles and terminates
the process.
Signed-off-by: Adam Roben <aroben@apple.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
command_bidi_pipe hands back the stdin and stdout file handles from the
executed command. command_close_bidi_pipe closes these handles and terminates
the process.
Signed-off-by: Adam Roben <aroben@apple.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-hash-object: Add --stdin-paths option
This allows multiple paths to be specified on stdin.
Signed-off-by: Adam Roben <aroben@apple.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This allows multiple paths to be specified on stdin.
Signed-off-by: Adam Roben <aroben@apple.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add more tests for git hash-object
Signed-off-by: Adam Roben <aroben@apple.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Adam Roben <aroben@apple.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Move git-hash-object tests from t5303 to t1007
This is a more appropriate location according to t/README.
Signed-off-by: Adam Roben <aroben@apple.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is a more appropriate location according to t/README.
Signed-off-by: Adam Roben <aroben@apple.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Updated status to show 'Not currently on any branch' in red
This provides additional warning to users when attempting to
commit to a detached HEAD. It is configurable in color.status.nobranch.
Signed-off-by: Chris Parsons <chris@edendevelopment.co.uk>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This provides additional warning to users when attempting to
commit to a detached HEAD. It is configurable in color.status.nobranch.
Signed-off-by: Chris Parsons <chris@edendevelopment.co.uk>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add test for cloning with "--reference" repo being a subset of source repo
The first test in this series tests "git clone -l -s --reference B A C",
where repo B is a superset of repo A (A has one commit, B has the same
commit plus another). In this case, all objects to be cloned are already
present in B.
However, we should also test the case where the "--reference" repo is a
_subset_ of the source repo (e.g. "git clone -l -s --reference A B C"),
i.e. some objects are not available in the "--reference" repo, and will
have to be found in the source repo.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The first test in this series tests "git clone -l -s --reference B A C",
where repo B is a superset of repo A (A has one commit, B has the same
commit plus another). In this case, all objects to be cloned are already
present in B.
However, we should also test the case where the "--reference" repo is a
_subset_ of the source repo (e.g. "git clone -l -s --reference A B C"),
i.e. some objects are not available in the "--reference" repo, and will
have to be found in the source repo.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add a test for another combination of --reference
In this case, the reference repository has some useful loose objects,
but not all useful objects, and we make sure that we can find the
objects we fetch from the repository we're cloning in the new
repository, instead of potentially being distracted by the reference
repository.
Doing the wrong thing in a builtin-clone implementation would lead to
this looking for an object in the wrong place, not finding it (because
it's only in the right place), and crashing.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In this case, the reference repository has some useful loose objects,
but not all useful objects, and we make sure that we can find the
objects we fetch from the repository we're cloning in the new
repository, instead of potentially being distracted by the reference
repository.
Doing the wrong thing in a builtin-clone implementation would lead to
this looking for an object in the wrong place, not finding it (because
it's only in the right place), and crashing.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Test that --reference actually suppresses fetching referenced objects
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add missing "short" alternative to --date in rev-list-options.txt
Signed-off-by: Heikki Orsila <heikki.orsila@iki.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Heikki Orsila <heikki.orsila@iki.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-show.txt: Not very stubby these days.
Signed-off-by: Jon Loeliger <jdl@freescale.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Jon Loeliger <jdl@freescale.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Clarify repack -n documentation
While repacking a local repository a coworker thought the -n option
was necessary to git-repack to keep it from updating some unknown
file on the central server we all share. Explaining further what
the option is (not) doing helps to make it clear the option does
not impact any remote repositories the user may have configured.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
While repacking a local repository a coworker thought the -n option
was necessary to git-repack to keep it from updating some unknown
file on the central server we all share. Explaining further what
the option is (not) doing helps to make it clear the option does
not impact any remote repositories the user may have configured.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
pull --rebase: exit early when the working directory is dirty
When rebasing fails during "pull --rebase", you cannot just clean up the
working directory and call "pull --rebase" again, since the remote branch
was already fetched.
Therefore, die early when the working directory is dirty.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When rebasing fails during "pull --rebase", you cannot just clean up the
working directory and call "pull --rebase" again, since the remote branch
was already fetched.
Therefore, die early when the working directory is dirty.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
gitweb: Convert string to internal form before chopping in chop_str
Fix chop_str not to cut in middle of utf8 multibyte chars. Without
this fix at least author name in short log may cut in middle of a
multibyte char. When the result comes to esc_html to_utf8 is called
again, which doesn't find valid utf8 and decodes using
$fallback_encoding making it even worse.
This also have the nice side effect that it actually tries to show the
first 10 _characters_, not the number of characters that happened to fit
into 10 bytes.
Signed-off-by: Anders Waldenborg <anders@0x63.nu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Fix chop_str not to cut in middle of utf8 multibyte chars. Without
this fix at least author name in short log may cut in middle of a
multibyte char. When the result comes to esc_html to_utf8 is called
again, which doesn't find valid utf8 and decodes using
$fallback_encoding making it even worse.
This also have the nice side effect that it actually tries to show the
first 10 _characters_, not the number of characters that happened to fit
into 10 bytes.
Signed-off-by: Anders Waldenborg <anders@0x63.nu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
bisect: use a detached HEAD to bisect
When "git bisect" was first written, it was not possible to
checkout a detached HEAD. The detached feature appeared latter.
That's why before this patch the "git bisect" process used a
"bisect" branch to checkout new revisions to be tested (and also
a "new-bisect" one to check if the checkouts could work).
This patch makes "git bisect" checkout revisions to be tested on
a detached HEAD. This simplifies the code a bit.
The tests to check that "git bisect" does not start if a
"bisect" or a "new-bisect" branch exists are removed as they
are not relevant any more.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When "git bisect" was first written, it was not possible to
checkout a detached HEAD. The detached feature appeared latter.
That's why before this patch the "git bisect" process used a
"bisect" branch to checkout new revisions to be tested (and also
a "new-bisect" one to check if the checkouts could work).
This patch makes "git bisect" checkout revisions to be tested on
a detached HEAD. This simplifies the code a bit.
The tests to check that "git bisect" does not start if a
"bisect" or a "new-bisect" branch exists are removed as they
are not relevant any more.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
bisect: trap critical errors in "bisect_start"
Before this patch, when using "git bisect start" with mistaken revs
or when the checkout of the branch we want to test failed, we exited
after having written files like ".git/BISECT_START",
".git/BISECT_NAMES" and after having written "refs/bisect/bad" and
"refs/bisect/good-*" refs.
With this patch we trap all errors that can happen when writing the
new state and when we are in "bisect_next". So that we can try to
clean up everything in case of problems, using "bisect_clean_state".
This patch also contains a "bisect_write" cleanup to make it exit
on error and return 0 otherwise.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Before this patch, when using "git bisect start" with mistaken revs
or when the checkout of the branch we want to test failed, we exited
after having written files like ".git/BISECT_START",
".git/BISECT_NAMES" and after having written "refs/bisect/bad" and
"refs/bisect/good-*" refs.
With this patch we trap all errors that can happen when writing the
new state and when we are in "bisect_next". So that we can try to
clean up everything in case of problems, using "bisect_clean_state".
This patch also contains a "bisect_write" cleanup to make it exit
on error and return 0 otherwise.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
bisect: fix left over "BISECT_START" file when starting with junk rev
Before this patch, when using for example:
$ git bisect start <stuff1> <stuff2>
with <stuff1> or <stuff2> that cannot be parsed as a revision, we
could leave a ".git/BISECT_START" file, from a previous
"git bisect start", alone.
This patch makes sure that it does not happen by removing the
"BISECT_START" file in "bisect_clean_state" and then always writing
it again at the end of "bisect_start".
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Before this patch, when using for example:
$ git bisect start <stuff1> <stuff2>
with <stuff1> or <stuff2> that cannot be parsed as a revision, we
could leave a ".git/BISECT_START" file, from a previous
"git bisect start", alone.
This patch makes sure that it does not happen by removing the
"BISECT_START" file in "bisect_clean_state" and then always writing
it again at the end of "bisect_start".
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
bisect: add test cases to check that "git bisect start" is atomic
This patch adds some test cases to check that "git bisect start"
doesn't leave us in a bad state, especially when it fails.
These test cases show that "git bisect start" is not atomic when it
fails and leave some files like .git/BISECT_START, and in some
cases some refs, over.
The test failures should be fixed in latter commits.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch adds some test cases to check that "git bisect start"
doesn't leave us in a bad state, especially when it fails.
These test cases show that "git bisect start" is not atomic when it
fails and leave some files like .git/BISECT_START, and in some
cases some refs, over.
The test failures should be fixed in latter commits.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-gui: Handle workdir detection when CYGWIN=nowinsymlinks
If the user has put nowinsymlinks into their CYGWIN environment
variable any symlinks created by a Cygwin process (e.g. ln -s)
will not have the ".lnk" suffix. In this case workdir is still
a workdir, but our detection of looking for "info.lnk" fails
as the symlink is actually a normal file called "info".
Instead we just always use Cygwin's test executable to see if
info/exclude is a file. If it is, we assume from there on it
can be read by git-ls-files --others and is thus safe to use
on the command line.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If the user has put nowinsymlinks into their CYGWIN environment
variable any symlinks created by a Cygwin process (e.g. ln -s)
will not have the ".lnk" suffix. In this case workdir is still
a workdir, but our detection of looking for "info.lnk" fails
as the symlink is actually a normal file called "info".
Instead we just always use Cygwin's test executable to see if
info/exclude is a file. If it is, we assume from there on it
can be read by git-ls-files --others and is thus safe to use
on the command line.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>