Use extended SHA1 syntax in merge-recursive conflicts.
When we get a line-level conflict in merge-recursive and print out
the two sides in the conflict hunk header and footer we should use
the standard extended SHA1 syntax to specify the specific blob,
as this allows the user to copy and paste the line right into
'git show' to view the complete version.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When we get a line-level conflict in merge-recursive and print out
the two sides in the conflict hunk header and footer we should use
the standard extended SHA1 syntax to specify the specific blob,
as this allows the user to copy and paste the line right into
'git show' to view the complete version.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
gitweb: Allow search to be disabled from the config file.
Signed-off-by: Robert Fitzsimons <robfitz@273k.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Robert Fitzsimons <robfitz@273k.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
gitweb: Require a minimum of two character for the search text.
Signed-off-by: Robert Fitzsimons <robfitz@273k.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Robert Fitzsimons <robfitz@273k.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
gitweb: Use rev-list pattern search options.
Use rev-list pattern search options instead of hand coded perl.
Signed-off-by: Robert Fitzsimons <robfitz@273k.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Use rev-list pattern search options instead of hand coded perl.
Signed-off-by: Robert Fitzsimons <robfitz@273k.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
checkout: make the message about the need for a new branch a bit clearer
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
gitweb: optimize git_summary.
We don't need to call git_get_head_hash at all just pass in "HEAD" and
use the return id field.
Signed-off-by: Robert Fitzsimons <robfitz@273k.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We don't need to call git_get_head_hash at all just pass in "HEAD" and
use the return id field.
Signed-off-by: Robert Fitzsimons <robfitz@273k.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
gitweb: optimize git_shortlog_body.
Don't call gitweb_have_snapshot from within the loop.
Signed-off-by: Robert Fitzsimons <robfitz@273k.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Don't call gitweb_have_snapshot from within the loop.
Signed-off-by: Robert Fitzsimons <robfitz@273k.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
gitweb: optimize git_get_last_activity.
Only return one line of output and we don't need the refname value.
Signed-off-by: Robert Fitzsimons <robfitz@273k.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Only return one line of output and we don't need the refname value.
Signed-off-by: Robert Fitzsimons <robfitz@273k.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
gitweb: Add missing show '...' links change.
Part of the patch for "gitweb: Show '...' links in "summary" view only
if there are more items" (313ce8cee665447e4476d7e8985b270346a8e5a1) is
missing. Add it back in.
Signed-off-by: Robert Fitzsimons <robfitz@273k.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Part of the patch for "gitweb: Show '...' links in "summary" view only
if there are more items" (313ce8cee665447e4476d7e8985b270346a8e5a1) is
missing. Add it back in.
Signed-off-by: Robert Fitzsimons <robfitz@273k.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Make git-show-branch options similar to git-branch.
Branch has "-r" for remote branches and "-a" for local and remote.
It seems logical to mirror that in show-branch. Also removes the
dubiously useful "--tags" option (as part of changing the meaning
for "--all").
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Branch has "-r" for remote branches and "-a" for local and remote.
It seems logical to mirror that in show-branch. Also removes the
dubiously useful "--tags" option (as part of changing the meaning
for "--all").
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Keep "git --git-dir" from causing a bus error.
The option checking code for --git-dir had an off by 1 error that
would cause it to access uninitialized memory if it was the last
argument. This causes it to display an error and display the usage
string instead.
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The option checking code for --git-dir had an off by 1 error that
would cause it to access uninitialized memory if it was the last
argument. This causes it to display an error and display the usage
string instead.
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-svn: enable common fetch/commit options for dcommit
dcommit does commits and fetches, so all options used for those
should work, too, including --authors-file.
Reported missing by Nicolas Vilz.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
dcommit does commits and fetches, so all options used for those
should work, too, including --authors-file.
Reported missing by Nicolas Vilz.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
vc-git: Ignore errors caused by a non-existent directory in vc-git-registered.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Remove NO_ACCURATE_DIFF options from build systems
The code no longer uses it, as we have --inaccurate-eof in
git-apply.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The code no longer uses it, as we have --inaccurate-eof in
git-apply.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-tag: lose exit after die
We are not running under /bin/resurrection shell ;-)
Signed-off-by: Junio C Hamano <junkio@cox.net>
We are not running under /bin/resurrection shell ;-)
Signed-off-by: Junio C Hamano <junkio@cox.net>
Really fix headers for __FreeBSD__
The symbol to detect FreeBSD is __FreeBSD__, not __FreeBSD.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The symbol to detect FreeBSD is __FreeBSD__, not __FreeBSD.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Do not support "partial URL shorthand" anymore.
We used to support specifying the top part of remote URL in
remotes and use that as a short-hand for the URL.
$ cat .git/remotes/jgarzik
URL: git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/
$ git pull jgarzik/misc-2.6
This is confusing when somebody attempts to do this:
$ git pull origin/foo
which is not syntactically correct (unless you have origin/foo.git
repository) and should fail, but it resulted in a mysterious
access to the 'foo' subdirectory of the origin repository.
Which was what it was designed to do, but because this is an
oddball "feature" I suspect nobody uses, let's remove it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
We used to support specifying the top part of remote URL in
remotes and use that as a short-hand for the URL.
$ cat .git/remotes/jgarzik
URL: git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/
$ git pull jgarzik/misc-2.6
This is confusing when somebody attempts to do this:
$ git pull origin/foo
which is not syntactically correct (unless you have origin/foo.git
repository) and should fail, but it resulted in a mysterious
access to the 'foo' subdirectory of the origin repository.
Which was what it was designed to do, but because this is an
oddball "feature" I suspect nobody uses, let's remove it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
default pull: forget about "newbie protection" for now.
This will not be backward compatible no matter how you cut it.
Shelve it for now until somebody comes up with a better way to
determine when we can safely refuse to use the first set of
branchse for merging without upsetting valid workflows.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This will not be backward compatible no matter how you cut it.
Shelve it for now until somebody comes up with a better way to
determine when we can safely refuse to use the first set of
branchse for merging without upsetting valid workflows.
Signed-off-by: Junio C Hamano <junkio@cox.net>
merge and reset: adjust for "reset --hard" messages
An earlier commit made "reset --hard" chattier but leaking its
message from "git rebase" (which calls it when first rewinding
the current branch to prepare replaying our own changes) without
explanation was confusing, so add an extra message to mention
it. Inside restorestate in merge (which is rarely exercised
codepath, where more than one strategies are attempted),
resetting to the original state uses "reset --hard" -- this can
be squelched entirely.
Signed-off-by: Junio C Hamano <junkio@cox.net>
An earlier commit made "reset --hard" chattier but leaking its
message from "git rebase" (which calls it when first rewinding
the current branch to prepare replaying our own changes) without
explanation was confusing, so add an extra message to mention
it. Inside restorestate in merge (which is rarely exercised
codepath, where more than one strategies are attempted),
resetting to the original state uses "reset --hard" -- this can
be squelched entirely.
Signed-off-by: Junio C Hamano <junkio@cox.net>
commit-tree: do not overflow MAXPARENT
We have a static allocation of MAXPARENT, but that limit was not
enforced, other than by a lucky invocation of the program segfaulting.
Signed-off-by: Junio C Hamano <junkio@cox.net>
We have a static allocation of MAXPARENT, but that limit was not
enforced, other than by a lucky invocation of the program segfaulting.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Introduce a global level warn() function.
Like the existing error() function the new warn() function can be
used to describe a situation that probably should not be occuring,
but which the user (and Git) can continue to work around without
running into too many problems.
An example situation is a bad commit SHA1 found in a reflog.
Attempting to read this record out of the reflog isn't really an
error as we have skipped over it in the past.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Like the existing error() function the new warn() function can be
used to describe a situation that probably should not be occuring,
but which the user (and Git) can continue to work around without
running into too many problems.
An example situation is a bad commit SHA1 found in a reflog.
Attempting to read this record out of the reflog isn't really an
error as we have skipped over it in the past.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Rename imap-send's internal info/warn functions.
Because I am about to introduce a global warn() function (much
like the global error function) this global declaration would
conflict with the one supplied by imap-send. Further since
imap-send's warn function output depends on its Quiet setting
we cannot simply remove its internal definition and use the
forthcoming global one.
So refactor warn() -> imap_warn() and info() -> imap_info()
(the latter was done just to be consistent in naming).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Because I am about to introduce a global warn() function (much
like the global error function) this global declaration would
conflict with the one supplied by imap-send. Further since
imap-send's warn function output depends on its Quiet setting
we cannot simply remove its internal definition and use the
forthcoming global one.
So refactor warn() -> imap_warn() and info() -> imap_info()
(the latter was done just to be consistent in naming).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
_XOPEN_SOURCE problem also exists on FreeBSD
Suggested by Rocco Rutte, Marco Roeland and others.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Suggested by Rocco Rutte, Marco Roeland and others.
Signed-off-by: Junio C Hamano <junkio@cox.net>
parse-remote: mark all refs not for merge only when fetching more than one
An earlier commit a71fb0a1 implemented much requested safety
valve to refuse "git pull" or "git pull origin" without explicit
refspecs from using the first set of remote refs obtained by
reading .git/remotes/origin file or branch.*.fetch configuration
variables to create a merge. The argument was that while on a
branch different from the default branch, it is often wrong to
merge the default remote ref suitable for merging into the master.
That is fine as a theory. But many repositories already in use
by people in the real world do not have any of the per branch
configuration crap. They did not need it, and they do not need
it now. Merging with the first remote ref listed was just fine,
because they had only one ref (e.g. 'master' from linux-2.6.git)
anyway.
So this changes the safety valve to be a lot looser. When "git
fetch" gets only one remote branch, the irritating warning would
not trigger anymore.
I think we could also make the warning trigger when branch.*.merge
is not specified for the current branch, but is for some other
branch. That is for another commit.
Signed-off-by: Junio C Hamano <junkio@cox.net>
An earlier commit a71fb0a1 implemented much requested safety
valve to refuse "git pull" or "git pull origin" without explicit
refspecs from using the first set of remote refs obtained by
reading .git/remotes/origin file or branch.*.fetch configuration
variables to create a merge. The argument was that while on a
branch different from the default branch, it is often wrong to
merge the default remote ref suitable for merging into the master.
That is fine as a theory. But many repositories already in use
by people in the real world do not have any of the per branch
configuration crap. They did not need it, and they do not need
it now. Merging with the first remote ref listed was just fine,
because they had only one ref (e.g. 'master' from linux-2.6.git)
anyway.
So this changes the safety valve to be a lot looser. When "git
fetch" gets only one remote branch, the irritating warning would
not trigger anymore.
I think we could also make the warning trigger when branch.*.merge
is not specified for the current branch, but is for some other
branch. That is for another commit.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Merge branch 'maint'
* maint:
diff --check: fix off by one error
spurious .sp in manpages
* maint:
diff --check: fix off by one error
spurious .sp in manpages
git-reset --hard: tell the user what the HEAD was reset to
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-tag: support -F <file> option
This imitates the behaviour of git-commit.
Noticed by Han-Wen Nienhuys.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This imitates the behaviour of git-commit.
Noticed by Han-Wen Nienhuys.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Revert "git-pull: refuse default merge without branch.*.merge"
This reverts commit a71fb0a1412c82405f078fb536797d3f5de68d53.
The logic to decide when to refuse to use the default "first set of
refs fetched" for merge was utterly bogus.
In a repository that happily worked correctly without any of the
per-branch configuration crap did not have (and did not have to
have) any branch.<current>.merge. With that broken commit, pulling
from origin no longer would work.
This reverts commit a71fb0a1412c82405f078fb536797d3f5de68d53.
The logic to decide when to refuse to use the default "first set of
refs fetched" for merge was utterly bogus.
In a repository that happily worked correctly without any of the
per-branch configuration crap did not have (and did not have to
have) any branch.<current>.merge. With that broken commit, pulling
from origin no longer would work.
Suggest 'add' in am/revert/cherry-pick.
Now that we have decided to make 'add' behave like 'update-index'
(and therefore fully classify update-index as strictly plumbing)
the am/revert/cherry-pick family of commands should not steer the
user towards update-index. Instead send them to the command they
probably already know, 'add'.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Now that we have decided to make 'add' behave like 'update-index'
(and therefore fully classify update-index as strictly plumbing)
the am/revert/cherry-pick family of commands should not steer the
user towards update-index. Instead send them to the command they
probably already know, 'add'.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Use git-merge-file in git-merge-one-file, too
Would you believe? I edited git-merge-one-file (note the missing ".sh"!)
when I submitted the patch which became commit e2b7008752...
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Would you believe? I edited git-merge-one-file (note the missing ".sh"!)
when I submitted the patch which became commit e2b7008752...
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
diff --check: fix off by one error
When parsing the diff line starting with '@@', the line number of the
'+' file is parsed. For the subsequent line parses, the line number
should therefore be incremented after the parse, not before it.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When parsing the diff line starting with '@@', the line number of the
'+' file is parsed. For the subsequent line parses, the line number
should therefore be incremented after the parse, not before it.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Documentation/git-branch: new -r to delete remote-tracking branches.
Signed-off-by: Quy Tonthat <qtonthat@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Quy Tonthat <qtonthat@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Fix system header problems on Mac OS X
For Mac OS X 10.4, _XOPEN_SOURCE defines _POSIX_C_SOURCE which
hides many symbols from the program.
Breakage noticed and initial analysis provided by Randal
L. Schwartz.
Signed-off-by: Junio C Hamano <junkio@cox.net>
For Mac OS X 10.4, _XOPEN_SOURCE defines _POSIX_C_SOURCE which
hides many symbols from the program.
Breakage noticed and initial analysis provided by Randal
L. Schwartz.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Merge branch 'ew/svn-pm'
* ew/svn-pm:
git-svn: rename 'commit' command to 'set-tree'
git-svn: remove support for the svn command-line client
git-svn: convert to using Git.pm
* ew/svn-pm:
git-svn: rename 'commit' command to 'set-tree'
git-svn: remove support for the svn command-line client
git-svn: convert to using Git.pm
diff documentation: mostly talk about <commit>
This corrects minor remaining bits that still talked about <tree-ish>;
the Porcelain users (as opposed to plumbers) are mostly interested in
commits so use <commit> consistently and keep a sentence that mentions
that <tree-ish> can be used in place of them.
This corrects minor remaining bits that still talked about <tree-ish>;
the Porcelain users (as opposed to plumbers) are mostly interested in
commits so use <commit> consistently and keep a sentence that mentions
that <tree-ish> can be used in place of them.
Merge branch 'jc/leftright'
* jc/leftright:
Revert "Make left-right automatic."
Make left-right automatic.
Teach all of log family --left-right output.
rev-list --left-right
* jc/leftright:
Revert "Make left-right automatic."
Make left-right automatic.
Teach all of log family --left-right output.
rev-list --left-right
Merge branch 'jc/blame'
* jc/blame:
blame: -b (blame.blankboundary) and --root (blame.showroot)
* jc/blame:
blame: -b (blame.blankboundary) and --root (blame.showroot)
Merge branch 'jc/branch-remove-remote'
* jc/branch-remove-remote:
git-branch -d: do not stop at the first failure.
Teach git-branch to delete tracking branches with -r -d
* jc/branch-remove-remote:
git-branch -d: do not stop at the first failure.
Teach git-branch to delete tracking branches with -r -d
Merge branch 'jc/clone'
* jc/clone:
Move "no merge candidate" warning into git-pull
Use preprocessor constants for environment variable names.
Do not create $GIT_DIR/remotes/ directory anymore.
Introduce GIT_TEMPLATE_DIR
Revert "fix testsuite: make sure they use templates freshly built from the source"
fix testsuite: make sure they use templates freshly built from the source
git-clone: lose the traditional 'no-separate-remote' layout
git-clone: lose the artificial "first" fetch refspec
git-pull: refuse default merge without branch.*.merge
git-clone: use wildcard specification for tracking branches
* jc/clone:
Move "no merge candidate" warning into git-pull
Use preprocessor constants for environment variable names.
Do not create $GIT_DIR/remotes/ directory anymore.
Introduce GIT_TEMPLATE_DIR
Revert "fix testsuite: make sure they use templates freshly built from the source"
fix testsuite: make sure they use templates freshly built from the source
git-clone: lose the traditional 'no-separate-remote' layout
git-clone: lose the artificial "first" fetch refspec
git-pull: refuse default merge without branch.*.merge
git-clone: use wildcard specification for tracking branches
compat/inet_ntop: do not use u_int
It is pointless.
Signed-off-by: Junio C Hamano <junkio@cox.net>
It is pointless.
Signed-off-by: Junio C Hamano <junkio@cox.net>
spurious .sp in manpages
This cherry-picks 7ef04350 that has been applied to the 'master'
to fix ".sp" in generated manpages.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This cherry-picks 7ef04350 that has been applied to the 'master'
to fix ".sp" in generated manpages.
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-add: error out when given no arguments.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Merge branch 'maint'
* maint:
GIT 1.4.4.3
* maint:
GIT 1.4.4.3
GIT 1.4.4.3
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
clarify some error messages wrt unknown object types
If ever new object types are added for future extensions then better
have current git version report them as "unknown" instead of
"corrupted".
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If ever new object types are added for future extensions then better
have current git version report them as "unknown" instead of
"corrupted".
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
simplify inclusion of system header files.
This is a mechanical clean-up of the way *.c files include
system header files.
(1) sources under compat/, platform sha-1 implementations, and
xdelta code are exempt from the following rules;
(2) the first #include must be "git-compat-util.h" or one of
our own header file that includes it first (e.g. config.h,
builtin.h, pkt-line.h);
(3) system headers that are included in "git-compat-util.h"
need not be included in individual C source files.
(4) "git-compat-util.h" does not have to include subsystem
specific header files (e.g. expat.h).
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is a mechanical clean-up of the way *.c files include
system header files.
(1) sources under compat/, platform sha-1 implementations, and
xdelta code are exempt from the following rules;
(2) the first #include must be "git-compat-util.h" or one of
our own header file that includes it first (e.g. config.h,
builtin.h, pkt-line.h);
(3) system headers that are included in "git-compat-util.h"
need not be included in individual C source files.
(4) "git-compat-util.h" does not have to include subsystem
specific header files (e.g. expat.h).
Signed-off-by: Junio C Hamano <junkio@cox.net>
index-pack usage of mmap() is unacceptably slower on many OSes other than Linux
It was reported by Randal L. Schwartz <merlyn@stonehenge.com> that
indexing the Linux repository ~150MB pack takes about an hour on OS x
while it's a minute on Linux. It seems that the OS X mmap()
implementation is more than 2 orders of magnitude slower than the Linux
one.
Linus proposed a patch replacing mmap() with pread() bringing index-pack
performance on OS X in line with the Linux one. The performances on
Linux also improved by a small margin.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
It was reported by Randal L. Schwartz <merlyn@stonehenge.com> that
indexing the Linux repository ~150MB pack takes about an hour on OS x
while it's a minute on Linux. It seems that the OS X mmap()
implementation is more than 2 orders of magnitude slower than the Linux
one.
Linus proposed a patch replacing mmap() with pread() bringing index-pack
performance on OS X in line with the Linux one. The performances on
Linux also improved by a small margin.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
gitweb: Show '...' links in "summary" view only if there are more items
Show "..." links in "summary" view to shortlog, heads (if there are
any), and tags (if there are any) only if there are more items to show
than shown already.
This means that "..." link is shown below shortened shortlog if there
are more than 16 commits, "..." link below shortened heads list if
there are more than 16 heads refs (16 branches), "..." link below
shortened tags list if there are more than 16 tags.
Modified patch from Jakub to to apply cleanly to master, also preform
the same "..." link logic to the forks list.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Robert Fitzsimons <robfitz@273k.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Show "..." links in "summary" view to shortlog, heads (if there are
any), and tags (if there are any) only if there are more items to show
than shown already.
This means that "..." link is shown below shortened shortlog if there
are more than 16 commits, "..." link below shortened heads list if
there are more than 16 heads refs (16 branches), "..." link below
shortened tags list if there are more than 16 tags.
Modified patch from Jakub to to apply cleanly to master, also preform
the same "..." link logic to the forks list.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Robert Fitzsimons <robfitz@273k.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
config_rename_section: fix FILE* leak
Noticed by SungHyun Nam.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Noticed by SungHyun Nam.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Remove COLLISION_CHECK from Makefile since it's not used.
It's rather misleading to have configuration options that don't do
anything. If someone adds collision checking they might also want to
restore this option.
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
It's rather misleading to have configuration options that don't do
anything. If someone adds collision checking they might also want to
restore this option.
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
fix populate-filespec
I hand munged the original patch when committing 1510fea78, and
screwed up the conversion.
Signed-off-by: Junio C Hamano <junkio@cox.net>
I hand munged the original patch when committing 1510fea78, and
screwed up the conversion.
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-cvsserver: fix breakage when calling git merge-file
In the same vein as 8336afa563fbeff35e531396273065161181f04c,
this fixes the the RCS merge to git-merge-file conversion in
commit e2b70087.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
In the same vein as 8336afa563fbeff35e531396273065161181f04c,
this fixes the the RCS merge to git-merge-file conversion in
commit e2b70087.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Revert "Make left-right automatic."
This reverts commit 5761231975ceffa531d86d9bab0f9a9a370674f6.
Feeding symmetric difference to gitk is so useful, and it is the
same for other graphical Porcelains. Rather than forcing them
to pass --no-left-right, making it optional.
Noticed and reported by Jeff King.
This reverts commit 5761231975ceffa531d86d9bab0f9a9a370674f6.
Feeding symmetric difference to gitk is so useful, and it is the
same for other graphical Porcelains. Rather than forcing them
to pass --no-left-right, making it optional.
Noticed and reported by Jeff King.
Move "no merge candidate" warning into git-pull
The warning triggered even when running "git fetch" only
when resulting .git/FETCH_HEAD only contained
branches marked as 'not-for-merge'.
Signed-off-by: Josef Weidendorfer <weidendo@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The warning triggered even when running "git fetch" only
when resulting .git/FETCH_HEAD only contained
branches marked as 'not-for-merge'.
Signed-off-by: Josef Weidendorfer <weidendo@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Use preprocessor constants for environment variable names.
We broke the discipline Linus set up to allow compiler help us
avoid typos in environment names in the early days of git over
time. This defines a handful preprocessor constants for
environment variable names used in relatively core parts of the
system.
I've left out variable names specific to subsystems such as HTTP
and SSL as I do not think they are big problems.
Signed-off-by: Junio C Hamano <junkio@cox.net>
We broke the discipline Linus set up to allow compiler help us
avoid typos in environment names in the early days of git over
time. This defines a handful preprocessor constants for
environment variable names used in relatively core parts of the
system.
I've left out variable names specific to subsystems such as HTTP
and SSL as I do not think they are big problems.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Do not create $GIT_DIR/remotes/ directory anymore.
Because we do not use --no-separate-remote anymore, there is no
reason to create that directory from the template.
t5510 test is updated to test both $GIT_DIR/remotes/ based
configuration and $GIT_DIR/config variable (credits to
Johannes).
Signed-off-by: Junio C Hamano <junkio@cox.net>
Because we do not use --no-separate-remote anymore, there is no
reason to create that directory from the template.
t5510 test is updated to test both $GIT_DIR/remotes/ based
configuration and $GIT_DIR/config variable (credits to
Johannes).
Signed-off-by: Junio C Hamano <junkio@cox.net>
Merge branch 'jc/test-clone' into jc/clone
* jc/test-clone: (35 commits)
Introduce GIT_TEMPLATE_DIR
Revert "fix testsuite: make sure they use templates freshly built from the source"
fix testsuite: make sure they use templates freshly built from the source
rerere: fix breakage of resolving.
Add config example with respect to branch
Add documentation for show-branch --topics
make git a bit less cryptic on fetch errors
make patch_delta() error cases a bit more verbose
racy-git: documentation updates.
show-ref: fix --exclude-existing
parse-remote::expand_refs_wildcard()
vim syntax: follow recent changes to commit template
show-ref: fix --verify --hash=length
show-ref: fix --quiet --verify
avoid accessing _all_ loose refs in git-show-ref --verify
git-fetch: Avoid reading packed refs over and over again
Teach show-branch how to show ref-log data.
markup fix in svnimport documentation.
Documentation: new option -P for git-svnimport
Fix mis-mark-up in git-merge-file.txt documentation
...
* jc/test-clone: (35 commits)
Introduce GIT_TEMPLATE_DIR
Revert "fix testsuite: make sure they use templates freshly built from the source"
fix testsuite: make sure they use templates freshly built from the source
rerere: fix breakage of resolving.
Add config example with respect to branch
Add documentation for show-branch --topics
make git a bit less cryptic on fetch errors
make patch_delta() error cases a bit more verbose
racy-git: documentation updates.
show-ref: fix --exclude-existing
parse-remote::expand_refs_wildcard()
vim syntax: follow recent changes to commit template
show-ref: fix --verify --hash=length
show-ref: fix --quiet --verify
avoid accessing _all_ loose refs in git-show-ref --verify
git-fetch: Avoid reading packed refs over and over again
Teach show-branch how to show ref-log data.
markup fix in svnimport documentation.
Documentation: new option -P for git-svnimport
Fix mis-mark-up in git-merge-file.txt documentation
...
Introduce GIT_TEMPLATE_DIR
Instead of passing --template explicitely to init-db and clone, you can
just set the environment variable GIT_TEMPLATE_DIR.
Also make use of it in the tests, to make sure that the templates are
copied.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Instead of passing --template explicitely to init-db and clone, you can
just set the environment variable GIT_TEMPLATE_DIR.
Also make use of it in the tests, to make sure that the templates are
copied.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Revert "fix testsuite: make sure they use templates freshly built from the source"
This reverts commit 74d20040cafdced657efbf49795183d209a3a07b.
Version from Johannes to introduce GIT_TEMPLATE_DIR is simpler,
although I unconsciously stayed away from introducing yet another
environment variable.
This reverts commit 74d20040cafdced657efbf49795183d209a3a07b.
Version from Johannes to introduce GIT_TEMPLATE_DIR is simpler,
although I unconsciously stayed away from introducing yet another
environment variable.
blame: -b (blame.blankboundary) and --root (blame.showroot)
When blame.blankboundary is set (or -b option is given), commit
object names are blanked out in the "human readable" output
format for boundary commits.
When blame.showroot is not set (or --root is not given), the
root commits are treated as boundary commits. The code still
attributes the lines to them, but with -b their object names are
not shown.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When blame.blankboundary is set (or -b option is given), commit
object names are blanked out in the "human readable" output
format for boundary commits.
When blame.showroot is not set (or --root is not given), the
root commits are treated as boundary commits. The code still
attributes the lines to them, but with -b their object names are
not shown.
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-branch -d: do not stop at the first failure.
If there are more than one branches to be deleted, failure on
one will no longer stop git-branch to process the next ones.
The command still reports failures by exitting non-zero status.
Signed-off-by: Quy Tonthat <qtonthat@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If there are more than one branches to be deleted, failure on
one will no longer stop git-branch to process the next ones.
The command still reports failures by exitting non-zero status.
Signed-off-by: Quy Tonthat <qtonthat@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Teach git-branch to delete tracking branches with -r -d
Because -r already means "remote" when listing, you can say:
$ git branch -d -r origin/todo origin/html origin/man
I just twisted it not to check fast-forwardness with the current
branch when you are removing a tracking branch. Most likely,
removal of a tracking branch is not because you are "done with"
it (for a local branch, it usually means "you merged it up"),
but because you are not even interested in it. In other words,
remote tracking branches are more like tags than branches.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Because -r already means "remote" when listing, you can say:
$ git branch -d -r origin/todo origin/html origin/man
I just twisted it not to check fast-forwardness with the current
branch when you are removing a tracking branch. Most likely,
removal of a tracking branch is not because you are "done with"
it (for a local branch, it usually means "you merged it up"),
but because you are not even interested in it. In other words,
remote tracking branches are more like tags than branches.
Signed-off-by: Junio C Hamano <junkio@cox.net>
fix testsuite: make sure they use templates freshly built from the source
The initial t/trash repository for testing was created properly
but over time we gained many tests that create secondary test
repositories with init-db or clone and they were not careful
enough.
This fixes it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The initial t/trash repository for testing was created properly
but over time we gained many tests that create secondary test
repositories with init-db or clone and they were not careful
enough.
This fixes it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
rerere: fix breakage of resolving.
commit e2b70087 botched the RCS merge to git-merge-file conversion.
There is no command called "git merge-file" (yes, we are using safer
variant of Perl's system(3)).
Signed-off-by: Junio C Hamano <junkio@cox.net>
commit e2b70087 botched the RCS merge to git-merge-file conversion.
There is no command called "git merge-file" (yes, we are using safer
variant of Perl's system(3)).
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add config example with respect to branch
Update config.txt with example with respect to branch
config variable. This give a better idea regarding
how branch names are expected.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Update config.txt with example with respect to branch
config variable. This give a better idea regarding
how branch names are expected.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add documentation for show-branch --topics
Add a quick paragraph explaining the --topics option for show-branch.
The explanation is an abbreviated version of the commit message from
d320a5437f8304cf9ea3ee1898e49d643e005738.
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add a quick paragraph explaining the --topics option for show-branch.
The explanation is an abbreviated version of the commit message from
d320a5437f8304cf9ea3ee1898e49d643e005738.
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
make git a bit less cryptic on fetch errors
The remote server might not want to tell why it doesn't like us for
security reasons, but let's make the client report such error in a bit
less confusing way. The remote failure remains a mystery, but the local
message might be a bit less so.
[jc: with a gentle wording updates from Andy Parkins]
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The remote server might not want to tell why it doesn't like us for
security reasons, but let's make the client report such error in a bit
less confusing way. The remote failure remains a mystery, but the local
message might be a bit less so.
[jc: with a gentle wording updates from Andy Parkins]
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
make patch_delta() error cases a bit more verbose
It is especially important to distinguish between a malloc() failure
from all the other cases. An out of memory condition is much less
worrisome than a compatibility/corruption problem.
Also make test-delta compilable again.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
It is especially important to distinguish between a malloc() failure
from all the other cases. An out of memory condition is much less
worrisome than a compatibility/corruption problem.
Also make test-delta compilable again.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
racy-git: documentation updates.
We've removed the workaround for runtime penalty that did not
exist in practice some time ago, but the technical paper that
proposed that change still said "we probably should do so".
Signed-off-by: Junio C Hamano <junkio@cox.net>
We've removed the workaround for runtime penalty that did not
exist in practice some time ago, but the technical paper that
proposed that change still said "we probably should do so".
Signed-off-by: Junio C Hamano <junkio@cox.net>
show-ref: fix --exclude-existing
Do not falsely document --filter-invalid which does not even exist.
Also make sure the line is long enough to have ^{} suffix before
checking for it.
Pointed out by Dscho.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Do not falsely document --filter-invalid which does not even exist.
Also make sure the line is long enough to have ^{} suffix before
checking for it.
Pointed out by Dscho.
Signed-off-by: Junio C Hamano <junkio@cox.net>
parse-remote::expand_refs_wildcard()
Work around dash incompatibility by not using "${name%'^{}'}".
Noticed by Jeff King; dash seems to mistake the closing brace
inside the single quote as the terminating brace for parameter
expansion.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Work around dash incompatibility by not using "${name%'^{}'}".
Noticed by Jeff King; dash seems to mistake the closing brace
inside the single quote as the terminating brace for parameter
expansion.
Signed-off-by: Junio C Hamano <junkio@cox.net>
vim syntax: follow recent changes to commit template
This patch changes the syntax highlighting to correctly match the new
text of the commit message introduced by
82dca84871637ac9812c0dec27f56d07cfba524c
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This patch changes the syntax highlighting to correctly match the new
text of the commit message introduced by
82dca84871637ac9812c0dec27f56d07cfba524c
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
show-ref: fix --verify --hash=length
An earlier optimization for --verify broke a lot of stuff
because it did not take interaction with other flags into
account.
This also fixes an unrelated argument parsing error; --hash=8
should mean the same as "--hash --abbrev=8".
Signed-off-by: Junio C Hamano <junkio@cox.net>
An earlier optimization for --verify broke a lot of stuff
because it did not take interaction with other flags into
account.
This also fixes an unrelated argument parsing error; --hash=8
should mean the same as "--hash --abbrev=8".
Signed-off-by: Junio C Hamano <junkio@cox.net>
show-ref: fix --quiet --verify
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Merge branch 'jc/blame-boundary'
* jc/blame-boundary:
git-blame: show lines attributed to boundary commits differently.
* jc/blame-boundary:
git-blame: show lines attributed to boundary commits differently.
Merge branch 'jc/reflog' (early part)
* 'jc/reflog' (early part):
Teach show-branch how to show ref-log data.
* 'jc/reflog' (early part):
Teach show-branch how to show ref-log data.
Merge branch 'js/branch-config'
* js/branch-config:
git-branch: rename config vars branch.<branch>.*, too
add a function to rename sections in the config
* js/branch-config:
git-branch: rename config vars branch.<branch>.*, too
add a function to rename sections in the config
Merge branch 'jn/web' (early part)
* 'jn/web' (early part):
gitweb: Add "next" link to commit view
gitweb: Add title attribute to ref marker with full ref name
gitweb: Do not show difftree for merges in "commit" view
gitweb: SHA-1 in commit log message links to "object" view
gitweb: Hyperlink target of symbolic link in "tree" view (if possible)
gitweb: Add generic git_object subroutine to display object of any type
gitweb: Show target of symbolic link in "tree" view
gitweb: Don't use Content-Encoding: header in git_snapshot
* 'jn/web' (early part):
gitweb: Add "next" link to commit view
gitweb: Add title attribute to ref marker with full ref name
gitweb: Do not show difftree for merges in "commit" view
gitweb: SHA-1 in commit log message links to "object" view
gitweb: Hyperlink target of symbolic link in "tree" view (if possible)
gitweb: Add generic git_object subroutine to display object of any type
gitweb: Show target of symbolic link in "tree" view
gitweb: Don't use Content-Encoding: header in git_snapshot
avoid accessing _all_ loose refs in git-show-ref --verify
If you want to verify a ref, it is overkill to first read all loose refs
into a linked list, and then check if the desired ref is there.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
If you want to verify a ref, it is overkill to first read all loose refs
into a linked list, and then check if the desired ref is there.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
git-fetch: Avoid reading packed refs over and over again
When checking which tags to fetch, the old code used to call
git-show-ref --verify for each remote tag. Since reading even
packed refs is not a cheap operation when there are a lot of
local refs, the code became quite slow.
This fixes it by teaching git-show-ref to filter out existing
refs using a new mode of operation of git-show-ref.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When checking which tags to fetch, the old code used to call
git-show-ref --verify for each remote tag. Since reading even
packed refs is not a cheap operation when there are a lot of
local refs, the code became quite slow.
This fixes it by teaching git-show-ref to filter out existing
refs using a new mode of operation of git-show-ref.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Teach show-branch how to show ref-log data.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Make left-right automatic.
When using symmetric differences, I think the user almost always
would want to know which side of the symmetry each commit came
from. So this removes --left-right option from the command
line, and turns it on automatically when a symmetric difference
is used ("git log --merge" counts as a symmetric difference
between HEAD and MERGE_HEAD).
Just in case, a new option --no-left-right is provided to defeat
this, but I do not know if it would be useful.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When using symmetric differences, I think the user almost always
would want to know which side of the symmetry each commit came
from. So this removes --left-right option from the command
line, and turns it on automatically when a symmetric difference
is used ("git log --merge" counts as a symmetric difference
between HEAD and MERGE_HEAD).
Just in case, a new option --no-left-right is provided to defeat
this, but I do not know if it would be useful.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Teach all of log family --left-right output.
This makes reviewing
git log --left-right --merge --no-merges -p
a lot more pleasant.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This makes reviewing
git log --left-right --merge --no-merges -p
a lot more pleasant.
Signed-off-by: Junio C Hamano <junkio@cox.net>
rev-list --left-right
The output from "symmetric diff", i.e. A...B, does not
distinguish between commits that are reachable from A and the
ones that are reachable from B. In this picture, such a
symmetric diff includes commits marked with a and b.
x---b---b branch B
/ \ /
/ .
/ / \
o---x---a---a branch A
However, you cannot tell which ones are 'a' and which ones are
'b' from the output. Sometimes this is frustrating. This adds
an output option, --left-right, to rev-list.
rev-list --left-right A...B
would show ones reachable from A prefixed with '<' and the ones
reachable from B prefixed with '>'.
When combined with --boundary, boundary commits (the ones marked
with 'x' in the above picture) are shown with prefix '-', so you
would see list that looks like this:
git rev-list --left-right --boundary --pretty=oneline A...B
>bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 3rd on b
>bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 2nd on b
<aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 3rd on a
<aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 2nd on a
-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 1st on b
-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 1st on a
Signed-off-by: Junio C Hamano <junkio@cox.net>
The output from "symmetric diff", i.e. A...B, does not
distinguish between commits that are reachable from A and the
ones that are reachable from B. In this picture, such a
symmetric diff includes commits marked with a and b.
x---b---b branch B
/ \ /
/ .
/ / \
o---x---a---a branch A
However, you cannot tell which ones are 'a' and which ones are
'b' from the output. Sometimes this is frustrating. This adds
an output option, --left-right, to rev-list.
rev-list --left-right A...B
would show ones reachable from A prefixed with '<' and the ones
reachable from B prefixed with '>'.
When combined with --boundary, boundary commits (the ones marked
with 'x' in the above picture) are shown with prefix '-', so you
would see list that looks like this:
git rev-list --left-right --boundary --pretty=oneline A...B
>bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 3rd on b
>bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 2nd on b
<aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 3rd on a
<aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 2nd on a
-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 1st on b
-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 1st on a
Signed-off-by: Junio C Hamano <junkio@cox.net>
markup fix in svnimport documentation.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Documentation: new option -P for git-svnimport
Documentation: new option -P for git-svnimport.
Signed-off-by: Quy Tonthat <qtonthat@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Documentation: new option -P for git-svnimport.
Signed-off-by: Quy Tonthat <qtonthat@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Fix mis-mark-up in git-merge-file.txt documentation
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Default GIT_COMMITTER_NAME to login name in recieve-pack.
If GIT_COMMITTER_NAME is not available in receive-pack but reflogs
are enabled we would normally die out with an error message asking
the user to correct their environment settings.
Now that reflogs are enabled by default in (what we guessed to be)
non-bare Git repositories this may cause problems for some users
who don't have their full name in the gecos field and who don't
have access to the remote system to correct the problem.
So rather than die()'ing out in receive-pack when we try to log a
ref change and have no committer name we default to the username,
as obtained from the host's password database.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If GIT_COMMITTER_NAME is not available in receive-pack but reflogs
are enabled we would normally die out with an error message asking
the user to correct their environment settings.
Now that reflogs are enabled by default in (what we guessed to be)
non-bare Git repositories this may cause problems for some users
who don't have their full name in the gecos field and who don't
have access to the remote system to correct the problem.
So rather than die()'ing out in receive-pack when we try to log a
ref change and have no committer name we default to the username,
as obtained from the host's password database.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Fix check_file_directory_conflict().
When replacing an existing file A with a directory A that has a
file A/B in it in the index, 'update-index --replace --add A/B'
did not properly remove the file to make room for the new
directory.
There was a trivial logic error, most likely a cut & paste one,
dating back to quite early days of git.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When replacing an existing file A with a directory A that has a
file A/B in it in the index, 'update-index --replace --add A/B'
did not properly remove the file to make room for the new
directory.
There was a trivial logic error, most likely a cut & paste one,
dating back to quite early days of git.
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-add: remove conflicting entry when adding.
When replacing an existing file A with a directory A that has a
file A/B in it in the index, 'git add' did not succeed because
it forgot to pass the allow-replace flag to add_cache_entry().
It might be safer to leave this as an error and require the user
to explicitly remove the existing A first before adding A/B
since it is an unusual case, but doing that automatically is
much easier to use.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When replacing an existing file A with a directory A that has a
file A/B in it in the index, 'git add' did not succeed because
it forgot to pass the allow-replace flag to add_cache_entry().
It might be safer to leave this as an error and require the user
to explicitly remove the existing A first before adding A/B
since it is an unusual case, but doing that automatically is
much easier to use.
Signed-off-by: Junio C Hamano <junkio@cox.net>
update-index: make D/F conflict error a bit more verbose.
When you remove a directory D that has a tracked file D/F out of the
way to create a file D and try to "git update-index --add D", it used
to say "cannot add" which was not very helpful. This issues an extra
error message to explain the situation before the final "fatal" message.
Since D/F conflicts are relatively rare event, extra verbosity would
not make things too noisy.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When you remove a directory D that has a tracked file D/F out of the
way to create a file D and try to "git update-index --add D", it used
to say "cannot add" which was not very helpful. This issues an extra
error message to explain the situation before the final "fatal" message.
Since D/F conflicts are relatively rare event, extra verbosity would
not make things too noisy.
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-branch: rename config vars branch.<branch>.*, too
When renaming a branch, the corresponding config section should
be renamed, too.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When renaming a branch, the corresponding config section should
be renamed, too.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
add a function to rename sections in the config
Given a config like this:
# A config
[very.interesting.section]
not
The command
$ git repo-config --rename-section very.interesting.section bla.1
will lead to this config:
# A config
[bla "1"]
not
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Given a config like this:
# A config
[very.interesting.section]
not
The command
$ git repo-config --rename-section very.interesting.section bla.1
will lead to this config:
# A config
[bla "1"]
not
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-clone: lose the traditional 'no-separate-remote' layout
Finally.
The separate-remote layout is so much more organized than
traditional and easier to work with especially when you need to
deal with remote repositories with multiple branches and/or you
need to deal with more than one remote repositories, and using
traditional layout for new repositories simply does not make
much sense.
Internally we still have code for 1:1 mappings to create a bare
clone; that is a good thing and will not go away.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Finally.
The separate-remote layout is so much more organized than
traditional and easier to work with especially when you need to
deal with remote repositories with multiple branches and/or you
need to deal with more than one remote repositories, and using
traditional layout for new repositories simply does not make
much sense.
Internally we still have code for 1:1 mappings to create a bare
clone; that is a good thing and will not go away.
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-clone: lose the artificial "first" fetch refspec
Now we lost the "first refspec is the one that is merged by default"
rule, there is no reason for clone to list the remote primary branch
in the config file explicitly anymore.
We still need it for the traditional layout for other reasons,
though.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Now we lost the "first refspec is the one that is merged by default"
rule, there is no reason for clone to list the remote primary branch
in the config file explicitly anymore.
We still need it for the traditional layout for other reasons,
though.
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-pull: refuse default merge without branch.*.merge
Everybody hated the pull behaviour of merging the first branch
listed on remotes/* file (or remote.*.fetch config) into the
current branch. This finally corrects that UI wart by
forbidding "git pull" without an explicit branch name on the
command line or branch.$current.merge for the current branch.
The matching change to git-clone was made to prepare the default
branch.*.merge entry for the primary branch some time ago.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Everybody hated the pull behaviour of merging the first branch
listed on remotes/* file (or remote.*.fetch config) into the
current branch. This finally corrects that UI wart by
forbidding "git pull" without an explicit branch name on the
command line or branch.$current.merge for the current branch.
The matching change to git-clone was made to prepare the default
branch.*.merge entry for the primary branch some time ago.
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-clone: use wildcard specification for tracking branches
This stops enumerating the set of branches found on the remote
side when a clone was made in the configuration file. Instead,
a single entry that maps each remote branch to the local
tracking branch for the remote under the same name is created.
Doing it this way not only shortens the configuration file, but
automatically adjusts to a new branch added on the remote side
after the clone is made.
Unfortunately this cannot be done for the traditional layout,
where we always need to special case the 'master' to 'origin'
mapping within the local branch namespace. But that is Ok; it
will be going away before v1.5.0.
We could also lose the "primary branch" mapping at the
beginning, but that has to wait until we implement the "forbid
'git pull' when we do not have branch.$current.merge for the
current branch" policy we earlier discussed. That should also
be in v1.5.0
Signed-off-by: Junio C Hamano <junkio@cox.net>
This stops enumerating the set of branches found on the remote
side when a clone was made in the configuration file. Instead,
a single entry that maps each remote branch to the local
tracking branch for the remote under the same name is created.
Doing it this way not only shortens the configuration file, but
automatically adjusts to a new branch added on the remote side
after the clone is made.
Unfortunately this cannot be done for the traditional layout,
where we always need to special case the 'master' to 'origin'
mapping within the local branch namespace. But that is Ok; it
will be going away before v1.5.0.
We could also lose the "primary branch" mapping at the
beginning, but that has to wait until we implement the "forbid
'git pull' when we do not have branch.$current.merge for the
current branch" policy we earlier discussed. That should also
be in v1.5.0
Signed-off-by: Junio C Hamano <junkio@cox.net>
merge: give a bit prettier merge message to "merge branch~$n"
This hacks the input to fmt-merge-msg to make the message for
merging early part of a branch a little easier to read.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This hacks the input to fmt-merge-msg to make the message for
merging early part of a branch a little easier to read.
Signed-off-by: Junio C Hamano <junkio@cox.net>
gitweb: Add "next" link to commit view
Add a kind of "next" view in the bottom part of navigation bar for
"commit" view, similar to what was added for "commitdiff" view in
commit 151602df00b8e5c5b4a8193f59a94b85f9b5aebc
'gitweb: Add "next" link to commitdiff view'
For "commit" view for single parent commit:
(parent: _commit_)
For "commit" view for merge (multi-parent) commit:
(merge: _commit_ _commit_ ...)
For "commit" view for root (parentless) commit
(initial)
where _link_ denotes hyperlink. SHA1 of commit is shortened
to 7 characters on display.
While at it, remove leftovers from commit cae1862a by Petr Baudis:
'gitweb: More per-view navigation bar links'
namely the "blame" link if there exist $file_name and commit has a
parent; it was added in git_commit probably by mistake. The rest
of what mentioned commit added for git_commit was removed in
commit 6e0e92fda893311ff5af91836e5007bf6bbd4a21 by Luben Tuikov:
'gitweb: Do not print "log" and "shortlog" redundantly in commit view'
(which should have probably removed also this "blame" link removed now).
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add a kind of "next" view in the bottom part of navigation bar for
"commit" view, similar to what was added for "commitdiff" view in
commit 151602df00b8e5c5b4a8193f59a94b85f9b5aebc
'gitweb: Add "next" link to commitdiff view'
For "commit" view for single parent commit:
(parent: _commit_)
For "commit" view for merge (multi-parent) commit:
(merge: _commit_ _commit_ ...)
For "commit" view for root (parentless) commit
(initial)
where _link_ denotes hyperlink. SHA1 of commit is shortened
to 7 characters on display.
While at it, remove leftovers from commit cae1862a by Petr Baudis:
'gitweb: More per-view navigation bar links'
namely the "blame" link if there exist $file_name and commit has a
parent; it was added in git_commit probably by mistake. The rest
of what mentioned commit added for git_commit was removed in
commit 6e0e92fda893311ff5af91836e5007bf6bbd4a21 by Luben Tuikov:
'gitweb: Do not print "log" and "shortlog" redundantly in commit view'
(which should have probably removed also this "blame" link removed now).
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
gitweb: Add title attribute to ref marker with full ref name
Add title attribute, which will be shown as popup on mouseover in
graphical web browsers, with full name of ref, including part (type)
removed from the name of ref itself. This is useful to see that this
strange ref is StGIT ref, or it is remote branch, or it is lightweigh
tag (with branch-like name).
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add title attribute, which will be shown as popup on mouseover in
graphical web browsers, with full name of ref, including part (type)
removed from the name of ref itself. This is useful to see that this
strange ref is StGIT ref, or it is remote branch, or it is lightweigh
tag (with branch-like name).
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>