[PATCH] t7502-commit.sh: fix a broken and-chain
Signed-off-by: Ramsay Jones ram...@ramsay1.demon.co.uk --- Hi Junio, This test recently started failing for me. I haven't heard anyone else complaining about this, so maybe I should look into why my environment may be different to everyone else ... :-D (when I can find some time, of course!) ATB, Ramsay Jones t/t7502-commit.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/t/t7502-commit.sh b/t/t7502-commit.sh index 051489e..2e0d557 100755 --- a/t/t7502-commit.sh +++ b/t/t7502-commit.sh @@ -370,7 +370,7 @@ exit 0 EOF test_expect_success !AUTOIDENT 'do not fire editor when committer is bogus' ' - .git/result + .git/result expect echo negative -- 2.3.0 -- 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
How are submodule conflicts resolved during rebase?
Hey guys, I'm using Git for Windows 2.3.6. There is a bit of confusion I have with regards to how submodule conflicts are resolved/handled during a rebase. Suppose I have a branch with 10 commits on it, 3 of those commits contain a change to the same (and only) submodule in the repository. When I rebase this branch onto the tip of its parent branch, I get a conflict in each of the 3 commits because the submodule also changed on the parent branch since my last rebase. I've seen some cases where I am asked to resolve the submodule conflict with local or remote. I expect this behavior and it isn't confusing to me. However, I have also seen cases where rebase auto resolves the conflicted submodule. How does Git know to auto resolve some submodule conflicts but not the others? I find this behavior unpredictable and I haven't found any documentation on it (I'm giving the git docs the benefit of the doubt and assuming it's there, since the git docs are very very good). Help is appreciated. Thank you. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Help with Getting started to Contribute
Hi , I would like to contribute to git. Can you guys point me to some useful resources to get me started to contribute to git. Also does git have something like junior jobs so that It can be done by new to contribution. Also searching about the git in google points to some other organisation which uses git :((well this is because of the popularity of the git) -- 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 report : bad filter-branch (OSX only)
2015-04-28 7:55 GMT+02:00 Jeff King p...@peff.net: On Sun, Apr 26, 2015 at 11:25:52AM +0200, Olivier ROLAND wrote: OSX 10.10.3 git 2.3.6 HFS+ case-sensitive How to reproduce : Step 1 : git clone https://github.com/begeric/FastParsers.git Step 2 : cd FastParsers/ Step 3 : git filter-branch --env-filter 'if [ 0 = 1 ]; then echo 0; fi' -- --all Result on OSX : Rewrite 65df7c5ac1ed956252b07b8c911ad7eba0a15c2b (206/206) Ref 'refs/heads/experiment' was rewritten Ref 'refs/remotes/origin/experiment' was rewritten WARNING: Ref 'refs/remotes/origin/experiment' is unchanged Ref 'refs/remotes/origin/master' was rewritten Result on Debian : Rewrite 65df7c5ac1ed956252b07b8c911ad7eba0a15c2b (206/206) WARNING: Ref 'refs/heads/experiment' is unchanged WARNING: Ref 'refs/remotes/origin/experiment' is unchanged WARNING: Ref 'refs/remotes/origin/experiment' is unchanged WARNING: Ref 'refs/remotes/origin/master' is unchanged Do you have any thoughts on this ? Weird. Did you build both versions of git from source (that is, there's no question that the OS X one is a hacked-up Apple git or something)? Presumably it's some incompatibility in the shells used. What does: head -1 $(git --exec-path)/git-filter-branch say about the shell in use on each system? Does running that shell with --version report anything useful? -Peff Hi, Both versions are builded from source. head -1 $(git --exec-path)/git-filter-branch #!/bin/sh sh --version GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin14) Copyright (C) 2007 Free Software Foundation, Inc. /bin/bash --version GNU bash, version 4.1.5(1)-release (x86_64-pc-linux-gnu) The bug seem really git related. 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 v5 1/5] setup: add gentle version of read_gitfile
On Tue, Apr 28, 2015 at 8:17 AM, Jeff King p...@peff.net wrote: There was a discussion not too long ago on strategies for returning errors, and one of the suggestions was to return an error strbuf rather than a code[1]. That's less flexible, as the caller can't react differently based on the type of error. But for cases like this, where the only fate for the code is to get converted back into a message, it can reduce the boilerplate. What you have here is OK to me, and I don't want to hold up your patch series in a flamewar about error-reporting techniques. But I think it's an interesting case study. -Peff Thanks. I haven't had time to look through that thread yet, I'll try to get to that later. My initial reaction is a bit skeptical though. For this case we currently don't want any error reporting, the NULL return is sufficient and even allocating and sending in the int* is pure noise. Allocating and releasing a strbuf seems like a lot more overhead for this type of caller? The one other potential candidate caller for read_gitfile_gently that I have seen (clone.c:get_repo_path) don't want any error code or message either as far as i can tell. Also if it turns out that we actually need to treat the file too large error differently in clean (as discussed in thread on the file size check) then we can no longer communicate that back using the strbuf interface. Overall it seems like a less attractive solution to me but I can be persuaded if there is more support expressed for the strbuf direction. /Erik -- 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] rebase -i: redo tasks that die during cherry-pick
When rebase--interactive processes a task, it removes the item from
the todo list and appends it to another list of executed tasks. If a
pick (this includes squash and fixup) fails before the index has
recorded the changes, take the corresponding item and put it on the todo
list again. Otherwise, the changes introduced by the scheduled commit
would be lost.
That kind of decision is possible since the cherry-pick command
signals why it failed to apply the changes of the given commit. Either
the changes are recorded in the index using a conflict (return value 1)
and rebase does not continue until they are resolved or the changes
are not recorded in the index (return value neither 0 nor 1) and
rebase has to try again with the same task.
Add a test cases for regression testing to the rebase-interactive
test suite.
Signed-off-by: Fabian Ruch baf...@gmail.com
Signed-off-by: Phil Hord ho...@cisco.com
---
Notes:
Last year in ${gmane}/250126 Fabian Ruch helpfully provided a patch
to fix a rebase bug I complained about. I have simplified it a bit
and merged in the tests which had been in a separate commit.
It has bitten me twice since the original discussion and has also
been reported by others, though I haven't found those emails to
add them to the CC list yet.
CC: Michael Haggerty mhag...@alum.mit.edu
git-rebase--interactive.sh| 16 +++
t/t3404-rebase-interactive.sh | 47 +++
2 files changed, 63 insertions(+)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 08e5d86..bab0dcc 100644
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -132,6 +132,16 @@ mark_action_done () {
fi
}
+# Put the last action marked done at the beginning of the todo list
+# again. If there has not been an action marked done yet, leave the list of
+# items on the todo list unchanged.
+reschedule_last_action () {
+ tail -n 1 $done | cat - $todo $todo.new
+ sed -e \$d $done $done.new
+ mv -f $todo.new $todo
+ mv -f $done.new $done
+}
+
append_todo_help () {
git stripspace --comment-lines $todo \EOF
@@ -252,6 +262,12 @@ pick_one () {
output eval git cherry-pick \
${gpg_sign_opt:+$(git rev-parse --sq-quote
$gpg_sign_opt)} \
$strategy_args $empty_args $ff $@
+
+ # If cherry-pick dies it leaves the to-be-picked commit unrecorded.
Reschedule
+ # previous task so this commit is not lost.
+ ret=$?
+ case $ret in [01]) ;; *) reschedule_last_action ;; esac
+ return $ret
}
pick_one_preserving_merges () {
diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
index eed76cc..ac429a0 100755
--- a/t/t3404-rebase-interactive.sh
+++ b/t/t3404-rebase-interactive.sh
@@ -1055,4 +1055,51 @@ test_expect_success 'todo count' '
grep ^# Rebase ..* onto ..* ([0-9] actual
'
+test_expect_success 'rebase -i commits that overwrite untracked files (pick)' '
+ git checkout --force branch2
+ git clean -f
+ set_fake_editor
+ FAKE_LINES=edit 1 2 git rebase -i A
+ test_cmp_rev HEAD F
+ test_path_is_missing file6
+ file6
+ test_must_fail git rebase --continue
+ test_cmp_rev HEAD F
+ rm file6
+ git rebase --continue
+ test_cmp_rev HEAD I
+'
+
+test_expect_success 'rebase -i commits that overwrite untracked files
(squash)' '
+ git checkout --force branch2
+ git clean -f
+ git tag original-branch2
+ set_fake_editor
+ FAKE_LINES=edit 1 squash 2 git rebase -i A
+ test_cmp_rev HEAD F
+ test_path_is_missing file6
+ file6
+ test_must_fail git rebase --continue
+ test_cmp_rev HEAD F
+ rm file6
+ git rebase --continue
+ test $(git cat-file commit HEAD | sed -ne \$p) = I
+ git reset --hard original-branch2
+'
+
+test_expect_success 'rebase -i commits that overwrite untracked files (no ff)'
'
+ git checkout --force branch2
+ git clean -f
+ set_fake_editor
+ FAKE_LINES=edit 1 2 git rebase -i --no-ff A
+ test $(git cat-file commit HEAD | sed -ne \$p) = F
+ test_path_is_missing file6
+ file6
+ test_must_fail git rebase --continue
+ test $(git cat-file commit HEAD | sed -ne \$p) = F
+ rm file6
+ git rebase --continue
+ test $(git cat-file commit HEAD | sed -ne \$p) = I
+'
+
test_done
--
2.4.0.rc3.329.gd1f7d3b
--
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 show' with multiple revisions
On Tue, Apr 28, 2015 at 10:10:52AM +, Ed Avis wrote:
Could 'git show' sprout an option to get multiple things programmatically
so that they can be separated out again? One way would be to quote or escape
the contents somehow so that the result can be parsed:
% git show --porcelain REV1:FILE REV2:FILE
[...]
Note that here I am only getting the file content, not log messages or any of
the other things which 'git show' can produce. So perhaps what I really want
is some kind of 'git cat'. Or is there another more appropriate tool?
I think you want `git cat-file`:
{
echo REV1:FILE
echo REV2:FILE
} |
git cat-file --batch
This prints a header line for each output object which contains the size
of the object (so a parser reads a header line, then N bytes, then a
header line, N bytes, and so on).
-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 1/5] setup: add gentle version of read_gitfile
Jeff King p...@peff.net writes: Yes, I agree converting the integer back into a string later does not always carry all of the data. OTOH, the caller can often supply the context (i.e., this is basically how errno works). This gets back to the idea we discussed a while ago of having a struct error that can carry the code and the parameters (or if you like, the code and a finished error message). It just feels in some ways like that ends up with the worst of both worlds (a lot of boilerplate for integer codes, _and_ the allocation and cleanup issues associated with a string error message). I dunno. I'd be interested to see a rough draft of an idea applied to a specific callsite. For this specific callsite, I think the error code alone is the right way forward. It conveys all information necessary out of the callee back to the caller, so that the caller, when it decides to do so later, can turn error code to human readable form. For some callsites, there may be cases where carrying a centrally produced string may be a handy way to grab detailed error message out of a deep call chain, but even in such a case, it is likely that we would need a separate error code, and a funtion that returns a pointer as its primary return value would need two extra out parameters, one for message and one for code. -- 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: add failing tests for case-folding p4d
The last comment in the test took me a minute to decipher. I would suggest no repo path called LC instead of no repo called LC. Also, it would have helped me to either have a little comment on the UC version of the test, or to make the previous comment a little more neutral so that it will apply to both test cases. Otherwise, while I am not a regular maintainer of this code, the patch does LGTM. Certainly it's good to have more test coverage. For the underlying problem, I haven't thought about it very much, but it looks like a plausible first step might be to simply probe the given file name and see if it comes back the same way. If it comes back differently, then maybe the command should abort? What a tough problem all around... Lex -- 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] rebase -i: redo tasks that die during cherry-pick
Hi, On 2015-04-29 00:55, Phil Hord wrote: When rebase--interactive processes a task, it removes the item from the todo list and appends it to another list of executed tasks. If a pick (this includes squash and fixup) fails before the index has recorded the changes, take the corresponding item and put it on the todo list again. Otherwise, the changes introduced by the scheduled commit would be lost. That kind of decision is possible since the cherry-pick command signals why it failed to apply the changes of the given commit. Either the changes are recorded in the index using a conflict (return value 1) and rebase does not continue until they are resolved or the changes are not recorded in the index (return value neither 0 nor 1) and rebase has to try again with the same task. Add a test cases for regression testing to the rebase-interactive test suite. Signed-off-by: Fabian Ruch baf...@gmail.com Signed-off-by: Phil Hord ho...@cisco.com --- ACK. It would be even nicer to avoid removing the task from the `todo` list until it has been performed correctly, of course, but I believe that would require a much more invasive patch. So this here patch is fine with me. Ciao, Dscho -- 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] t7502-commit.sh: fix a broken and-chain
On Tue, Apr 28, 2015 at 01:04:44PM +0100, Ramsay Jones wrote: This test recently started failing for me. I haven't heard anyone else complaining about this, so maybe I should look into why my environment may be different to everyone else ... :-D (when I can find some time, of course!) [...] test_expect_success !AUTOIDENT 'do not fire editor when committer is bogus' ' - .git/result + .git/result It looks like 92b269f (test-lib: turn on GIT_TEST_CHAIN_LINT by default, 2015-04-22) made it into pu recently, so you are probably just the first person to test it whose system matches !AUTOIDENT (which in turn is based on things like whether we can come up with a plausible-looking email from your system). Patch itself is obviously correct, and it looks like Junio has already picked it up for pu. Thanks. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Inexplicable merge conflict produced when when lines next to each other are changed
On Tue, Apr 28, 2015 at 07:34:30AM +, Anuradha Dissanayake wrote: Let's say I have a file with this content in master: _ Line 1 Line 2 Line 3 Line 4 _ Now say I create and checkout a new branch called Test. In this branch I change the file to this: _ Line 1 Line 2 Line 3 Modified Line 4 _ and I commit this and switch back to master. In master I change the file to: _ Line 1 Line 2 Line 3 Line 4 Modified _ and I commit. Now if I merge branch Test into master, I get a conflict. Why can't git auto resolve this, as those are two entirely independent lines? The content-level merge in git looks for overlapping diff hunks. It does have a level setting which will try with varying degrees of effort to shrink the conflict section, but I do not think there is a setting that will resolve this cleanly. Short of teaching a new level to the libxdiff merge code, I think the best you can do is to specify your own content-level merge driver for these files, and feed the data to another program which does the merge differently (whether it is simply more aggressive at finding conflicts, or it might even know something about the semantics of the file). See the three-way merge section in git help attributes. If I tell git to edit conflicts using BeyondCompare as the difftool, BeyondCompare autoresolves this without even telling the user, since this isn't a real conflict (other merge tools we use at our company do so also). Is there a way to get git to autoresolve these? I've tried the recursive and resolve merge strategies but neither do it. I don't think a change of merge strategy will help; they all end up doing the content-level merge with the same libxdiff code. -Peff PS I'm answering your how to questions directly without considering whether what you are asking for is a good idea. But you may want to think about whether there is a case that matches the above pattern that you would _not_ want to auto-resolve (i.e., even though there is not strictly a textual conflict, there is a good chance there is a semantic conflict because the lines are so close together). -- 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 0/3] Improve robustness of putty detection
On Sun, Apr 26, 2015 at 03:04:56PM -0700, Junio C Hamano wrote: Good eyes. While fixing the test is necessary, we should also be able to improve the test framework to prevent such mistakes at the same time. ok 38 # skip git clone [myhost:123]:src ssh-bracket-clone expect_ssh myhost -p (missing bracketed hostnames are still ssh) The test scripts are expected to take either 3 or 4 parameters, and the extra parameter when it takes 4 is the comma separated list of prerequisites. bracketed hostnames are still ssh does not look like prerequisites at all to us humans, and the framework should also be able to notice that and barf, I would think. Perhaps something like this? I think this is a good change. I haven't tested to see if we have any other issues in the testsuite that this would expose, but if so, they should be easy enough to fix up. -- 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: [PATCH v8 2/4] cat-file: teach cat-file a '--literally' option
On 04/28/2015 12:08 AM, Eric Sunshine wrote: On Mon, Apr 27, 2015 at 7:57 AM, karthik nayak karthik@gmail.com wrote: On 04/25/2015 10:34 PM, Junio C Hamano wrote: karthik nayak karthik@gmail.com writes: Yes this gives the best description, but its large, while we could use something like --no-strict instead. We could, if you answered my first question with no. By naming this --no-strict, the first bug report you will receive may be that cat-file --no-strict should parse a zlib deflate that begins with blob 1234\n\0 (notice that there are two SPs instead of the usual one, and length is followed by LF that should not be there before the NUL) but it does not. As your option name --no-strict signals that you will make the best effort to parse such nonsense, that would be a valid bug report, against which you would need to update the code to make it work. But is it worth the effort to make such a thing work? I dunno. Nice point, I don't see the need to parse such objects at the moment. That rules out --no-strict and everything similar. I still find --allow-unkown-type a bit too big, what about something like * --any-type * --arbitrary-type As a diagnostic aid when encountering a (hopefully rare) broken or corrupt object, this option is not likely to be used often. The allow in --allow-unknown-type conveys the intended purpose more accurately than either of the shorter names suggested above; and considering how infrequently it is likely to be used, the extra six characters should not be a significant burden. You do have a point, thanks for putting it out. Will stick to --allow-unkown-type. -- 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: GSoC 2015: 2 accepted proposals
Hello to Everyone, On 04/28/2015 01:20 AM, Matthieu Moy wrote: Hi, The results just got offical: the Git organization has 2 students accepted for the summer of code 2015. Karthik Nayak will work on Unifying git branch -l, git tag -l, and git for-each-ref mentored by Christian Couder and yours truly. Thanks a lot for accepting my proposal and giving me an opportunity to work with Git via GSoC. Can't express how excited I am. As Matthieu mentioned I will be working on Unifying git branch -l, git tag -l, and git for-each-ref. I plan to start off by going through the existing implementation of each of the above commands and come up with a design for unification for now. Also to take notes from Jeff King's attempt at unification[1]. I will be pushing all my work to my personal Git repository on Github[2]. Where anyone can get involved. Will also make sure to notify the mailing list on a regular basis on what is going on with my project. Looking forward to work with Git and complete this project successfully. Regards, Karthik Paul Tan will work on Make git-pull and git-am builtins, mentored by Johannes Schindelin and Stefan Beller. Congrats Paul, I wish you the very best. Regards, [1] https://github.com/peff/git/tree/jk/for-each-ref-contains-wip [2] https://github.com/KarthikNayak/git -- 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: Windows path limites, was Re: [PATCH v5 2/5] setup: sanity check file size in read_gitfile_gently
On Tue, Apr 28, 2015 at 2:23 AM Johannes Schindelin johannes.schinde...@gmx.de wrote: Hi Peff, On 2015-04-28 08:02, Jeff King wrote: My understanding is that PATH_MAX is set absurdly low on Windows systems (and doesn't actually represent the real limit of a path!). Well, yes and no. Yes, it is absurdly low on Windows, and yes, it is not the real limit of a path *if you know how to work around it*. Most Win32 API calls actually do have that absurdly low limit, but internally longer paths can be represented (and there is a hack where you prefix the path -- which must be an absolute one for this hack -- by `\\?\`). Keep in mind, though, that even the Windows Explorer is (at least sometimes) limited by the absurdly low path limit. One more thing worth noting is that path lengths are actually restricted further within git_path_submodule(), I would presume to reserve some amount of space when cloning a submodule (it seems to set aside 100 characters)? For other cases, yes, Dscho is absolutely right: the MAX_PATH constant is 260 (which gives something like 256 usable characters). If you're able to do everything through the Unicode Win32 APIs, you can reach 65535 characters, assuming the filesystem supports it (NTFS does, FAT32 would not, for example). I recall there being one function (possibly thinking of mktemp) that couldn't properly handle the long paths, but I believe that was it. Other apps may or may not handle the longer paths well; the core.longpaths switch may prevent mishaps in more than just Explorer, but the downside isn't disaster always either -- for example, Explorer just refuses to browse to that path. (Note that other apps may include both the msys bits as well as the Windows command line built-in commands, which may make things that farm out to sh behave in unusual ways. I vaguely remember testing this myself, but I don't recall what I did exactly or what happened.) --Doug -- 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 are submodule conflicts resolved during rebase?
On Tue, Apr 28, 2015 at 9:34 AM, Robert Dailey rcdailey.li...@gmail.com wrote: Hey guys, I'm using Git for Windows 2.3.6. There is a bit of confusion I have with regards to how submodule conflicts are resolved/handled during a rebase. Suppose I have a branch with 10 commits on it, 3 of those commits contain a change to the same (and only) submodule in the repository. When I rebase this branch onto the tip of its parent branch, I get a conflict in each of the 3 commits because the submodule also changed on the parent branch since my last rebase. I've seen some cases where I am asked to resolve the submodule conflict with local or remote. I expect this behavior and it isn't confusing to me. However, I have also seen cases where rebase auto resolves the conflicted submodule. How does Git know to auto resolve some submodule conflicts but not the others? I find this behavior unpredictable and I haven't found any documentation on it (I'm giving the git docs the benefit of the doubt and assuming it's there, since the git docs are very very good). Help is appreciated. Thank you. I also have rerere enabled in my global .gitconfig. Would this result in the behavior above? Resolve first submodule conflict, rebase --continue, then the next one is auto resolved? -- 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: Help with Getting started to Contribute
Hello Tummala, On 04/28/2015 07:15 PM, Tummala Dhanvi wrote: Hi , I would like to contribute to git. Can you guys point me to some useful resources to get me started to contribute to git. I suggest you go through the Documentation, especially Documentation/CodingGuidelines and Documentation/SubmittingPatches to get an idea of the workflow and guidelines for contributing to Git. Also does git have something like junior jobs so that It can be done by new to contribution. All issues and bugs are discussed on the mailing list, so keep going through the list for potential problems. There is also Junio's Blog where he keeps a list of things to be done http://git-blame.blogspot.de/p/leftover-bits.html You could pick something from there and work on that. Have Fun. Regards, Karthik Also searching about the git in google points to some other organisation which uses git :((well this is because of the popularity of the git) -- 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 -- 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 report : bad filter-branch (OSX only)
On Wed, Apr 29, 2015 at 12:39:47AM -0400, Jeff King wrote: So I can't figure out how to replicate the problem here. Actually, that's not quite true. I could get hold of an OS X system to replicate, which I just did. The problem is that commit 3b754f212 does not have a newline at the end of its commit message, and the OS X version of sed doesn't preserve that. Here's a much smaller reproduction recipe: git init echo content file git add file tree=$(git write-tree) commit=$(printf 'no newline' | git commit-tree $tree) git update-ref HEAD $commit git filter-branch On my Linux system, this results in an unchanged history, but on OS X, the commit is rewritten to have a newline at the end of the commit message. The culprit is this line from git-filter-branch: sed -e '1,/^$/d' ../commit | \ eval $filter_msg ../message || die msg filter failed: $filter_msg The sed command silently appends an extra newline to the final line of the message. You can see the sed behavior more directly with: printf foo | sed -ne 1p which adds a newline on OS X, but not when using GNU sed on Linux. It looks like OS X has just BSD sed, so the same behavior probably happens on FreeBSD and elsewhere. I'm not sure of a solution short of replacing the use of sed here with something else. perl would be a simple choice, but filter-branch does not otherwise depend on it. We could use a shell read loop, but those are quite slow (and filter-branch is slow enough as it is!). -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug report : bad filter-branch (OSX only)
Jeff King p...@peff.net writes: I'm not sure of a solution short of replacing the use of sed here with something else. perl would be a simple choice, but filter-branch does not otherwise depend on it. We could use a shell read loop, but those are quite slow (and filter-branch is slow enough as it is!). You need to only skip the header part, right? I would imagine that ( while read x test -n $x do :; done cat ) ../commit | eval $filter_msg would not spin too much in shell loop, perhaps? -- 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 report : bad filter-branch (OSX only)
On Tue, Apr 28, 2015 at 01:02:17PM +0200, Olivier ROLAND wrote: Both versions are builded from source. head -1 $(git --exec-path)/git-filter-branch #!/bin/sh sh --version GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin14) Copyright (C) 2007 Free Software Foundation, Inc. /bin/bash --version GNU bash, version 4.1.5(1)-release (x86_64-pc-linux-gnu) The bug seem really git related. Yes, but I guessed it might be part of the filter-branch shell script that behaves differently under two different shells (i.e., that we used some unportable construct). However, I built bash 3.2.57 on my Linux box and could not replicate the problem. The other usual thing that causes bugs to show up on OS X but not Linux is case-folding. But you said you are using a case-sensitive filesystem, so it's probably not that. So I can't figure out how to replicate the problem here. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How are submodule conflicts resolved during rebase?
On Tue, Apr 28, 2015 at 09:34:06AM -0500, Robert Dailey wrote: Suppose I have a branch with 10 commits on it, 3 of those commits contain a change to the same (and only) submodule in the repository. When I rebase this branch onto the tip of its parent branch, I get a conflict in each of the 3 commits because the submodule also changed on the parent branch since my last rebase. I've seen some cases where I am asked to resolve the submodule conflict with local or remote. I expect this behavior and it isn't confusing to me. However, I have also seen cases where rebase auto resolves the conflicted submodule. How does Git know to auto resolve some submodule conflicts but not the others? I find this behavior unpredictable and I haven't found any documentation on it (I'm giving the git docs the benefit of the doubt and assuming it's there, since the git docs are very very good). There is some logic for submodule merges, but to prevent false merges only the straight forward case results in a clean merge. In short: Conflicts for submodules are auto resolved when one side is contained in the other and both changes point forward. I.e. when merging A and B in the superproject and the submodule looks like this: base---*---*---B \ / *---A---*---* It will result in a clean merge in the superproject. If there is a common commit that contains both sides but that commit is not part of any side in the superproject the merge will fail but suggest that commit as a conflict resolution. Hope that helps. Cheers Heiko -- 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: Windows path limits, was Re: [PATCH v5 2/5] setup: sanity check file size in read_gitfile_gently
Hi, On 2015-04-28 17:33, Doug Kelly wrote: If you're able to do everything through the Unicode Win32 APIs, you can reach 65535 characters, assuming the filesystem supports it (NTFS does, FAT32 would not, for example). I recall there being one function (possibly thinking of mktemp) that couldn't properly handle the long paths, but I believe that was it. IIRC the MSDN documentation of at least one of the directory-related functions was not quite guaranteeing that it would support long paths with all Windows versions, either. Other apps may or may not handle the longer paths well; the core.longpaths switch may prevent mishaps in more than just Explorer, but the downside isn't disaster always either -- for example, Explorer just refuses to browse to that path. The problem comes from a different angle, though: I had *a lot* of fun when working on the tests for the `core.longpaths` feature because our very own `rm.exe` would not handle the long paths. As a consequence, quite a few tests failed to remove the trash directories of previous, failed test runs. In such a case you will have to resort to use different tools than you are used to, and *that* is the reason why we do not enable that feature by default. Ciao, Dscho -- 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 v5 1/5] setup: add gentle version of read_gitfile
Jeff King wrote: On Tue, Apr 28, 2015 at 10:07:43PM +0200, erik elfström wrote: Also if it turns out that we actually need to treat the file too large error differently in clean (as discussed in thread on the file size check) then we can no longer communicate that back using the strbuf interface. Yeah, agreed. This system breaks down as soon as you need to programatically know which error happened. On the contrary: it separates the information that is used programatically and the information intended for the user. The return value (or an int * parameter) distinguishes errors that affect control flow. A string can provide information for the user. This way it is easy to tweak the information that the user sees in one place, without changing control flow. -- 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 v5 1/5] setup: add gentle version of read_gitfile
Jeff King wrote: On Tue, Apr 28, 2015 at 01:42:13PM -0700, Jonathan Nieder wrote: Jeff King wrote: But the NULL does not carry the information about _which_ error, and Erik is suggesting that the caller may need to change behavior based on that information. IOW, his current patch (return NULL and set the specific integer code in a variable) allows this, but switching the integer code out for a human-readable strbuf does not. Right. Two ways to handle that are: Sure, but this system that I was referring to one was not one of those ways. :) That means I wasn't communicating well. I never advocated *not* providing an integer return code when you want to affect control flow. An example of a function that provides information both to the caller and user and doesn't conflate the two is ref_transaction_commit. It returns TRANSACTION_NAME_CONFLICT for a certain kind of recoverable error and TRANSACTION_GENERIC_ERROR for all other errors. In either case, the 'err' parameter is populated with information intended for the user. Sometimes you might want to affect control flow without providing information for the user. Then there's no need for a string output parameter and you can just provide the int. At other times you might want to provide information for the user without affecting control flow. Then you can provide a string without the int. Providing error codes when you also want to return a string or struct pointer is an unrelated problem. One runs into that problem even if only intending to provide a return code. Possible approaches, like mentioned before, are - an int * parameter to pass back the return code - using ERR_PTR to embed error codes in the pointer space There is another approach which is sometimes nicer: - return int and pass the string or struct pointer through an output paramter Thanks and sorry for the lack of clarity, 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/RFC] blame: CRLF in the working tree and LF in the repo
Am 28.04.2015 um 21:52 schrieb Junio C Hamano: Johannes Sixt j...@kdbg.org writes: I set none of these. But I do commit CRLF and expect to get CRLF back. Am I commiting binary files? Am I doing something that Git does not support? Am I on [my] own? I think these specific sentences are merely uninformed opinions; if I ignore and re-read what people said in the discussion, I think the thread as a whole makes sense. Thanks for the clarification. Following the thread only superficially, I feared some behavior change (or even just a redefinition of what is supported) is about to surface that impacts established workflows. -- Hannes -- 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 v5 1/5] setup: add gentle version of read_gitfile
On Tue, Apr 28, 2015 at 01:34:00PM -0700, Jonathan Nieder wrote: Jeff King wrote: On Tue, Apr 28, 2015 at 10:07:43PM +0200, erik elfström wrote: Also if it turns out that we actually need to treat the file too large error differently in clean (as discussed in thread on the file size check) then we can no longer communicate that back using the strbuf interface. Yeah, agreed. This system breaks down as soon as you need to programatically know which error happened. On the contrary: it separates the information that is used programatically and the information intended for the user. The return value (or an int * parameter) distinguishes errors that affect control flow. A string can provide information for the user. This way it is easy to tweak the information that the user sees in one place, without changing control flow. But the NULL does not carry the information about _which_ error, and Erik is suggesting that the caller may need to change behavior based on that information. IOW, his current patch (return NULL and set the specific integer code in a variable) allows this, but switching the integer code out for a human-readable strbuf does not. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 1/5] setup: add gentle version of read_gitfile
Jeff King wrote: But the NULL does not carry the information about _which_ error, and Erik is suggesting that the caller may need to change behavior based on that information. IOW, his current patch (return NULL and set the specific integer code in a variable) allows this, but switching the integer code out for a human-readable strbuf does not. Right. Two ways to handle that are: - two out parameters: an integer code and a human-readable string, or - an integer code returned using the ERR_PTR method and a human-readable string out parameter The point I was trying to make clear is that the human-readable error message and the integer to affect control flow have different purposes and are not tightly related except in that they are produced at the same time. Using an integer to convey the human-readable error message (like errno does) unnecessarily forces the message to be more vague (by not being parameterized, and by always using the same error message for the same integer error). -- 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 v5 5/5] clean: improve performance when removing lots of directories
On Tue, Apr 28, 2015 at 8:24 AM, Jeff King p...@peff.net wrote:
This iteration looks reasonable overall to me.
Should this is_git_repository() helper be available to other files? I
think there are other calls to resolve_gitlink_ref() that would want the
same treatment (e.g., I think git status may have a similar issue).
-Peff
Yes that is probably the direction to go in but I think the current
version is too tailored to the clean case to be generally useful
(although I haven't check the status case). Right now this is more of
a is_this_a_repo_clean_should_care_about_ignoring_some_cornercase_quirks
than a true is_git_repository check.
I would think a general version would look more like this:
static int is_git_repository(struct strbuf *path)
{
if (is_bare_repository(path))
return BARE_REPO;
if (is_submodule(path))
return SUBMODULE;
if (is_git_director(path))
return REPO;
return 0;
}
probably also communicating any errors back to the caller.
To sum it up I think you are correct in the direction but I suspect
that the current version is not sufficient for the general case and
that it would be best to leave the generalization and making it public
for future work.
/Erik
--
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 v5 1/5] setup: add gentle version of read_gitfile
On Tue, Apr 28, 2015 at 01:42:13PM -0700, Jonathan Nieder wrote: Jeff King wrote: But the NULL does not carry the information about _which_ error, and Erik is suggesting that the caller may need to change behavior based on that information. IOW, his current patch (return NULL and set the specific integer code in a variable) allows this, but switching the integer code out for a human-readable strbuf does not. Right. Two ways to handle that are: Sure, but this system that I was referring to one was not one of those ways. :) - two out parameters: an integer code and a human-readable string, or - an integer code returned using the ERR_PTR method and a human-readable string out parameter The point I was trying to make clear is that the human-readable error message and the integer to affect control flow have different purposes and are not tightly related except in that they are produced at the same time. Using an integer to convey the human-readable error message (like errno does) unnecessarily forces the message to be more vague (by not being parameterized, and by always using the same error message for the same integer error). Yes, I agree converting the integer back into a string later does not always carry all of the data. OTOH, the caller can often supply the context (i.e., this is basically how errno works). This gets back to the idea we discussed a while ago of having a struct error that can carry the code and the parameters (or if you like, the code and a finished error message). It just feels in some ways like that ends up with the worst of both worlds (a lot of boilerplate for integer codes, _and_ the allocation and cleanup issues associated with a string error message). I dunno. I'd be interested to see a rough draft of an idea applied to a specific callsite. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] blame: CRLF in the working tree and LF in the repo
Hello Hannes, let me correct my previous statement: On Mon, Apr 27, 2015 at 08:58:05PM +0200, Johannes Sixt wrote: When I commit my C source code files with CRLF into the repository (because I do not set any line ending options or configurations or any 'text' attributes or similar), do I then commit binary files or text files? Should I expect not to see any diffs? Of course, you can see diffs. The files are not binary in that sense. Johannes Sixt j...@kdbg.org writes: I set none of these. But I do commit CRLF and expect to get CRLF back. [...] That works. You will not encounter any problem. (Supposing you do not change the line ending options, of course.) Finally, let me explain my previous statement: Am 27.04.2015 um 08:11 schrieb Stepan Kasal: Git does not support CRLF as the internal line separator. I'm often asked: How do I set up git so that it uses CRLF in text files in the repository and checks them out with CRLF on Windows and with LF on unixy systems? My answer to that question always was that you cannot configure the internal line separator in git repo, it is always LF. Your only chance to support both line endings is to have LF in the repo and configure the Windows client to do the conversion. If you commit file in binary mode with CRLF, you are on your own. OK, scratch the word binary. The files in the repo are actually text files. But each text line is contains one more char than you would think. From time to time, this lurks: 1) Does git grep ';$' HEAD find anything? 2) What about git grep ';.$' HEAD ? Or git grep `printf ';\r$' HEAD ? 3) If you try things like git diff HEAD^^..HEAD^ outfile.diff and then open outfile.diff with a suitable editor (e.g. vim), you can see an extra ^M at the end of some lines (the content ones). This is why I tell users that they are on their own if they decide to use the setup you described. Have a nice day, Stepan -- 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: GSoC 2015: 2 accepted proposals
Hi all, On Tue, Apr 28, 2015 at 3:50 AM, Matthieu Moy matthieu@grenoble-inp.fr wrote: Hi, The results just got offical: the Git organization has 2 students accepted for the summer of code 2015. Karthik Nayak will work on Unifying git branch -l, git tag -l, and git for-each-ref mentored by Christian Couder and yours truly. Paul Tan will work on Make git-pull and git-am builtins, mentored by Johannes Schindelin and Stefan Beller. Thanks for accepting me, and it is my pleasure to work with everyone. For reference, information on the proposed project can be found at [1]. As stated in the proposal, I will be starting work on the project immediately. The first step would be to review the test coverage of git-pull and git-am in order to make sure that nothing breaks during the rewriting. I am currently reviewing all related code in order to get a better perspective on the issues involved. I am also aware of the recent issues with git-pull[2], which I will look into. All patches that I'm working on but are not ready to be published to the mailing list will be cooked in their corresponding branches in my personal git repo[3], which I will push at least once a working day. Everyone is welcome to have a look :-). Again, thanks all for your support and guidance, and I look forward to working with everyone to make this project a success. Regards, Paul [1] https://gist.github.com/pyokagan/1b7b0d1f4dab6ba3cef1 [2] http://thread.gmane.org/gmane.comp.version-control.git/267432 [3] https://github.com/pyokagan/git -- 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
Inexplicable merge conflict produced when when lines next to each other are changed
I posted this question to StackOverflow a while ago but no one answered it so I thought I'd try here. Let's say I have a file with this content in master: _ Line 1 Line 2 Line 3 Line 4 _ Now say I create and checkout a new branch called Test. In this branch I change the file to this: _ Line 1 Line 2 Line 3 Modified Line 4 _ and I commit this and switch back to master. In master I change the file to: _ Line 1 Line 2 Line 3 Line 4 Modified _ and I commit. Now if I merge branch Test into master, I get a conflict. Why can't git auto resolve this, as those are two entirely independent lines? If I tell git to edit conflicts using BeyondCompare as the difftool, BeyondCompare autoresolves this without even telling the user, since this isn't a real conflict (other merge tools we use at our company do so also). Is there a way to get git to autoresolve these? I've tried the recursive and resolve merge strategies but neither do it. It's an issue in our company because there are certain files where multiple developers change lines in close proximity and this causes many unnecessary conflicts when they pull. -- 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] git-p4: add failing tests for case-folding p4d
When p4d runs on a case-folding OS, git-p4 can end up getting
very confused. This adds failing tests to demonstrate the problem.
Signed-off-by: Luke Diamand l...@diamand.org
---
t/lib-git-p4.sh| 2 +-
t/t9819-git-p4-case-folding.sh | 54 ++
2 files changed, 55 insertions(+), 1 deletion(-)
create mode 100755 t/t9819-git-p4-case-folding.sh
diff --git a/t/lib-git-p4.sh b/t/lib-git-p4.sh
index 5aa8adc..7548225 100644
--- a/t/lib-git-p4.sh
+++ b/t/lib-git-p4.sh
@@ -69,7 +69,7 @@ start_p4d() {
(
cd $db
{
- p4d -q -p $P4DPORT
+ p4d -q -p $P4DPORT $@
echo $! $pidfile
}
)
diff --git a/t/t9819-git-p4-case-folding.sh b/t/t9819-git-p4-case-folding.sh
new file mode 100755
index 000..78f1d0f
--- /dev/null
+++ b/t/t9819-git-p4-case-folding.sh
@@ -0,0 +1,54 @@
+#!/bin/sh
+
+test_description='interaction with P4 case-folding'
+
+. ./lib-git-p4.sh
+
+test_expect_success 'start p4d with case folding enabled' '
+ start_p4d -C1
+'
+
+test_expect_success 'Create a repo, name is lowercase' '
+ (
+ client_view //depot/... //client/...
+ cd $cli
+ mkdir -p lc UC
+ lc/file.txt UC/file.txt
+ p4 add lc/file.txt UC/file.txt
+ p4 submit -d Add initial lc and UC repos
+ )
+'
+
+test_expect_success 'Check p4 is in case-folding mode' '
+ (
+ cd $cli
+ lc/FILE.TXT
+ p4 add lc/FILE.TXT
+ test_must_fail p4 submit -d Cannot add file differing only in
case lc/FILE.TXT
+ )
+'
+
+# Check we created the repo properly
+test_expect_success 'Clone lc repo using lc name' '
+ git p4 clone //depot/lc/...
+ test_path_is_file lc/file.txt
+ git p4 clone //depot/UC/...
+ test_path_is_file UC/file.txt
+'
+
+# The clone should fail, since there is no repo called LC, but because
+# we have case-insensitive p4d enabled, it appears to go ahead and work,
+# but leaves an empty git repo in place.
+test_expect_failure 'Clone lc repo using uc name' '
+ test_must_fail git p4 clone //depot/LC/...
+'
+
+test_expect_failure 'Clone UC repo with lc name' '
+ test_must_fail git p4 clone //depot/uc/...
+'
+
+test_expect_success 'kill p4d' '
+ kill_p4d
+'
+
+test_done
--
2.4.0.rc3.380.g8e2ddc7
--
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] git-p4: add failing tests for case-folding in p4d
Lex found out recently that when git-p4 is asked to clone a repo and the case of the repo is incorrect (but otherwise correct) that git-p4, instead of reporting an error, appears to work fine, but actually produces an empty repo. This can be quite confusing. This patch adds a couple of failing test cases that illustrate the problem. The next step is to figure out where it's going wrong, and how it should actually behave. Luke Diamand (1): git-p4: add failing tests for case-folding p4d t/lib-git-p4.sh| 2 +- t/t9819-git-p4-case-folding.sh | 54 ++ 2 files changed, 55 insertions(+), 1 deletion(-) create mode 100755 t/t9819-git-p4-case-folding.sh -- 2.4.0.rc3.380.g8e2ddc7 -- 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 are submodule conflicts resolved during rebase?
On Tue, Apr 28, 2015 at 11:49 AM, Heiko Voigt hvo...@hvoigt.net wrote: On Tue, Apr 28, 2015 at 09:34:06AM -0500, Robert Dailey wrote: Suppose I have a branch with 10 commits on it, 3 of those commits contain a change to the same (and only) submodule in the repository. When I rebase this branch onto the tip of its parent branch, I get a conflict in each of the 3 commits because the submodule also changed on the parent branch since my last rebase. I've seen some cases where I am asked to resolve the submodule conflict with local or remote. I expect this behavior and it isn't confusing to me. However, I have also seen cases where rebase auto resolves the conflicted submodule. How does Git know to auto resolve some submodule conflicts but not the others? I find this behavior unpredictable and I haven't found any documentation on it (I'm giving the git docs the benefit of the doubt and assuming it's there, since the git docs are very very good). There is some logic for submodule merges, but to prevent false merges only the straight forward case results in a clean merge. In short: Conflicts for submodules are auto resolved when one side is contained in the other and both changes point forward. I.e. when merging A and B in the superproject and the submodule looks like this: base---*---*---B \ / *---A---*---* It will result in a clean merge in the superproject. If there is a common commit that contains both sides but that commit is not part of any side in the superproject the merge will fail but suggest that commit as a conflict resolution. Hope that helps. Cheers Heiko So if I understand this correctly, you are saying that during a rebase if it sees a potential conflict for a submodule in the commit being rebased, it will inspect the ancestry of the actual commits in the submodule logs? For a rebase, does this mean that the local (latest SHA1 from the submodule in the target branch of the rebase) submodule commit must be reachable from the remote (SHA1 contained in the diff of the commit currently being rebased) submodule commit? I just want to make sure this is the logic. Thanks for explaining, still trying to wrap my head around it. -- 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/RFC] blame: CRLF in the working tree and LF in the repo
Am 27.04.2015 um 21:45 schrieb Torsten Bögershausen: On 04/27/2015 08:58 PM, Johannes Sixt wrote: Am 27.04.2015 um 08:11 schrieb Stepan Kasal: Git does not support CRLF as the internal line separator. If you commit file in binary mode with CRLF, you are on your own. When I commit my C source code files with CRLF into the repository (because I do not set any line ending options or configurations or any 'text' attributes or similar), do I then commit binary files or text files? Should I expect not to see any diffs? -- Hannes You commit files with CRLF in the repo. If you have CRLF in the working tree, things are as follows: core.autocrlf=false : Same as binary, no changes core.autocrlf=true: Normalization is suppressed, (CRLF in repo), and therefore no changes. core.autocrlf=input : Normalization wanted, (CRLF in repo), normalization will be done (and should be committed as soon as possible) I set none of these. But I do commit CRLF and expect to get CRLF back. Am I commiting binary files? Am I doing something that Git does not support? Am I on [my] own? -- Hannes -- 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 v5 2/5] setup: sanity check file size in read_gitfile_gently
On Sun, Apr 26, 2015 at 08:49:42AM +0200, Erik Elfström wrote:
read_gitfile_gently will allocate a buffer to fit the entire file that
should be read. Add a sanity check of the file size before opening to
avoid allocating a potentially huge amount of memory if we come across
a large file that someone happened to name .git. The limit is set to
a sufficiently unreasonable size that should never be exceeded by a
genuine .git file.
[...]
+ if (st.st_size PATH_MAX * 4) {
+ error_code = READ_GITFILE_ERR_TOO_LARGE;
+ goto cleanup_return;
+ }
My understanding is that PATH_MAX is set absurdly low on Windows
systems (and doesn't actually represent the real limit of a path!).
Since the value is picked arbitrarily anyway, could use something more
independent (like 100K or something, which is large enough to be beyond
absurd and small enough that a malloc isn't a big deal)?
-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3] git-p4: t9814: prevent --chain-lint failure
Use test_lazy_prereq to setup prerequisites for the p4 move
test. This both makes the test simpler and clearer, and also
means it no longer fails the new --chain-lint tests.
Suggested-by: Jeff King p...@peff.net
Signed-off-by: Luke Diamand l...@diamand.org
---
t/t9814-git-p4-rename.sh | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/t/t9814-git-p4-rename.sh b/t/t9814-git-p4-rename.sh
index 99bb71b..c89992c 100755
--- a/t/t9814-git-p4-rename.sh
+++ b/t/t9814-git-p4-rename.sh
@@ -226,14 +226,9 @@ test_expect_success 'detect copies' '
# See if configurables can be set, and in particular if the run.move.allow
# variable exists, which allows admins to disable the p4 move command.
-test_expect_success 'p4 configure command and run.move.allow are available' '
- p4 configure show run.move.allow out ; retval=$?
- test $retval = 0
- {
- egrep ^run.move.allow: out
- test_set_prereq P4D_HAVE_CONFIGURABLE_RUN_MOVE_ALLOW ||
- true
- } || true
+test_lazy_prereq P4D_HAVE_CONFIGURABLE_RUN_MOVE_ALLOW '
+ p4 configure show run.move.allow out
+ egrep ^run.move.allow: out
'
# If move can be disabled, turn it off and test p4 move handling
--
2.3.4.48.g223ab37
--
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
Windows path limites, was Re: [PATCH v5 2/5] setup: sanity check file size in read_gitfile_gently
Hi Peff, On 2015-04-28 08:02, Jeff King wrote: My understanding is that PATH_MAX is set absurdly low on Windows systems (and doesn't actually represent the real limit of a path!). Well, yes and no. Yes, it is absurdly low on Windows, and yes, it is not the real limit of a path *if you know how to work around it*. Most Win32 API calls actually do have that absurdly low limit, but internally longer paths can be represented (and there is a hack where you prefix the path -- which must be an absolute one for this hack -- by `\\?\`). Keep in mind, though, that even the Windows Explorer is (at least sometimes) limited by the absurdly low path limit. Note that we have support for `core.longpaths` in Git for Windows (to be submitted just after I get 2.x out), but it is disabled by default because of the Windows Explorer issue. Ciao, Dscho -- 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
[PATCHv3] Fixup test-lint error in git-p4 t9814 test
Using Jeff's suggestion of converting the t9814 test to use test_lazy_prereq makes the test a lot clearer, and as a bonus, also fixes the --chain-lint error. Version 3 of the patch corrects a small typo in the commit message of version 2. Luke Diamand (1): git-p4: t9814: prevent --chain-lint failure t/t9814-git-p4-rename.sh | 11 +++ 1 file changed, 3 insertions(+), 8 deletions(-) -- 2.3.4.48.g223ab37 -- 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 v5 1/5] setup: add gentle version of read_gitfile
On Sun, Apr 26, 2015 at 08:49:41AM +0200, Erik Elfström wrote: -extern const char *read_gitfile(const char *path); + +#define READ_GITFILE_ERR_STAT_FAILED 1 +#define READ_GITFILE_ERR_NOT_A_FILE 2 +#define READ_GITFILE_ERR_OPEN_FAILED 3 +#define READ_GITFILE_ERR_READ_FAILED 4 +#define READ_GITFILE_ERR_INVALID_FORMAT 5 +#define READ_GITFILE_ERR_NO_PATH 6 +#define READ_GITFILE_ERR_NOT_A_REPO 7 +extern const char *read_gitfile_gently(const char *path, int *return_error_code); There was a discussion not too long ago on strategies for returning errors, and one of the suggestions was to return an error strbuf rather than a code[1]. That's less flexible, as the caller can't react differently based on the type of error. But for cases like this, where the only fate for the code is to get converted back into a message, it can reduce the boilerplate. What you have here is OK to me, and I don't want to hold up your patch series in a flamewar about error-reporting techniques. But I think it's an interesting case study. -Peff [1] The original thread was here: http://thread.gmane.org/gmane.comp.version-control.git/259695/focus=260722 I'm still a little wary of the allocation boilerplate introduced by the strbuf approach. But in this case it would not be too bad, I think. -- 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
[PATCHv2] git-p4: t9814: prevent --chain-lint failure
Use test_lazy_prereq to setup prerequisites for the p4 move
test. This both makes the test simpler and clearer, and also
means they no longer fail the new --chain-lint tests.
Suggested-by: Jeff King p...@peff.net
Signed-off-by: Luke Diamand l...@diamand.org
---
t/t9814-git-p4-rename.sh | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/t/t9814-git-p4-rename.sh b/t/t9814-git-p4-rename.sh
index 99bb71b..c89992c 100755
--- a/t/t9814-git-p4-rename.sh
+++ b/t/t9814-git-p4-rename.sh
@@ -226,14 +226,9 @@ test_expect_success 'detect copies' '
# See if configurables can be set, and in particular if the run.move.allow
# variable exists, which allows admins to disable the p4 move command.
-test_expect_success 'p4 configure command and run.move.allow are available' '
- p4 configure show run.move.allow out ; retval=$?
- test $retval = 0
- {
- egrep ^run.move.allow: out
- test_set_prereq P4D_HAVE_CONFIGURABLE_RUN_MOVE_ALLOW ||
- true
- } || true
+test_lazy_prereq P4D_HAVE_CONFIGURABLE_RUN_MOVE_ALLOW '
+ p4 configure show run.move.allow out
+ egrep ^run.move.allow: out
'
# If move can be disabled, turn it off and test p4 move handling
--
2.3.4.48.g223ab37
--
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
[PATCHv2] Fixup test-lint error in git-p4 t9814 test
Using Jeff's suggestion of converting the t9814 test to use test_lazy_prereq makes the test a lot clearer, and as a bonus, also fixes the --chain-lint error. Thanks, Luke Luke Diamand (1): git-p4: t9814: prevent --chain-lint failure t/t9814-git-p4-rename.sh | 11 +++ 1 file changed, 3 insertions(+), 8 deletions(-) -- 2.3.4.48.g223ab37 -- 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] blame: add blame.showemail config option
Eric Sunshine sunsh...@sunshineco.com writes:
Right. Rather than having a separate global 'show_email' variable and
consulting that variable in parallel with OUTPUT_SHOW_EMAIL throughout
the code, instead set the OUTPUT_SHOW_EMAIL bit in git_blame_config().
To do this, take advantage of the callback data argument of
git_config(), which will arrive in git_blame_config() as its 'void
*cb' argument. So, for instance, something like this:
static int git_blame_config(var, value, void *cb)
{
...
if (!strcmp(var, blame.showemail)) {
if (git_config_bool(var, value)) {
int *output_options = cb;
*output_options |= OUTPUT_SHOW_EMAIL;
}
Don't forget to clear the bit when the bool is set to false, too.
return 0;
}
...
}
int cmd_blame(...)
{
...
git_config(git_blame_config, output_options);
...
parse_options(...);
...
}
--
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] Update git-multimail to version 1.0.2
Michael Haggerty mhag...@alum.mit.edu writes: On 04/27/2015 09:05 PM, Junio C Hamano wrote: ... Hmm, that may be technically correct but it is grossly misleading to update the existing was obtained on 2014-04-07 to was obtained on 2015-04-27, especially if nothing was actually obtained, isn't it? ... It's true that only documentation changes are in the patch, but it still seemed like good practice to create a tag and all that. If nothing else, it will make it easier to figure out the baseline for future code drops. Oh, there is no question about that ;-) There have been a couple of small software changes in git-multimail's master branch, but I didn't include those in the patch I submitted to you because I thought you wouldn't want to have code changes so close to the release. So 1.0.2 is on the newly-created maint branch. OK. I honestly am surprised that, after seeing the announcement about a new repository, co-maintainer and multiple contributors, no code change is made over the past 12 months. I totally understand your disappointment. Mea culpa. I am not *disappointed* at all. No recent changes do not automatically mean abandoned software---it may be a sign of stability. I was just *surprised*. After all, 1.0.2 tag will hopefully soon become stale, and people have to go to the upstream to see what the latest version is called anyway, instead of looking at my tree. So the primary value of having a copy in my tree is (1) to have the URL for the true upstream and (2) to have a working version that is not too stale. So from that point of view, a patch without the update to the version numbers or datestamps, i.e. just changes the URLs and updates who to contact, would have been more truthful, unless it also updated the code. It was just that the update changed the last obtained date without changing anything of substance that was obtained (because there wasn't anything new to be obtained) and that looked unexpected and surprised me. That's all. -- 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/RFC] blame: CRLF in the working tree and LF in the repo
Torsten Bögershausen tbo...@web.de writes: What do you think about the following test cases for a V2 patch ? test_expect_success 'create blamerepo' ' test_create_repo blamerepo ( cd blamerepo printf testcase\r\n crlffile git -c core.autocrlf=false add crlffile git commit -m add files git -c core.autocrlf=false blame crlffile crlfclean.txt ) ' test_expect_success 'blaming files with CRLF newlines in repo, core.autoclrf=input' ' ( cd blamerepo git -c core.autocrlf=input blame crlffile actual grep Not Committed Yet actual Are you interested in seeing just some of the lines to show up as Not commited yet, or all of them? I think it would be the latter, so perhaps ! grep -v Not Committed Yet actual or something? ) ' Two blank lines only here? test_expect_success 'blaming files with CRLF newlines core.autocrlf=true' ' ( cd blamerepo git -c core.autocrlf=true blame crlffile actual test_cmp crlfclean.txt actual ) ' OK test_expect_success 'blaming files with CRLF newlines core.autocrlf=false' ' ( cd blamerepo git -c core.autocrlf=false blame crlffile actual test_cmp crlfclean.txt actual ) ' Hmm, how's this blame invocation any different from the one done in the set-up step at the very beginning? In other words, I am not sure what kind of breakage could cause this step to fail. I see there is no git blame HEAD crlffile that bypasses the fake latest commit altogether. Wouldn't that be the most appropriate thing to compare against (i.e. how to create crlfclean.txt in the set-up step)? -- 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
'git show' with multiple revisions
I would like to see the content of a file in multiple revisions. I can get them with 'git show' as follows: % git show REV1:FILE % git show REV2:FILE and so on. But that launches a new process for each revision. Now, there is the option to pass multiple arguments to 'git show': % git show REV1:FILE REV2:FILE This gets both revisions in a single process and so is faster. But it concatenates the content so there isn't a way to separate them out again. Could 'git show' sprout an option to get multiple things programmatically so that they can be separated out again? One way would be to quote or escape the contents somehow so that the result can be parsed: % git show --porcelain REV1:FILE REV2:FILE The question is what format should be used to output many strings to stdout. An alternative would be to specify an output file: % git show --output foo REV1:FILE# writes foo % git show --output foo REV1:FILE --output bar REV2:FILE # writes foo, bar Note that here I am only getting the file content, not log messages or any of the other things which 'git show' can produce. So perhaps what I really want is some kind of 'git cat'. Or is there another more appropriate tool? Thanks, -- Ed Avis e...@waniasset.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: add failing tests for case-folding in p4d
On 28/04/15 10:08, Luke Diamand wrote: Lex found out recently that when git-p4 is asked to clone a repo and the case of the repo is incorrect (but otherwise correct) that git-p4, instead of reporting an error, appears to work fine, but actually produces an empty repo. This can be quite confusing. Oops, not Lex, but Fusion, noticed the problem! Thanks! 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
Re: curl
On Tue, 2015-04-28 at 00:57 -0400, Jeff King wrote: On Mon, Apr 27, 2015 at 11:49:51PM -0300, Thiago Farina wrote: Is it right that git uses libcurl to download while libgit2 does without it? I'm not sure if you mean right as in this statement is true or as in is this a good thing that it is the case. For the former, yes, libgit2 does not use curl. On Windows, it can use the native http calls (which do nice things like using the system proxy and auth systems). On Unix, I think it is a combination of hand-rolled code, openssl, and an imported http parser (from nginx). Whether that is a good idea or not, I can't comment too much. From what I have seen discussed in libgit2 issues, the stock http transport is meant to be bare-bones (but with minimal dependencies). But it could co-exist with a curl transport (just as it does with the WinHTTP transport). Maybe Carlos (cc'd) can say more. This is accurate, though I'll add that the development version of libgit2 now uses SecureTransport instead of OpenSSL on Mac OS X. But this is just the default. You can replace what libgit2 will use as a transport if you have special needs. Visual Studio use their own network code, and the cargo package manager uses libcurl. Eventually libcurl support will likely be added to mainline libgit2, when we find time. cmn -- 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 v5 4/5] p7300: add performance tests for clean
On Tue, Apr 28, 2015 at 8:33 AM, Jeff King p...@peff.net wrote: Do we actually need a large repo here? The real cost is coming from the directories we create. We could actually start with a totally empty repository if we wanted (though I don't think the t/perf system handles that right now). But if there's not a reason to use the large repo, I think using test_perf_default_repo is better, as it works out of the box without specifying extra environment variables (well, it works either way, but you get a nasty warning from perf-lib.sh). -Peff Sure, I'll change this to the default. I wasn't sure about the performance characteristics of clean (does working tree size matter?) when I started so it felt safest to go with a large repo. -- 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 are submodule conflicts resolved during rebase?
On Tue, Apr 28, 2015 at 01:19:00PM -0500, Robert Dailey wrote: On Tue, Apr 28, 2015 at 11:49 AM, Heiko Voigt hvo...@hvoigt.net wrote: On Tue, Apr 28, 2015 at 09:34:06AM -0500, Robert Dailey wrote: Suppose I have a branch with 10 commits on it, 3 of those commits contain a change to the same (and only) submodule in the repository. When I rebase this branch onto the tip of its parent branch, I get a conflict in each of the 3 commits because the submodule also changed on the parent branch since my last rebase. I've seen some cases where I am asked to resolve the submodule conflict with local or remote. I expect this behavior and it isn't confusing to me. However, I have also seen cases where rebase auto resolves the conflicted submodule. How does Git know to auto resolve some submodule conflicts but not the others? I find this behavior unpredictable and I haven't found any documentation on it (I'm giving the git docs the benefit of the doubt and assuming it's there, since the git docs are very very good). There is some logic for submodule merges, but to prevent false merges only the straight forward case results in a clean merge. In short: Conflicts for submodules are auto resolved when one side is contained in the other and both changes point forward. I.e. when merging A and B in the superproject and the submodule looks like this: base---*---*---B \ / *---A---*---* It will result in a clean merge in the superproject. If there is a common commit that contains both sides but that commit is not part of any side in the superproject the merge will fail but suggest that commit as a conflict resolution. So if I understand this correctly, you are saying that during a rebase if it sees a potential conflict for a submodule in the commit being rebased, it will inspect the ancestry of the actual commits in the submodule logs? Yes that is correct. For a rebase, does this mean that the local (latest SHA1 from the submodule in the target branch of the rebase) submodule commit must be reachable from the remote (SHA1 contained in the diff of the commit currently being rebased) submodule commit? I does not matter which is reachable from which but yes one has to be reachable from the other. I just want to make sure this is the logic. Thanks for explaining, still trying to wrap my head around it. Yeah submodule things tend become complicated to think about at times. Cheers Heiko -- 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 v5 2/5] setup: sanity check file size in read_gitfile_gently
On Tue, Apr 28, 2015 at 8:02 AM, Jeff King p...@peff.net wrote: My understanding is that PATH_MAX is set absurdly low on Windows systems (and doesn't actually represent the real limit of a path!). Since the value is picked arbitrarily anyway, could use something more independent (like 100K or something, which is large enough to be beyond absurd and small enough that a malloc isn't a big deal)? -Peff I'm happy to set the limit to anything that makes everybody feel safe. I'll set it to 1MB to be on the safe side. I'm not sure though how the code (in general) is supposed to keep working if a path can exceed PATH_MAX? A cursory search for PATH_MAX comes up with char array sizes and check-and-die kind of things. If a path is longer then surely we will be unable to handle it and abort in all sorts of places? Are you only worried we might have a submodule with a too long path (that will create various other problems in different codepaths) that we may mistakenly clean (if it doesn't trigger any other abort earlier in the clean call chain) or do you want clean to keep working and do the right thing even in this case? While digging around looking at this I also noticed that there is another problem I have overlooked previously. read_gitfile_gently will call is_git_directory at the very end and it contains the following check at the very beginning: if (PATH_MAX = len + strlen(/objects)) die(Too long path: %.*s, 60, suspect); Now, this is good in the way that we will avoid mistakenly cleaning stuff because the path is too long but also bad because it makes read_gitfile_gently behave very ungently in this case. I suspect I should make a gentle version of this also. The question is what to do in clean if the path is reported as too long? Abort? Avoid cleaning it to be safe? Ignore and clean it? is_git_directory is also called from the new is_git_repository directly but here I think dying is ok since this path is a path in the working tree and if we can't handle the paths in the tree then there seem to be little point in trying to go on (as opposed to when some string in a file is too large for a path) Thoughts? /Erik -- 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/RFC] blame: CRLF in the working tree and LF in the repo
Johannes Sixt j...@kdbg.org writes: I set none of these. But I do commit CRLF and expect to get CRLF back. Am I commiting binary files? Am I doing something that Git does not support? Am I on [my] own? I think these specific sentences are merely uninformed opinions; if I ignore and re-read what people said in the discussion, I think the thread as a whole makes sense. -- 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 v5 5/5] clean: improve performance when removing lots of directories
On Sun, Apr 26, 2015 at 08:49:45AM +0200, Erik Elfström wrote:
+/*
+ * Return 1 if the given path is the root of a git repository or
+ * submodule else 0. Will not return 1 for bare repositories with the
+ * exception of creating a bare repository in foo/.git and calling
+ * is_git_repository(foo).
+ */
+static int is_git_repository(struct strbuf *path)
+{
+ int ret = 0;
+ int unused_error_code;
+ size_t orig_path_len = path-len;
+ assert(orig_path_len != 0);
+ if (path-buf[orig_path_len - 1] != '/')
+ strbuf_addch(path, '/');
+ strbuf_addstr(path, .git);
+ if (read_gitfile_gently(path-buf, unused_error_code) ||
is_git_directory(path-buf))
+ ret = 1;
+ strbuf_setlen(path, orig_path_len);
+ return ret;
+}
This iteration looks reasonable overall to me.
Should this is_git_repository() helper be available to other files? I
think there are other calls to resolve_gitlink_ref() that would want the
same treatment (e.g., I think git status may have a similar issue).
-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 4/5] p7300: add performance tests for clean
On Sun, Apr 26, 2015 at 08:49:44AM +0200, Erik Elfström wrote: diff --git a/t/perf/p7300-clean.sh b/t/perf/p7300-clean.sh new file mode 100755 index 000..6ae55ec --- /dev/null +++ b/t/perf/p7300-clean.sh @@ -0,0 +1,31 @@ +#!/bin/sh + +test_description=Test git-clean performance + +. ./perf-lib.sh + +test_perf_large_repo Do we actually need a large repo here? The real cost is coming from the directories we create. We could actually start with a totally empty repository if we wanted (though I don't think the t/perf system handles that right now). But if there's not a reason to use the large repo, I think using test_perf_default_repo is better, as it works out of the box without specifying extra environment variables (well, it works either way, but you get a nasty warning from perf-lib.sh). -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] blame: CRLF in the working tree and LF in the repo
On 28/04/15 09:28, Junio C Hamano wrote: Torsten Bögershausentbo...@web.de writes: What do you think about the following test cases for a V2 patch ? test_expect_success 'create blamerepo' ' test_create_repo blamerepo ( cd blamerepo printf testcase\r\n crlffile git -c core.autocrlf=false add crlffile git commit -m add files git -c core.autocrlf=false blame crlffile crlfclean.txt ) ' test_expect_success 'blaming files with CRLF newlines in repo, core.autoclrf=input' ' ( cd blamerepo git -c core.autocrlf=input blame crlffile actual grep Not Committed Yet actual Are you interested in seeing just some of the lines to show up as Not commited yet, or all of them? I think it would be the latter, so perhaps ! grep -v Not Committed Yet actual or something? ) ' Two blank lines only here? test_expect_success 'blaming files with CRLF newlines core.autocrlf=true' ' ( cd blamerepo git -c core.autocrlf=true blame crlffile actual test_cmp crlfclean.txt actual ) ' OK Interestingly this test doesn't pass on one of my systems, after having stripped t8003 to contain to only have the corner cases. When core.autocrlf is true, the converting should be suppressed: convert.c/has_cr_in_index() should return 1, but doesn't. data = read_blob_data_from_cache(path, sz); and data is NULL. Some more digging has to be done here. On the other hand we want to test blame on a file with LF in the repo and CRLF in the workspace as well. So all in all I need to send a V2. test_expect_success 'blaming files with CRLF newlines core.autocrlf=false' ' ( cd blamerepo git -c core.autocrlf=false blame crlffile actual test_cmp crlfclean.txt actual ) ' Hmm, how's this blame invocation any different from the one done in the set-up step at the very beginning? In other words, I am not sure what kind of breakage could cause this step to fail. I see there is no git blame HEAD crlffile that bypasses the fake latest commit altogether. Wouldn't that be the most appropriate thing to compare against (i.e. how to create crlfclean.txt in the set-up step)? Jepp, There is room for improvements. -- 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
