* Re: [PATCH] t: don't redefine test_config() in various places
From: Ramkumar Ramachandra @ 2013-03-20 19:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git List
In-Reply-To: <7vsj3pewgl.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Ramkumar Ramachandra <artagnon@gmail.com> writes:
>
>> test_config() is already a well-defined function in
>> test-lib-functions.sh. Don't duplicate it unnecessarily in:
>>
>> t4018-diff-funcname.sh
>> t7810-grep.sh
>> t7811-grep-open.sh
>>
>> Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
>> ---
>> Thanks, Junio.
>
> Heh, I've pushed out the original one after fixing them up myself
> last night.
Doing a fine job as the editor, as always. I need to watch `pu` more closely.
^ permalink raw reply
* Re: [PATCH 3/6] t5516 (fetch-push): introduce mk_test_with_name()
From: Jonathan Nieder @ 2013-03-20 20:00 UTC (permalink / raw)
To: Jeff King; +Cc: Ramkumar Ramachandra, Git List, Junio C Hamano, Eric Sunshine
In-Reply-To: <20130320185844.GB30165@sigill.intra.peff.net>
Jeff King wrote:
> I
> tend to read the tests in a top-down manner: a test is interesting
> (usually because it fails), and then I want to see what it is doing, so
> I look at any functions it calls, and so forth.
>
> What I usually find _much_ harder to debug is when there is hidden state
> leftover from other tests.
Thanks for articulating this. I agree that keeping track of state is
the hardest part of working with git's tests.
To clarify my earlier comment, I was reading the test script from the
point of view of someone who wants to add an additional test, rather
than someone debugging an existing one. That person has a difficult
task: she needs to understand
* What do the existing tests in the script do? This information
is important in deciding whether the new test will be redundant.
* How do I work with the particular dialect used in the script,
including helpers? A new test should fit in with the style of its
surroundings to avoid contributing to an unmaintainable mess.
* What is the intended scope of the test script? Does my new test
belong in this script?
* What is the logical progression of the script? What story does this
script tell? Where should I insert my test to maintain a logical
ordering?
* What state that later tests rely on do I need to avoid clobbering?
Generally the best way to help such a person is to make the script
very simple. In particular, using standard helpers instead of custom
functions when appropriate and documenting helpers used to give new
readers a quick introduction to the dialect can help a lot.
^ permalink raw reply
* Which file is older in history?
From: Ramkumar Ramachandra @ 2013-03-20 20:21 UTC (permalink / raw)
To: Git List
Hi,
I want to compare two files in a git repository and tell which one was
introduced into the repository earlier, assuming that they're in the
same history line (by ancestry, not timestamp). The naive way to do
this is to find the individual commits that introduced the files
(`rev-list HEAD -- <filename> | tail -n 1`), and query whether there
are commits between them (`rev-list commit1 ^commit2`). However, this
is slow. What about bisecting the history until we find a tree that
contains one file but not the other?
Thanks.
Ram
^ permalink raw reply
* Re: [BUG?] rebase -i: edit versus unmerged changes
From: Ramkumar Ramachandra @ 2013-03-20 20:25 UTC (permalink / raw)
To: Andrew Wong; +Cc: Git List, Junio C Hamano
In-Reply-To: <CADeaMWoeRQBbrqLsfieKTE2rRbpzU-Hyp+mv-=CTj+=Znmf=Zw@mail.gmail.com>
Andrew Wong wrote:
> On 3/19/13, Ramkumar Ramachandra <artagnon@gmail.com> wrote:
>> I know that this is expected behavior, but is there an easy way to get
>> rid of this inconsistency?
>
> You can actually rely on "rebase" to run the appropriate command.
Didn't Junio explicitly mention that this is undesirable earlier (from
the point of view of `rebase -i` design)? The printed advice too,
says that you should use `commit --amend` to finish the job before
invoking --continue. Also IIRC, we don't allow --continue after
staging changes in the sequencer.
^ permalink raw reply
* Re: [PATCH] do not use GIT_TRACE_PACKET=3 in tests
From: Eric Sunshine @ 2013-03-20 20:29 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Sixt, Junio C Hamano, Git Mailing List
In-Reply-To: <20130320174347.GA28548@sigill.intra.peff.net>
On Wed, Mar 20, 2013 at 1:43 PM, Jeff King <peff@peff.net> wrote:
> Some test scripts use the GIT_TRACE mechanism to dump
> debugging information to descriptor 3 (and point it to a
> file using the shell). On Windows, however, bash is unable
> to set up descriptor 3. We do not write our trace to the
> file, and worse, we may interfere with other operations
> happening on descriptor 3, causing tests to fail or other
> even behave inconsistently.
s/other even/even/
^ permalink raw reply
* Re: [BUG?] rebase -i: edit versus unmerged changes
From: Jonathan Nieder @ 2013-03-20 20:42 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Andrew Wong, Git List, Junio C Hamano
In-Reply-To: <CALkWK0mgX40oicqxnoa7M3NJP_k8jDrg7mVGyWrg5T+=iRtHQA@mail.gmail.com>
Ramkumar Ramachandra wrote:
> Andrew Wong wrote:
>> You can actually rely on "rebase" to run the appropriate command.
>
> Didn't Junio explicitly mention that this is undesirable earlier (from
> the point of view of `rebase -i` design)?
I missed the earlier discussion. Does the documentation (e.g.,
git-rebase(1)) cover this? I can't think of any reason off-hand not to
rely on the DWIMery involved in "git rebase --continue".
Curious,
Jonathan
^ permalink raw reply
* Re: [PATCH] t3200 (branch): modernize style
From: Junio C Hamano @ 2013-03-20 20:43 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Git List
In-Reply-To: <1363782612-19260-1-git-send-email-artagnon@gmail.com>
Ramkumar Ramachandra <artagnon@gmail.com> writes:
> Another random patch. Found it while grep'ping around. I thought I
> could automate my work, which would have been the case if it was
> consistently inconsistent. Unfortunately, it wasn't, and I ended up
> doing a lot of manual janitorial work :|
Thanks. It would have been nicer to also fix the redirection,
e.g. "cmd >target" (not "cmd > target") that appear in the first
hunk, i.e. this on top (I'll squash this in myself).
t/t3200-branch.sh | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh
index 3203b15..74fbba1 100755
--- a/t/t3200-branch.sh
+++ b/t/t3200-branch.sh
@@ -8,10 +8,10 @@ test_description='git branch assorted tests'
. ./test-lib.sh
test_expect_success 'prepare a trivial repository' '
- echo Hello > A &&
+ echo Hello >A &&
git update-index --add A &&
git commit -m "Initial commit." &&
- echo World >> A &&
+ echo World >>A &&
git update-index --add A &&
git commit -m "Second commit." &&
HEAD=$(git rev-parse --verify HEAD)'
@@ -750,7 +750,7 @@ test_expect_success 'detect misconfigured autosetuprebase (bad value)' '
test_expect_success 'detect misconfigured autosetuprebase (no value)' '
git config --unset branch.autosetuprebase &&
- echo "[branch] autosetuprebase" >> .git/config &&
+ echo "[branch] autosetuprebase" >>.git/config &&
test_must_fail git branch &&
git config --unset branch.autosetuprebase
'
^ permalink raw reply related
* RE: FW: Windows. Git, and Dedupe
From: Josh Rowe @ 2013-03-20 20:43 UTC (permalink / raw)
To: René Scharfe; +Cc: git@vger.kernel.org, msysgit@googlegroups.com
In-Reply-To: <514A140C.1040901@lsrfire.ath.cx>
If you have Win8 or HyperV 2012, I can ship you a small NTFS .vhd with some deduped files. I'm not sure if that will be readable, but I would hazard a guess that it would be. It definitely will not be readable on Win7.
I'm using:
PS C:\> git version
git version 1.8.0.msysgit.0
I don't see any changes related to this in the file log since the original code was added in 2010. I do notice that mingw_fstat doesn't do anything special with symlinks; I don't know where that is used.
The file sizes show up as their original size with Windows tools (powershell, Win32, cmd, .Net, etc). git ls-tree -r HEAD does not show that hash code for files that are not intentionally empty.
Jmr
-----Original Message-----
From: René Scharfe [mailto:rene.scharfe@lsrfire.ath.cx]
Sent: Wednesday, March 20, 2013 12:55 PM
To: Josh Rowe
Cc: git@vger.kernel.org; msysgit@googlegroups.com
Subject: Re: FW: Windows. Git, and Dedupe
Am 19.03.2013 22:36, schrieb Josh Rowe:
> Yes, Dedup is in fact a Server-only feature.
Is there an easier way to reproduce the issue than registering and downloading the Windows Server 2012 evaluation version? It's not that hard, admittedly, but still.
> The reparse point could be decoded as being a non-symlink reparse
> itemusing; in those cases, treating the file as an "ordinary"
> file would be appropriate.
>
> For example, see the following. The reparse tag value for symlinks
> isIO_REPARSE_TAG_SYMLINK (0xa000000c) and for deduped files is
> (IO_REPARSE_TAG_DEDUP) 0x80000013.
That's interesting and invalidates my initial checks with mklink, because if I read compat/mingw.c [1] correctly then git handles symlinks on Windows in a special way, but should treat dedup reparse points as normal files already.
Hrm, but probably st_size is set to zero for them. Do the deduped files appear as empty? "git ls-tree -r HEAD" would show them with a hash of e69de29bb2d1d6434b8b29ae775ad8c2e48c5391. If true then how do we get their real content sizes using Win32 API calls?
By the way, what does the command "git version" return for you?
Thanks,
René
[1] https://git.kernel.org/cgit/git/git.git/tree/compat/mingw.c#n427
^ permalink raw reply
* Re: [BUG?] rebase -i: edit versus unmerged changes
From: Junio C Hamano @ 2013-03-20 20:45 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Andrew Wong, Git List
In-Reply-To: <CALkWK0mgX40oicqxnoa7M3NJP_k8jDrg7mVGyWrg5T+=iRtHQA@mail.gmail.com>
Ramkumar Ramachandra <artagnon@gmail.com> writes:
> Andrew Wong wrote:
>> On 3/19/13, Ramkumar Ramachandra <artagnon@gmail.com> wrote:
>>> I know that this is expected behavior, but is there an easy way to get
>>> rid of this inconsistency?
>>
>> You can actually rely on "rebase" to run the appropriate command.
>
> Didn't Junio explicitly mention that this is undesirable earlier (from
> the point of view of `rebase -i` design)?
I am sure it is my fault but my memory fails me. As Andrew
mentioned, "rebase --continue" seemed to get this right.
^ permalink raw reply
* Re: Which file is older in history?
From: Junio C Hamano @ 2013-03-20 20:46 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Git List
In-Reply-To: <CALkWK0nTjoR9qBY-hnkrDKnyf8088ZDJ1LK_zNqAoAB7ndvaww@mail.gmail.com>
Ramkumar Ramachandra <artagnon@gmail.com> writes:
> I want to compare two files in a git repository and tell which one was
> introduced into the repository earlier, assuming that they're in the
> same history line (by ancestry, not timestamp). The naive way to do
> this is to find the individual commits that introduced the files
> (`rev-list HEAD -- <filename> | tail -n 1`), and...
This must be a trick question but the naïve way I think of is
git log --diff-filter=A -- path1 path2
^ permalink raw reply
* Re: [PATCH] do not use GIT_TRACE_PACKET=3 in tests
From: Jeff King @ 2013-03-20 20:58 UTC (permalink / raw)
To: Eric Sunshine; +Cc: Johannes Sixt, Junio C Hamano, Git Mailing List
In-Reply-To: <CAPig+cQhG-oE5n-RjxhHqGoPzTZbLGagU+9gxzrJhaOcUAtffQ@mail.gmail.com>
On Wed, Mar 20, 2013 at 04:29:40PM -0400, Eric Sunshine wrote:
> On Wed, Mar 20, 2013 at 1:43 PM, Jeff King <peff@peff.net> wrote:
> > Some test scripts use the GIT_TRACE mechanism to dump
> > debugging information to descriptor 3 (and point it to a
> > file using the shell). On Windows, however, bash is unable
> > to set up descriptor 3. We do not write our trace to the
> > file, and worse, we may interfere with other operations
> > happening on descriptor 3, causing tests to fail or other
> > even behave inconsistently.
>
> s/other even/even/
Urgh, I should probably add another proofreading pass to my commit
messages. Thanks.
-Peff
^ permalink raw reply
* Re: [PATCH] t3200 (branch): modernize style
From: Junio C Hamano @ 2013-03-20 21:34 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Git List
In-Reply-To: <7vwqt1dcp1.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Ramkumar Ramachandra <artagnon@gmail.com> writes:
>
>> Another random patch. Found it while grep'ping around. I thought I
>> could automate my work, which would have been the case if it was
>> consistently inconsistent. Unfortunately, it wasn't, and I ended up
>> doing a lot of manual janitorial work :|
>
> Thanks. It would have been nicer to also fix the redirection,
> e.g. "cmd >target" (not "cmd > target") that appear in the first
> hunk, i.e. this on top (I'll squash this in myself).
By the way, please pick a time when a file is quiescent, next time
when your grep urges you to do a file-wide clean-up. I _think_ I
got the conflicts with an in-flight topic resolved correctly, but I
may have made trivial and stupid mistakes while doing so.
Thanks.
^ permalink raw reply
* Re: FW: Windows. Git, and Dedupe
From: René Scharfe @ 2013-03-20 21:45 UTC (permalink / raw)
To: Josh Rowe; +Cc: git@vger.kernel.org, msysgit@googlegroups.com
In-Reply-To: <2156b5b7b012490490c1b52637a6164a@BLUPR03MB019.namprd03.prod.outlook.com>
Am 20.03.2013 21:43, schrieb Josh Rowe:
> If you have Win8 or HyperV 2012, I can ship you a small NTFS .vhd
> with some deduped files. I'm not sure if that will be readable, but
> I would hazard a guess that it would be. It definitely will not be
> readable on Win7.
It would be nice if you could upload it to an FTP server or website and
post a public link so that the real git-on-Windows developers can get it
as well. You can also send it to me personally and I'll see if I can
mount it using Windows 8 and where I get from there. In any case,
please make sure there's no sensitive or private data in the VHD file.
How big is it after compression using (preferably) 7-Zip or ZIP?
> I'm using:
>
> PS C:\> git version git version 1.8.0.msysgit.0
That means compat/mingw.c is directly relevant to you; more about MinGW,
MSys and git at http://msysgit.github.com/ and http://mingw.org/.
> The file sizes show up as their original size with Windows tools
> (powershell, Win32, cmd, .Net, etc). git ls-tree -r HEAD does not
> show that hash code for files that are not intentionally empty.
So we can likely (hopefully) get the sizes of deduped files with the
same API calls as for regular ones. Which makes me even more puzzled
over the question of why git makes a difference between the two kinds.
René
--
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
---
You received this message because you are subscribed to the Google Groups "msysGit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
^ permalink raw reply
* Re: [PATCH v3 3/4] t7800: modernize tests
From: David Aguilar @ 2013-03-20 22:59 UTC (permalink / raw)
To: Johannes Sixt, Sitaram Chamarty; +Cc: Junio C Hamano, git, Jonathan Nieder
In-Reply-To: <514985FB.8080806@viscovery.net>
On Wed, Mar 20, 2013 at 2:48 AM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> Am 2/21/2013 5:03, schrieb David Aguilar:
>> test_expect_success PERL 'difftool -d' '
>> - diff=$(git difftool -d --extcmd ls branch) &&
>> - echo "$diff" | stdin_contains sub &&
>> - echo "$diff" | stdin_contains file
>> + git difftool -d --extcmd ls branch >output &&
>> + stdin_contains sub <output &&
>> + stdin_contains file <output
>> '
>
> This test is broken on Windows. There is this code in git-difftool.perl
>
> for my $file (@worktree) {
> ...
> copy("$b/$file", "$workdir/$file") or
> exit_cleanup($tmpdir, 1);
> ...
> }
>
> @worktree is populated with all files in the worktree. At this point,
> "output" is among them. Then follows an attempt to copy a file over
> "$workdir/$file". I guess that is some link+remove magic going on behind
> the scenes. At any rate, this fails on Windows with
> "D:/Src/mingw-git/t/trash directory.t7800-difftool/../../git-difftool line
> 408: Bad file number", because files that are open cannot be written from
> outside (the file is open due to the redirection in the test snippet).
>
> What is going on here? Why can this ever succeed even on Unix?
Thanks for the report. Yes, these do pass on Unix.
Hmm I wonder what's going on here?
I started digging in and the @worktree_files (aka @worktree above)
is populated from the output of "git diff --raw ...".
Seeing the "output" filename in "diff --raw" implies that one of the
tests added "output" to the index somehow. I do not see that
happening anywhere, though, so I do not know how it would end up in
the @worktree array if it is not reported by "diff --raw".
My current understanding of how it could possibly be open twice:
1. via the >output redirect
2. via the copy() perl code which is fed by @worktree
So I'm confused. Why would we get different results on Windows?
I just re-ran these tests from "next" to check my sanity and they
passed on both Linux and OS X.
> Same for some later tests.
Ditto.
> BTW, while debugging this, I found the use of the helper function
> stdin_contains() highly unhelpful; it just resolves to a 'grep' that on
> top of all hides stdout. Please don't do that. Just use unadorned grep
> like we do everywhere else.
I'm not too opposed to that.
The one small advantage to the helper is that you can tweak the redirect
in one central place, so it's not all for naught.
Sitaram, you added this back in:
ba959de1 git-difftool: allow skipping file by typing 'n' at prompt
Do you have any thoughts?
It seems like removing the stdout redirect could be helpful for debugging,
and if we did that then there's really no point in having the helper
(aside from the indirection which can sometimes help during debugging).
I don't really feel too strongly either way, but it did bother you
while debugging the test script, so unadorned grep seems like the way to go.
I'll wait and see if anybody else has any Windows-specific clues that
we can use to narrow down this problem.
In lieu of an immediate fix, are there any test prerequisite we can
use to skip these tests on windows? One or both of NOT_CYGWIN,NOT_MINGW?
--
David
^ permalink raw reply
* Re: [PATCH v2 0/6] Support triangular workflows
From: Philip Oakley @ 2013-03-20 23:04 UTC (permalink / raw)
To: Ramkumar Ramachandra, Git List
Cc: Junio C Hamano, Jeff King, Eric Sunshine, Jonathan Nieder
In-Reply-To: <1363783501-27981-1-git-send-email-artagnon@gmail.com>
From: "Ramkumar Ramachandra" <artagnon@gmail.com>
Sent: Wednesday, March 20, 2013 12:44 PM
> This follows-up [1], with three important differences:
>
> 1. pushremote_get() and remote_get() share code better. Thanks Jeff.
>
> 2. All spelling mistakes have been corrected. Thanks Eric.
>
> 3. One new test for each of the new configuration variables. The
> extra two parts [2/6] and [3/6] preprare the file for introducing
> tests. However, I've not gone overboard in this preparation; I don't
> replicate the work done by Jonathan in [2].
>
> Thanks for reading.
>
> [1]: http://thread.gmane.org/gmane.comp.version-control.git/218410
> [2]:
> http://thread.gmane.org/gmane.comp.version-control.git/218451/focus=218465
>
> Ramkumar Ramachandra (6):
> remote.c: simplify a bit of code using git_config_string()
> t5516 (fetch-push): update test description
> t5516 (fetch-push): introduce mk_test_with_name()
> remote.c: introduce a way to have different remotes for fetch/push
> remote.c: introduce remote.pushdefault
> remote.c: introduce branch.<name>.pushremote
>
> Documentation/config.txt | 23 +++++++++++++++---
Shouldn't Documentation/gitworkflows.txt also be updated with the
triangular workflow and its configuration?
> builtin/push.c | 2 +-
> remote.c | 36 +++++++++++++++++++++------
> remote.h | 1 +
> t/t5516-fetch-push.sh | 63
> ++++++++++++++++++++++++++++++++++++++++--------
> 5 files changed, 104 insertions(+), 21 deletions(-)
>
> --
> 1.8.2
>
^ permalink raw reply
* [PATCH] git-am: fix "Applying" message when applypatch-hook was run
From: Simon Ruderich @ 2013-03-20 23:18 UTC (permalink / raw)
To: git
---
Hello,
This patch fixes a minor issue with git-am. When the
applypatch-hook modifies the commit message, git-am displays the
original message. This patch updates the message to use the
modified version.
Regards
Simon
git-am.sh | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/git-am.sh b/git-am.sh
index 202130f..0997077 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -795,6 +795,14 @@ To restore the original branch and stop patching run \"\$cmdline --abort\"."
then
"$GIT_DIR"/hooks/applypatch-msg "$dotest/final-commit" ||
stop_here $this
+
+ # applypatch-msg can update the commit message.
+ if test -f "$dotest/final-commit"
+ then
+ FIRSTLINE=$(sed 1q "$dotest/final-commit")
+ else
+ FIRSTLINE=""
+ fi
fi
say "$(eval_gettext "Applying: \$FIRSTLINE")"
--
1.8.2
--
+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0x92FEFDB7E44C32F9
^ permalink raw reply related
* Re: [PATCH] git-am: fix "Applying" message when applypatch-hook was run
From: Matthieu Moy @ 2013-03-20 23:36 UTC (permalink / raw)
To: Simon Ruderich; +Cc: git
In-Reply-To: <b978a77f8a37c47b2d6c2201d1f7cfffa01f8443.1363820289.git.simon@ruderich.org>
Simon Ruderich <simon@ruderich.org> writes:
> ---
> Hello,
>
> This patch fixes a minor issue with git-am. When the
> applypatch-hook modifies the commit message, git-am displays the
> original message. This patch updates the message to use the
> modified version.
Please, read SubmittingPatches in the Documentation directory of Git's
source tree. Your text above should be a commit message (hence, no
hello), and should not be below the --- line.
Also, read about signed-off-by in the same document.
> diff --git a/git-am.sh b/git-am.sh
> index 202130f..0997077 100755
> --- a/git-am.sh
> +++ b/git-am.sh
> @@ -795,6 +795,14 @@ To restore the original branch and stop patching run \"\$cmdline --abort\"."
> then
> "$GIT_DIR"/hooks/applypatch-msg "$dotest/final-commit" ||
> stop_here $this
> +
> + # applypatch-msg can update the commit message.
> + if test -f "$dotest/final-commit"
> + then
> + FIRSTLINE=$(sed 1q "$dotest/final-commit")
> + else
> + FIRSTLINE=""
> + fi
> fi
This copy/paste a piece of code that is already a few lines above. Is
there any reason not to _move_ the assignment to FIRSTLINE after the "if
test -x "$GIT_DIR"/hooks/applypatch-msg", to avoid duplicating?
Thanks,
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH] git-am: fix "Applying" message when applypatch-hook was run
From: Junio C Hamano @ 2013-03-20 23:52 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Simon Ruderich, git
In-Reply-To: <vpqli9hmyov.fsf@grenoble-inp.fr>
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> Please, read SubmittingPatches in the Documentation directory of Git's
> source tree. Your text above should be a commit message (hence, no
> hello), and should not be below the --- line.
>
> Also, read about signed-off-by in the same document.
> ...
> This copy/paste a piece of code that is already a few lines above. Is
> there any reason not to _move_ the assignment to FIRSTLINE after the "if
> test -x "$GIT_DIR"/hooks/applypatch-msg", to avoid duplicating?
More importantly, is this change even desirable?
The original motivation behind the "Applying:" message was to help
the user identify which one of the 100+ patches being fed to the
command, and it was not about showing what we ended up committing.
When you are running the command interactively, we do grab the
edited result since f23272f3fd84 (git-am -i: report rewritten title,
2007-12-04), but I tend to feel that the automated munging done by
applypatch-msg falls into a different category.
^ permalink raw reply
* Re: [PATCH] git-am: fix "Applying" message when applypatch-hook was run
From: Simon Ruderich @ 2013-03-21 2:40 UTC (permalink / raw)
To: Matthieu Moy, Junio C Hamano; +Cc: git
In-Reply-To: <vpqli9hmyov.fsf@grenoble-inp.fr>
applypatch-hook can modify the commit message. Display the updated
commit message instead of the original one.
Signed-off-by: Simon Ruderich <simon@ruderich.org>
---
On Thu, Mar 21, 2013 at 12:36:00AM +0100, Matthieu Moy wrote:
> Please, read SubmittingPatches in the Documentation directory of Git's
> source tree. Your text above should be a commit message (hence, no
> hello), and should not be below the --- line.
>
> Also, read about signed-off-by in the same document.
Hello Matthieu,
Thank you for the suggestions. I've adapted the patch message and
added the signed-off.
> This copy/paste a piece of code that is already a few lines above. Is
> there any reason not to _move_ the assignment to FIRSTLINE after the "if
> test -x "$GIT_DIR"/hooks/applypatch-msg", to avoid duplicating?
No, there wasn't a reason not to move the code. I just wasn't
sure if it had any side effects. But I rechecked and it should
work fine. Updating version attached.
On Wed, Mar 20, 2013 at 04:52:43PM -0700, Junio C Hamano wrote:
> More importantly, is this change even desirable?
>
> The original motivation behind the "Applying:" message was to help
> the user identify which one of the 100+ patches being fed to the
> command, and it was not about showing what we ended up committing.
> When you are running the command interactively, we do grab the
> edited result since f23272f3fd84 (git-am -i: report rewritten title,
> 2007-12-04), but I tend to feel that the automated munging done by
> applypatch-msg falls into a different category.
When I first used the applypatch-msg hook I was confused because
the messages were different and I thought the hook wasn't
working, hence the patch.
I'm not sure how extensive most applypatch-msg hooks modify the
commit message (in my case just a number prepended), but I think
it's more natural and less confusing to see the message which is
being applied.
If the original behaviour is preferred, a short comment in
githooks(5) should prevent any confusion.
Regards
Simon
git-am.sh | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index 202130f..c092855 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -778,13 +778,6 @@ To restore the original branch and stop patching run \"\$cmdline --abort\"."
action=yes
fi
- if test -f "$dotest/final-commit"
- then
- FIRSTLINE=$(sed 1q "$dotest/final-commit")
- else
- FIRSTLINE=""
- fi
-
if test $action = skip
then
go_next
@@ -797,6 +790,13 @@ To restore the original branch and stop patching run \"\$cmdline --abort\"."
stop_here $this
fi
+ if test -f "$dotest/final-commit"
+ then
+ FIRSTLINE=$(sed 1q "$dotest/final-commit")
+ else
+ FIRSTLINE=""
+ fi
+
say "$(eval_gettext "Applying: \$FIRSTLINE")"
case "$resolved" in
--
1.8.2
--
+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0x92FEFDB7E44C32F9
^ permalink raw reply related
* Re: [PATCH v2 00/45] parse_pathspec and :(glob) magic
From: Duy Nguyen @ 2013-03-21 5:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1ubaeyph.fsf@alter.siamese.dyndns.org>
On Wed, Mar 20, 2013 at 11:02:50AM -0700, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
>
> > Junio please pull the series from github [1]....
> > [1] https://github.com/pclouds/git/commits/parse-pathspec
>
> Please write it like this:
>
> https://github.com/pclouds/git parse-pathspec
>
> so that I can just say
>
> git fetch <<that thing>>
> git diff nd/magic-pathspecs FETCH_HEAD
OK
> I am still getting this out of 7300, though.
I still can't reproduce it. But I think I found a bug that
miscalculates prefix length from absolute paths. Does this "fix" your
test?
-- 8< --
diff --git a/setup.c b/setup.c
index 3584f22..6ae147a 100644
--- a/setup.c
+++ b/setup.c
@@ -14,6 +14,7 @@ char *prefix_path_gently(const char *prefix, int *p_len, const char *path)
const char *temp = real_path(path);
sanitized = xmalloc(len + strlen(temp) + 1);
strcpy(sanitized, temp);
+ *p_len = 0;
} else {
sanitized = xmalloc(len + strlen(path) + 1);
if (len)
-- 8< --
^ permalink raw reply related
* Re: [PATCH v2 00/45] parse_pathspec and :(glob) magic
From: Duy Nguyen @ 2013-03-21 5:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20130321053326.GA17446@duynguyen-vnpc.dek-tpc.internal>
On Thu, Mar 21, 2013 at 12:33:26PM +0700, Duy Nguyen wrote:
> > I am still getting this out of 7300, though.
>
> I still can't reproduce it. But I think I found a bug that
> miscalculates prefix length from absolute paths. Does this "fix" your
> test?
>
> -- 8< --
> diff --git a/setup.c b/setup.c
> index 3584f22..6ae147a 100644
> --- a/setup.c
> +++ b/setup.c
> @@ -14,6 +14,7 @@ char *prefix_path_gently(const char *prefix, int *p_len, const char *path)
> const char *temp = real_path(path);
> sanitized = xmalloc(len + strlen(temp) + 1);
> strcpy(sanitized, temp);
> + *p_len = 0;
> } else {
> sanitized = xmalloc(len + strlen(path) + 1);
> if (len)
>
> -- 8< --
Nope, that one could cause more crashes. Try this
-- 8< --
diff --git a/setup.c b/setup.c
index 3584f22..3d8eb97 100644
--- a/setup.c
+++ b/setup.c
@@ -14,6 +14,8 @@ char *prefix_path_gently(const char *prefix, int *p_len, const char *path)
const char *temp = real_path(path);
sanitized = xmalloc(len + strlen(temp) + 1);
strcpy(sanitized, temp);
+ if (p_len)
+ *p_len = 0;
} else {
sanitized = xmalloc(len + strlen(path) + 1);
if (len)
-- 8< --
^ permalink raw reply related
* Re: [PATCH] do not use GIT_TRACE_PACKET=3 in tests
From: Johannes Sixt @ 2013-03-21 6:36 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <20130320174347.GA28548@sigill.intra.peff.net>
Am 3/20/2013 18:43, schrieb Jeff King:
> Now that we are using the GIT_TRACE mechanism, we can
> improve both scripts by asking git to write directly to a
> file rather than a descriptor. That fixes the hang in t5700,
> and should allow t5503 to successfully run on Windows.
Well spotted, and, right, both tests pass with this patch.
Tested-by: Johannes Sixt <j6t@kdbg.org>
Thanks,
-- Hannes
^ permalink raw reply
* Re: gitk says "file name too long"
From: steven Loker @ 2013-03-21 6:39 UTC (permalink / raw)
To: git
In-Reply-To: <hm5usf$6ba$1@dough.gmane.org>
Use LongPathTool. If u had problem with files i suggest this software.
http://LongPathTool.com
--
View this message in context: http://git.661346.n2.nabble.com/gitk-says-file-name-too-long-tp4632510p7580237.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH jk/checkout-attribute-lookup] t2003: work around path mangling issue on Windows
From: Johannes Sixt @ 2013-03-21 6:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vli9if159.fsf@alter.siamese.dyndns.org>
Am 3/20/2013 18:10, schrieb Junio C Hamano:
> Johannes Sixt <j.sixt@viscovery.net> writes:
>
>> From: Johannes Sixt <j6t@kdbg.org>
>>
>> MSYS bash considers the part "/g" in the sed expression "s/./=/g" as an
>> absolute path after an assignment, and mangles it to a C:/something
>> string. Do not attract bash's attention by avoiding the equals sign.
>
> If this breakage is about path mangling, I suspect it may be cleaner
> to work it around by not using / as the pattern separator, e.g.
>
> sed -e s!.!=!g
Half a year down the road you'd scratch your head why you were not using
'/' as separator. As the replacement character is irrelevant here, it's
better to exchange that. Therefore, I still prefer my version.
> Or perhaps use SHELL_PATH to point at a more reasonable
> implementation of shell that does not have such an idiocy?
Well, POSIX and DOS paths look inherently different, particularly absolute
paths. You can't write a reasonably portable shell script if the shell
doesn't help in some way.
Not to mention that the supply of POSIX shells on Windows is inherently
scarce.
-- Hannes
^ permalink raw reply
* Re: [PATCH v3 3/4] t7800: modernize tests
From: Johannes Sixt @ 2013-03-21 7:41 UTC (permalink / raw)
To: David Aguilar; +Cc: Sitaram Chamarty, Junio C Hamano, git, Jonathan Nieder
In-Reply-To: <CAJDDKr4O-OU57j0f7F2E2_4EvtCTE1gFP5uLv+fvD6VcpPiifg@mail.gmail.com>
Am 3/20/2013 23:59, schrieb David Aguilar:
> I started digging in and the @worktree_files (aka @worktree above)
> is populated from the output of "git diff --raw ...".
>
> Seeing the "output" filename in "diff --raw" implies that one of the
> tests added "output" to the index somehow. I do not see that
> happening anywhere, though, so I do not know how it would end up in
> the @worktree array if it is not reported by "diff --raw".
>
>
> My current understanding of how it could possibly be open twice:
>
> 1. via the >output redirect
> 2. via the copy() perl code which is fed by @worktree
>
> So I'm confused. Why would we get different results on Windows?
I tracked down the difference between Windows and Linux, and it is...
for my $file (@worktree) {
next if $symlinks && -l "$b/$file";
... this line in sub dir_diff. On Linux, we take the short-cut, but on
Windows we proceed through the rest of the loop, which ultimately finds a
difference here:
my $diff = compare("$b/$file", "$workdir/$file");
and attempts to copy a file here:
copy("$b/$file", "$workdir/$file") or
where one of the files is the locked "output" file.
I don't know how essential symlinks are for the operation of git-difftool
and whether something can be done about it. The immediate fix is
apparently to protect the tests with SYMLINKS.
-- Hannes
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox