Re: [PATCH v3] push: respect --no-thin
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
Over the time the default value for --thin has been switched between
on and off. As of now it's always on, even if --no-thin is given.
Correct the code to respect --no-thin.
receive-pack learns about --no-thin only for testing purposes, hence
no document update.
Please name it --reject-thin-pack-for-testing to make it crystal
clear that a documentation patch to document undocumented option
is unwanted.
diff --git a/builtin/push.c b/builtin/push.c
index 04f0eaf..333a1fb 100644
--- a/builtin/push.c
+++ b/builtin/push.c
@@ -15,7 +15,7 @@ static const char * const push_usage[] = {
NULL,
};
-static int thin;
+static int thin = 1;
static int deleterefs;
static const char *receivepack;
static int verbosity;
@@ -313,8 +313,7 @@ static int push_with_options(struct transport *transport,
int flags)
if (receivepack)
transport_set_option(transport,
TRANS_OPT_RECEIVEPACK, receivepack);
- if (thin)
- transport_set_option(transport, TRANS_OPT_THIN, yes);
+ transport_set_option(transport, TRANS_OPT_THIN, thin ? yes : NULL);
if (verbosity 0)
fprintf(stderr, _(Pushing to %s\n), transport-url);
Hmm, I am utterly confused.
How does the original code have thin as an non-overridable default?
The variable is initialized to 0, parse-options specifies it as
OPT_BOOLEAN, and TRANS_OPT_THIN is set only if thin is set.
Updated code flips the default to 1 but unconditionally uses
TRANS_OPT_THIN to set it to either yes or NULL. While it is not
wrong per-se, do_push() (i.e. the caller of this function) grabs the
transport from transport_get() which initializes the transport with
the thin option disabled by default, so it is not immediately
obvious to me why always call TRANS_OPT_THIN but set it explicitly
to NULL when --no-thin is asked is necessary or improvement.
Puzzled
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] status: always show tracking branch even no change
Jiang Xin worldhello@gmail.com writes: 2013/8/10 Junio C Hamano gits...@pobox.com: Jiang Xin worldhello@gmail.com writes: So always show the remote tracking branch in the output of git status and other commands will help users to see where the current branch will push to and pull from. E.g. ... Hmmph. I do not know if this will help any case you described above, even though this might help some other cases. The added output is to always show the current branch and its upstream, but the thing is, the original issue in $gmane/198703 was *not* that the current branch was pushed and up to date. It was that there was no current branch to be pushed. The same thing would happen if you are on a local branch that is not set to be pushed to the other side (e.g. the configuration is set to matching and there is no such branch on the other end). How about write the commit log like this: ... Then if there is no tracking info reported, the user may need to do something. Maybe the current branch is a new branch that needs to be pushed out, or maybe it's a branch which should add remote tracking settings. Would that help anybody, though? A user who does not notice the _lack_ of mention of the current branch in the feedback from git push would not notice the lack of ahead, behind or the same. We could contemplate on saying your current branch is not set to be pushed out to anywhere instead of being silent in the case where the output with your patch is silent, but that would make status output irritatingly chatty when you are on a private topic branch that you never intend to push out except as a part of an integration branch after merging into it, so it is not a good solution either, but at least that would solve the original problem. Isn't it the real solution to the original poster's problem to make git push explain Everything is up to date, and nothing is pushed case better? Perhaps git push can learn an option to show what the command would push out if there were something to push. If push.default is set to matching and the user is on a branch that does not exist on the receiving end, matching branches will be listed as up to date and the user could notice that his current branch is _not_ among the ones that are listed. When there is _no_ branch to be pushed out (e.g. there is no matching branches, or you are on a detached HEAD) that please explain option could really explain whey there is no branch to be pushed out. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] pull: Allow pull to preserve merges when rebasing.
If a user is working on master, and has merged in their feature branch, but now
has to git pull because master moved, with pull.rebase their feature branch
will be flattened into master.
This is because git pull currently does not know about rebase's preserve
merges flag, which would avoid this behavior, as it would instead replay just
the merge commit of the feature branch onto the new master, and not replay each
individual commit in the feature branch.
Add a --rebase=preserve option, which will pass along --preserve-merges to
rebase.
Also add 'preserve' to the allowed values for the pull.rebase config setting.
Signed-off-by: Stephen Haberman step...@exigencecorp.com
---
Hi,
This is v4 of my pull.rebase=preserve patch, previously discussed here:
http://thread.gmane.org/gmane.comp.version-control.git/232140
This version addresses feedback from Andreas about using case statements
instead of yoda conditions, and feedback from both Andreas and Junio
about avoiding ambiguity with --rebase preserve. Now it must be
--rebase=preseve.
I assume I'm doing the right thing by just posting another version of
this patch to the git list; let me know if I'm missing something.
Thanks!
Documentation/config.txt | 8 +
Documentation/git-pull.txt | 18 +++
git-pull.sh| 27 +---
t/t5520-pull.sh| 81 ++
4 files changed, 123 insertions(+), 11 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index ec57a15..4c22be2 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -766,6 +766,10 @@ branch.name.rebase::
git pull is run. See pull.rebase for doing this in a non
branch-specific manner.
+
+ When preserve, also pass `--preserve-merges` along to 'git rebase'
+ so that locally committed merge commits will not be flattened
+ by running 'git pull'.
++
*NOTE*: this is a possibly dangerous operation; do *not* use
it unless you understand the implications (see linkgit:git-rebase[1]
for details).
@@ -1826,6 +1830,10 @@ pull.rebase::
pull is run. See branch.name.rebase for setting this on a
per-branch basis.
+
+ When preserve, also pass `--preserve-merges` along to 'git rebase'
+ so that locally committed merge commits will not be flattened
+ by running 'git pull'.
++
*NOTE*: this is a possibly dangerous operation; do *not* use
it unless you understand the implications (see linkgit:git-rebase[1]
for details).
diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
index 6ef8d59..beea10b 100644
--- a/Documentation/git-pull.txt
+++ b/Documentation/git-pull.txt
@@ -102,12 +102,18 @@ include::merge-options.txt[]
:git-pull: 1
-r::
---rebase::
- Rebase the current branch on top of the upstream branch after
- fetching. If there is a remote-tracking branch corresponding to
- the upstream branch and the upstream branch was rebased since last
- fetched, the rebase uses that information to avoid rebasing
- non-local changes.
+--rebase[=false|true|preserve]::
+ When true, rebase the current branch on top of the upstream
+ branch after fetching. If there is a remote-tracking branch
+ corresponding to the upstream branch and the upstream branch
+ was rebased since last fetched, the rebase uses that information
+ to avoid rebasing non-local changes.
++
+When preserve, also rebase the current branch on top of the upstream
+branch, but pass `--preserve-merges` along to `git rebase` so that
+locally created merge commits will not be flattened.
++
+When false, merge the current branch into the upstream branch.
+
See `pull.rebase`, `branch.name.rebase` and `branch.autosetuprebase` in
linkgit:git-config[1] if you want to make `git pull` always use
diff --git a/git-pull.sh b/git-pull.sh
index f0df41c..6ae6640 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -4,7 +4,7 @@
#
# Fetch one or more remote refs and merge it/them into the current HEAD.
-USAGE='[-n | --no-stat] [--[no-]commit] [--[no-]squash] [--[no-]ff] [-s
strategy]... [fetch-options] repo head...'
+USAGE='[-n | --no-stat] [--[no-]commit] [--[no-]squash] [--[no-]ff]
[-r=[true|false|preserve]] [-s strategy]... [fetch-options] repo head...'
LONG_USAGE='Fetch one or more remote refs and integrate it/them with the
current HEAD.'
SUBDIRECTORY_OK=Yes
OPTIONS_SPEC=
@@ -40,13 +40,13 @@ test -f $GIT_DIR/MERGE_HEAD die_merge
strategy_args= diffstat= no_commit= squash= no_ff= ff_only=
log_arg= verbosity= progress= recurse_submodules= verify_signatures=
-merge_args= edit=
+merge_args= edit= rebase_args=
curr_branch=$(git symbolic-ref -q HEAD)
curr_branch_short=${curr_branch#refs/heads/}
-rebase=$(git config --bool branch.$curr_branch_short.rebase)
+rebase=$(git config branch.$curr_branch_short.rebase)
if test -z $rebase
then
- rebase=$(git config --bool pull.rebase)
+
Re: [PATCH 2/3] t3404: rebase: interactive: demonstrate short SHA-1 collision
Eric Sunshine sunsh...@sunshineco.com writes: The 'todo' sheet for interactive rebase shows abbreviated SHA-1's and then performs its operations upon those shortened values. This can lead to an abort if the SHA-1 of a reworded or edited commit is no longer unique within the abbreviated SHA-1 space and a subsequent SHA-1 in the todo list has the same abbreviated value. For example: edit f00dfad first pick badbeef second If, after editing, the new SHA-1 of first is now badbeef5ba78983324dff5265c80c4490d5a809a, then the subsequent 'pick badbeef second' will fail since badbeef is no longer a unique SHA-1 abbreviation: error: short SHA1 badbeef is ambiguous. fatal: Needed a single revision Invalid commit name: badbeef Demonstrate this problem with a couple of specially crafted commits which initially have distinct abbreviated SHA-1's, but for which the abbreviated SHA-1's collide after a simple rewording of the first commit's message. Signed-off-by: Eric Sunshine sunsh...@sunshineco.com --- t/t3404-rebase-interactive.sh | 17 + 1 file changed, 17 insertions(+) diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh index af141be..e5ebec6 100755 --- a/t/t3404-rebase-interactive.sh +++ b/t/t3404-rebase-interactive.sh @@ -977,4 +977,21 @@ test_expect_success 'rebase -i with --strategy and -X' ' test $(cat file1) = Z ' +test_expect_success 'short SHA-1 setup' ' + test_when_finished git checkout master + git checkout --orphan collide + git rm -rf . + unset test_tick This will inconvenience tests added later to these two in the future. Oversight, or deliberate act knowing that these two are the last tests in this script ;-)? One bad thing is that unset loses information so that such future tests cannot resurrect test_tick and continue on from where the last test-tick left off. + test_commit collide1 collide + test_commit --notick collide2 collide + test_commit --notick collide3 115158b5 collide collide3 collide3 +' +test_expect_failure 'short SHA-1 collide' ' + test_when_finished reset_rebase git checkout master + git checkout collide + FAKE_COMMIT_MESSAGE=collide2 815200e \ ;-) + FAKE_LINES=reword 1 2 git rebase -i HEAD~2 +' + test_done -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pull: Allow pull to preserve merges when rebasing.
Stephen Haberman step...@exigencecorp.com writes:
I assume I'm doing the right thing by just posting another version of
this patch to the git list; let me know if I'm missing something.
Thanks. Writing the story so far... summary like you did after
the three-dash line was very helpful.
diff --git a/git-pull.sh b/git-pull.sh
index f0df41c..6ae6640 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -4,7 +4,7 @@
#
# Fetch one or more remote refs and merge it/them into the current HEAD.
-USAGE='[-n | --no-stat] [--[no-]commit] [--[no-]squash] [--[no-]ff] [-s
strategy]... [fetch-options] repo head...'
+USAGE='[-n | --no-stat] [--[no-]commit] [--[no-]squash] [--[no-]ff]
[-r=[true|false|preserve]] [-s strategy]... [fetch-options] repo
head...'
-r, even though it happens to be accepted, is not a good idea
here, as there are other --r* commands that are not --rebase.
[--[no-]rebase|--rebase=preserve]
would be better.
@@ -40,13 +40,13 @@ test -f $GIT_DIR/MERGE_HEAD die_merge
strategy_args= diffstat= no_commit= squash= no_ff= ff_only=
log_arg= verbosity= progress= recurse_submodules= verify_signatures=
-merge_args= edit=
+merge_args= edit= rebase_args=
curr_branch=$(git symbolic-ref -q HEAD)
curr_branch_short=${curr_branch#refs/heads/}
-rebase=$(git config --bool branch.$curr_branch_short.rebase)
+rebase=$(git config branch.$curr_branch_short.rebase)
if test -z $rebase
then
- rebase=$(git config --bool pull.rebase)
+ rebase=$(git config pull.rebase)
This is a grave regression (the same for the earlier one that reads
the branch.*.rebase configuraiton). Those who did any of the
following will be broken:
[pull]
;; any of the following are true
rebase
rebase = yes
rebase = 1
;; any of the following are false
rebase = no
rebase = 0
You would want bool or string helper function to parse it
correctly, something like:
bool_or_string_config () {
git config --bool $1 2/dev/null || git config $1
}
rebase=$(boo_or_string_config pull.rebase)
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pull: Allow pull to preserve merges when rebasing.
Junio C Hamano gits...@pobox.com writes: Andres Perera andre...@zoho.com writes: i just realized that there are ambiguities: pull -r (true|false|preserve) foo there are 2 ways to interpret this: pull --rebase=(true|false|preserve) foo # pull from remote named foo pull --rebase (true|false|preserve) foo # pull from remote named (true|false|preserve), branch foo options with optional operands usually require that the operands be concatenated with the option argument. Yes. This command line option should be like this: - --rebase and --no-rebase are accepted as true and false; - --rebase=preserve should be the _only_ way to spell the new mode of operation (if we were to add --rebase=interactive later, that should follow suit); and - --rebase=true and --rebase=false is nice to have for consistency. Thanks. Oh, another thing. How should this interact with 949e0d8e (pull: require choice between rebase/merge on non-fast-forward pull, 2013-06-27) which has been in 'next' and will likely to be one of the earlier topics to graduate to 'master' after 1.8.4 is released? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
ephemeral-branches instead of detached-head?
Has there ever been any any discussion of creating an ephemeral-branch name mechanism, instead of using detached HEADs? By ephemeral, I mean that a branch-name could be created which would live only so long as it is the only named way to reach a ref or the ref is in the working directory. Ephemeral branch names would be local-only and would never be pushed. For example, if one performed git checkout 2c29d..., one would not get a detached head-state, but instead would get an ephemeral branch name similar to etmp/2c29d If no changes were checked into this ephemeral branch, it would disappear as soon as it was no longer in the working directory. If any changes were checked in on this branch, it would survive until (a) the ref is given a non-ephemeral branch name, (b) the changes are merged, (c) the ephemeral branch is deleted/discarded. I'm asking about (and proposing) this mechanism, because it would prevent refs from ever being accidentally lost, such as occurs in the following scenerios.. 1) forgetting to branch a detached head before checkin 2) forgetting a head is detached before moving away from it 3) forgetting about checkins before a submodule update Also, these etmp/ branches would serve as an obvious visible reminder in the branch list that a change was checked in that should either be merged, named, or discarded. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] t3404: restore specialized rebase-editor following commentchar test
On Mon, Aug 12, 2013 at 2:28 AM, Junio C Hamano gits...@pobox.com wrote: Eric Sunshine sunsh...@sunshineco.com writes: At start of script, t3404 installs a specialized test-editor ($EDITOR) upon which many of the interactive rebase tests depend. Late in t3404, test rebase -i respects core.commentchar installs its own custom editor but neglects to restore the specialized editor when finished. This oversight will cause later tests, which require the specialized editor, to fail. That is not oversight but was deliberately done knowing that it will be the last test (and new tests can be added before it). There is no mention of this being deliberate either in the mailing list discussion [1] or the commit message (180bad3d1), and other tests have been added following this one. [1]: http://thread.gmane.org/gmane.comp.version-control.git/216079 I think the patch is one way to give _known_ status to later tests by declaring the editor installed by set_fake_editor the gold standard, but isn't a better alternative to make sure that any newly added tests after this point (or before the commentchar tests, for that matter) set a fake editor it wants to use explicitly? set_fake_editor is the very first thing done by t3404, and many tests depend upon this state. It would have been inconsistent for this one new test to be the exception by having to invoke set_fake_editor itself, however, I don't mind making the new test more self-contained, despite the inconsistency. (A later cleanup patch can do the same for other existing tests.) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git-po] [fr] first commits for French localization (#62)
Hi, Junio Haven't seen new languages support for git l10n for over 1 year. Here comes French translation. Please pull the following updates from Jean-Noel Avila. The following changes since commit 96cb27a9d2db3c01b8e296a0fbc1da1da09d1412: Merge branch 'maint' (2013-08-09 15:49:55 -0700) are available in the git repository at: git://github.com/git-l10n/git-po master for you to fetch changes up to 1b5f46f15917fc938c219732fe5ec6a45748f1f7: l10n: Add reference for french translation team (2013-08-11 17:14:58 +0200) Jean-Noel Avila (2): l10n: fr.po: 821/2112 messages translated l10n: Add reference for french translation team po/TEAMS |4 + po/fr.po | 9668 ++ 2 files changed, 9672 insertions(+) create mode 100644 po/fr.po -- Jiang Xin -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ephemeral-branches instead of detached-head?
David Jeske wrote: Ephemeral branch names would be local-only and would never be pushed. That's how normal branch names behave (local branch names and remote branch names live in different namespaces). How would the proposed detached HEAD replacement compare to them? Would the temporary branch created by checking out a random commit be automatically deleted when checking out another branch, or would it be garbage-collected at some point later? Curious, Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] t3404: rebase: interactive: demonstrate short SHA-1 collision
On Mon, Aug 12, 2013 at 2:31 AM, Junio C Hamano gits...@pobox.com wrote: Eric Sunshine sunsh...@sunshineco.com writes: The 'todo' sheet for interactive rebase shows abbreviated SHA-1's and then performs its operations upon those shortened values. This can lead to an abort if the SHA-1 of a reworded or edited commit is no longer unique within the abbreviated SHA-1 space and a subsequent SHA-1 in the todo list has the same abbreviated value. For example: edit f00dfad first pick badbeef second If, after editing, the new SHA-1 of first is now badbeef5ba78983324dff5265c80c4490d5a809a, then the subsequent 'pick badbeef second' will fail since badbeef is no longer a unique SHA-1 abbreviation: error: short SHA1 badbeef is ambiguous. fatal: Needed a single revision Invalid commit name: badbeef Demonstrate this problem with a couple of specially crafted commits which initially have distinct abbreviated SHA-1's, but for which the abbreviated SHA-1's collide after a simple rewording of the first commit's message. Signed-off-by: Eric Sunshine sunsh...@sunshineco.com --- t/t3404-rebase-interactive.sh | 17 + 1 file changed, 17 insertions(+) diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh index af141be..e5ebec6 100755 --- a/t/t3404-rebase-interactive.sh +++ b/t/t3404-rebase-interactive.sh @@ -977,4 +977,21 @@ test_expect_success 'rebase -i with --strategy and -X' ' test $(cat file1) = Z ' +test_expect_success 'short SHA-1 setup' ' + test_when_finished git checkout master + git checkout --orphan collide + git rm -rf . + unset test_tick This will inconvenience tests added later to these two in the future. Oversight, or deliberate act knowing that these two are the last tests in this script ;-)? One bad thing is that unset loses information so that such future tests cannot resurrect test_tick and continue on from where the last test-tick left off. Oversight. The commits were quite deliberately crafted with very specific commit times, commit messages, trees, and blobs in order to achieve a conflicting short SHA-1 (badbeef) at rebase time, so it was necessary to have test_tick at a known state. It shouldn't be too much effort to save its value and restore it at the end of the test. + test_commit collide1 collide + test_commit --notick collide2 collide + test_commit --notick collide3 115158b5 collide collide3 collide3 +' +test_expect_failure 'short SHA-1 collide' ' + test_when_finished reset_rebase git checkout master + git checkout collide + FAKE_COMMIT_MESSAGE=collide2 815200e \ ;-) + FAKE_LINES=reword 1 2 git rebase -i HEAD~2 +' + test_done -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-p4: Fix occasional truncation of symlink contents.
On 11 August 2013 14:57, Pete Wyckoff p...@padd.com wrote:
al...@rosedu.org wrote on Thu, 08 Aug 2013 16:17 +0300:
Symlink contents in p4 print sometimes have a trailing
new line character, but sometimes it doesn't. git-p4
should only remove the last character if that character
is '\n'.
Your patch looks fine, and harmless if symlinks continue
to have \n on the end. I'd like to understand a bit why
this behavior is different for you, though. Could you do
this test on a symlink in your depot?
Here //depot/symlink points to symlink-target. You can
see the \n in position 0o332 below. What happens on a
symlink in your repo?
arf-git-test$ p4 fstat //depot/symlink
... depotFile //depot/symlink
... clientFile /dev/shm/trash directory.t9802-git-p4-filetype/cli/symlink
... isMapped
... headAction add
... headType symlink
... headTime 1376221978
... headRev 1
... headChange 6
... headModTime 1376221978
... haveRev 1
arf-git-test$ p4 -G print //depot/symlink | od -c
000 { s 004 \0 \0 \0 c o d e s 004 \0 \0 \0 s
020 t a t s \t \0 \0 \0 d e p o t F i l
040 e s 017 \0 \0 \0 / / d e p o t / s y
060 m l i n k s 003 \0 \0 \0 r e v s 001 \0
100 \0 \0 1 s 006 \0 \0 \0 c h a n g e s 001
120 \0 \0 \0 6 s 006 \0 \0 \0 a c t i o n s
140 003 \0 \0 \0 a d d s 004 \0 \0 \0 t y p e
160 s \a \0 \0 \0 s y m l i n k s 004 \0 \0
200 \0 t i m e s \n \0 \0 \0 1 3 7 6 2 2
220 1 9 7 8 s \b \0 \0 \0 f i l e S i z
240 e s 002 \0 \0 \0 1 5 0 { s 004 \0 \0 \0 c
260 o d e s 006 \0 \0 \0 b i n a r y s 004
300 \0 \0 \0 d a t a s 017 \0 \0 \0 s y m l
320 i n k - t a r g e t \n 0 { s 004 \0
340 \0 \0 c o d e s 006 \0 \0 \0 b i n a r
360 y s 004 \0 \0 \0 d a t a s \0 \0 \0 \0 0
400
Also, what version is your server, from p4 info:
Server version: P4D/LINUX26X86_64/2013.1/610569 (2013/03/19)
-- Pete
Hello!
Let me give you an example. Here are the links as resulted in the git
p4 clone (one was correct, one wasn't):
./lib/update.sh - ../update.sh
./apps/update.sh - ../update.s
alexj@ixro-alexj ~/perforce $ p4 print path/lib/update.sh
//path/update.sh#6 - edit change 119890 (symlink)
../update.sh
alexj@ixro-alexj ~/perforce $ p4 print path/apps/update.sh
//path/apps/update.sh#144 - edit change 116063 (symlink)
../update.shalexj@ixro-alexj ~/perforce/unstable $
Notice the output and the prompt.
(I removed the exact path to the file from the output)
The fstat output is kind of irrelevant, but the hexdump shows the missing \n:
p4 -G print lib/update.sh|od -c
360 t e . s h \n 0
p4 -G print apps/update.sh|od -c
360 p d a t e . s h 0
Server version: P4D/LINUX26X86_64/2013.1/610569
Signed-off-by: Alex Juncu aju...@ixiacom.com
Signed-off-by: Alex Badea aba...@ixiacom.com
---
git-p4.py | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/git-p4.py b/git-p4.py
index 31e71ff..a53a6dc 100755
--- a/git-p4.py
+++ b/git-p4.py
@@ -2180,9 +2180,13 @@ class P4Sync(Command, P4UserMap):
git_mode = 100755
if type_base == symlink:
git_mode = 12
-# p4 print on a symlink contains target\n; remove the newline
+# p4 print on a symlink sometimes contains target\n;
+# if it does, remove the newline
data = ''.join(contents)
-contents = [data[:-1]]
+if data[-1] == '\n':
+contents = [data[:-1]]
+else:
+contents = [data]
if type_base == utf16:
# p4 delivers different text in the python output to -G
--
1.8.4.rc0.1.g8f6a3e5
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] whatchanged: document its historical nature
On Fri, Aug 09, 2013 at 01:57:19PM -0700, Junio C Hamano wrote: John Keeping j...@keeping.me.uk writes: +New users are encouraged to use linkgit:git-log[1] instead. The +`whatchanged` command is essentially the same as linkgit:git-log[1] +run with different defaults that shows a --raw diff outputat the s/outputat/output at/ Thanks. Although I wonder if it would be better to say New users are encouraged to use linkgit:git-log[1] instead. The `whatchanged` command is essentially the same as linkgit:git-log[1] with the `--raw` option specified. But that is different from the truth, no? git whatchanged -p will not behave as if git whatchanged -p with the --raw specified. The 'raw' kicks in only as a default. Hmm, I hadn't realised that specifying -p would disable the --raw. I still find the last sentence of the original patch slightly awkward though. How about New users are encouraged to use linkgit:git-log[1] instead. The `whatchanged` command is essentially the same as linkgit:git-log[1] but defaults to ``raw'' diff output and does not show merge commits. ? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ephemeral-branches instead of detached-head?
David Jeske dav...@gmail.com writes: I'm asking about (and proposing) this mechanism, because it would prevent refs from ever being accidentally lost, such as occurs in the following scenerios.. 1) forgetting to branch a detached head before checkin 2) forgetting a head is detached before moving away from it 3) forgetting about checkins before a submodule update As Jonathan mentioned, your local branch namespace _is_ ephemeral in the larger picture, and you can and should use your regular branches as such. I do not think any of the above will be helped by truly epheral branch that are not consciously named by the end user. (1) is not a problem at all by itself with detached HEAD. You can commit all you want, and the true problem people perceive that comes from (1) is (2), as they think they would lose commit that way. But the thing is, the commits are not lost---they are recoverable from the reflog of the HEAD itself. A truely ephemeral branch that users do not consciously name would be referred to some random string (your etmp/4324 below) that is just as discoverable as an entry in the reflog of the HEAD, so you didn't solve any problem here. I am not sure what you are trying to improve with (3) but I suspect it is just the same issue between (1) and (2) in the submodule working tree. After running a submodule update in the superproject, you will get into the detached HEAD state in the submodule, and that state by itself is not a problem at all, but after committing and then switching to other branch (or to another commit), the history leading to the tip commit will not be at the tip of any meaningfully named branch. That is different from a commit getting lost, and I do not see how ephemerally created branches with random names would help people discover these commits better compared to reflog for the HEAD. Also, these etmp/ branches would serve as an obvious visible reminder in the branch list that a change was checked in that should either be merged, named, or discarded. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] .mailmap: mark bouncing email addresses
Junio C Hamano gits...@pobox.com writes: I'd suggest using the lavabit address unless we hear the preferred address from her, as the lavabit address was used in 5bf46841 (git-gui: update Japanese translation, 2010-02-02), while the last use of the bluebottle address was in 6762079a (Cloning from a repo without current branch, 2007-06-16). So with the above, and the four responses from long-lost friends, here is what I came up with. -- 8 -- Subject: .mailmap: update long-lost friends with multiple defunct addresses A handful of past contributors are recorded with multiple e-mail addresses, all of which are undeliberable. With a lot of help from Jonathan, we located all of them except for one. Update the found ones with their currently preferred address, and use the last known address to consolidate contributions by the lost person under a single entry. Helped-by: Stefan Beller stefanbel...@googlemail.com Helped-by: Jonathan Nieder jrnie...@gmail.com Signed-off-by: Junio C Hamano gits...@pobox.com --- .mailmap | 14 +- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/.mailmap b/.mailmap index f7cc21e..7a5d0a6 100644 --- a/.mailmap +++ b/.mailmap @@ -18,6 +18,8 @@ Alexey Shumkin alex.crez...@gmail.com alex.crez...@gmail.com Anders Kaseorg ande...@mit.edu ande...@ksplice.com Anders Kaseorg ande...@mit.edu ande...@mit.edu Aneesh Kumar K.V aneesh.ku...@gmail.com +Amos Waterland a...@debian.org a...@rossby.metr.ou.edu +Amos Waterland a...@debian.org a...@us.ibm.com Ben Walton bdwal...@gmail.com bwal...@artsci.utoronto.ca Bernt Hansen be...@norang.ca be...@alumni.uwaterloo.ca Brandon Casey draf...@gmail.com ca...@nrlssc.navy.mil @@ -34,6 +36,8 @@ Dan Johnson computerdr...@gmail.com Dana L. How dana...@gmail.com h...@deathvalley.cswitch.com Dana L. How dana...@gmail.com Dana How Daniel Barkalow barka...@iabervon.org +Daniel Trstenjak daniel.trsten...@gmail.com daniel.trsten...@online.de +Daniel Trstenjak daniel.trsten...@gmail.com trs...@science-computing.de David Brown g...@davidb.org dav...@quicinc.com David D. Kilzer ddkil...@kilzer.net David Kågedal dav...@lysator.liu.se @@ -68,11 +72,17 @@ J. Bruce Fields bfie...@citi.umich.edu bfie...@pig.linuxdev.us.dell.com J. Bruce Fields bfie...@citi.umich.edu bfie...@puzzle.fieldses.org Jakub Narębski jna...@gmail.com James Y Knight jkni...@itasoftware.com f...@fuhm.net +# The 2 following authors are probably the same person, +# but both emails bounce. +Jason McMullan jason.mcmul...@timesys.com +Jason McMullan mcmul...@netapp.com Jason Riedy e...@eecs.berkeley.edu e...@eecs.berkeley.edu Jason Riedy e...@eecs.berkeley.edu e...@cs.berkeley.edu Jay Soffian jaysoff...@gmail.com jaysoffian+...@gmail.com Jeff King p...@peff.net p...@github.com Jeff Muizelaar jmuizel...@mozilla.com j...@infidigm.net +Jens Axboe ax...@kernel.dk ax...@suse.de +Jens Axboe ax...@kernel.dk jens.ax...@oracle.com Jim Meyering j...@meyering.net meyer...@redhat.com Joachim Berdal Haga cjh...@fys.uio.no Johannes Schindelin johannes.schinde...@gmx.de johannes.schinde...@gmx.de @@ -144,7 +154,7 @@ Michele Ballabio barra_c...@katamail.com Miklos Vajna vmik...@frugalware.org vmik...@suse.cz Namhyung Kim namhy...@gmail.com namhyung@lge.com Namhyung Kim namhy...@gmail.com namhy...@kernel.org -Nanako Shiraishi nana...@bluebottle.com +Nanako Shiraishi nana...@lavabit.com nana...@bluebottle.com Nanako Shiraishi nana...@lavabit.com Nelson Elhage nelh...@mit.edu nelh...@mit.edu Nelson Elhage nelh...@mit.edu nelh...@ksplice.com @@ -177,6 +187,8 @@ Robert Fitzsimons robf...@273k.net Robert Shearman robertshear...@gmail.com r...@codeweavers.com Robert Zeh robert.a@gmail.com Robin Rosenberg robin.rosenb...@dewire.com robin.rosenberg.li...@dewire.com +Rutger Nijlunsing rutger.nijluns...@gmail.com rut...@nospam.com +Rutger Nijlunsing rutger.nijluns...@gmail.com g...@tux.tmfweb.nl Ryan Anderson r...@michonline.com r...@google.com Salikh Zakirov salikh.zaki...@gmail.com salikh.zaki...@intel.com Sam Vilain s...@vilain.net sam.vil...@catalyst.net.nz -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] During a shallow fetch, prevent sending over unneeded objects
Hi Duy, OK. Mathijs, do you want make a patch for it? I'm willing, but: - I don't understand the code and all of your comments well enough yet to start coding right away (though I haven't actually invested enough time in this yet, either). - I'll be on vacation for the next two weeks. When I get back, I'll re-read this thread properly and reply where I don't follow it. Feel free to continue discussing the plan until then, of course :-) Gr. Matthijs -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] .mailmap: mark bouncing email addresses
On 08/12/2013 09:58 AM, Junio C Hamano wrote: Junio C Hamano gits...@pobox.com writes: I'd suggest using the lavabit address unless we hear the preferred address from her, as the lavabit address was used in 5bf46841 (git-gui: update Japanese translation, 2010-02-02), while the last use of the bluebottle address was in 6762079a (Cloning from a repo without current branch, 2007-06-16). So with the above, and the four responses from long-lost friends, here is what I came up with. -- 8 -- Subject: .mailmap: update long-lost friends with multiple defunct addresses A handful of past contributors are recorded with multiple e-mail addresses, all of which are undeliberable. With a lot of help from Jonathan, we located all of them except for one. Update the found ones with their currently preferred address, and use the last known address to consolidate contributions by the lost person under a single entry. Helped-by: Stefan Beller stefanbel...@googlemail.com Helped-by: Jonathan Nieder jrnie...@gmail.com Signed-off-by: Junio C Hamano gits...@pobox.com --- .mailmap | 14 +- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/.mailmap b/.mailmap index f7cc21e..7a5d0a6 100644 --- a/.mailmap +++ b/.mailmap @@ -18,6 +18,8 @@ Alexey Shumkin alex.crez...@gmail.com alex.crez...@gmail.com Anders Kaseorg ande...@mit.edu ande...@ksplice.com Anders Kaseorg ande...@mit.edu ande...@mit.edu Aneesh Kumar K.V aneesh.ku...@gmail.com +Amos Waterland a...@debian.org a...@rossby.metr.ou.edu +Amos Waterland a...@debian.org a...@us.ibm.com Ben Walton bdwal...@gmail.com bwal...@artsci.utoronto.ca Bernt Hansen be...@norang.ca be...@alumni.uwaterloo.ca Brandon Casey draf...@gmail.com ca...@nrlssc.navy.mil @@ -34,6 +36,8 @@ Dan Johnson computerdr...@gmail.com Dana L. How dana...@gmail.com h...@deathvalley.cswitch.com Dana L. How dana...@gmail.com Dana How Daniel Barkalow barka...@iabervon.org +Daniel Trstenjak daniel.trsten...@gmail.com daniel.trsten...@online.de +Daniel Trstenjak daniel.trsten...@gmail.com trs...@science-computing.de David Brown g...@davidb.org dav...@quicinc.com David D. Kilzer ddkil...@kilzer.net David Kågedal dav...@lysator.liu.se @@ -68,11 +72,17 @@ J. Bruce Fields bfie...@citi.umich.edu bfie...@pig.linuxdev.us.dell.com J. Bruce Fields bfie...@citi.umich.edu bfie...@puzzle.fieldses.org Jakub Narębski jna...@gmail.com James Y Knight jkni...@itasoftware.com f...@fuhm.net +# The 2 following authors are probably the same person, +# but both emails bounce. You seemed to be sure about Nanako Shiraishi for example, but here you're uncertain, whether he is one person or 2 persons having the same name? I, as a really new contributor, tried a very conservative approach as specially the mailmap is a sensitive field. So in case you'd know he is one person with just different emails, maybe we could write +Jason McMullan jason.mcmul...@timesys.com mcmul...@netapp.com as it doesn't matter which email comes first (both bounce anyway). +Jason McMullan jason.mcmul...@timesys.com +Jason McMullan mcmul...@netapp.com Jason Riedy e...@eecs.berkeley.edu e...@eecs.berkeley.edu Jason Riedy e...@eecs.berkeley.edu e...@cs.berkeley.edu Jay Soffian jaysoff...@gmail.com jaysoffian+...@gmail.com Jeff King p...@peff.net p...@github.com Jeff Muizelaar jmuizel...@mozilla.com j...@infidigm.net +Jens Axboe ax...@kernel.dk ax...@suse.de +Jens Axboe ax...@kernel.dk jens.ax...@oracle.com Jim Meyering j...@meyering.net meyer...@redhat.com Joachim Berdal Haga cjh...@fys.uio.no Johannes Schindelin johannes.schinde...@gmx.de johannes.schinde...@gmx.de @@ -144,7 +154,7 @@ Michele Ballabio barra_c...@katamail.com Miklos Vajna vmik...@frugalware.org vmik...@suse.cz Namhyung Kim namhy...@gmail.com namhyung@lge.com Namhyung Kim namhy...@gmail.com namhy...@kernel.org -Nanako Shiraishi nana...@bluebottle.com +Nanako Shiraishi nana...@lavabit.com nana...@bluebottle.com Nanako Shiraishi nana...@lavabit.com Nelson Elhage nelh...@mit.edu nelh...@mit.edu Nelson Elhage nelh...@mit.edu nelh...@ksplice.com @@ -177,6 +187,8 @@ Robert Fitzsimons robf...@273k.net Robert Shearman robertshear...@gmail.com r...@codeweavers.com Robert Zeh robert.a@gmail.com Robin Rosenberg robin.rosenb...@dewire.com robin.rosenberg.li...@dewire.com +Rutger Nijlunsing rutger.nijluns...@gmail.com rut...@nospam.com +Rutger Nijlunsing rutger.nijluns...@gmail.com g...@tux.tmfweb.nl Ryan Anderson r...@michonline.com r...@google.com Salikh Zakirov salikh.zaki...@gmail.com salikh.zaki...@intel.com Sam Vilain s...@vilain.net sam.vil...@catalyst.net.nz Ok, I've got more responses, which will follow in the next mail. signature.asc Description: OpenPGP digital signature
Re: [PATCH 2/2] .mailmap: mark bouncing email addresses
Stefan Beller stefanbel...@googlemail.com writes: +# The 2 following authors are probably the same person, +# but both emails bounce. You seemed to be sure about Nanako Shiraishi for example, but here you're uncertain, whether he is one person or 2 persons having the same name? Nanako did 70+ patches, and was on many discussion threads, which made me feel that I was corresponding with the same person across address change. I however cannot recall this contributor with just 3 patches whose last contribution was in 2007. But more importantly, this leftover unreachable comment I did not notice before sending the patch out---I did not send any please ping back message to any suspected current address for this contributor. So in case you'd know he is one person with just different emails, maybe we could write +Jason McMullan jason.mcmul...@timesys.com mcmul...@netapp.com as it doesn't matter which email comes first (both bounce anyway). The last contribution was from netapp.com address in late 2007 (the other address sent two patches in 2005), so I'd suggest making the netapp address the canonical one. If we cannot reach him, that is. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] diff: remove ternary operator evaluating always to true
On 08/12/2013 07:46 AM, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
On Thu, Aug 08, 2013 at 08:31:44PM +0200, Stefan Beller wrote:
The next occurrences are at:
/* Never use a non-valid filename anywhere if at all possible */
name_a = DIFF_FILE_VALID(one) ? name_a : name_b;
name_b = DIFF_FILE_VALID(two) ? name_b : name_a;
a_one = quote_two(a_prefix, name_a + (*name_a == '/'));
b_two = quote_two(b_prefix, name_b + (*name_b == '/'));
In the last line of this block 'name_b' is dereferenced and compared
to '/'. This would crash if name_b was NULL. Hence in the following code
we can assume name_b being non-null.
I think your change is correct, but I find the reasoning above a little
suspect. It assumes that the second chunk of code (accessing name_a and
name_b) is correct, and pins the correctness of the code you are
changing to it. If the second chunk is buggy, then you are actually
making the code worse.
True. I think the original code structure design is name_a should
always exist but name_b may not (the caller of run_diff_cmd() that
eventually calls this call these name and other, and the intent
is renaming filepair is what needs other).
I wonder if the implicit expectation of the function to take at least
one non-NULL name would be more obvious if the first few lines were
written as:
if (DIFF_FILE_VALID(one)) {
if (!DIFF_FILE_VALID(two))
name_b = name_a;
} else if (DIFF_FILE_VALID(two))
name_a = name_b;
else
die(BUG: two invalid files to diff);
That covers all of the cases explicitly, though it is IMHO uglier to
read (and there is still an implicit assumption that the name is
non-NULL if DIFF_FILE_VALID() is true).
I think that is an overall improvement, especially if we also update
the checks of {one,two}-mode made for the block that deals with
submodules to use DIFF_FILE_VALID().
Thanks.
So, do I understand your reasoning, when proposing this patch?
(This may break whitespaces as it's copied into my MUA, will resend with
git send-mail if you think this is the right thing.)
This patch just covers your discussion and not the previous patches.
Stefan
--8--
From 701bab4f15598ba230552af7f1d5719187f1b2e8 Mon Sep 17 00:00:00 2001
From: Stefan Beller stefanbel...@googlemail.com
Date: Mon, 12 Aug 2013 10:29:07 +0200
Subject: [PATCH] diff: Additional error checking for input parameters
This makes the diff function error out instead of segfaulting if the
parameters are bad.
Helped-by: Jeff King p...@peff.net
Helped-by: Junio C Hamano gits...@pobox.com
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
diff.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/diff.c b/diff.c
index e53ddad..de21971 100644
--- a/diff.c
+++ b/diff.c
@@ -2254,8 +2254,11 @@ static void builtin_diff(const char *name_a,
(!two-mode || S_ISGITLINK(two-mode))) {
const char *del = diff_get_color_opt(o, DIFF_FILE_OLD);
const char *add = diff_get_color_opt(o, DIFF_FILE_NEW);
- show_submodule_summary(o-file, one ? one-path : two-path,
- line_prefix,
+ struct diff_filespec *spec = one DIFF_FILE_VALID(one) ? one
: two;
+ if (!spec !DIFF_FILE_VALID(spec))
+ die(BUG: two invalid diff_filespec structs in diff);
+
+ show_submodule_summary(o-file, spec-path, line_prefix,
one-sha1, two-sha1, two-dirty_submodule,
meta, del, add, reset);
return;
@@ -2276,8 +2279,13 @@ static void builtin_diff(const char *name_a,
}
/* Never use a non-valid filename anywhere if at all possible */
- name_a = DIFF_FILE_VALID(one) ? name_a : name_b;
- name_b = DIFF_FILE_VALID(two) ? name_b : name_a;
+ if (DIFF_FILE_VALID(one)) {
+ if (!DIFF_FILE_VALID(two))
+ name_b = name_a;
+ } else if (DIFF_FILE_VALID(two))
+ name_a = name_b;
+ else
+ die(BUG: two invalid files to diff);
a_one = quote_two(a_prefix, name_a + (*name_a == '/'));
b_two = quote_two(b_prefix, name_b + (*name_b == '/'));
--
1.8.4.rc2
signature.asc
Description: OpenPGP digital signature
Re: ephemeral-branches instead of detached-head?
Would the temporary branch created by checking out a random commit be automatically deleted when checking out another branch, or would it be garbage-collected at some point later? Yes, as I stated in my example, the ephemeral branch created from checking out a random commit would be automatically deleted anytime there was another downstream name for the ref (and the ref was no longer in the working-directory). Another way to think of the proposal is to allowed detached-HEADs, but automatically create ephemeral branch-names when checking into a detached head. On Mon, Aug 12, 2013 at 12:55 AM, Junio C Hamano gits...@pobox.com wrote: As Jonathan mentioned, your local branch namespace _is_ ephemeral in the larger picture, and you can and should use your regular branches as such. This is not the case. To me ephemeral means that the branch name automatically disappears if nothing gets checked into it. The local branch names definitely do not operate this way. (1) is not a problem at all by itself with detached HEAD. You can commit all you want, and the true problem people perceive that comes from (1) is (2), as they think they would lose commit that way. It is not a matter of a commit being destroyed, as I know they are not destroyed, it is a matter of losing as in it being a pain-in-the-a-s-s to find the darn thing. The reflog is only really useful for a short time. If you don't notice until later, it's too late for this to be a reasonable way to find the missing commit.. and this assumes you noticed at all. For as long as I've used git, I simplu don't understand why I should be able to commit something, and have it go missing in the branch namespace without an explicit action on my part. A truely ephemeral branch that users do not consciously name would be referred to some random string (your etmp/4324 below) that is just as discoverable as an entry in the reflog of the HEAD, so you didn't solve any problem here. This is simply not true. The reflog is filled with every reflog action. Any checkout, push, pull, existing commits, etc. The ephemeral space would *only* contain dangling refs that were not named, merged, or discarded. ...the history leading to the tip commit will not be at the tip of any meaningfully named branch. That is different from a commit getting lost, and I do not see how ephemerally created branches with random names would help people discover these commits better compared to reflog for the HEAD. Is there currently any way to say hey, git, show me what commits are dangling that might be lost in the reflog? I'm not aware of one. This is the difference. It's making the action of throwing away a dangling ref more explicit. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] diff: remove ternary operator evaluating always to true
On 08/12/2013 10:32 AM, Stefan Beller wrote:
diff --git a/diff.c b/diff.c
index e53ddad..de21971 100644
--- a/diff.c
+++ b/diff.c
@@ -2254,8 +2254,11 @@ static void builtin_diff(const char *name_a,
(!two-mode || S_ISGITLINK(two-mode))) {
const char *del = diff_get_color_opt(o, DIFF_FILE_OLD);
const char *add = diff_get_color_opt(o, DIFF_FILE_NEW);
- show_submodule_summary(o-file, one ? one-path : two-path,
- line_prefix,
+ struct diff_filespec *spec = one DIFF_FILE_VALID(one) ? one
: two;
+ if (!spec !DIFF_FILE_VALID(spec))
+ die(BUG: two invalid diff_filespec structs in diff);
+
+ show_submodule_summary(o-file, spec-path, line_prefix,
one-sha1, two-sha1, two-dirty_submodule,
meta, del, add, reset);
return;
This doesn't make sense, as we're definitely dereferencing both
one and two with -sha1, so we do not need the one and the
!spec .
I think the originally sent patches are correct, but the commit
message may need rewriting to comply with Jeffs nitpicking.
signature.asc
Description: OpenPGP digital signature
Re: Huge possible memory leak while cherry-picking.
Thank you, it works very well! Will this patch go to upstream? Also, there is still some unexpected memory consumption - about 2Gb per ~200 commits, but it's bearable. I will do a futher investigation. Felipe, should I exclude you from my futher reports on possible memory leaks? On 10 August 2013 00:39, Felipe Contreras felipe.contre...@gmail.com wrote: On Fri, Aug 9, 2013 at 7:13 AM, Лежанкин Иван abys...@gmail.com wrote: I have tried to cherry-pick a range of ~200 commits from one branch to another. And you can't imagine how I was surprised when the git process ate 8 Gb of RAM and died - before cherry-picking was complete. Try this: http://article.gmane.org/gmane.comp.version-control.git/226757 -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Huge possible memory leak while cherry-picking.
On Mon, Aug 12, 2013 at 5:04 AM, Лежанкин Иван abys...@gmail.com wrote: Thank you, it works very well! Will this patch go to upstream? Ask Junio. Also, there is still some unexpected memory consumption - about 2Gb per ~200 commits, but it's bearable. I will do a futher investigation. Can you post some valgrind log? Or even better, a way to reproduce? Felipe, should I exclude you from my futher reports on possible memory leaks? Exclude me? -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Huge possible memory leak while cherry-picking.
On Mon, Aug 12, 2013 at 5:04 AM, Лежанкин Иван abys...@gmail.com wrote: Thank you, it works very well! Will this patch go to upstream? Ask Junio. Also, there is still some unexpected memory consumption - about 2Gb per ~200 commits, but it's bearable. I will do a futher investigation. Can you post some valgrind log? Or even better, a way to reproduce? Felipe, should I exclude you from my futher reports on possible memory leaks? Exclude me? -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] push: respect --no-thin
On Mon, Aug 12, 2013 at 12:59 PM, Junio C Hamano gits...@pobox.com wrote:
@@ -15,7 +15,7 @@ static const char * const push_usage[] = {
NULL,
};
-static int thin;
+static int thin = 1;
static int deleterefs;
static const char *receivepack;
static int verbosity;
@@ -313,8 +313,7 @@ static int push_with_options(struct transport
*transport, int flags)
if (receivepack)
transport_set_option(transport,
TRANS_OPT_RECEIVEPACK, receivepack);
- if (thin)
- transport_set_option(transport, TRANS_OPT_THIN, yes);
+ transport_set_option(transport, TRANS_OPT_THIN, thin ? yes : NULL);
if (verbosity 0)
fprintf(stderr, _(Pushing to %s\n), transport-url);
Hmm, I am utterly confused.
How does the original code have thin as an non-overridable default?
The variable is initialized to 0, parse-options specifies it as
OPT_BOOLEAN, and TRANS_OPT_THIN is set only if thin is set.
Updated code flips the default to 1 but unconditionally uses
TRANS_OPT_THIN to set it to either yes or NULL. While it is not
wrong per-se, do_push() (i.e. the caller of this function) grabs the
transport from transport_get() which initializes the transport with
the thin option disabled by default,
transport_get() actually sets thin option to 1 by default. If I don't
misread the code, the first version of transport.c already flipped
thin from 0 (in push.c) to 1 (in transport.c), see 9b28851 (Push
code for transport library - 2007-09-10). The funny thing is that
commit was just one day after Shawn flipped 'thin' from 1 to 0 in
push.c in a4503a1.
so it is not immediately
obvious to me why always call TRANS_OPT_THIN but set it explicitly
to NULL when --no-thin is asked is necessary or improvement.
--
Duy
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git should not use a default user.email config value
On 11 August 2013 02:58, Junio C Hamano gits...@pobox.com wrote: Perhaps we need a lighter-weight mechanism git init --profile=open git clone --profile=open git://git.kernel.org/git.git This is something I would definitely use. All of my work git directories are in a separate folder to my other git directories, and as such it would be extremely convenient if every repository under that folder defaulted to the same profile. That may be asking for too much though! Regards, Andrew Ardill -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ephemeral-branches instead of detached-head?
@Junio - to put the issue in the context of your previous comments on the topic... way back when you made a comment about warnings during commits to detached heads.. http://git.661346.n2.nabble.com/RFC-Detached-HEAD-reminder-on-commit-td834710.html#a834959 If we _really_ don't want newbies to shoot themselves in the foot, we probably can issue a loud warning when they detach there HEAD. Oh, wait,... we already do that. The reason this rationale doesn't ring true for me, is that it is *very* common for me to checkout a detached-head and there is nothing odd or dangerous about it. I do this when using checkout to move around the history to inspect, build, and test different revisions. As a result, it's very easy to just start ignoring this (usually meaningless) message. The dangerous situation only occurs when something is committed onto a detached-head, and at this point there is no warning. The # Not currently on any branch message that appears during git status easily blends in with boilerplate text there. IMO, the current warning during checkout of a detached-head is misplaced. It should be removed, and instead there should only be a warning after detached-head commit, since this is the only time there is a danger of losing something. With my proposed ephemeral branch concept, there is no warning necessary in either case, since any check-ins left dangling would get names in the branch space you could see and take a look at. If that dangling head was temporary and was named or rebased, the ephemeral branch name would disappear automatically, leaving the expert-user with no warnings and no annoyance, while the novice user with a simple tool to help them not lose track of changes they made. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-p4: Fix occasional truncation of symlink contents.
al...@rosedu.org wrote on Mon, 12 Aug 2013 10:46 +0300:
On 11 August 2013 14:57, Pete Wyckoff p...@padd.com wrote:
al...@rosedu.org wrote on Thu, 08 Aug 2013 16:17 +0300:
Symlink contents in p4 print sometimes have a trailing
new line character, but sometimes it doesn't. git-p4
should only remove the last character if that character
is '\n'.
Your patch looks fine, and harmless if symlinks continue
to have \n on the end. I'd like to understand a bit why
this behavior is different for you, though. Could you do
this test on a symlink in your depot?
Here //depot/symlink points to symlink-target. You can
see the \n in position 0o332 below. What happens on a
symlink in your repo?
arf-git-test$ p4 fstat //depot/symlink
... depotFile //depot/symlink
... clientFile /dev/shm/trash
directory.t9802-git-p4-filetype/cli/symlink
... isMapped
... headAction add
... headType symlink
... headTime 1376221978
... headRev 1
... headChange 6
... headModTime 1376221978
... haveRev 1
arf-git-test$ p4 -G print //depot/symlink | od -c
000 { s 004 \0 \0 \0 c o d e s 004 \0 \0 \0 s
020 t a t s \t \0 \0 \0 d e p o t F i l
040 e s 017 \0 \0 \0 / / d e p o t / s y
060 m l i n k s 003 \0 \0 \0 r e v s 001 \0
100 \0 \0 1 s 006 \0 \0 \0 c h a n g e s 001
120 \0 \0 \0 6 s 006 \0 \0 \0 a c t i o n s
140 003 \0 \0 \0 a d d s 004 \0 \0 \0 t y p e
160 s \a \0 \0 \0 s y m l i n k s 004 \0 \0
200 \0 t i m e s \n \0 \0 \0 1 3 7 6 2 2
220 1 9 7 8 s \b \0 \0 \0 f i l e S i z
240 e s 002 \0 \0 \0 1 5 0 { s 004 \0 \0 \0 c
260 o d e s 006 \0 \0 \0 b i n a r y s 004
300 \0 \0 \0 d a t a s 017 \0 \0 \0 s y m l
320 i n k - t a r g e t \n 0 { s 004 \0
340 \0 \0 c o d e s 006 \0 \0 \0 b i n a r
360 y s 004 \0 \0 \0 d a t a s \0 \0 \0 \0 0
400
Also, what version is your server, from p4 info:
Server version: P4D/LINUX26X86_64/2013.1/610569 (2013/03/19)
-- Pete
Hello!
Let me give you an example. Here are the links as resulted in the git
p4 clone (one was correct, one wasn't):
./lib/update.sh - ../update.sh
./apps/update.sh - ../update.s
alexj@ixro-alexj ~/perforce $ p4 print path/lib/update.sh
//path/update.sh#6 - edit change 119890 (symlink)
../update.sh
alexj@ixro-alexj ~/perforce $ p4 print path/apps/update.sh
//path/apps/update.sh#144 - edit change 116063 (symlink)
../update.shalexj@ixro-alexj ~/perforce/unstable $
Notice the output and the prompt.
(I removed the exact path to the file from the output)
The fstat output is kind of irrelevant, but the hexdump shows the missing \n:
p4 -G print lib/update.sh|od -c
360 t e . s h \n 0
p4 -G print apps/update.sh|od -c
360 p d a t e . s h 0
I had forgotten, in fact, another thread on this very topic:
http://thread.gmane.org/gmane.comp.version-control.git/221500
Now with your evidence, I think we can decide that no matter how
the symlink managed to sneak into p4d, git p4 should be able to
handle it.
The only problem is that due to the \n ambiguity, in your setup
where p4d loses the \n, git p4 will not handle symlinks with a
target that ends with a newline, e.g.:
symlink(foo\n, bar);
But the small chance of someone actually doing that, coupled with
the fact that for you git p4 is unusable with these symlinks,
says we should go ahead and make the change.
You should send the patch to junio for inclusion in pu/ for the
next release, with:
Acked-by: Pete Wyckoff p...@padd.com
Thanks for fixing this!
-- Pete
Server version: P4D/LINUX26X86_64/2013.1/610569
Signed-off-by: Alex Juncu aju...@ixiacom.com
Signed-off-by: Alex Badea aba...@ixiacom.com
---
git-p4.py | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/git-p4.py b/git-p4.py
index 31e71ff..a53a6dc 100755
--- a/git-p4.py
+++ b/git-p4.py
@@ -2180,9 +2180,13 @@ class P4Sync(Command, P4UserMap):
git_mode = 100755
if type_base == symlink:
git_mode = 12
-# p4 print on a symlink contains target\n; remove the
newline
+# p4 print on a symlink sometimes contains target\n;
+# if it does, remove the newline
data = ''.join(contents)
-contents = [data[:-1]]
+if data[-1] == '\n':
+
Re: git should not use a default user.email config value
On Mon, Aug 12, 2013 at 09:52:45PM +1000, Andrew Ardill wrote:
On 11 August 2013 02:58, Junio C Hamano gits...@pobox.com wrote:
Perhaps we need a lighter-weight mechanism
git init --profile=open
git clone --profile=open git://git.kernel.org/git.git
This is something I would definitely use.
All of my work git directories are in a separate folder to my other
git directories, and as such it would be extremely convenient if every
repository under that folder defaulted to the same profile. That may
be asking for too much though!
We could do something like the patch below, which allows:
$ git config --global include./magic/.path .gitconfig-magic
to read ~/.gitconfig-magic only when we are in a repository with a
directory component /magic/.
I can see how such a thing might be useful, even though I do not have a
use for that much flexibility myself. I find myself doing this trick for
things like editor settings, but not for git config. So do not count
this necessarily as a vote for doing this; it was a fun exercise for me
that others might find useful.
Comparing this against a profile type of solution:
1. This handles only config, not full templates (so no custom hooks;
however, we could provide a level of indirection for hooks inside
the config).
2. Unlike a profile that is used during repository init, this is
resolved at runtime, so it keeps up to date as you change
~/.gitconfig-magic.
---
diff --git a/config.c b/config.c
index e13a7b6..a31dc85 100644
--- a/config.c
+++ b/config.c
@@ -119,10 +119,45 @@ int git_config_include(const char *var, const char
*value, void *data)
return ret;
}
+static NORETURN void die_bad_regex(int err, regex_t *re)
+{
+ char errbuf[1024];
+ regerror(err, re, errbuf, sizeof(errbuf));
+ if (cf cf-name)
+ die(bad regex (at %s:%d): %s, cf-name, cf-linenr, errbuf);
+ else
+ die(bad regex: %s, errbuf);
+}
+
+static int match_repo_path(const char *re_str)
+{
+ regex_t re;
+ int ret;
+ const char *repo_path;
+
+ ret = regcomp(re, re_str, REG_EXTENDED);
+ if (ret)
+ die_bad_regex(ret, re);
+
+ repo_path = absolute_path(get_git_dir());
+ ret = regexec(re, repo_path, 0, NULL, 0);
+ regfree(re);
+ return !ret;
+}
+
+static int match_repo_path_mem(const char *re_buf, int len)
+{
+ char *re_str = xmemdupz(re_buf, len);
+ int ret = match_repo_path(re_str);
+ free(re_str);
+ return ret;
+}
+
int git_config_include(const char *var, const char *value, void *data)
{
struct config_include_data *inc = data;
- const char *type;
+ const char *match, *type;
+ int match_len;
int ret;
/*
@@ -133,8 +168,9 @@ int git_config_include(const char *var, const char *value,
void *data)
if (ret 0)
return ret;
- type = skip_prefix(var, include.);
- if (!type)
+ if (parse_config_key(var, include, match, match_len, type))
+ return ret;
+ if (match !match_repo_path_mem(match, match_len))
return ret;
if (!strcmp(type, path))
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git should not use a default user.email config value
Jeff King p...@peff.net writes:
On Sat, Aug 10, 2013 at 11:59:21AM +0200, Michael Haggerty wrote:
I intentionally don't set user.email in my ~/.gitconfig because I use
different identities (on the same machine) depending on what project I
am committing to (open-source vs. work). After I clone a repo, I *rely*
on Git reminding me to set user.email on my first commit, because I
invariably forget to set it myself. And for me, *any* universal,
heuristically-determined email address would be wrong for me for at
least some repos.
So if I understand your use case, then you would be even happier if
rather than giving a warning, git simply barfed and said please set
your identity before committing?
I also think it's a bug that git will create commits without an
explicitly-set author. I've seen multiple cases of the author being
something unreasonable in a shared/official repository because of this.
One was a person's personal email address on a work-repo commit,
apparently because on Mac there was some magic extraction of primary
email address from Mail.app (but I'm not 100% clear on what happened).
If name/mail are not explicitly set, failing and making the user set
them seems like the right thing.
I find all the discussion of /etc/mailname to be a bit perplexing. The
notion that the externally-visible email of a person making a commit
should be the same as if they sent mail from that machine seems to be a
bit of a stretch. And their username might be different. I don't think
it's possible to reliably figure out what ought to be in the git author
field.
Another reason to fail rather than use a possibly-wrong default is that
it's very difficult (if not impossible, depending on local CM policy
about forced updates in shared repos) to recover from pushing a commit
with a bad email address. (And the people that don't set their email
right are the same people that won't run git log -p @{u}.. before
pushing.) But failing and having to set it manually is easy (people who
are already competent will be slowed down a minute or two, and the
others need to learn anyway), results in something that should have been
done anyway, and has no long-term negative consequences.
pgpGtvyDdMd2C.pgp
Description: PGP signature
Re: git should not use a default user.email config value
On 08/12/2013 02:39 PM, Jeff King wrote:
On Mon, Aug 12, 2013 at 09:52:45PM +1000, Andrew Ardill wrote:
On 11 August 2013 02:58, Junio C Hamano gits...@pobox.com wrote:
Perhaps we need a lighter-weight mechanism
git init --profile=open
git clone --profile=open git://git.kernel.org/git.git
This is something I would definitely use.
All of my work git directories are in a separate folder to my other
git directories, and as such it would be extremely convenient if every
repository under that folder defaulted to the same profile. That may
be asking for too much though!
We could do something like the patch below, which allows:
$ git config --global include./magic/.path .gitconfig-magic
to read ~/.gitconfig-magic only when we are in a repository with a
directory component /magic/.
I can see how such a thing might be useful, even though I do not have a
use for that much flexibility myself. I find myself doing this trick for
things like editor settings, but not for git config. So do not count
this necessarily as a vote for doing this; it was a fun exercise for me
that others might find useful.
We could satisfy a whole class of wishes by supporting
user-wide/system-wide git hooks like
~/.githooks/{pre,post}-clone /etc/githooks/{pre,post}-clone
~/.githooks/{pre,post}-init /etc/githooks/{pre,post}-init
I suppose similar functionality could be implemented via git aliases,
but hook scripts are easier to install and share.
Michael
--
Michael Haggerty
mhag...@alum.mit.edu
http://softwareswirl.blogspot.com/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git should not use a default user.email config value
On 12 August 2013 22:39, Jeff King p...@peff.net wrote: We could do something like the patch below, which allows: $ git config --global include./magic/.path .gitconfig-magic to read ~/.gitconfig-magic only when we are in a repository with a directory component /magic/. Thanks, this looks great! I'll have a play with it tomorrow. Would locally configured config options override this one? From a quick read of the patch there doesn't look like there is a way of turning this off for a specific repository, but perhaps that is unnecessary. I think after a bit of use the edge cases will be a bit clearer. Again thanks, this will scratch an itch I didn't even realise I had. Regards, Andrew Ardill -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ephemeral-branches instead of detached-head?
On Mon, Aug 12, 2013 at 7:14 PM, David Jeske dav...@gmail.com wrote: IMO, the current warning during checkout of a detached-head is misplaced. It should be removed, and instead there should only be a warning after detached-head commit, since this is the only time there is a danger of losing something. That would annoy me as I often work on top of detached HEAD on purpose and only create a branch when I want to save something. If the warning is to be moved, it should warn at the next checkout. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-p4: Fix occasional truncation of symlink contents.
On 12 August 2013 15:38, Pete Wyckoff p...@padd.com wrote:
al...@rosedu.org wrote on Mon, 12 Aug 2013 10:46 +0300:
On 11 August 2013 14:57, Pete Wyckoff p...@padd.com wrote:
al...@rosedu.org wrote on Thu, 08 Aug 2013 16:17 +0300:
Symlink contents in p4 print sometimes have a trailing
new line character, but sometimes it doesn't. git-p4
should only remove the last character if that character
is '\n'.
Your patch looks fine, and harmless if symlinks continue
to have \n on the end. I'd like to understand a bit why
this behavior is different for you, though. Could you do
this test on a symlink in your depot?
Here //depot/symlink points to symlink-target. You can
see the \n in position 0o332 below. What happens on a
symlink in your repo?
arf-git-test$ p4 fstat //depot/symlink
... depotFile //depot/symlink
... clientFile /dev/shm/trash
directory.t9802-git-p4-filetype/cli/symlink
... isMapped
... headAction add
... headType symlink
... headTime 1376221978
... headRev 1
... headChange 6
... headModTime 1376221978
... haveRev 1
arf-git-test$ p4 -G print //depot/symlink | od -c
000 { s 004 \0 \0 \0 c o d e s 004 \0 \0 \0 s
020 t a t s \t \0 \0 \0 d e p o t F i l
040 e s 017 \0 \0 \0 / / d e p o t / s y
060 m l i n k s 003 \0 \0 \0 r e v s 001 \0
100 \0 \0 1 s 006 \0 \0 \0 c h a n g e s 001
120 \0 \0 \0 6 s 006 \0 \0 \0 a c t i o n s
140 003 \0 \0 \0 a d d s 004 \0 \0 \0 t y p e
160 s \a \0 \0 \0 s y m l i n k s 004 \0 \0
200 \0 t i m e s \n \0 \0 \0 1 3 7 6 2 2
220 1 9 7 8 s \b \0 \0 \0 f i l e S i z
240 e s 002 \0 \0 \0 1 5 0 { s 004 \0 \0 \0 c
260 o d e s 006 \0 \0 \0 b i n a r y s 004
300 \0 \0 \0 d a t a s 017 \0 \0 \0 s y m l
320 i n k - t a r g e t \n 0 { s 004 \0
340 \0 \0 c o d e s 006 \0 \0 \0 b i n a r
360 y s 004 \0 \0 \0 d a t a s \0 \0 \0 \0 0
400
Also, what version is your server, from p4 info:
Server version: P4D/LINUX26X86_64/2013.1/610569 (2013/03/19)
-- Pete
Hello!
Let me give you an example. Here are the links as resulted in the git
p4 clone (one was correct, one wasn't):
./lib/update.sh - ../update.sh
./apps/update.sh - ../update.s
alexj@ixro-alexj ~/perforce $ p4 print path/lib/update.sh
//path/update.sh#6 - edit change 119890 (symlink)
../update.sh
alexj@ixro-alexj ~/perforce $ p4 print path/apps/update.sh
//path/apps/update.sh#144 - edit change 116063 (symlink)
../update.shalexj@ixro-alexj ~/perforce/unstable $
Notice the output and the prompt.
(I removed the exact path to the file from the output)
The fstat output is kind of irrelevant, but the hexdump shows the missing \n:
p4 -G print lib/update.sh|od -c
360 t e . s h \n 0
p4 -G print apps/update.sh|od -c
360 p d a t e . s h 0
I had forgotten, in fact, another thread on this very topic:
http://thread.gmane.org/gmane.comp.version-control.git/221500
Now with your evidence, I think we can decide that no matter how
the symlink managed to sneak into p4d, git p4 should be able to
handle it.
The only problem is that due to the \n ambiguity, in your setup
where p4d loses the \n, git p4 will not handle symlinks with a
target that ends with a newline, e.g.:
symlink(foo\n, bar);
But the small chance of someone actually doing that, coupled with
the fact that for you git p4 is unusable with these symlinks,
says we should go ahead and make the change.
You should send the patch to junio for inclusion in pu/ for the
next release, with:
Acked-by: Pete Wyckoff p...@padd.com
Thanks for fixing this!
-- Pete
Sorry, I didn't get where I am supposed to submit the patch (I thought
I was supposed to send it here, lkml style).
Server version: P4D/LINUX26X86_64/2013.1/610569
Signed-off-by: Alex Juncu aju...@ixiacom.com
Signed-off-by: Alex Badea aba...@ixiacom.com
---
git-p4.py | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/git-p4.py b/git-p4.py
index 31e71ff..a53a6dc 100755
--- a/git-p4.py
+++ b/git-p4.py
@@ -2180,9 +2180,13 @@ class P4Sync(Command, P4UserMap):
git_mode = 100755
if type_base == symlink:
git_mode = 12
-# p4 print on a symlink contains target\n; remove the
newline
+# p4 print on a symlink sometimes contains
[PATCH v4] push: respect --no-thin
- From the beginning of push.c in 755225d, 2006-04-29, thin option
was enabled by default but could be turned off with --no-thin.
- Then Shawn changed the default to 0 in favor of saving server
resources in a4503a1, 2007-09-09. --no-thin worked great.
- One day later, in 9b28851 Daniel extracted some code from push.c to
create transport.c. He (probably accidentally) flipped the default
value from 0 to 1 in transport_get().
From then on --no-thin is effectively no-op because git-push still
expects the default value to be false and only calls
transport_set_option() when thin variable in push.c is true (which
is unnecessary). Correct the code to respect --no-thin by calling
transport_set_option() in both cases.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
v4 elaborates a bit on the story of thin variable in push.c and
renames receive-pack --no-thin to --reject-thin-pack-for-testing.
builtin/push.c | 5 ++---
builtin/receive-pack.c | 8 +++-
t/t5516-fetch-push.sh | 17 +
3 files changed, 26 insertions(+), 4 deletions(-)
diff --git a/builtin/push.c b/builtin/push.c
index 04f0eaf..333a1fb 100644
--- a/builtin/push.c
+++ b/builtin/push.c
@@ -15,7 +15,7 @@ static const char * const push_usage[] = {
NULL,
};
-static int thin;
+static int thin = 1;
static int deleterefs;
static const char *receivepack;
static int verbosity;
@@ -313,8 +313,7 @@ static int push_with_options(struct transport *transport,
int flags)
if (receivepack)
transport_set_option(transport,
TRANS_OPT_RECEIVEPACK, receivepack);
- if (thin)
- transport_set_option(transport, TRANS_OPT_THIN, yes);
+ transport_set_option(transport, TRANS_OPT_THIN, thin ? yes : NULL);
if (verbosity 0)
fprintf(stderr, _(Pushing to %s\n), transport-url);
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index e3eb5fc..fc6d53a 100644
--- a/builtin/receive-pack.c
+++ b/builtin/receive-pack.c
@@ -38,6 +38,7 @@ static int quiet;
static int prefer_ofs_delta = 1;
static int auto_update_server_info;
static int auto_gc = 1;
+static int fix_thin = 1;
static const char *head_name;
static void *head_name_to_free;
static int sent_capabilities;
@@ -869,7 +870,8 @@ static const char *unpack(int err_fd)
keeper[i++] = --stdin;
if (fsck_objects)
keeper[i++] = --strict;
- keeper[i++] = --fix-thin;
+ if (fix_thin)
+ keeper[i++] = --fix-thin;
keeper[i++] = hdr_arg;
keeper[i++] = keep_arg;
keeper[i++] = NULL;
@@ -975,6 +977,10 @@ int cmd_receive_pack(int argc, const char **argv, const
char *prefix)
stateless_rpc = 1;
continue;
}
+ if (!strcmp(arg, --reject-thin-pack-for-testing)) {
+ fix_thin = 0;
+ continue;
+ }
usage(receive_pack_usage);
}
diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh
index 4691d51..99c32d7 100755
--- a/t/t5516-fetch-push.sh
+++ b/t/t5516-fetch-push.sh
@@ -1172,4 +1172,21 @@ test_expect_success 'push --follow-tag only pushes
relevant tags' '
test_cmp expect actual
'
+test_expect_success 'push --no-thin must produce non-thin pack' '
+ cat path1 \EOF
+keep base version of path1 big enough, compared to the new changes
+later, in order to pass size heuristics in
+builtin/pack-objects.c:try_delta()
+EOF
+ git commit -am initial
+ git init no-thin
+ git --git-dir=no-thin/.git config receive.unpacklimit 0
+ git push no-thin/.git refs/heads/master:refs/heads/foo
+ echo modified path1
+ git commit -am modified
+ git repack -adf
+ rcvpck=git receive-pack --reject-thin-pack-for-testing
+ git push --no-thin --receive-pack=$rcvpck no-thin/.git
refs/heads/master:refs/heads/foo
+'
+
test_done
--
1.8.2.83.gc99314b
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git should not use a default user.email config value
On Mon, Aug 12, 2013 at 11:01:03PM +1000, Andrew Ardill wrote: On 12 August 2013 22:39, Jeff King p...@peff.net wrote: We could do something like the patch below, which allows: $ git config --global include./magic/.path .gitconfig-magic to read ~/.gitconfig-magic only when we are in a repository with a directory component /magic/. Thanks, this looks great! I'll have a play with it tomorrow. Would locally configured config options override this one? From a quick read of the patch there doesn't look like there is a way of turning this off for a specific repository, but perhaps that is unnecessary. I think after a bit of use the edge cases will be a bit clearer. Yes, the usual config and include rules apply; the patch just selectively ignores the include based on the subsection regex. So if you put the magic include in your ~/.gitconfig, anything in the repo's .git/config will override it. But that also means the usual restrictions apply, too. There is no way to unset a variable as if it had never been specified in the first place. And multi-valued variables will always append (e.g., remote.*.fetch). The matcher is a regex, so depending on how tortured you want your regex to get, you can probably exclude a particular directory with that. :) -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git should not use a default user.email config value
On Mon, Aug 12, 2013 at 02:54:13PM +0200, Michael Haggerty wrote:
We could satisfy a whole class of wishes by supporting
user-wide/system-wide git hooks like
~/.githooks/{pre,post}-clone /etc/githooks/{pre,post}-clone
~/.githooks/{pre,post}-init /etc/githooks/{pre,post}-init
I suppose similar functionality could be implemented via git aliases,
but hook scripts are easier to install and share.
I don't mind something like that, as it is very flexible. But I have a
feeling most uses would end up just symlinking some template hooks or
config. At which point we might be better serving the user to provide a
solution that is simpler to use (e.g., a ~/.githooks directory that is
checked for all hooks; the tricky part there would be making rules for
the case that there are system, user, and repo-level scripts for a
particular hook).
-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pull: Allow pull to preserve merges when rebasing.
Hi Junio, -r, even though it happens to be accepted, is not a good idea here, as there are other --r* commands that are not --rebase. [--[no-]rebase|--rebase=preserve] Cool, I will change that. You would want bool or string helper function to parse it correctly, something like: Oh, interesting, I had not thought of that--thanks for that git config --bool snippet, that's really helpful. - Stephen -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ephemeral-branches instead of detached-head?
Duy Nguyen pclo...@gmail.com writes: That would annoy me as I often work on top of detached HEAD on purpose and only create a branch when I want to save something. If the warning is to be moved, it should warn at the next checkout. $ git checkout master Warning: you are leaving 1 commit behind, not connected to any of your branches: 0e3618e a Switched to branch 'master' Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pull: Allow pull to preserve merges when rebasing.
How should this interact with 949e0d8e (pull: require choice between rebase/merge on non-fast-forward pull, 2013-06-27) I believe there should not be any conflicts in functionality, other than just tweaking the docs to mention --rebase=preserve as an option. Personally, I would assert that, for people using a rebase workflow with git pull, --prebase=preserve should be the default behavior, otherwise they'll be surprised when their feature branches get flattened. Unfortunately, we can't change the behavior of the naked --rebase flag to really mean --rebase=preserve, but I think that would be ideal. I think it's what people mean they do git pull. If you want a more raw rebase, they would likely (I think/assume) be running git rebase directly. Nonetheless, thanks for pointing out 949e0d8e, I did not know about it. Perhaps after that commit graduates to master, I can base this commit on it, and tweak the new docs to suggest --rebase=preserve as the least-surprising behavior. (Since I'm offering opinions, I think --rebase=preserve would be a great default for git pull in 2.0, but please ignore this statement if you've already hashed out the future/2.0 behavior of git pull.) - Stephen -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-p4: Fix occasional truncation of symlink contents.
Pete Wyckoff p...@padd.com writes: You should send the patch to junio for inclusion in pu/ for the next release, with: Acked-by: Pete Wyckoff p...@padd.com Thanks; I'll queue this then. -- 8 -- From: Alexandru Juncu al...@rosedu.org Date: Thu, 8 Aug 2013 16:17:38 +0300 Subject: [PATCH] git-p4: Fix occasional truncation of symlink contents. Symlink contents in p4 print sometimes have a trailing new line character, but sometimes it doesn't. git-p4 should only remove the last character if that character is '\n'. Signed-off-by: Alex Juncu aju...@ixiacom.com Signed-off-by: Alex Badea aba...@ixiacom.com Acked-by: Pete Wyckoff p...@padd.com Signed-off-by: Junio C Hamano gits...@pobox.com --- git-p4.py | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/git-p4.py b/git-p4.py index 31e71ff..a53a6dc 100755 --- a/git-p4.py +++ b/git-p4.py @@ -2180,9 +2180,13 @@ class P4Sync(Command, P4UserMap): git_mode = 100755 if type_base == symlink: git_mode = 12 -# p4 print on a symlink contains target\n; remove the newline +# p4 print on a symlink sometimes contains target\n; +# if it does, remove the newline data = ''.join(contents) -contents = [data[:-1]] +if data[-1] == '\n': +contents = [data[:-1]] +else: +contents = [data] if type_base == utf16: # p4 delivers different text in the python output to -G -- 1.8.4-rc2-235-g32b7467 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] diff: remove ternary operator evaluating always to true
Stefan Beller stefanbel...@googlemail.com writes:
On 08/12/2013 07:46 AM, Junio C Hamano wrote:
I think that is an overall improvement, especially if we also update
the checks of {one,two}-mode made for the block that deals with
submodules to use DIFF_FILE_VALID().
Thanks.
So, do I understand your reasoning, when proposing this patch?
I meant the condition in the if statement, not the parameters to
show_submodule_summary(). There are checks on -mode fields that
bypass the DIFF_FILE_VALID() macro, hurting readability.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ephemeral-branches instead of detached-head?
David Jeske dav...@gmail.com writes: @Junio - to put the issue in the context of your previous comments on the topic... way back when you made a comment about warnings during commits to detached heads.. http://git.661346.n2.nabble.com/RFC-Detached-HEAD-reminder-on-commit-td834710.html#a834959 If we _really_ don't want newbies to shoot themselves in the foot, we probably can issue a loud warning when they detach there HEAD. Oh, wait,... we already do that. The reason this rationale doesn't ring true for me, is that it is *very* common for me to checkout a detached-head and there is nothing odd or dangerous about it. You do not have to say that to me _now_ ;-) because after makinng the above ancient comment others have corrected me, I agreed with them, and we no longer rely on that you are detaching, danger ahead warning. With the same line of reasoning, the place where users make commits on detached HEAD is not where the danger arises, either; the real danger is where you switch out of the detached HEAD state, and I think we do give a loud warning there. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ephemeral-branches instead of detached-head?
Duy Nguyen pclo...@gmail.com writes: On Mon, Aug 12, 2013 at 7:14 PM, David Jeske dav...@gmail.com wrote: IMO, the current warning during checkout of a detached-head is misplaced. It should be removed, and instead there should only be a warning after detached-head commit, since this is the only time there is a danger of losing something. That would annoy me as I often work on top of detached HEAD on purpose and only create a branch when I want to save something. If the warning is to be moved, it should warn at the next checkout. Don't we already do that? Warning: you are leaving N commits behind, not connected to any of your branches: ... list of commits to be lost ... If you want to keep them by creating a new branch, this may be a good time to do so with: git branch new_branch_name xx Switched to branch 'master' -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Help with sparse checkouts
Hello all! At my current workplace, I have a git-svn repository which has an extremely large working directory. I did not use the --stdlayout option in this clone, so I have a number of branches in my working directory which duplicate large amounts of trunk. There is a particularly large subdirectory which has now been copied to branches four times (and hence shows up in my working directory 5 times). This directory and its copies are making up the vast majority of the files and storage space in my working directory. Furthermore, I do not need or want to have access to the data in these particular directories. Hence, I would like to use the sparse checkouts feature to exclude them from my working directory. Let's say that these directories are all called thedir. What I would like to do with the sparse checkouts feature is to simply ignore directories with this name anywhere in the working tree. Intuitively, it seems like I should be able to put: !thedir or possibly !thedir/ in the sparse-checkout file, but these don't seem to work. I've tried a number of other things, but I always seem to either get the sparse checkout leaves no entry on working directory error or no effect at all. In the end, I basically just don't really understand how this file is supposed to work, so I'd rather get some expert help here rather than thrashing about randomly. I realize that sparse checkouts is usually used to select a specific directory rather than what I'm trying to do, so I accept that what I want may simply not be possible with the current implementation. I've asked on IRC, but I wanted to ask here also since it seemed that most of the people I talked to weren't that familiar with the sparse checkouts feature. Note that, while using --stdlayout would mitigate the massive working directory somewhat, I would still probably want to exclude this directory from my worktree. I will probably do a reclone at some point and use --stdlayout, but I will still want to exclude this particular directory even at that point. I had a lot of people on IRC telling me to just use --stdlayout, which was a good suggestion, but didn't fully fulfill my needs. Thanks! Ari -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ephemeral-branches instead of detached-head?
On Mon, Aug 12, 2013 at 6:23 AM, Duy Nguyen pclo...@gmail.com wrote: That would annoy me as I often work on top of detached HEAD on purpose and only create a branch when I want to save something. If the warning is to be moved, it should warn at the next checkout. Yes, you're absolutely right ... My point about the current checkout warning is that it's crying wolf, and nullifying the value of the warning. Most of the time I checkout a ref, I'm not doing anything dangerous because I'm not going to check anything in. The warning would be more effective if it warns in as narrow a situation as possible. You're correct that the clobber is even more narrow than the checkin. The warning on clobber would be similar to (but shorter than) the one which could be removed from checkout.. Clobbered detached HEAD 'cce40d6'! git log cce40d6 ^master # log detached changes vs master git branch name cc340d6# name the changes with a branch Personally, I'd prefer for explicit action to discard a detached head. It's true that this is an explicit step, but for me it generally takes a heck of alot less time to explicitly discard than it did to checkout the detached head, make changes (or apply a patch), and then decide to throw them away. My ephemeral branch idea was a way to make this explicit discard as passive and lazy as possible. Basically, never stop you from doing your work, assume you know what you are doing. If the user names-the-branch it disappears. If the user merges or rebases the detached head, it disappears. The only time the ephemeral branch would survive is if the user really clobbered a detached head and then didn't do anything about it. Even if they missed the warning (in the middle of a script or automated process), eventually they would see the ephemeral branch lying around. Clobbering a detached head with ephemeral branches could show no warning at all, or a warning like: Clobbered detached HEAD. git log cce40d6 ^master # log detached changes vs master git branch -D tmp/cce40d6 # Discard these changes git branch tmp/cce40d6 newname # name this branch -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ephemeral-branches instead of detached-head?
On Mon, Aug 12, 2013 at 10:24 AM, Junio C Hamano gits...@pobox.com wrote: Don't we already do that? Warning: you are leaving N commits behind, not connected to any of your branches: ... list of commits to be lost ... This only shows on checkout... not reset, not submodule-update, nor any other ways you can clobber a detached head. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] .mailmap: mark bouncing email addresses
On Mon, Aug 12, 2013 at 3:44 AM, Junio C Hamano gits...@pobox.com wrote: Subject: .mailmap: update long-lost friends with multiple defunct addresses A handful of past contributors are recorded with multiple e-mail addresses, all of which are undeliberable. With a lot of help from s/undeliberable/undeliverable/ Jonathan, we located all of them except for one. Update the found ones with their currently preferred address, and use the last known address to consolidate contributions by the lost person under a single entry. Helped-by: Stefan Beller stefanbel...@googlemail.com Helped-by: Jonathan Nieder jrnie...@gmail.com Signed-off-by: Junio C Hamano gits...@pobox.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] pull: Allow pull to preserve merges when rebasing.
If a user is working on master, and has merged in their feature branch, but now
has to git pull because master moved, with pull.rebase their feature branch
will be flattened into master.
This is because git pull currently does not know about rebase's preserve
merges flag, which would avoid this behavior, as it would instead replay just
the merge commit of the feature branch onto the new master, and not replay each
individual commit in the feature branch.
Add a --rebase=preserve option, which will pass along --preserve-merges to
rebase.
Also add 'preserve' to the allowed values for the pull.rebase config setting.
Signed-off-by: Stephen Haberman step...@exigencecorp.com
---
Hi,
This is v5 of my --rebase=preserve patch, the last discussion of which
was here:
http://thread.gmane.org/gmane.comp.version-control.git/232156
This update has two small changes:
* Change the usage output to match Junio's suggestion, and
* Respect existing true-but-not-true values of pull.rebase, using
Junio's bool_or_string_config function (with a test for pull.rebase=1).
Thanks!
Documentation/config.txt | 8 +
Documentation/git-pull.txt | 18 ++
git-pull.sh| 31 +---
t/t5520-pull.sh| 89 ++
4 files changed, 135 insertions(+), 11 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index ec57a15..4c22be2 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -766,6 +766,10 @@ branch.name.rebase::
git pull is run. See pull.rebase for doing this in a non
branch-specific manner.
+
+ When preserve, also pass `--preserve-merges` along to 'git rebase'
+ so that locally committed merge commits will not be flattened
+ by running 'git pull'.
++
*NOTE*: this is a possibly dangerous operation; do *not* use
it unless you understand the implications (see linkgit:git-rebase[1]
for details).
@@ -1826,6 +1830,10 @@ pull.rebase::
pull is run. See branch.name.rebase for setting this on a
per-branch basis.
+
+ When preserve, also pass `--preserve-merges` along to 'git rebase'
+ so that locally committed merge commits will not be flattened
+ by running 'git pull'.
++
*NOTE*: this is a possibly dangerous operation; do *not* use
it unless you understand the implications (see linkgit:git-rebase[1]
for details).
diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
index 6ef8d59..beea10b 100644
--- a/Documentation/git-pull.txt
+++ b/Documentation/git-pull.txt
@@ -102,12 +102,18 @@ include::merge-options.txt[]
:git-pull: 1
-r::
---rebase::
- Rebase the current branch on top of the upstream branch after
- fetching. If there is a remote-tracking branch corresponding to
- the upstream branch and the upstream branch was rebased since last
- fetched, the rebase uses that information to avoid rebasing
- non-local changes.
+--rebase[=false|true|preserve]::
+ When true, rebase the current branch on top of the upstream
+ branch after fetching. If there is a remote-tracking branch
+ corresponding to the upstream branch and the upstream branch
+ was rebased since last fetched, the rebase uses that information
+ to avoid rebasing non-local changes.
++
+When preserve, also rebase the current branch on top of the upstream
+branch, but pass `--preserve-merges` along to `git rebase` so that
+locally created merge commits will not be flattened.
++
+When false, merge the current branch into the upstream branch.
+
See `pull.rebase`, `branch.name.rebase` and `branch.autosetuprebase` in
linkgit:git-config[1] if you want to make `git pull` always use
diff --git a/git-pull.sh b/git-pull.sh
index f0df41c..e11d9a0 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -4,7 +4,7 @@
#
# Fetch one or more remote refs and merge it/them into the current HEAD.
-USAGE='[-n | --no-stat] [--[no-]commit] [--[no-]squash] [--[no-]ff] [-s
strategy]... [fetch-options] repo head...'
+USAGE='[-n | --no-stat] [--[no-]commit] [--[no-]squash] [--[no-]ff]
[--[no-]rebase|--rebase=preserve] [-s strategy]... [fetch-options] repo
head...'
LONG_USAGE='Fetch one or more remote refs and integrate it/them with the
current HEAD.'
SUBDIRECTORY_OK=Yes
OPTIONS_SPEC=
@@ -38,15 +38,19 @@ Please, commit your changes before you can merge.)
test -z $(git ls-files -u) || die_conflict
test -f $GIT_DIR/MERGE_HEAD die_merge
+bool_or_string_config () {
+ git config --bool $1 2/dev/null || git config $1
+}
+
strategy_args= diffstat= no_commit= squash= no_ff= ff_only=
log_arg= verbosity= progress= recurse_submodules= verify_signatures=
-merge_args= edit=
+merge_args= edit= rebase_args=
curr_branch=$(git symbolic-ref -q HEAD)
curr_branch_short=${curr_branch#refs/heads/}
-rebase=$(git config --bool branch.$curr_branch_short.rebase)
+rebase=$(bool_or_string_config branch.$curr_branch_short.rebase)
if
Re: [PATCH v3] status: always show tracking branch even no change
2013/8/12 Junio C Hamano gits...@pobox.com: Jiang Xin worldhello@gmail.com writes: 2013/8/10 Junio C Hamano gits...@pobox.com: Jiang Xin worldhello@gmail.com writes: So always show the remote tracking branch in the output of git status and other commands will help users to see where the current branch will push to and pull from. E.g. ... Hmmph. I do not know if this will help any case you described above, even though this might help some other cases. The added output is to always show the current branch and its upstream, but the thing is, the original issue in $gmane/198703 was *not* that the current branch was pushed and up to date. It was that there was no current branch to be pushed. The same thing would happen if you are on a local branch that is not set to be pushed to the other side (e.g. the configuration is set to matching and there is no such branch on the other end). How about write the commit log like this: ... Then if there is no tracking info reported, the user may need to do something. Maybe the current branch is a new branch that needs to be pushed out, or maybe it's a branch which should add remote tracking settings. Would that help anybody, though? I will split the patch into two. The 1st patch resolves a real problem: branch: not report invalid tracking branch Command git branch -vv will report tracking branches, but invalid tracking branches are also reported. This is because the function stat_tracking_info() can not distinguish whether the upstream branch does not exist, or nothing is changed between one branch and its upstream. This patch changes the return value of function stat_tracking_info(). Only returns false when there is no tracking branch or the tracking branch is invalid, otherwise true. If the caller does not like to report tracking info when nothing changed between the branch and its upstream, simply checks if num_theirs and num_ours are both 0. And in the 2nd patch, I will not mention git push (current not be pushed out ...) any more, and only focus on git status. It's just a suggestion, may only fit small group of users' taste. -- Jiang Xin -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 2/2] status: always show tracking branch even no change
In order to see what the current branch is tracking, one way is using
git branch -v -v, but branches other than the current are also
reported. Another way is using git status, such as:
$ git status
# On branch master
# Your branch is ahead of 'origin/master' by 1 commit.
...
But this will not work if there is no change between the current
branch and its upstream. What if report upstream tracking info
always even if there is no difference. E.g.
$ git status
# On branch feature1
# Your branch is identical to 'github/feature1'.
...
$ git status -bs
## feature1...github/feature1
...
$ git checkout feature1
Already on 'feature1'
Your branch is identical to 'github/feature1'.
...
Also add some test cases in t6040.
Signed-off-by: Jiang Xin worldhello@gmail.com
---
remote.c | 10 -
t/t6040-tracking-info.sh | 54
wt-status.c | 13 +---
3 files changed, 60 insertions(+), 17 deletions(-)
diff --git a/remote.c b/remote.c
index c747936..70307f4 100644
--- a/remote.c
+++ b/remote.c
@@ -1811,13 +1811,13 @@ int format_tracking_info(struct branch *branch, struct
strbuf *sb)
if (!stat_tracking_info(branch, num_ours, num_theirs))
return 0;
- /* Nothing to report if neither side has changes. */
- if (!num_ours !num_theirs)
- return 0;
-
base = branch-merge[0]-dst;
base = shorten_unambiguous_ref(base, 0);
- if (!num_theirs) {
+ if (!num_ours !num_theirs) {
+ strbuf_addf(sb,
+ _(Your branch is identical to '%s'.\n),
+ base);
+ } else if (!num_theirs) {
strbuf_addf(sb,
Q_(Your branch is ahead of '%s' by %d commit.\n,
Your branch is ahead of '%s' by %d commits.\n,
diff --git a/t/t6040-tracking-info.sh b/t/t6040-tracking-info.sh
index ec2b516..eafce7d 100755
--- a/t/t6040-tracking-info.sh
+++ b/t/t6040-tracking-info.sh
@@ -28,18 +28,20 @@ test_expect_success setup '
git reset --hard HEAD^
git checkout -b b4 origin
advance e
- advance f
+ advance f
+ git checkout -b b5 origin
)
git checkout -b follower --track master
advance g
'
-script='s/^..\(b.\)[0-9a-f]*\[\([^]]*\)\].*/\1 \2/p'
+script='s/^..\(b.\)[0-9a-f]*\(\[\([^]]*\)\]\)\{0,1\}.*/\1 \3/p'
cat expect \EOF
b1 ahead 1, behind 1
b2 ahead 1, behind 1
b3 behind 1
b4 ahead 2
+b5
EOF
test_expect_success 'branch -v' '
@@ -56,6 +58,7 @@ b1 origin/master: ahead 1, behind 1
b2 origin/master: ahead 1, behind 1
b3 origin/master: behind 1
b4 origin/master: ahead 2
+b5 origin/master
EOF
test_expect_success 'branch -vv' '
@@ -67,20 +70,27 @@ test_expect_success 'branch -vv' '
test_i18ncmp expect actual
'
-test_expect_success 'checkout' '
+test_expect_success 'checkout (diverged from upstream)' '
(
cd test git checkout b1
) actual
test_i18ngrep have 1 and 1 different actual
'
+test_expect_success 'checkout (identical to upstream)' '
+ (
+ cd test git checkout b5
+ ) actual
+ test_i18ngrep Your branch is identical to .origin/master actual
+'
+
test_expect_success 'checkout with local tracked branch' '
git checkout master
git checkout follower actual
test_i18ngrep is ahead of actual
'
-test_expect_success 'status' '
+test_expect_success 'status (diverged from upstream)' '
(
cd test
git checkout b1 /dev/null
@@ -90,6 +100,42 @@ test_expect_success 'status' '
test_i18ngrep have 1 and 1 different actual
'
+test_expect_success 'status (identical to upstream)' '
+ (
+ cd test
+ git checkout b5 /dev/null
+ # reports nothing to commit
+ test_must_fail git commit --dry-run
+ ) actual
+ test_i18ngrep Your branch is identical to .origin/master actual
+'
+
+cat expect \EOF
+## b1...origin/master [ahead 1, behind 1]
+EOF
+
+test_expect_success 'status -s -b (diverged from upstream)' '
+ (
+ cd test
+ git checkout b1 /dev/null
+ git status -s -b | head -1
+ ) actual
+ test_i18ncmp expect actual
+'
+
+cat expect \EOF
+## b5...origin/master
+EOF
+
+test_expect_success 'status -s -b (identical to upstream)' '
+ (
+ cd test
+ git checkout b5 /dev/null
+ git status -s -b | head -1
+ ) actual
+ test_i18ncmp expect actual
+'
+
test_expect_success 'fail to track lightweight tags' '
git checkout master
git tag light
diff --git a/wt-status.c b/wt-status.c
index 0c6a3a5..627b59e 100644
--- a/wt-status.c
+++
Re: [Bug] git stash generates a different diff then other commands (diff, add, etc) resulting in merge conflicts!
On 08/12/2013 12:05 PM, Phil Hord wrote: On Mon, Aug 12, 2013 at 1:29 AM, Luke San Antonio lukesananto...@gmail.com wrote: On 08/08/20130 04:54 PM, Phil Hord wrote: Luke, I think the issue is that your working directory receives your cached file when you say 'git stash --keep-index'. When you restore the stash, your previous working directory now conflicts with your new working directory, but neither is the same as HEAD. Here's a test script to demonstrate the issue, I think. Did I get this right, Luke? # cd /tmp rm -rf foo git init foo cd foo echo foo bar git add bar git commit -mfoo echo bar bar git add bar echo baz bar echo Before stash bar: $(cat bar) git stash --keep-index echo After stash bar: $(cat bar) git stash apply Actually no, in your script, the bar file has a modification in the working tree which is in the same hunk as a change applied to the index. In my project the changes that were added to the index are not modified further in theworking tree. Not only that, but I found out why git was generated different patches! I realized that when I removed a hunk appearing before the merge conflict from the working tree and index, the merge conflict disappeared! Turns out, we can forget about stashing for a minute! First the hunk in my working tree: @@ -56,12 +56,14 @@ bool running_ = true; /*! - * \brief The default font renderer, global to all who have a pointer to - * the Game class. + * \brief The font renderer implementation, obtained from the config file. * - * It need not be used at all! + * It should be used and passed along to member objects by GameStates! + * + * \note It can be cached, but not between GameStates, meaning it should be + * cached again every time a new GameState is constructed! */ -std::unique_ptrFontRenderer font_renderer_ = nullptr; +FontRenderer* font_renderer_ = nullptr; int run(int argc, char* argv[]); Most of this is unimportant, but notice the line number spec:@@ -56,12 +56,14 @@ The line number of this hunk doesn't change! Then I addeda few lines *above* this hunk, (around line 30 I think). Here is the diff again: @@ -56,12 +58,14 @@ bool running_ = true; /*! - * \brief The default font renderer, global to all who have a pointer to - * the Game class. + * \brief The font renderer implementation, obtained from the config file. + * + * It should be used and passed along to member objects by GameStates! * - * It need not be used at all! + * \note It can be cached, but not between GameStates, meaning it should be + * cached again every time a new GameState is constructed! */ -std::unique_ptrFontRenderer font_renderer_ = nullptr; +FontRenderer* font_renderer_ = nullptr; int run(int argc, char* argv[]); Notice the new line number spec:@@ -56,12 +58,14 @@ It moves two lines down, because I added those two lines before it, makes sense! But also notice that the patches are different, just because of the two lines above it! I thought I might be able to fix this problem by changing the new diff.algorithm config option to 'patience', but it seems to only affect how patches look, not how they are stored internally... Same problem! Also, I'm wondering why that line was picked up by git if the patches don't match, shouldn't git give me a conflict with the whole hunk, or is the system smarter than that? Git does not store patches. Git stores the entire file. I do not think the diff algorithm you choose will have any effect on the results of the merge. But I am pretty clueless about the merge engine, so I could be off-base on this last part. What if merging suppressed the conflict if both possibilities are the same? Isn't that reasonable, or is there some 1% where this could cause (silent but deadly) data loss. I think that is what Git is meant to do. But I am confused now about where the failure is occurring for you. Can you demonstrate the problem by modifying my test script? Is this more like it? cd /tmp rm -rf foo git init foo cd foo printf 1\n2 foo\n3\n4\n5\n6\n7\n8 foo\n9\n10\n bar git add bar git commit -mfoo printf 1\n2 XXX\n3\n4\n5\n6\n7\n8 foo\n9\n10\n bar git add bar printf 1\n2 XXX\n3\n4\n5\n6\n7\n8 XXX\n9\n10\n bar echo Before stash bar: $(cat bar) git stash --keep-index echo After stash bar: $(cat bar) git stash apply Phil So I found an isolated case, it's very strange... Here's a script! cd /tmp rm -rf foo; git init foo cd foo; git config --local diff.algorithm myers printf \n\n-\n\n\n/*'!'\ \n * -\n * ^\n *\n \ * =\n */\n|---|\n foo; git add foo git commit -m foo; printf \n-\n\n\n/*'!'\ \n * #\n *\n * !\n \ *\n * @\n * \n */\n\
