Documentation: add a new man page for "git-help"
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-commit documentation: fix unfinished sentence.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-commit --allow-empty
It does not usually make sense to record a commit that has the exact
same tree as its sole parent commit and that is why git-commit prevents
you from making such a mistake, but when data from foreign scm is
involved, it is a different story. We are equipped to represent such an
(perhaps insane, perhaps by mistake, or perhaps done on purpose) empty
change, and it is better to represent it bypassing the safety valve for
native use.
This is primarily for use by foreign scm interface scripts.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It does not usually make sense to record a commit that has the exact
same tree as its sole parent commit and that is why git-commit prevents
you from making such a mistake, but when data from foreign scm is
involved, it is a different story. We are equipped to represent such an
(perhaps insane, perhaps by mistake, or perhaps done on purpose) empty
change, and it is better to represent it bypassing the safety valve for
native use.
This is primarily for use by foreign scm interface scripts.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-commit: Allow to amend a merge commit that does not change the tree
Normally, it should not be allowed to generate an empty commit. A merge
commit generated with git 'merge -s ours' does not change the tree (along
the first parent), but merges are not "empty" even if they do not change
the tree. Hence, commit 8588452ceb7 allowed to amend a merge commit that
does not change the tree, but 4fb5fd5d301 disallowed it again in an
attempt to avoid that an existing commit is amended such that it becomes
empty. With this change, a commit can be edited (create a new one or amend
an existing one) either if there are changes or if there are at least two
parents.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Normally, it should not be allowed to generate an empty commit. A merge
commit generated with git 'merge -s ours' does not change the tree (along
the first parent), but merges are not "empty" even if they do not change
the tree. Hence, commit 8588452ceb7 allowed to amend a merge commit that
does not change the tree, but 4fb5fd5d301 disallowed it again in an
attempt to avoid that an existing commit is amended such that it becomes
empty. With this change, a commit can be edited (create a new one or amend
an existing one) either if there are changes or if there are at least two
parents.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'js/prune-expire'
* js/prune-expire:
Add "--expire <time>" option to 'git prune'
* js/prune-expire:
Add "--expire <time>" option to 'git prune'
Merge branch 'js/export-with-assignment'
* js/export-with-assignment:
Replace instances of export VAR=VAL with VAR=VAL; export VAR
* js/export-with-assignment:
Replace instances of export VAR=VAL with VAR=VAL; export VAR
Merge branch 'js/fast-export'
* js/fast-export:
Add 'git fast-export', the sister of 'git fast-import'
* js/fast-export:
Add 'git fast-export', the sister of 'git fast-import'
Merge branch 'js/rebase-i-rerere'
* js/rebase-i-rerere:
rebase -i: give rerere a chance
* js/rebase-i-rerere:
rebase -i: give rerere a chance
Merge branch 'js/pull-rebase'
* js/pull-rebase:
Teach 'git pull' about --rebase
* js/pull-rebase:
Teach 'git pull' about --rebase
Merge branch 'wc/rebase-insn'
* wc/rebase-insn:
Mention that git-rm can be an appropriate resolution as well as git-add.
revert/cherry-pick: Allow overriding the help text by the calling Porcelain
* wc/rebase-insn:
Mention that git-rm can be an appropriate resolution as well as git-add.
revert/cherry-pick: Allow overriding the help text by the calling Porcelain
Merge branch 'jc/typebreak'
* jc/typebreak:
Enable rewrite as well as rename detection in git-status
rename: Break filepairs with different types.
* jc/typebreak:
Enable rewrite as well as rename detection in git-status
rename: Break filepairs with different types.
Enable rewrite as well as rename detection in git-status
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'jc/color'
* jc/color:
git-config --get-color: get configured color
"color.diff = true" is not "always" anymore.
* jc/color:
git-config --get-color: get configured color
"color.diff = true" is not "always" anymore.
Add 'git fast-export', the sister of 'git fast-import'
This program dumps (parts of) a git repository in the format that
fast-import understands.
For clarity's sake, it does not use the 'inline' method of specifying
blobs in the commits, but builds the blobs before building the commits.
Since signed tags' signatures will not necessarily be valid (think
transformations after the export, or excluding revisions, changing
the history), there are 4 modes to handle them: abort (default),
ignore, warn and strip. The latter just turns the tags into
unsigned ones.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This program dumps (parts of) a git repository in the format that
fast-import understands.
For clarity's sake, it does not use the 'inline' method of specifying
blobs in the commits, but builds the blobs before building the commits.
Since signed tags' signatures will not necessarily be valid (think
transformations after the export, or excluding revisions, changing
the history), there are 4 modes to handle them: abort (default),
ignore, warn and strip. The latter just turns the tags into
unsigned ones.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'dc/gitweb'
* dc/gitweb:
gitweb: the commitdiff is very commonly used, it's needed on search page, too
* dc/gitweb:
gitweb: the commitdiff is very commonly used, it's needed on search page, too
gitweb: Update and improve gitweb/README file
Update list of build configuration variables, add references
to gitweb/INSTALL, add description of runtime and per-repository
runtime configuration.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Update list of build configuration variables, add references
to gitweb/INSTALL, add description of runtime and per-repository
runtime configuration.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-stash: Display help message if git-stash is run with wrong sub-commands
The current git-stash behaviour is very error prone to typos. For example,
if you typed "git-stash llist", git-stash would think that you wanted to
save to a stash named "llist", but in fact, you meant "git-stash list".
Signed-off-by: Kevin Leung <kevinlsk@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The current git-stash behaviour is very error prone to typos. For example,
if you typed "git-stash llist", git-stash would think that you wanted to
save to a stash named "llist", but in fact, you meant "git-stash list".
Signed-off-by: Kevin Leung <kevinlsk@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-am: catch missing author date early.
Even though commit-tree would default to the current time if the incoming
e-mail message somehow did not record the timestamp, it is safer to catch
the breakage sooner.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Even though commit-tree would default to the current time if the incoming
e-mail message somehow did not record the timestamp, it is safer to catch
the breakage sooner.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'maint'
* maint:
t9600: test cvsimport from CVS working tree
* maint:
t9600: test cvsimport from CVS working tree
t9600: test cvsimport from CVS working tree
This test passes with v1.5.3.7, but not with v1.5.3.6.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This test passes with v1.5.3.7, but not with v1.5.3.6.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
gitweb: the commitdiff is very commonly used, it's needed on search page, too
Acked-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Acked-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
rename: Break filepairs with different types.
When we consider if a path has been totally rewritten, we did not
touch changes from symlinks to files or vice versa. But a change
that modifies even the type of a blob surely should count as a
complete rewrite.
While we are at it, modernise diffcore-break to be aware of gitlinks (we
do not want to touch them).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When we consider if a path has been totally rewritten, we did not
touch changes from symlinks to files or vice versa. But a change
that modifies even the type of a blob surely should count as a
complete rewrite.
While we are at it, modernise diffcore-break to be aware of gitlinks (we
do not want to touch them).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Update draft release notes for 1.5.4
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Consolidate command list to one.
The categorized list of commands in git(7) and the list of common
commands in "git help" output were maintained separately, which was
insane. This consolidates them to a single command-list.txt file.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The categorized list of commands in git(7) and the list of common
commands in "git help" output were maintained separately, which was
insane. This consolidates them to a single command-list.txt file.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Resurrect peek-remote
8951d7c1f1ae38f34617b6c2490bf65e73e371f7 (Build in ls-remote) made
peek-remote as a synonym to ls-remote by enhancing the latter, but
at the same time actually _removed_ it, before we officially gave
removal notice. This was bad.
Resurrect it for v1.5.4.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
8951d7c1f1ae38f34617b6c2490bf65e73e371f7 (Build in ls-remote) made
peek-remote as a synonym to ls-remote by enhancing the latter, but
at the same time actually _removed_ it, before we officially gave
removal notice. This was bad.
Resurrect it for v1.5.4.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'tt/help'
* tt/help:
Remove hint to use "git help -a"
Make the list of common commands more exclusive
* tt/help:
Remove hint to use "git help -a"
Make the list of common commands more exclusive
Merge branch 'jc/move-gitk'
* jc/move-gitk:
Move gitk to its own subdirectory
* jc/move-gitk:
Move gitk to its own subdirectory
Merge branch 'jc/branch-contains'
* jc/branch-contains:
git-branch --contains: doc and test
git-branch --contains=commit
parse-options: Allow to hide options from the default usage.
* jc/branch-contains:
git-branch --contains: doc and test
git-branch --contains=commit
parse-options: Allow to hide options from the default usage.
Merge branch 'cr/tag-options'
* cr/tag-options:
git-tag: test that -s implies an annotated tag
"git-tag -s" should create a signed annotated tag
builtin-tag: accept and process multiple -m just like git-commit
Make builtin-tag.c use parse_options.
* cr/tag-options:
git-tag: test that -s implies an annotated tag
"git-tag -s" should create a signed annotated tag
builtin-tag: accept and process multiple -m just like git-commit
Make builtin-tag.c use parse_options.
Update draft release notes for 1.5.4
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge 1.5.3.7 in
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
GIT 1.5.3.7
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Fix typo in t4008 test title
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-svn: Don't create a "master" branch every time rebase is run
If you run "git-svn rebase" while sitting on a topic branch, there is
no need to create a "master" branch if one didn't exist already. The
branch was created implicitly by the automatic checkout after fetching,
which in the case of rebase isn't actually necessary anyway.
Signed-off-by: Steven Grimm <koreth@midwinter.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
If you run "git-svn rebase" while sitting on a topic branch, there is
no need to create a "master" branch if one didn't exist already. The
branch was created implicitly by the automatic checkout after fetching,
which in the case of rebase isn't actually necessary anyway.
Signed-off-by: Steven Grimm <koreth@midwinter.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
git-svn: add a show-externals command.
show-externals can be used by scripts to provide svn:externals-like
functionality. For example, a script can list all of the externals and then
use check out the listed URLs at the appropriate paths, similar to what the svn
client does. Said script (or perhaps git-svn itself, in the future) could
simply invoke svn export on the paths, or it could go one further, using
git-svn clone and even git-submodule together to better integrate externals
checkouts.
The implementation is shamelessly copied from show-ignores. A more general
command to list user-specified properties is probably a better idea.
Signed-off-by: Vineet Kumar <vineet@doorstop.net>
Acked-by: Eric Wong <normalperson@yhbt.net>
show-externals can be used by scripts to provide svn:externals-like
functionality. For example, a script can list all of the externals and then
use check out the listed URLs at the appropriate paths, similar to what the svn
client does. Said script (or perhaps git-svn itself, in the future) could
simply invoke svn export on the paths, or it could go one further, using
git-svn clone and even git-submodule together to better integrate externals
checkouts.
The implementation is shamelessly copied from show-ignores. A more general
command to list user-specified properties is probably a better idea.
Signed-off-by: Vineet Kumar <vineet@doorstop.net>
Acked-by: Eric Wong <normalperson@yhbt.net>
git-svn: Remove unnecessary Git::SVN::Util package
Digest::MD5 is loaded regardless of the package in which it's
declared, so move its 'use' statement and the md5sum() function
into the main package.
Signed-off-by: David D. Kilzer <ddkilzer@kilzer.net>
Acked-by: Eric Wong <normalperson@yhbt.net>
Digest::MD5 is loaded regardless of the package in which it's
declared, so move its 'use' statement and the md5sum() function
into the main package.
Signed-off-by: David D. Kilzer <ddkilzer@kilzer.net>
Acked-by: Eric Wong <normalperson@yhbt.net>
git-svn: add support for pulling author from From: and Signed-off-by:
Add support for pulling the real author of a commit from the From:
and first Signed-off-by: fields of the SVN commit message.
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
Acked-by: Eric Wong <normalperson@yhbt.net>
Add support for pulling the real author of a commit from the From:
and first Signed-off-by: fields of the SVN commit message.
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
Acked-by: Eric Wong <normalperson@yhbt.net>
git-svn now reads settings even if called in subdirectory
Previously, git-svn first read the .git/config file for settings as if
current working directory was the repository top-directory, and after
that made sure to cd into top-directory. The result was a silent
failur to read configuration settings. This patch changes the order
these two things are done.
Signed-off-by: Gustaf Hendeby <hendeby@isy.liu.se>
Acked-by: Eric Wong <normalperson@yhbt.net>
Previously, git-svn first read the .git/config file for settings as if
current working directory was the repository top-directory, and after
that made sure to cd into top-directory. The result was a silent
failur to read configuration settings. This patch changes the order
these two things are done.
Signed-off-by: Gustaf Hendeby <hendeby@isy.liu.se>
Acked-by: Eric Wong <normalperson@yhbt.net>
Merge branch 'maint'
* maint:
Replace the word 'update-cache' by 'update-index' everywhere
cvsimport: fix usage of cvsimport.module
t7003-filter-branch: Fix test of a failing --msg-filter.
cvsimport: miscellaneous packed-ref fixes
cvsimport: use rev-parse to support packed refs
Add basic cvsimport tests
* maint:
Replace the word 'update-cache' by 'update-index' everywhere
cvsimport: fix usage of cvsimport.module
t7003-filter-branch: Fix test of a failing --msg-filter.
cvsimport: miscellaneous packed-ref fixes
cvsimport: use rev-parse to support packed refs
Add basic cvsimport tests
Fix a pathological case in git detecting proper renames
On Thu, 29 Nov 2007, Jeff King wrote:
>
> I think it will get worse, because you are simultaneously calculating
> all of the similarity scores bit by bit rather than doing a loop. Though
> perhaps you mean at the end you will end up with a list of src/dst pairs
> sorted by score, and you can loop over that.
Well, after thinking about this a bit, I think there's a solution that may
work well with the current thing too: instead of looping just *once* over
the list of rename pairs, loop twice - and simply refuse to do copies on
the first loop.
This trivial patch does that, and turns Kumar's test-case into a perfect
rename list.
It's not pretty, it's not smart, but it seems to work. There's something
to be said for keeping it simple and stupid.
And it should not be nearly as expensive as it may _look_. Yes, the loop
is "(i = 0; i < num_create * num_src; i++)", but the important part is
that the whole array is sorted by rename score, and we have a
if (mx[i].score < minimum_score)
break;
in it, so uthe loop actually would tend to terminate rather quickly.
Anyway, Kumar, the thing to take away from this is:
- git really doesn't even *care* about the whole "rename detection"
internally, and any commits you have done with renames are totally
independent of the heuristics we then use to *show* the renames.
- the rename detection really is for just two reasons: (a) keep humans
happy, and keep the diffs small and (b) help automatic merging across
renames. So getting renames right is certainly good, but it's more of a
"politeness" issue than a "correctness" issue, although the merge
portion of it does matter a lot sometimes.
- the important thing here is that you can commit your changes and not
worry about them being somehow "corrupted" by lack of rename detection,
even if you commit them with a version of git that doesn't do rename
detection the way you expected it. The rename detection is an
"after-the-fact" thing, not something that actually gets saved in the
repository, which is why we can change the heuristics _after_ seeing
examples, and the examples magically correct themselves!
- try out the two patches I've posted, and see if they work for you. They
pass the test-suite, and the output for your example commit looks sane,
but hey, if you have other test-cases, try them out.
Here's Kumar's pretty diffstat with both my patches:
Makefile | 6 +++---
board/{cds => freescale}/common/cadmus.c | 0
board/{cds => freescale}/common/cadmus.h | 0
board/{cds => freescale}/common/eeprom.c | 0
board/{cds => freescale}/common/eeprom.h | 0
board/{cds => freescale}/common/ft_board.c | 0
board/{cds => freescale}/common/via.c | 0
board/{cds => freescale}/common/via.h | 0
board/{cds => freescale}/mpc8541cds/Makefile | 0
board/{cds => freescale}/mpc8541cds/config.mk | 0
board/{cds => freescale}/mpc8541cds/init.S | 0
board/{cds => freescale}/mpc8541cds/mpc8541cds.c | 0
board/{cds => freescale}/mpc8541cds/u-boot.lds | 4 ++--
board/{cds => freescale}/mpc8548cds/Makefile | 0
board/{cds => freescale}/mpc8548cds/config.mk | 0
board/{cds => freescale}/mpc8548cds/init.S | 0
board/{cds => freescale}/mpc8548cds/mpc8548cds.c | 0
board/{cds => freescale}/mpc8548cds/u-boot.lds | 4 ++--
board/{cds => freescale}/mpc8555cds/Makefile | 0
board/{cds => freescale}/mpc8555cds/config.mk | 0
board/{cds => freescale}/mpc8555cds/init.S | 0
board/{cds => freescale}/mpc8555cds/mpc8555cds.c | 0
board/{cds => freescale}/mpc8555cds/u-boot.lds | 4 ++--
23 files changed, 9 insertions(+), 9 deletions(-)
and here it is before:
Makefile | 6 +-
board/cds/mpc8548cds/Makefile | 60 -----
board/cds/mpc8555cds/Makefile | 60 -----
board/cds/mpc8555cds/init.S | 255 --------------------
board/cds/mpc8555cds/u-boot.lds | 150 ------------
board/{cds => freescale}/common/cadmus.c | 0
board/{cds => freescale}/common/cadmus.h | 0
board/{cds => freescale}/common/eeprom.c | 0
board/{cds => freescale}/common/eeprom.h | 0
board/{cds => freescale}/common/ft_board.c | 0
board/{cds => freescale}/common/via.c | 0
board/{cds => freescale}/common/via.h | 0
board/{cds => freescale}/mpc8541cds/Makefile | 0
board/{cds => freescale}/mpc8541cds/config.mk | 0
board/{cds => freescale}/mpc8541cds/init.S | 0
board/{cds => freescale}/mpc8541cds/mpc8541cds.c | 0
board/{cds => freescale}/mpc8541cds/u-boot.lds | 4 +-
.../mpc8541cds => freescale/mpc8548cds}/Makefile | 0
board/{cds => freescale}/mpc8548cds/config.mk | 0
board/{cds => freescale}/mpc8548cds/init.S | 0
board/{cds => freescale}/mpc8548cds/mpc8548cds.c | 0
board/{cds => freescale}/mpc8548cds/u-boot.lds | 4 +-
.../mpc8541cds => freescale/mpc8555cds}/Makefile | 0
board/{cds => freescale}/mpc8555cds/config.mk | 0
.../mpc8541cds => freescale/mpc8555cds}/init.S | 0
board/{cds => freescale}/mpc8555cds/mpc8555cds.c | 0
.../mpc8541cds => freescale/mpc8555cds}/u-boot.lds | 4 +-
27 files changed, 9 insertions(+), 534 deletions(-)
so it certainly makes the diffs prettier.
Linus
Signed-off-by: Junio C Hamano <gitster@pobox.com>
On Thu, 29 Nov 2007, Jeff King wrote:
>
> I think it will get worse, because you are simultaneously calculating
> all of the similarity scores bit by bit rather than doing a loop. Though
> perhaps you mean at the end you will end up with a list of src/dst pairs
> sorted by score, and you can loop over that.
Well, after thinking about this a bit, I think there's a solution that may
work well with the current thing too: instead of looping just *once* over
the list of rename pairs, loop twice - and simply refuse to do copies on
the first loop.
This trivial patch does that, and turns Kumar's test-case into a perfect
rename list.
It's not pretty, it's not smart, but it seems to work. There's something
to be said for keeping it simple and stupid.
And it should not be nearly as expensive as it may _look_. Yes, the loop
is "(i = 0; i < num_create * num_src; i++)", but the important part is
that the whole array is sorted by rename score, and we have a
if (mx[i].score < minimum_score)
break;
in it, so uthe loop actually would tend to terminate rather quickly.
Anyway, Kumar, the thing to take away from this is:
- git really doesn't even *care* about the whole "rename detection"
internally, and any commits you have done with renames are totally
independent of the heuristics we then use to *show* the renames.
- the rename detection really is for just two reasons: (a) keep humans
happy, and keep the diffs small and (b) help automatic merging across
renames. So getting renames right is certainly good, but it's more of a
"politeness" issue than a "correctness" issue, although the merge
portion of it does matter a lot sometimes.
- the important thing here is that you can commit your changes and not
worry about them being somehow "corrupted" by lack of rename detection,
even if you commit them with a version of git that doesn't do rename
detection the way you expected it. The rename detection is an
"after-the-fact" thing, not something that actually gets saved in the
repository, which is why we can change the heuristics _after_ seeing
examples, and the examples magically correct themselves!
- try out the two patches I've posted, and see if they work for you. They
pass the test-suite, and the output for your example commit looks sane,
but hey, if you have other test-cases, try them out.
Here's Kumar's pretty diffstat with both my patches:
Makefile | 6 +++---
board/{cds => freescale}/common/cadmus.c | 0
board/{cds => freescale}/common/cadmus.h | 0
board/{cds => freescale}/common/eeprom.c | 0
board/{cds => freescale}/common/eeprom.h | 0
board/{cds => freescale}/common/ft_board.c | 0
board/{cds => freescale}/common/via.c | 0
board/{cds => freescale}/common/via.h | 0
board/{cds => freescale}/mpc8541cds/Makefile | 0
board/{cds => freescale}/mpc8541cds/config.mk | 0
board/{cds => freescale}/mpc8541cds/init.S | 0
board/{cds => freescale}/mpc8541cds/mpc8541cds.c | 0
board/{cds => freescale}/mpc8541cds/u-boot.lds | 4 ++--
board/{cds => freescale}/mpc8548cds/Makefile | 0
board/{cds => freescale}/mpc8548cds/config.mk | 0
board/{cds => freescale}/mpc8548cds/init.S | 0
board/{cds => freescale}/mpc8548cds/mpc8548cds.c | 0
board/{cds => freescale}/mpc8548cds/u-boot.lds | 4 ++--
board/{cds => freescale}/mpc8555cds/Makefile | 0
board/{cds => freescale}/mpc8555cds/config.mk | 0
board/{cds => freescale}/mpc8555cds/init.S | 0
board/{cds => freescale}/mpc8555cds/mpc8555cds.c | 0
board/{cds => freescale}/mpc8555cds/u-boot.lds | 4 ++--
23 files changed, 9 insertions(+), 9 deletions(-)
and here it is before:
Makefile | 6 +-
board/cds/mpc8548cds/Makefile | 60 -----
board/cds/mpc8555cds/Makefile | 60 -----
board/cds/mpc8555cds/init.S | 255 --------------------
board/cds/mpc8555cds/u-boot.lds | 150 ------------
board/{cds => freescale}/common/cadmus.c | 0
board/{cds => freescale}/common/cadmus.h | 0
board/{cds => freescale}/common/eeprom.c | 0
board/{cds => freescale}/common/eeprom.h | 0
board/{cds => freescale}/common/ft_board.c | 0
board/{cds => freescale}/common/via.c | 0
board/{cds => freescale}/common/via.h | 0
board/{cds => freescale}/mpc8541cds/Makefile | 0
board/{cds => freescale}/mpc8541cds/config.mk | 0
board/{cds => freescale}/mpc8541cds/init.S | 0
board/{cds => freescale}/mpc8541cds/mpc8541cds.c | 0
board/{cds => freescale}/mpc8541cds/u-boot.lds | 4 +-
.../mpc8541cds => freescale/mpc8548cds}/Makefile | 0
board/{cds => freescale}/mpc8548cds/config.mk | 0
board/{cds => freescale}/mpc8548cds/init.S | 0
board/{cds => freescale}/mpc8548cds/mpc8548cds.c | 0
board/{cds => freescale}/mpc8548cds/u-boot.lds | 4 +-
.../mpc8541cds => freescale/mpc8555cds}/Makefile | 0
board/{cds => freescale}/mpc8555cds/config.mk | 0
.../mpc8541cds => freescale/mpc8555cds}/init.S | 0
board/{cds => freescale}/mpc8555cds/mpc8555cds.c | 0
.../mpc8541cds => freescale/mpc8555cds}/u-boot.lds | 4 +-
27 files changed, 9 insertions(+), 534 deletions(-)
so it certainly makes the diffs prettier.
Linus
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Fix a pathological case in git detecting proper renames
Kumar Gala had a case in the u-boot archive with multiple renames of files
with identical contents, and git would turn those into multiple "copy"
operations of one of the sources, and just deleting the other sources.
This patch makes the git exact rename detection prefer to spread out the
renames over the multiple sources, rather than do multiple copies of one
source.
NOTE! The changes are a bit larger than required, because I also renamed
the variables named "one" and "two" to "target" and "source" respectively.
That makes the logic easier to follow, especially as the "one" was
illogically the target and not the soruce, for purely historical reasons
(this piece of code used to traverse over sources and targets in the wrong
order, and when we fixed that, we didn't fix the names back then. So I
fixed them now).
The important part of this change is just the trivial score calculations
for when files have identical contents:
/* Give higher scores to sources that haven't been used already */
score = !source->rename_used;
score += basename_same(source, target);
and when we have multiple choices we'll now pick the choice that gets the
best rename score, rather than only looking at whether the basename
matched.
It's worth noting a few gotchas:
- this scoring is currently only done for the "exact match" case.
In particular, in Kumar's example, even after this patch, the inexact
match case is still done as a copy+delete rather than as two renames:
delete mode 100644 board/cds/mpc8555cds/u-boot.lds
copy board/{cds => freescale}/mpc8541cds/u-boot.lds (97%)
rename board/{cds/mpc8541cds => freescale/mpc8555cds}/u-boot.lds (97%)
because apparently the "cds/mpc8541cds/u-boot.lds" copy looked
a bit more similar to both end results. That said, I *suspect* we just
have the exact same issue there - the similarity analysis just gave
identical (or at least very _close_ to identical) similarity points,
and we do not have any logic to prefer multiple renames over a
copy/delete there.
That is a separate patch.
- When you have identical contents and identical basenames, the actual
entry that is chosen is still picked fairly "at random" for the first
one (but the subsequent ones will prefer entries that haven't already
been used).
It's not actually really random, in that it actually depends on the
relative alphabetical order of the files (which in turn will have
impacted the order that the entries got hashed!), so it gives
consistent results that can be explained. But I wanted to point it out
as an issue for when anybody actually does cross-renames.
In Kumar's case the choice is the right one (and for a single normal
directory rename it should always be, since the relative alphabetical
sorting of the files will be identical), and we now get:
rename board/{cds => freescale}/mpc8541cds/init.S (100%)
rename board/{cds => freescale}/mpc8548cds/init.S (100%)
which is the "expected" answer. However, it might still be better to
change the pedantic "exact same basename" on/off choice into a more
graduated "how similar are the pathnames" scoring situation, in order
to be more likely to get the exact rename choice that people *expect*
to see, rather than other alternatives that may *technically* be
equally good, but are surprising to a human.
It's also unclear whether we should consider "basenames are equal" or
"have already used this as a source" to be more important. This gives them
equal weight, but I suspect we might want to just multiple the "basenames
are equal" weight by two, or something, to prefer equal basenames even if
that causes a copy/delete pair. I dunno.
Anyway, what I'm just saying in a really long-winded manner is that I
think this is right as-is, but it's not the complete solution, and it may
want some further tweaking in the future.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Kumar Gala had a case in the u-boot archive with multiple renames of files
with identical contents, and git would turn those into multiple "copy"
operations of one of the sources, and just deleting the other sources.
This patch makes the git exact rename detection prefer to spread out the
renames over the multiple sources, rather than do multiple copies of one
source.
NOTE! The changes are a bit larger than required, because I also renamed
the variables named "one" and "two" to "target" and "source" respectively.
That makes the logic easier to follow, especially as the "one" was
illogically the target and not the soruce, for purely historical reasons
(this piece of code used to traverse over sources and targets in the wrong
order, and when we fixed that, we didn't fix the names back then. So I
fixed them now).
The important part of this change is just the trivial score calculations
for when files have identical contents:
/* Give higher scores to sources that haven't been used already */
score = !source->rename_used;
score += basename_same(source, target);
and when we have multiple choices we'll now pick the choice that gets the
best rename score, rather than only looking at whether the basename
matched.
It's worth noting a few gotchas:
- this scoring is currently only done for the "exact match" case.
In particular, in Kumar's example, even after this patch, the inexact
match case is still done as a copy+delete rather than as two renames:
delete mode 100644 board/cds/mpc8555cds/u-boot.lds
copy board/{cds => freescale}/mpc8541cds/u-boot.lds (97%)
rename board/{cds/mpc8541cds => freescale/mpc8555cds}/u-boot.lds (97%)
because apparently the "cds/mpc8541cds/u-boot.lds" copy looked
a bit more similar to both end results. That said, I *suspect* we just
have the exact same issue there - the similarity analysis just gave
identical (or at least very _close_ to identical) similarity points,
and we do not have any logic to prefer multiple renames over a
copy/delete there.
That is a separate patch.
- When you have identical contents and identical basenames, the actual
entry that is chosen is still picked fairly "at random" for the first
one (but the subsequent ones will prefer entries that haven't already
been used).
It's not actually really random, in that it actually depends on the
relative alphabetical order of the files (which in turn will have
impacted the order that the entries got hashed!), so it gives
consistent results that can be explained. But I wanted to point it out
as an issue for when anybody actually does cross-renames.
In Kumar's case the choice is the right one (and for a single normal
directory rename it should always be, since the relative alphabetical
sorting of the files will be identical), and we now get:
rename board/{cds => freescale}/mpc8541cds/init.S (100%)
rename board/{cds => freescale}/mpc8548cds/init.S (100%)
which is the "expected" answer. However, it might still be better to
change the pedantic "exact same basename" on/off choice into a more
graduated "how similar are the pathnames" scoring situation, in order
to be more likely to get the exact rename choice that people *expect*
to see, rather than other alternatives that may *technically* be
equally good, but are surprising to a human.
It's also unclear whether we should consider "basenames are equal" or
"have already used this as a source" to be more important. This gives them
equal weight, but I suspect we might want to just multiple the "basenames
are equal" weight by two, or something, to prefer equal basenames even if
that causes a copy/delete pair. I dunno.
Anyway, what I'm just saying in a really long-winded manner is that I
think this is right as-is, but it's not the complete solution, and it may
want some further tweaking in the future.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add "--expire <time>" option to 'git prune'
Earlier, 'git prune' would prune all loose unreachable objects.
This could be quite dangerous, as the objects could be used in
an ongoing operation.
This patch adds a mode to expire only loose, unreachable objects
which are older than a certain time. For example, by
git prune --expire 14.days
you can prune only those objects which are loose, unreachable
and older than 14 days (and thus probably outdated).
The implementation uses st.st_mtime rather than st.st_ctime,
because it can be tested better, using 'touch -d <time>' (and
omitting the test when the platform does not support that
command line switch).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Earlier, 'git prune' would prune all loose unreachable objects.
This could be quite dangerous, as the objects could be used in
an ongoing operation.
This patch adds a mode to expire only loose, unreachable objects
which are older than a certain time. For example, by
git prune --expire 14.days
you can prune only those objects which are loose, unreachable
and older than 14 days (and thus probably outdated).
The implementation uses st.st_mtime rather than st.st_ctime,
because it can be tested better, using 'touch -d <time>' (and
omitting the test when the platform does not support that
command line switch).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Replace the word 'update-cache' by 'update-index' everywhere
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
cvsimport: fix usage of cvsimport.module
There were two problems:
1. We only look at the config variable if there is no module
given on the command line. We checked this by comparing
@ARGV == 0. However, at the time of the comparison, we
have not yet parsed the dashed options, meaning that
"git cvsimport" would read the variable but "git
cvsimport -a" would not. This is fixed by simply moving
the check after the call to getopt.
2. If the config variable did not exist, we were adding an
empty string to @ARGV. The rest of the script, rather
than barfing for insufficient input, would then try to
import the module '', leading to rather confusing error
messages. Based on patch from Emanuele Giaquinta.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There were two problems:
1. We only look at the config variable if there is no module
given on the command line. We checked this by comparing
@ARGV == 0. However, at the time of the comparison, we
have not yet parsed the dashed options, meaning that
"git cvsimport" would read the variable but "git
cvsimport -a" would not. This is fixed by simply moving
the check after the call to getopt.
2. If the config variable did not exist, we were adding an
empty string to @ARGV. The rest of the script, rather
than barfing for insufficient input, would then try to
import the module '', leading to rather confusing error
messages. Based on patch from Emanuele Giaquinta.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
receive-pack: allow deletion of corrupt refs
Occasionally, in some setups (*cough* forks on repo.or.cz *cough*) some
refs go stale, e.g. when the forkee rebased and lost some objects needed
by the fork. The quick & dirty way to deal with those refs is to delete
them and push them again.
However, git-push first would first fetch the current commit name for the
ref, would receive a null sha1 since the ref does not point to a valid
object, then tell receive-pack that it should delete the ref with this
commit name. delete_ref() would be subsequently be called, and check that
resolve_ref() (which does _not_ check for validity of the object) returns
the same commit name. Which would fail.
The proper fix is to avoid corrupting repositories, but in the meantime
this is a good fix in any case.
Incidentally, some instances of "cd .." in the test cases were fixed, so
that subsequent test cases run in t/trash/ irrespective of the outcome of
the previous test cases.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Occasionally, in some setups (*cough* forks on repo.or.cz *cough*) some
refs go stale, e.g. when the forkee rebased and lost some objects needed
by the fork. The quick & dirty way to deal with those refs is to delete
them and push them again.
However, git-push first would first fetch the current commit name for the
ref, would receive a null sha1 since the ref does not point to a valid
object, then tell receive-pack that it should delete the ref with this
commit name. delete_ref() would be subsequently be called, and check that
resolve_ref() (which does _not_ check for validity of the object) returns
the same commit name. Which would fail.
The proper fix is to avoid corrupting repositories, but in the meantime
this is a good fix in any case.
Incidentally, some instances of "cd .." in the test cases were fixed, so
that subsequent test cases run in t/trash/ irrespective of the outcome of
the previous test cases.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'jk/maint-cvsimport-fix' into maint
* jk/maint-cvsimport-fix:
cvsimport: miscellaneous packed-ref fixes
cvsimport: use rev-parse to support packed refs
Add basic cvsimport tests
* jk/maint-cvsimport-fix:
cvsimport: miscellaneous packed-ref fixes
cvsimport: use rev-parse to support packed refs
Add basic cvsimport tests
t7003-filter-branch: Fix test of a failing --msg-filter.
The test passed for the wrong reason: If the script given to --msg-filter
fails, it is expected that git-filter-branch aborts. But the test forgot
to tell the branch name to rewrite, and so git-filter-branch failed due to
incorrect usage.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The test passed for the wrong reason: If the script given to --msg-filter
fails, it is expected that git-filter-branch aborts. But the test forgot
to tell the branch name to rewrite, and so git-filter-branch failed due to
incorrect usage.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Mention that git-rm can be an appropriate resolution as well as git-add.
Especially when using git-cherry-pick, removing files that are unmerged can be
a logical action. This patch merely changes the informative text to be less
confusing.
Signed-off-by: David Symonds <dsymonds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Especially when using git-cherry-pick, removing files that are unmerged can be
a logical action. This patch merely changes the informative text to be less
confusing.
Signed-off-by: David Symonds <dsymonds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
revert/cherry-pick: Allow overriding the help text by the calling Porcelain
A Porcelain command that uses cherry-pick or revert may make a commit
out of resolved index itself, in which case telling the user to commit
the result is not appropriate at all. This allows GIT_CHERRY_PICK_HELP
environment variable to be set by the calling Porcelain in order to
override the built-in help text.
[jc: this is heavily modified from the original but should be equivalent
in spirit]
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A Porcelain command that uses cherry-pick or revert may make a commit
out of resolved index itself, in which case telling the user to commit
the result is not appropriate at all. This allows GIT_CHERRY_PICK_HELP
environment variable to be set by the calling Porcelain in order to
override the built-in help text.
[jc: this is heavily modified from the original but should be equivalent
in spirit]
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add config_int() method to the Git perl module
Integer variables can have optional 'k', 'm' or 'g' suffix.
config_int() method will return simple decimal number, taking
care of those suffixes.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Integer variables can have optional 'k', 'm' or 'g' suffix.
config_int() method will return simple decimal number, taking
care of those suffixes.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Error out when user doesn't have access permission to the repository
Signed-off-by: André Goddard Rosa <andre.goddard@gmail.com>
Signed-off-by: André Goddard Rosa <andre.goddard@gmail.com>
per-directory-exclude: lazily read .gitignore files
Operations that walk directories or trees, which potentially need to
consult the .gitignore files, used to always try to open the .gitignore
file every time they entered a new directory, even when they ended up
not needing to call excluded() function to see if a path in the
directory is ignored. This was done by push/pop exclude_per_directory()
functions that managed the data in a stack.
This changes the directory walking API to remove the need to call these
two functions. Instead, the directory walk data structure caches the
data used by excluded() function the last time, and lazily reuses it as
much as possible. Among the data the last check used, the ones from
deeper directories that the path we are checking is outside are
discarded, data from the common leading directories are reused, and then
the directories between the common directory and the directory the path
being checked is in are checked for .gitignore file. This is very
similar to the way gitattributes are handled.
This API change also fixes "ls-files -c -i", which called excluded()
without setting up the gitignore data via the old push/pop functions.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Operations that walk directories or trees, which potentially need to
consult the .gitignore files, used to always try to open the .gitignore
file every time they entered a new directory, even when they ended up
not needing to call excluded() function to see if a path in the
directory is ignored. This was done by push/pop exclude_per_directory()
functions that managed the data in a stack.
This changes the directory walking API to remove the need to call these
two functions. Instead, the directory walk data structure caches the
data used by excluded() function the last time, and lazily reuses it as
much as possible. Among the data the last check used, the ones from
deeper directories that the path we are checking is outside are
discarded, data from the common leading directories are reused, and then
the directories between the common directory and the directory the path
being checked is in are checked for .gitignore file. This is very
similar to the way gitattributes are handled.
This API change also fixes "ls-files -c -i", which called excluded()
without setting up the gitignore data via the old push/pop functions.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
dir.c: minor clean-up
Replace handcrafted reallocation with ALLOC_GROW().
Reindent "file_exists()" helper function.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Replace handcrafted reallocation with ALLOC_GROW().
Reindent "file_exists()" helper function.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
rebase -i: give rerere a chance
Like non-interactive rebase, interactive mode now calls rerere when
appropriate.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Like non-interactive rebase, interactive mode now calls rerere when
appropriate.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-config --get-color: get configured color
This new option allows scripts to grab color setting from the user
configuration, translated to ANSI color escape sequence.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This new option allows scripts to grab color setting from the user
configuration, translated to ANSI color escape sequence.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"color.diff = true" is not "always" anymore.
Too many people got burned by setting color.diff and color.status to
true when they really should have set it to "auto".
This makes only "always" to do the unconditional colorization, and
change the meaning of "true" to the same as "auto": colorize only when
we are talking to a terminal.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Too many people got burned by setting color.diff and color.status to
true when they really should have set it to "auto".
This makes only "always" to do the unconditional colorization, and
change the meaning of "true" to the same as "auto": colorize only when
we are talking to a terminal.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Teach 'git pull' about --rebase
When calling 'git pull' with the '--rebase' option, it performs a
fetch + rebase instead of a fetch + merge.
This behavior is more desirable than fetch + pull when a topic branch
is ready to be submitted and needs to be update.
fetch + rebase might also be considered a better workflow with shared
repositories in any case, or for contributors to a centrally managed
repository, such as WINE's.
As a convenience, you can set the default behavior for a branch by
defining the config variable branch.<name>.rebase, which is
interpreted as a bool. This setting can be overridden on the command
line by --rebase and --no-rebase.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When calling 'git pull' with the '--rebase' option, it performs a
fetch + rebase instead of a fetch + merge.
This behavior is more desirable than fetch + pull when a topic branch
is ready to be submitted and needs to be update.
fetch + rebase might also be considered a better workflow with shared
repositories in any case, or for contributors to a centrally managed
repository, such as WINE's.
As a convenience, you can set the default behavior for a branch by
defining the config variable branch.<name>.rebase, which is
interpreted as a bool. This setting can be overridden on the command
line by --rebase and --no-rebase.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Replace instances of export VAR=VAL with VAR=VAL; export VAR
It might be POSIX, but there are shells that do not like the
expression 'export VAR=VAL'. To be on the safe side, rewrite them
into 'VAR=VAL' and 'export VAR'.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It might be POSIX, but there are shells that do not like the
expression 'export VAR=VAL'. To be on the safe side, rewrite them
into 'VAR=VAL' and 'export VAR'.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'maint'
* maint:
scripts: do not get confused with HEAD in work tree
Improve description of git-branch -d and -D in man page.
* maint:
scripts: do not get confused with HEAD in work tree
Improve description of git-branch -d and -D in man page.
scripts: do not get confused with HEAD in work tree
When you have a file called HEAD in your work tree, many commands that
our scripts feed "HEAD" to would complain about the rev vs path
ambiguity. A solution is to form command line more carefully by
appending -- to them, which makes it clear that we mean HEAD rev not
HEAD file.
This patch would apply to maint.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When you have a file called HEAD in your work tree, many commands that
our scripts feed "HEAD" to would complain about the rev vs path
ambiguity. A solution is to form command line more carefully by
appending -- to them, which makes it clear that we mean HEAD rev not
HEAD file.
This patch would apply to maint.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
bash completion: add diff options
I use "git diff" (the porcelain) really often, and am almost as often
annoyed that the completions do not know how to complete something simple
as --cached. Now they do.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
I use "git diff" (the porcelain) really often, and am almost as often
annoyed that the completions do not know how to complete something simple
as --cached. Now they do.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git checkout's reflog: even when detaching the HEAD, say from where
When checking out another ref, the reflogs already record from which
branch you switched. Do that also when switching to a detached HEAD.
While at it, record also when coming _from_ a detached HEAD.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When checking out another ref, the reflogs already record from which
branch you switched. Do that also when switching to a detached HEAD.
While at it, record also when coming _from_ a detached HEAD.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
sha1_file.c: Fix size_t related printf format warnings
The old way of fixing warnings did not succeed on MinGW. MinGW
does not support C99 printf format strings for size_t [1]. But
gcc on MinGW issues warnings if C99 printf format is not used.
Hence, the old stragegy to avoid warnings fails.
[1] http://www.mingw.org/MinGWiki/index.php/C99
This commits passes arguments of type size_t through a tiny
helper functions that casts to the type expected by the format
string.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The old way of fixing warnings did not succeed on MinGW. MinGW
does not support C99 printf format strings for size_t [1]. But
gcc on MinGW issues warnings if C99 printf format is not used.
Hence, the old stragegy to avoid warnings fails.
[1] http://www.mingw.org/MinGWiki/index.php/C99
This commits passes arguments of type size_t through a tiny
helper functions that casts to the type expected by the format
string.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Revert "t5516: test update of local refs on push"
This reverts commit 09fba7a59d38d1cafaf33eadaf1d409c4113b30c.
These tests are superseded by the ones in t5404 (added in
6fa92bf3 and 8736a848), which are more extensive and better
organized.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This reverts commit 09fba7a59d38d1cafaf33eadaf1d409c4113b30c.
These tests are superseded by the ones in t5404 (added in
6fa92bf3 and 8736a848), which are more extensive and better
organized.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Improve description of git-branch -d and -D in man page.
Some users expect that deleting a remote-tracking branch would prevent
fetch from creating it again, so be explcit about that it's not the case.
Also be a little more explicit about what fully merged means.
Signed-off-by: Jan Hudec <bulb@ucw.cz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some users expect that deleting a remote-tracking branch would prevent
fetch from creating it again, so be explcit about that it's not the case.
Also be a little more explicit about what fully merged means.
Signed-off-by: Jan Hudec <bulb@ucw.cz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
filter-branch: fix dirty way to provide the helpers to commit filters
The helper functions 'map' and 'skip_commit' were provided to commit
filters by sourcing filter-branch itself. This was done with a certain
environment variable set to indicate that only the functions should be
defined, and the script should return then.
This was really hacky, and it did not work all that well, since the
full path to git-filter-branch was not known at all times.
Avoid that by putting the functions into a variable, and eval'ing
that variable. The commit filter gets these functions by prepending
the variable to the specified commands.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The helper functions 'map' and 'skip_commit' were provided to commit
filters by sourcing filter-branch itself. This was done with a certain
environment variable set to indicate that only the functions should be
defined, and the script should return then.
This was really hacky, and it did not work all that well, since the
full path to git-filter-branch was not known at all times.
Avoid that by putting the functions into a variable, and eval'ing
that variable. The commit filter gets these functions by prepending
the variable to the specified commands.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
cvsimport: miscellaneous packed-ref fixes
These were found with a grep for '$git_dir'; they all
replace a direct access of "$git_dir/refs/..." with a call
to git-rev-parse or git-update-ref.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These were found with a grep for '$git_dir'; they all
replace a direct access of "$git_dir/refs/..." with a call
to git-rev-parse or git-update-ref.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
cvsimport: use rev-parse to support packed refs
Previously, if refs were packed, git-cvsimport would assume
that particular refs did not exist. This could lead to, for
example, overwriting previous 'origin' commits that were
packed.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Previously, if refs were packed, git-cvsimport would assume
that particular refs did not exist. This could lead to, for
example, overwriting previous 'origin' commits that were
packed.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add basic cvsimport tests
We weren't even testing basic things before, so let's at
least try importing and updating a trivial repository, which
will catch total breakage.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We weren't even testing basic things before, so let's at
least try importing and updating a trivial repository, which
will catch total breakage.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-stash: do not get fooled with "color.diff = true"
When colors are set to "true" on the repository, the git log output
will contain control characters to set/reset the colors, even when
the output is to a pipe. This makes list_stash() fail as the
downstream sed does not see what it is expecting.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When colors are set to "true" on the repository, the git log output
will contain control characters to set/reset the colors, even when
the output is to a pipe. This makes list_stash() fail as the
downstream sed does not see what it is expecting.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Use is_absolute_path() in diff-lib.c, lockfile.c, setup.c, trace.c
Using the helper function to test for absolute paths makes porting easier.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Using the helper function to test for absolute paths makes porting easier.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Fix typo in draft 1.5.4 release notes
Signed-off-by: Wincent Colaiuta <win@wincent.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Wincent Colaiuta <win@wincent.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-tag: test that -s implies an annotated tag
This detects a regression introduced while moving git-tag to a C
builtin.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This detects a regression introduced while moving git-tag to a C
builtin.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'maint'
* maint:
user-manual: recovering from corruption
user-manual: clarify language about "modifying" old commits
user-manual: failed push to public repository
user-manual: define "branch" and "working tree" at start
git-checkout: describe detached head correctly
* maint:
user-manual: recovering from corruption
user-manual: clarify language about "modifying" old commits
user-manual: failed push to public repository
user-manual: define "branch" and "working tree" at start
git-checkout: describe detached head correctly
Merge branch 'maint' of git://linux-nfs.org/~bfields/git into maint
* 'maint' of git://linux-nfs.org/~bfields/git:
user-manual: recovering from corruption
user-manual: clarify language about "modifying" old commits
user-manual: failed push to public repository
user-manual: define "branch" and "working tree" at start
* 'maint' of git://linux-nfs.org/~bfields/git:
user-manual: recovering from corruption
user-manual: clarify language about "modifying" old commits
user-manual: failed push to public repository
user-manual: define "branch" and "working tree" at start
user-manual: recovering from corruption
Some instructions on dealing with corruption of the object database.
Most of this text is from an example by Linus, identified by Nicolas
Pitre <nico@cam.org> with a little further editing by me.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Some instructions on dealing with corruption of the object database.
Most of this text is from an example by Linus, identified by Nicolas
Pitre <nico@cam.org> with a little further editing by me.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Print the real filename that we failed to open.
When we fail to open a temporary file to be renamed to something else,
we reported the final filename, not the temporary file we failed to
open.
Signed-off-by: André Goddard Rosa <andre.goddard@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When we fail to open a temporary file to be renamed to something else,
we reported the final filename, not the temporary file we failed to
open.
Signed-off-by: André Goddard Rosa <andre.goddard@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
user-manual: clarify language about "modifying" old commits
It's important to remember that git doesn't really allowing "editing" or
"modifying" commits, only replacing them by new commits. Redo some of
the language to make this clearer.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
It's important to remember that git doesn't really allowing "editing" or
"modifying" commits, only replacing them by new commits. Redo some of
the language to make this clearer.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
revert/cherry-pick: do not mention the original ref
When you cherry-pick or revert a commit, naming it with an annotated
tag, we added a comment, attempting to repeat what we got from the end
user, to the message.
But this was inconsistent. When we got "cherry-pick branch", we
recorded the object name (40-letter SHA-1) without saying anything like
"original was 'branch'". There was no need to. Also recent rewrite to
use parse-options made it impossible to parrot the original command line
without "unparsing".
This removes the code that implements the misguided "we dereferenced the
tag so record that in the commit message" behaviour.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When you cherry-pick or revert a commit, naming it with an annotated
tag, we added a comment, attempting to repeat what we got from the end
user, to the message.
But this was inconsistent. When we got "cherry-pick branch", we
recorded the object name (40-letter SHA-1) without saying anything like
"original was 'branch'". There was no need to. Also recent rewrite to
use parse-options made it impossible to parrot the original command line
without "unparsing".
This removes the code that implements the misguided "we dereferenced the
tag so record that in the commit message" behaviour.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git-tag -s" should create a signed annotated tag
The earlier patch 396865859918e9c7bf8ce74aae137c57da134610 (Make
builtin-tag.c use parse_options.) broke "git-tag -s".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The earlier patch 396865859918e9c7bf8ce74aae137c57da134610 (Make
builtin-tag.c use parse_options.) broke "git-tag -s".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
user-manual: failed push to public repository
More details on the case of a failed push to a public (non-shared)
repository.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
More details on the case of a failed push to a public (non-shared)
repository.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
user-manual: define "branch" and "working tree" at start
Some explanation here might help.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Some explanation here might help.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
git-checkout: describe detached head correctly
When you have a file called HEAD in the work tree, the code to report
where the HEAD is at when "git checkout $commit^0" is done triggered
unnecessary ambiguity checking.
Explicitly mark the command line with "--" and make it clear that we are
talking about a revision.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When you have a file called HEAD in the work tree, the code to report
where the HEAD is at when "git checkout $commit^0" is done triggered
unnecessary ambiguity checking.
Explicitly mark the command line with "--" and make it clear that we are
talking about a revision.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Update draft release notes for 1.5.4
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'maint'
* maint:
Fix rev-list when showing objects involving submodules
test format-patch -s: make sure MIME content type is shown as needed
format-patch -s: add MIME encoding header if signer's name requires so
* maint:
Fix rev-list when showing objects involving submodules
test format-patch -s: make sure MIME content type is shown as needed
format-patch -s: add MIME encoding header if signer's name requires so
Merge branch 'rv/maint-index-commit' into maint
* rv/maint-index-commit:
Make GIT_INDEX_FILE apply to git-commit
* rv/maint-index-commit:
Make GIT_INDEX_FILE apply to git-commit
Merge branch 'lt/maint-rev-list-gitlink' into maint
* lt/maint-rev-list-gitlink:
Fix rev-list when showing objects involving submodules
* lt/maint-rev-list-gitlink:
Fix rev-list when showing objects involving submodules
Merge branch 'jc/maint-add-sync-stat' into maint
* jc/maint-add-sync-stat:
t2200: test more cases of "add -u"
git-add: make the entry stat-clean after re-adding the same contents
ce_match_stat, run_diff_files: use symbolic constants for readability
* jc/maint-add-sync-stat:
t2200: test more cases of "add -u"
git-add: make the entry stat-clean after re-adding the same contents
ce_match_stat, run_diff_files: use symbolic constants for readability
Merge branch 'jc/maint-format-patch-encoding' into maint
* jc/maint-format-patch-encoding:
test format-patch -s: make sure MIME content type is shown as needed
format-patch -s: add MIME encoding header if signer's name requires so
* jc/maint-format-patch-encoding:
test format-patch -s: make sure MIME content type is shown as needed
format-patch -s: add MIME encoding header if signer's name requires so
Merge branch 'bs/maint-t7005' into maint
* bs/maint-t7005:
t7005-editor.sh: Don't invoke real vi when it is in GIT_EXEC_PATH
* bs/maint-t7005:
t7005-editor.sh: Don't invoke real vi when it is in GIT_EXEC_PATH
Merge branch 'bs/maint-commit-options' into maint
* bs/maint-commit-options:
git-commit: Add tests for invalid usage of -a/--interactive with paths
git-commit.sh: Fix usage checks regarding paths given when they do not make sense
* bs/maint-commit-options:
git-commit: Add tests for invalid usage of -a/--interactive with paths
git-commit.sh: Fix usage checks regarding paths given when they do not make sense
Deprecate peek-remote
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t4119: correct overeager war-on-whitespace
Earlier a6080a0a44d5ead84db3dabbbc80e82df838533d (War on whitespace)
dropped a necessary trailing whitespace from the test vector.
Earlier a6080a0a44d5ead84db3dabbbc80e82df838533d (War on whitespace)
dropped a necessary trailing whitespace from the test vector.
Merge branch 'jk/send-pack'
* jk/send-pack: (24 commits)
send-pack: cluster ref status reporting
send-pack: fix "everything up-to-date" message
send-pack: tighten remote error reporting
make "find_ref_by_name" a public function
Fix warning about bitfield in struct ref
send-pack: assign remote errors to each ref
send-pack: check ref->status before updating tracking refs
send-pack: track errors for each ref
git-push: add documentation for the newly added --mirror mode
Add tests for git push'es mirror mode
Update the tracking references only if they were succesfully updated on remote
Add a test checking if send-pack updated local tracking branches correctly
git-push: plumb in --mirror mode
Teach send-pack a mirror mode
send-pack: segfault fix on forced push
Reteach builtin-ls-remote to understand remotes
send-pack: require --verbose to show update of tracking refs
receive-pack: don't mention successful updates
more terse push output
Build in ls-remote
...
* jk/send-pack: (24 commits)
send-pack: cluster ref status reporting
send-pack: fix "everything up-to-date" message
send-pack: tighten remote error reporting
make "find_ref_by_name" a public function
Fix warning about bitfield in struct ref
send-pack: assign remote errors to each ref
send-pack: check ref->status before updating tracking refs
send-pack: track errors for each ref
git-push: add documentation for the newly added --mirror mode
Add tests for git push'es mirror mode
Update the tracking references only if they were succesfully updated on remote
Add a test checking if send-pack updated local tracking branches correctly
git-push: plumb in --mirror mode
Teach send-pack a mirror mode
send-pack: segfault fix on forced push
Reteach builtin-ls-remote to understand remotes
send-pack: require --verbose to show update of tracking refs
receive-pack: don't mention successful updates
more terse push output
Build in ls-remote
...
Merge branch 'sb/clean'
* sb/clean:
Teach git clean to use setup_standard_excludes()
git-clean: Fix error message if clean.requireForce is not set.
Make git-clean a builtin
* sb/clean:
Teach git clean to use setup_standard_excludes()
git-clean: Fix error message if clean.requireForce is not set.
Make git-clean a builtin
Merge branch 'js/mingw-fallouts'
* js/mingw-fallouts:
fetch-pack: Prepare for a side-band demultiplexer in a thread.
rehabilitate some t5302 tests on 32-bit off_t machines
Allow ETC_GITCONFIG to be a relative path.
Introduce git_etc_gitconfig() that encapsulates access of ETC_GITCONFIG.
Allow a relative builtin template directory.
Close files opened by lock_file() before unlinking.
builtin run_command: do not exit with -1.
Move #include <sys/select.h> and <sys/ioctl.h> to git-compat-util.h.
Use is_absolute_path() in sha1_file.c.
Skip t3902-quoted.sh if the file system does not support funny names.
t5302-pack-index: Skip tests of 64-bit offsets if necessary.
t7501-commit.sh: Not all seds understand option -i
t5300-pack-object.sh: Split the big verify-pack test into smaller parts.
* js/mingw-fallouts:
fetch-pack: Prepare for a side-band demultiplexer in a thread.
rehabilitate some t5302 tests on 32-bit off_t machines
Allow ETC_GITCONFIG to be a relative path.
Introduce git_etc_gitconfig() that encapsulates access of ETC_GITCONFIG.
Allow a relative builtin template directory.
Close files opened by lock_file() before unlinking.
builtin run_command: do not exit with -1.
Move #include <sys/select.h> and <sys/ioctl.h> to git-compat-util.h.
Use is_absolute_path() in sha1_file.c.
Skip t3902-quoted.sh if the file system does not support funny names.
t5302-pack-index: Skip tests of 64-bit offsets if necessary.
t7501-commit.sh: Not all seds understand option -i
t5300-pack-object.sh: Split the big verify-pack test into smaller parts.
Merge branch 'mh/rebase-skip-hard'
* mh/rebase-skip-hard:
Do git reset --hard HEAD when using git rebase --skip
* mh/rebase-skip-hard:
Do git reset --hard HEAD when using git rebase --skip
Merge branch 'cc/bisect'
* cc/bisect:
Bisect reset: do nothing when not bisecting.
Bisect: use "$GIT_DIR/BISECT_NAMES" to check if we are bisecting.
Bisect visualize: use "for-each-ref" to list all good refs.
git-bisect: modernize branch shuffling hack
git-bisect: use update-ref to mark good/bad commits
git-bisect: war on "sed"
Bisect reset: remove bisect refs that may have been packed.
* cc/bisect:
Bisect reset: do nothing when not bisecting.
Bisect: use "$GIT_DIR/BISECT_NAMES" to check if we are bisecting.
Bisect visualize: use "for-each-ref" to list all good refs.
git-bisect: modernize branch shuffling hack
git-bisect: use update-ref to mark good/bad commits
git-bisect: war on "sed"
Bisect reset: remove bisect refs that may have been packed.
Merge branch 'maint'
* maint:
Fix sample pre-commit hook
* maint:
Fix sample pre-commit hook
Fix sample pre-commit hook
If the worktree happened to have a file called HEAD, "diff-index --cached HEAD"
would complain about the ambiguity between revision and path. Avoid it by
using an explicit "--" for disambiguation.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If the worktree happened to have a file called HEAD, "diff-index --cached HEAD"
would complain about the ambiguity between revision and path. Avoid it by
using an explicit "--" for disambiguation.
Signed-off-by: Junio C Hamano <gitster@pobox.com>