Re: [PATCH] pull: Allow pull to preserve merges when rebasing.
Stephen Haberman 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]... [] ...'
> +USAGE='[-n | --no-stat] [--[no-]commit] [--[no-]squash] [--[no-]ff]
> [-r=[true|false|preserve]] [-s strategy]... []
> ...'
"-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 2/3] t3404: rebase: interactive: demonstrate short SHA-1 collision
Eric Sunshine 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 > --- > 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 1/3] t3404: restore specialized rebase-editor following commentchar test
Eric Sunshine 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). 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? > (There are no such tests presently, but a subsequent > patch will introduce one.) Fix this problem. > > Signed-off-by: Eric Sunshine > --- > t/t3404-rebase-interactive.sh | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh > index 49ccb38..af141be 100755 > --- a/t/t3404-rebase-interactive.sh > +++ b/t/t3404-rebase-interactive.sh > @@ -949,6 +949,7 @@ test_expect_success 'rebase -i respects core.commentchar' > ' > sed -e "2,\$s/^//" "$1" >"$1.tmp" && > mv "$1.tmp" "$1" > EOF > + test_when_finished "set_fake_editor" && > test_set_editor "$(pwd)/remove-all-but-first.sh" && > git rebase -i B && > test B = $(git cat-file commit HEAD^ | sed -ne \$p) -- 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: document git blame --no-follow and git diff --no-follow
乙酸鋰 writes: > Please document git blame --no-follow and git diff --no-follow I do not think these (and blame/diff --follow) make any sense. The ideal would be to reject the nonsense optoin at the command parser level. The second best is not to document it. The worst is to document them as nonsense. -- 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
---
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..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..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..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]... [] ...'
+USAGE='[-n | --no-stat] [--[no-]commit] [--[no-]squash] [--[no-]ff]
[-r=[true|false|preserve]] [-s strategy]... [] ...'
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)
+ rebase=$(git config pull.rebase)
fi
dry_run=
while :
@@ -110,6 +
Re: [PATCH v3] status: always show tracking branch even no change
Jiang Xin writes: > 2013/8/10 Junio C Hamano : >> Jiang Xin 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
Re: [PATCH v3] push: respect --no-thin
Nguyễn Thái Ngọc Duy 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
Зеленый кофе обозначается сокрушительным натуральным антиоксидантом
Кофеин благоприятствует оперативнейшему раздроблению жира внутри клеток http://is.gd/oFiLKe Эти цифры знают все на свете Смело можете кричать,
Re: [PATCH] diff: remove ternary operator evaluating always to true
Jeff King 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.
--
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.
Andres Perera 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. -- 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: [Bug] git stash generates a different diff then other commands (diff, add, etc) resulting in merge conflicts!
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_ptr 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_ptr 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? 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. Sorry, I'm just rambling... Anyway, thanks for your help Phil! - Luke -- 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 0/3] fix interactive rebase short SHA-1 collision bug
This series addresses a bug [1][2] which can manifest during interactive rebase when the prefix of the new SHA-1 of an edited commit is shared with the abbreviated SHA-1 of a subsequent commit in the 'todo' list. When rebase attempts to process the subsequent command, it dies with a "short SHA1 badbeef is ambiguous" error. patch 1: fix a problem in the interactive rebase test suite which can make subsequent tests fail patch 2: add a test demonstrating the short SHA-1 collision bug patch 3: fix the bug (this patch is from Junio [3] but augmented also to fix up "rebase --edit-todo") [1]: http://thread.gmane.org/gmane.comp.version-control.git/229091 [2]: http://thread.gmane.org/gmane.comp.version-control.git/232012 [3]: http://thread.gmane.org/gmane.comp.version-control.git/229091/focus=229120 Eric Sunshine (2): t3404: restore specialized rebase-editor following commentchar test t3404: rebase: interactive: demonstrate short SHA-1 collision Junio C Hamano (1): rebase: interactive: fix short SHA-1 collision git-rebase--interactive.sh| 30 ++ t/t3404-rebase-interactive.sh | 18 ++ 2 files changed, 48 insertions(+) -- 1.8.4.rc2.460.ga591f4a -- 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 1/3] t3404: restore specialized rebase-editor following commentchar test
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. (There are no such tests presently, but a subsequent patch will introduce one.) Fix this problem. Signed-off-by: Eric Sunshine --- t/t3404-rebase-interactive.sh | 1 + 1 file changed, 1 insertion(+) diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh index 49ccb38..af141be 100755 --- a/t/t3404-rebase-interactive.sh +++ b/t/t3404-rebase-interactive.sh @@ -949,6 +949,7 @@ test_expect_success 'rebase -i respects core.commentchar' ' sed -e "2,\$s/^//" "$1" >"$1.tmp" && mv "$1.tmp" "$1" EOF + test_when_finished "set_fake_editor" && test_set_editor "$(pwd)/remove-all-but-first.sh" && git rebase -i B && test B = $(git cat-file commit HEAD^ | sed -ne \$p) -- 1.8.4.rc2.460.ga591f4a -- 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 3/3] rebase: interactive: fix short SHA-1 collision
From: Junio C Hamano
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
Fix this problem by expanding the SHA-1's in the todo list before
performing the operations.
[es: also collapse & expand SHA-1's for --edit-todo]
Signed-off-by: Eric Sunshine
---
git-rebase--interactive.sh| 30 ++
t/t3404-rebase-interactive.sh | 2 +-
2 files changed, 31 insertions(+), 1 deletion(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 83d6d46..ea11e62 100644
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -689,6 +689,32 @@ skip_unnecessary_picks () {
die "Could not skip unnecessary pick commands"
}
+transform_todo_ids () {
+ while read -r command rest
+ do
+ case "$command" in
+ '#'* | exec)
+ # Be careful for oddball commands like 'exec'
+ # that do not have a SHA-1 at the beginning of $rest.
+ ;;
+ *)
+ sha1=$(git rev-parse --verify --quiet "$@" ${rest%% *})
&&
+ rest="$sha1 ${rest#* }"
+ ;;
+ esac
+ printf '%s\n' "$command${rest:+ }$rest"
+ done <"$todo" >"$todo.new" &&
+ mv -f "$todo.new" "$todo"
+}
+
+expand_todo_ids() {
+ transform_todo_ids
+}
+
+collapse_todo_ids() {
+ transform_todo_ids --short=7
+}
+
# Rearrange the todo list that has both "pick sha1 msg" and
# "pick sha1 fixup!/squash! msg" appears in it so that the latter
# comes immediately after the former, and change "pick" to
@@ -841,6 +867,7 @@ skip)
edit-todo)
git stripspace --strip-comments <"$todo" >"$todo".new
mv -f "$todo".new "$todo"
+ collapse_todo_ids
append_todo_help
git stripspace --comment-lines >>"$todo" <<\EOF
@@ -852,6 +879,7 @@ EOF
git_sequence_editor "$todo" ||
die "Could not execute editor"
+ expand_todo_ids
exit
;;
@@ -1008,6 +1036,8 @@ git_sequence_editor "$todo" ||
has_action "$todo" ||
die_abort "Nothing to do"
+expand_todo_ids
+
test -d "$rewritten" || test -n "$force_rebase" || skip_unnecessary_picks
GIT_REFLOG_ACTION="$GIT_REFLOG_ACTION: checkout $onto_name"
diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
index e5ebec6..db56db3 100755
--- a/t/t3404-rebase-interactive.sh
+++ b/t/t3404-rebase-interactive.sh
@@ -987,7 +987,7 @@ test_expect_success 'short SHA-1 setup' '
test_commit --notick "collide3 115158b5" collide collide3 collide3
'
-test_expect_failure 'short SHA-1 collide' '
+test_expect_success 'short SHA-1 collide' '
test_when_finished "reset_rebase && git checkout master" &&
git checkout collide &&
FAKE_COMMIT_MESSAGE="collide2 815200e" \
--
1.8.4.rc2.460.ga591f4a
--
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 2/3] t3404: rebase: interactive: demonstrate short SHA-1 collision
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 --- 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 && + 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 -- 1.8.4.rc2.460.ga591f4a -- 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 Andres, > i just realized that there are ambiguities: > pull --rebase (true|false|preserve) foo # pull from remote named > (true|false|preserve), branch foo Yeah. Right now, I did the latter. Around line 125, when parsing "--rebase ", we accept only if it's true, false, or preserve, and shift it off. Otherwise we leave it alone and assume it's a remote name. Without this logic, t5520 fails because it uses "git pull --rebase . copy", which, as you noted, is ambiguous, so "." was showing up as the rebase argument. So, this is technically handled right now, but I'm fine removing the ambiguous "--rebase true|false|preserve" option if that is what is preferred. - 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] pull: Allow pull to preserve merges when rebasing.
On Sun, Aug 11, 2013 at 6:39 PM, Stephen Haberman wrote: > >> 1. i'm not sure why you are testing $3 == preserve. it looks like a >> typo > > Yes, good catch. I've added a test that fails, and will fix that. > >> 2. clearer than a string of yoda conditions: >> >> case $2 in >> true|false|preserve) > > Makes sense, will change. > >> 1. in the error message you say that rebase should be a trystate of >> true, false, or preserve. why then do you allow $rebase == '' ? > > Because it may be unset, like if the user ran "git pull . copy" and > the pull.rebase setting was not set. > >> 2. clearer than a string of yoda conditions: > > Will change again. > > I'll wait to see if I get any more feedback and then will send out > another version. 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, so that pull --rebase[=(true|false|preserve)] | -r[(true|false|preserve)] avoids the ambiguity of pull --rebase [(true|false|preserve)] | -r [(true|false|preserve)] 1. you can make it a disambiguation by appending ? to the optspec (according to man git-rev-parse) 2. you could also disambiguate by testing if the argument is a configured remote and warn the user, but this makes option parsing inconsistent, requires additional logic, and is overall inelegant > > Thanks! > > - 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] pull: Allow pull to preserve merges when rebasing.
> 1. i'm not sure why you are testing $3 == preserve. it looks like a > typo Yes, good catch. I've added a test that fails, and will fix that. > 2. clearer than a string of yoda conditions: > > case $2 in > true|false|preserve) Makes sense, will change. > 1. in the error message you say that rebase should be a trystate of > true, false, or preserve. why then do you allow $rebase == '' ? Because it may be unset, like if the user ran "git pull . copy" and the pull.rebase setting was not set. > 2. clearer than a string of yoda conditions: Will change again. I'll wait to see if I get any more feedback and then will send out another version. Thanks! - 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] pull: Allow pull to preserve merges when rebasing.
hello, comments inline On Sun, Aug 11, 2013 at 4:56 PM, Stephen Haberman wrote: > 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 > --- > Hi, > > This is v3 of my previous pull.rebase=preserve patch, previously discussed > here: > > http://thread.gmane.org/gmane.comp.version-control.git/232061 > http://thread.gmane.org/gmane.comp.version-control.git/231909 > > In this version, I addressed all of Eric's excellent feedback. > > I believe the patch is much better now, but would still appreciate more > detailed feedback. In particular, I kind of made up how to handle and > invalid "--rebase=invalid" value, and the resulting error message. > > Also, I changed git-pull's usage to include the -r parameter...not > sure if that's okay or not. Let me know if not. > > Thanks! > > Documentation/config.txt | 8 + > Documentation/git-pull.txt | 18 +++ > git-pull.sh| 42 > t/t5520-pull.sh| 81 > ++ > 4 files changed, 137 insertions(+), 12 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..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..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..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..78ad52d 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]... [] ...' > +USAGE='[-n | --no-stat] [--[no-]commit] [--[no-]squash] [--[no-]ff] [-r > [true|false|preserve]] [-s strategy]... [] ...' > 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=
[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
---
Hi,
This is v3 of my previous pull.rebase=preserve patch, previously discussed here:
http://thread.gmane.org/gmane.comp.version-control.git/232061
http://thread.gmane.org/gmane.comp.version-control.git/231909
In this version, I addressed all of Eric's excellent feedback.
I believe the patch is much better now, but would still appreciate more
detailed feedback. In particular, I kind of made up how to handle and
invalid "--rebase=invalid" value, and the resulting error message.
Also, I changed git-pull's usage to include the -r parameter...not
sure if that's okay or not. Let me know if not.
Thanks!
Documentation/config.txt | 8 +
Documentation/git-pull.txt | 18 +++
git-pull.sh| 42
t/t5520-pull.sh| 81 ++
4 files changed, 137 insertions(+), 12 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..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..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..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..78ad52d 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]... [] ...'
+USAGE='[-n | --no-stat] [--[no-]commit] [--[no-]squash] [--[no-]ff] [-r
[true|false|preserve]] [-s strategy]... [] ...'
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
Re: [PATCH 1/2] submodule: fix confusing variable name
On 08/08/2013 01:44 PM, Ramsay Jones wrote: Fredrik Gustafsson wrote: On Sun, Aug 04, 2013 at 07:34:48PM +0200, Jens Lehmann wrote: But we'll have to use sm_path here (like everywhere else in the submodule script), because we'll run into problems under Windows otherwise (see 64394e3ae9 for details). Apart from that the patch is fine. We're still using path= in the foreach-script. Or rather, we're setting it. From what I can see and from the commit message 64394e3ae9 it could possible be a problem. Please do not use a $path variable in any script intended to be run on windows; those poor souls who would otherwise have to fix the bugs will thank you! :-D Actually, it's not so much the use of a $path variable, rather the act of _exporting_ such a variable that causes the problem. (Which is why using $path with eval_gettext[ln] is such a problem, of course.) Please note that especially in this case, Cygwin != Windows. Cygwin allows $path, $Path, $PATH, etc., to all coexist and be accessed case sensitively. Exporting $path causes no problem, either. Should the eval invoke a Windows program, $PATH is converted to Windows format and exported, the other case-sensitive variants of path remain in the environment and can be accessed by any program implementing case-sensitive lookup as well. Not sure what will happen with case-insensitive lookups, but a quick test showed that cmd.exe is not bothered by $path given $PATH exists. Mark -- 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] submodule: don't print status output with ignore=all
brian m. carlson wrote:
> module_name uses whatever's in .gitmodules. I'm not sure what you mean
> by "renamed a submodule", since "git mv foo bar" fails with:
>
> vauxhall ok % git mv .vim/bundle/ctrlp .vim/bundle/ctrlq
> fatal: source directory is empty, source=.vim/bundle/ctrlp,
> destination=.vim/bundle/ctrlq
>
> Can you provide me a set of steps to reproduce that operation so I can
> test it effectively?
Ah, I forgot Jens's "submodule-mv" patch series has not hit master yet.
You can get it by running
git merge origin/pu^{/jl/submodule-mv}^2
before building git.
Thanks,
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/2] submodule: don't print status output with ignore=all
On Sat, Aug 03, 2013 at 11:24:20AM -0700, Jonathan Nieder wrote: > If I have '[submodule "favorite"] ignore = all' and I then replace > that submodule with a blob, should "git submodule status" not mention > that path? Yes, I think it should. I'll fix this in the reroll. > If I just renamed a submodule, will 'module_name "$path"' do the right > thing with the old path? module_name uses whatever's in .gitmodules. I'm not sure what you mean by "renamed a submodule", since "git mv foo bar" fails with: vauxhall ok % git mv .vim/bundle/ctrlp .vim/bundle/ctrlq fatal: source directory is empty, source=.vim/bundle/ctrlp, destination=.vim/bundle/ctrlq Can you provide me a set of steps to reproduce that operation so I can test it effectively? -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: git clone doesn't work in symlink dir roots on Windows
On Sun, Aug 11, 2013 at 9:28 AM, Sedat Kapanoglu wrote: > Thanks folks. So that this won't be fixed, I added a new Q&A to > MsysGit FAQ at > https://github.com/msysgit/msysgit/wiki/Frequently-Asked-Questions > , I appreciate if you can review and correct if needed. I hope it will > help avoiding further conversations about this matter. Thanks, that's very helpful! -- 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: How can I automatically create a GIT branch that represents a sequence of tags?
On Sun, Aug 11, 2013 at 12:13:18PM +0100, Kristian Freed wrote: > On Sun, Aug 11, 2013 at 12:20 AM, Fredrik Gustafsson wrote: > > I don't understand, why is it better to find between which tags a error > > was found and not in what commit. It's much easier to find a bug > > introduced in a commit than in a tag/release. It sounds like you're > > doing the bug hunting harder. Could you explain this further? > > For better or worse, the current state includes a lot of noisy "fixing > tests" type commits which I > would like to automatically skip over when hunting bugs. This is not > great and is being addressed, > but I am trying to make the most of the historical data we have today > - which does contain tags > for all builds that passed automated testing etc but does not have > only good commits on the related > branch. Thank you, that make sense (even if it's really sad to have such history). > > > My suggestion if you want to do this, is to have your buildtool to > > checkout a special branch (let's call it tag_branch) do a git reset > > to get the worktree from the newly tagged commit and commit on that > > branch once for each tag it's creating, when it creates the tag. > > I can see how this would work, but only for future builds. I would > need something like it but loop > over all existing tags as this is a problem with historical data. > Could you please be more specific > as to the steps required to automatically form a commit that > represents the change between > two commits (i.e. tags)? > Create an orphan branch: git checkout --orphan tag_branch Now for every tag, t: git checkout t git reset --soft tag_branch git add . git commit -m "t" -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.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: [PATCH] git-p4: Fix occasional truncation of symlink contents.
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
> Signed-off-by: Alex Juncu
> Signed-off-by: Alex Badea
> ---
> 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: gitk: "Can't parse git log output: { }"
Thomas Rast: Have you tried moving away .git/gitk.cache? If that fixes it, perhaps you can share it for inspection. Yes, I did, just after I sent off that email. It did not fix the problem, however. -- \\// Peter - http://www.softwolves.pp.se/ -- 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: How can I automatically create a GIT branch that represents a sequence of tags?
On Sun, Aug 11, 2013 at 12:20 AM, Fredrik Gustafsson wrote: > I don't understand, why is it better to find between which tags a error > was found and not in what commit. It's much easier to find a bug > introduced in a commit than in a tag/release. It sounds like you're > doing the bug hunting harder. Could you explain this further? For better or worse, the current state includes a lot of noisy "fixing tests" type commits which I would like to automatically skip over when hunting bugs. This is not great and is being addressed, but I am trying to make the most of the historical data we have today - which does contain tags for all builds that passed automated testing etc but does not have only good commits on the related branch. > My suggestion if you want to do this, is to have your buildtool to > checkout a special branch (let's call it tag_branch) do a git reset > to get the worktree from the newly tagged commit and commit on that > branch once for each tag it's creating, when it creates the tag. I can see how this would work, but only for future builds. I would need something like it but loop over all existing tags as this is a problem with historical data. Could you please be more specific as to the steps required to automatically form a commit that represents the change between two commits (i.e. tags)? Thanks, Kristian -- 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: How can I automatically create a GIT branch that represents a sequence of tags?
On Sat, Aug 10, 2013 at 5:29 PM, Kristian Freed wrote: > In our current setup, we have automatic tagging in git of all > successful release builds. This makes it easy to go back to stable > points in history and compare functionality, check when bugs were > introduced etc. > > To help with this process further, it would be useful to be able to > use git bisect, but as these are just a sequence of tags, not commits > on a branch, git bisect will not work as is. Why don't you just do 'git bisect skip' if the commit doesn't have a tag? > Is there any tooling for automatically recreating a branch from a > sequence of tags, where each generated commit is the calculated delta > between each two neighbouring tags? That would probably involve listing the wanted tags: % git log --topo-order --simplify-by-decoration --decorate --oneline And then generating the commits: % git cat-file -p v1.8.3 > commit # modify commit's parent % git hash-object -w < commit -- 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: How can I automatically create a GIT branch that represents a sequence of tags?
Kristian Freed writes: > To help with this process further, it would be useful to be able to > use git bisect, but as these are just a sequence of tags, not commits > on a branch, git bisect will not work as is. git bisect takes arbitrary revisions, there is no restriction on using tags as bounds. 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
[PATCH v3] push: respect --no-thin
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.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
v3 gets rid of seq in the test.
builtin/push.c | 5 ++---
builtin/receive-pack.c | 8 +++-
t/t5516-fetch-push.sh | 16
3 files changed, 25 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..da60817 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, "--no-thin")) {
+ fix_thin = 0;
+ continue;
+ }
usage(receive_pack_usage);
}
diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh
index 4691d51..3cfd1cd 100755
--- a/t/t5516-fetch-push.sh
+++ b/t/t5516-fetch-push.sh
@@ -1172,4 +1172,20 @@ 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 &&
+ git push --no-thin --receive-pack="git receive-pack --no-thin"
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: Bug in git on windows
On 2013-08-11 08.45, Илья Воронцов wrote: > git under windows doesn't check case of letters in filename. So when > one rename for example images from *.JPG to *.jpg, git doesn't files > in a repository so when one deliver this repo on *nix -system, old > filenames preserve and this matters. > It can be very confusing when some of assets in your website on server > can't be loaded after deploy, though on windows all was ok. > Possibly git windows shall identify changed case of symbols and > suggested to rename files in commit. It does (but this is disabled by default), you can try git config core.ignorecase false /Torsten -- 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: How can I automatically create a GIT branch that represents a sequence of tags?
From: "Fredrik Gustafsson" On Sat, Aug 10, 2013 at 11:29:45PM +0100, Kristian Freed wrote: In our current setup, we have automatic tagging in git of all successful release builds. This makes it easy to go back to stable points in history and compare functionality, check when bugs were introduced etc. To help with this process further, it would be useful to be able to use git bisect, but as these are just a sequence of tags, not commits on a branch, git bisect will not work as is. I was going to say simply use `git describe --contains ` and check the result is ^0 first and then either skip the commit (git bisect skip) or test it. Unfortunately I think it will conflict with the binary search style (i.e. a too sparse history with good tags). In such case it may be useful to have an alternate search style but that would be a code update. Is there any tooling for automatically recreating a branch from a sequence of tags, where each generated commit is the calculated delta between each two neighbouring tags? I don't understand, why is it better to find between which tags a error was found and not in what commit. It's much easier to find a bug introduced in a commit than in a tag/release. It sounds like you're doing the bug hunting harder. Could you explain this further? I can see that in many commercial environments that this would be considered "best practice" (which actually equates to common practice, rather than good practice). Obviously in a FOSS environment the developers are willing to use the 'rebase until ready' approaches until their patches are acceptable. In a large corporate it can be that the fixes are locally good but globally bad, hence the extra tagging step. It would be very hard to do a tool such as you describe, the reason is that there's no sane way to order your tags. Git today show tags alphabetically, all versions does not have a alphabtic order. You could argue that it should be in the order of the tagged commits commit date, however the commits are not ordered by date, an older commit can have a younger commit as a parent. You could say that the tag order is the order you find the tags if you go from a branch and backwards in the history, however how do you then choose which path to take when you find a merge? My suggestion if you want to do this, is to have your buildtool to checkout a special branch (let's call it tag_branch) do a git reset to get the worktree from the newly tagged commit and commit on that branch once for each tag it's creating, when it creates the tag. It would be quite easy to make a script that create such branch for you, if you only can sort the tags somehow. -- Med vänliga hälsningar Fredrik Gustafsson -- Philip -- 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 clone doesn't work in symlink dir roots on Windows
Thanks folks. So that this won't be fixed, I added a new Q&A to MsysGit FAQ at https://github.com/msysgit/msysgit/wiki/Frequently-Asked-Questions , I appreciate if you can review and correct if needed. I hope it will help avoiding further conversations about this matter. Sedat -- 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.
On Sun, Aug 11, 2013 at 2:16 AM, Eric Sunshine wrote: > Also, it's not clear from the documentation how one would override > pull.rebase=preserve in order to do a normal non-preserving rebase. > From reading the code, one can see that --preserve=true (or s/--preserve=true/--rebase=true/ > --no-rebase followed by --rebase) will override pull.rebase=preserve, > but it would be hard for someone to guess this. One could imagine > people thinking that --rebase alone would intuitively override > pull.rebase=preserve, or that --preserve=no-preserve would do so, but > that's getting ugly. -- 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
