Re: [RFC] git clean --local
> > Would something like git clean --exclude=file-pattern work as a > > compromise notion? Files matching the pattern would not be cleaned > > regardless of .gitignore or their potential preciousness status > > long-term. Multiple repetitions of the --exclude option might be > > supportable. I could see that being somewhat useful in scripting. > > I think "git clean" already takes "-e", but I am not sure if it is > meant to do what you wrote above. It does already take --exclude=file-pattern, which is like adding lines to .gitignore. (W/o -x/-X, that would mean DON'T clean them, but with -x/-X, it means DO clean them.) > > If "git clean" takes a pathspec, perhaps you can give a negative > pathspec to exclude whatever you do not want to get cleaned, > something like > > git clean '*.o' ':!precious.o' > I like this, but I'm also 100% satisfied with Junio's previous suggestion: git -c core.excludesFile=/dev/null clean ...
Price Inquiry 03-12-2018
Hi,friend, This is Daniel Murray and i am from Sinara Group Co.Ltd in Russia. We are glad to know about your company from the web and we are interested in your products. Could you kindly send us your Latest catalog and price list for our trial order. Best Regards, Daniel Murray Purchasing Manager
Re: [PATCH] t5004: avoid using tar for empty packages
Carlo Marcelo Arenas Belón writes:
> ea2d20d4c2 ("t5004: avoid using tar for checking emptiness of archive",
> 2013-05-09), introduced a fake empty tar archive to allow for portable
> tests of emptiness without having to invoke tar
>
> 4318094047 ("archive: don't add empty directories to archives", 2017-09-13)
> changed the expected result for its tests from one containing an empty
> directory to a plain empty archive but the portable test wasn't updated
> resulting on them failing again in (at least) NetBSD and OpenBSD
>
> Signed-off-by: Carlo Marcelo Arenas Belón
> ---
> t/t5004-archive-corner-cases.sh | 17 -
> 1 file changed, 8 insertions(+), 9 deletions(-)
>
> diff --git a/t/t5004-archive-corner-cases.sh b/t/t5004-archive-corner-cases.sh
> index ced44355ca..271eb5a1fd 100755
> --- a/t/t5004-archive-corner-cases.sh
> +++ b/t/t5004-archive-corner-cases.sh
> @@ -3,8 +3,12 @@
> test_description='test corner cases of git-archive'
> . ./test-lib.sh
>
> -test_expect_success 'create commit with empty tree' '
> - git commit --allow-empty -m foo
> +# the 10knuls.tar file is used to test for an empty git generated tar
> +# without having to invoke tar because an otherwise valid empty GNU tar
> +# will be considered broken by {Open,Net}BSD tar
> +test_expect_success 'create commit with empty tree and fake empty tar' '
> + git commit --allow-empty -m foo &&
> + perl -e "print \"\\0\" x 10240" >10knuls.tar
> '
OK, so you moved the creation of the file with block of NULs to the
set-up phase of the entire script.
> # Make a dir and clean it up afterwards
> @@ -47,7 +51,6 @@ test_expect_success HEADER_ONLY_TAR_OK 'tar archive of
> commit with empty tree' '
>
> test_expect_success 'tar archive of empty tree is empty' '
> git archive --format=tar HEAD: >empty.tar &&
> - perl -e "print \"\\0\" x 10240" >10knuls.tar &&
> test_cmp_bin 10knuls.tar empty.tar
> '
And because of that, this one that was added for ea2d20d4 ("t5004:
avoid using tar for checking emptiness of archive", 2013-05-09) is
now simplified. It can use the one that was created in the set-up
phase.
> @@ -106,16 +109,12 @@ test_expect_success 'create a commit with an empty
> subtree' '
>
> test_expect_success 'archive empty subtree with no pathspec' '
> git archive --format=tar $root_tree >subtree-all.tar &&
> - make_dir extract &&
> - "$TAR" xf subtree-all.tar -C extract &&
> - check_dir extract
> + test_cmp_bin 10knuls.tar subtree-all.tar
> '
And then we avoid the test that assumes that an empty tar archive
can safely and portably extracted, and instead check the emptiness
the same way as the earlier test here ...
> test_expect_success 'archive empty subtree by direct pathspec' '
> git archive --format=tar $root_tree -- sub >subtree-path.tar &&
> - make_dir extract &&
> - "$TAR" xf subtree-path.tar -C extract &&
> - check_dir extract
> + test_cmp_bin 10knuls.tar subtree-path.tar
> '
... and here, too.
OK, and the result is consistent with the "We can help GNU and BSD
tar, but NetBSD tar cannot be salvageable" approach, laid out in the
earlier ea2d20d4 ("t5004: avoid using tar for checking emptiness of
archive", 2013-05-09). Makes sense.
Thanks.
Re: BUG: CR marker ^M doesn't show up in '-' lines of diffs when the ending of the removed line is CR+LF
Frank Schäfer writes: > Hi Junio, > > Am 29.11.18 um 03:11 schrieb Junio C Hamano: > [...] >> This was misspoken a bit. Let's revise it to >> >> When producing a colored output (not limited to whitespace >> error coloring of diff output) for contents that are not >> marked as eol=crlf (and other historical means), insert >> before a CR that comes immediately before a LF. > You mean > ... > *after* a CR that comes immediately before a LF." > > OK, AFAICS this produces the desired output in all cases if eol=lf. OK, yeah, I think I meant "after", i.e. ... CR LF, in order to force CR to be separated from LF. > Now what about the case eol=crlf ? I have no strong opinions, other than that "LF in repository, CRLF in working tree" would make the issue go away (when it is solved for EOL=LF like the above, that is). > Keeping the current behavior of '-' lines is correct. > But shouldn't ^M now be suppressed in '+' lines for a consistent behavior ? If "LF in repository, CRLF in working tree" is done, there would not be ^M at the end of the line, not just for removed lines, but also for added lines, no?
Re: [PATCH] Do not fail test if '.' is part of $PATH
"H.Merijn Brand" writes: > When $PATH contains the current directory as .:PATH, PATH:., PATH:.:PATH, > or (maybe worse) as :PATH, PATH:, or PATH::PATH - as an empty entry is > identical to having dot in $PATH - this test used to fail It is totally unclear what "this test" refers to. Let's retitle it to > Subject: [PATCH] t0061: do not fail test if '.' is part of $PATH and do something like this: t0061 created a script named with an unlikely name in the current directory to ensure that it is not found via the run_command() API, expecting that $PATH does not contain an element that names the current directory (i.e. '.' or '') in a sane environment. This obviously would not work if the $PATH does contain such an element. Introduce a DOT_IN_PATH lazy prerequisite to catch such a case and skip the test when the environment is not so sane. > +test_lazy_prereq DOT_IN_PATH ' > + case ":$PATH:" in > + *:.:*|*::*) true ;; > + *) false ;; > + esac > +' > + > +test_expect_success !DOT_IN_PATH 'run_command is restricted to PATH' ' > write_script should-not-run <<-\EOF && > echo yikes > EOF I also like Peff's more straight-forward approach that avoids looking into PATH but instead ask the shell what we care about (i.e. would we end up running 'should-not-run' if we asked the system to run it without giving an explicit path to it?). The last paragraph of the above would need to change if we were to go in that direction to something like Check if the running shell picks up the script without an explicit path to it and skip the test when it does. perhaps. The code to do so got a bit more compact than what Peff wrote but I think it still retains its main beauty, which is how straight-forward it is. t/t0061-run-command.sh | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/t/t0061-run-command.sh b/t/t0061-run-command.sh index cf932c8514..17b560370e 100755 --- a/t/t0061-run-command.sh +++ b/t/t0061-run-command.sh @@ -29,7 +29,15 @@ test_expect_success 'run_command can run a command' ' test_must_be_empty err ' -test_expect_success 'run_command is restricted to PATH' ' + +test_lazy_prereq RUNS_COMMANDS_FROM_PWD ' + write_script runs-commands-from-pwd <<-\EOF && + true + EOF + runs-commands-from-pwd >/dev/null 2>&1 +' + +test_expect_success !RUNS_COMMANDS_FROM_PWD 'run_command is restricted to PATH' ' write_script should-not-run <<-\EOF && echo yikes EOF
Re: [PATCH] Do not fail test if '.' is part of $PATH
Jeff King writes: > Since the test is ultimately checking "can we run should-not-run from > the current directory", might it be simpler to actually try that as the > precondition? I.e., something like: > ... A nice egg of columbus. It also would save us from mischievous users who have should-not-run somewhere no the $PATH that outputs the string we expect (no, I do not think it is a common thing to do; I am just saying that the solution covers such an extremely stupid case without special casing).
Re: BUG: CR marker ^M doesn't show up in '-' lines of diffs when the ending of the removed line is CR+LF
Am 02.12.18 um 20:31 schrieb Frank Schäfer: Am 29.11.18 um 03:11 schrieb Junio C Hamano: [...] This was misspoken a bit. Let's revise it to When producing a colored output (not limited to whitespace error coloring of diff output) for contents that are not marked as eol=crlf (and other historical means), insert before a CR that comes immediately before a LF. You mean ... *after* a CR that comes immediately before a LF." OK, AFAICS this produces the desired output in all cases if eol=lf. Now what about the case eol=crlf ? Keeping the current behavior of '-' lines is correct. But shouldn't ^M now be suppressed in '+' lines for a consistent behavior ? That can be achieved with whitespace=cr-at-eol. With other words: "If CR comes immediately before a LF, do the following with *all* lines: after the CR if eol=lf but do not after the CR if eol=crlf." Why? It is the pager's duty to highlight CR, IMO. If it doesn't, but the user wants to see them, then they are using the wrong pager or the wrong pager settings. As far as I am concerned, I do not have any of my files marked as eol=crlf, but I do *not* want to see ^M in the pager. I.e., having git insert between CR and LF would do the wrong thing for me. -- Hannes
DEAREST ONE
Greetings My name is Miss Alizata Aron. It give me a great pleasure to write you, it attracts me to write to you so that we can be friends if you will have the desire as me. i will be very happy to be in communication with you so that we can get to know each other better and see what happens in future. I await your reply so that i can tell you more about myself and give you my picture. Have a blessed day. Miss Alizata Aron.
Re: [PATCH] rebase -i: introduce the 'test' command
Hi Peff, On Sat, 1 Dec 2018, Jeff King wrote: > On Thu, Nov 29, 2018 at 09:32:48AM +0100, Johannes Schindelin wrote: > > > > > Would it not make more sense to add a command-line option (and a config > > > > setting) to re-schedule failed `exec` commands? Like so: > > > > > > Your proposition would do in most cases, however it is not possible to > > > make a distinction between reschedulable and non-reschedulable commands. > > > > True. But I don't think that's so terrible. > > > > What I think is something to avoid is two commands that do something very, > > very similar, but with two very, very different names. > > > > In reality, I think that it would even make sense to change the default to > > reschedule failed `exec` commands. Which is why I suggested to also add a > > config option. > > I sometimes add "x false" to the top of the todo list to stop and create > new commits before the first one. That would be awkward if I could never > get past that line. However, I think elsewhere a "pause" line has been > discussed, which would serve the same purpose. Yep, `break`, as Eric pointed out. After all, you did not really want a command to fail, you just wanted the interactive rebase to give you a break. > I wonder how often this kind of "yes, I know it fails, but keep going > anyway" situation would come up. And what the interface is like for > getting past it. E.g., what if you fixed a bunch of stuff but your tests > still fail? You may not want to abandon the changes you've made, but you > need to "rebase --continue" to move forward. I encounter this often when > the correct fix is actually in an earlier commit than the one that > yields the test failure. You can't rewind an interactive rebase, so I > complete and restart it, adding an "e"dit at the earlier commit. > > How would I move past the test that fails to continue? I guess "git > rebase --edit-todo" and then manually remove it (and any other remaining > test lines)? Yes, the current way would be to use `git rebase --edit-todo`. > That's not too bad, but I wonder if people would find it more awkward > than the current way (which is to just "rebase --continue" until you get > to the end). > > I dunno. I am not sure if I am for or against changing the default, so > these are just some musings. :) It's good that you chimed in with your side of things. If you missed the `break` command, so will many others have missed it. And continue to miss it. Besides, Junio mentioned elsewhere that he is in the camp of people who wait for enough users to complain why some config option isn't the default to actually change the default. So... I guess we'll leave the default where it is for now. Ciao, Dscho
Re: [PATCH/RFC v3 00/14] Introduce new commands switch-branch and restore-files
Thomas Gummerer writes:
> Agreed, I think --{no-,}overlay is a much better name for the option,
> I'll use that for my patch series (I hope to send that soon after 2.20
> is released).
OK.
> I must admit that I was not aware that the mode is called overlay
> mode, before you explained it to me, so I wouldn't expect most users
> to know either. But as it's easy to explain that probably doesn't
> matter much.
I do not think "the mode is called the overlay mode" is so accurate
a description. I think I've seen the word 'overlay' used to
describe the behaviour in earlier discussions, but because there is
no 'non-overlay' mode exists in versions of 'git checkout' the
end-users have, the users won't even be aware of the possibility
that mode different from what they are used to see could exist, or
that the mode that they are used to see could be called/explained as
the 'overlay' mode. IOW, we should pick the best phrase to explain
the behaviour we can use when coming up with the command line
option, and that phrase does not have to be 'overlay'---there is no
"using the word 'overlay' for this is good because the users are
familiar with the existing use of the word", simply because there
isn't such familiarilty ;-)
Re: [L10N] Kickoff for Git 2.20.0 round 3
Jiang Xin writes: > Git v2.20.0-rc2 has been released, and there are 5 new messages need to > be translated. So let's start new round of l10n for Git 2.20.0. A huge thanks, as always, to the translation team. Jiang, sorry to see that -rc2 slipped just after you sent out the round 2 message and you needed to start round 3 just after it.
Fill the form
We are licensed loan company, rendering our customers with amount they need is our main priority. We offer all kinds of loans. reply us now for more details.
Re: [RFC] git clean --local
"Randall S. Becker" writes: > Would something like git clean --exclude=file-pattern work as a > compromise notion? Files matching the pattern would not be cleaned > regardless of .gitignore or their potential preciousness status > long-term. Multiple repetitions of the --exclude option might be > supportable. I could see that being somewhat useful in scripting. I think "git clean" already takes "-e", but I am not sure if it is meant to do what you wrote above. If "git clean" takes a pathspec, perhaps you can give a negative pathspec to exclude whatever you do not want to get cleaned, something like git clean '*.o' ':!precious.o' to say "presious.o is ignored (hence normally expendable), but I do not want to clean it with this invocation of 'git clean'"?
Re: BUG: CR marker ^M doesn't show up in '-' lines of diffs when the ending of the removed line is CR+LF
Hi Junio, Am 29.11.18 um 03:11 schrieb Junio C Hamano: [...] > This was misspoken a bit. Let's revise it to > > When producing a colored output (not limited to whitespace > error coloring of diff output) for contents that are not > marked as eol=crlf (and other historical means), insert >before a CR that comes immediately before a LF. You mean ... *after* a CR that comes immediately before a LF." OK, AFAICS this produces the desired output in all cases if eol=lf. Now what about the case eol=crlf ? Keeping the current behavior of '-' lines is correct. But shouldn't ^M now be suppressed in '+' lines for a consistent behavior ? With other words: "If CR comes immediately before a LF, do the following with *all* lines: after the CR if eol=lf but do not after the CR if eol=crlf." Regards, Frank
Re: [PATCH/RFC v3 00/14] Introduce new commands switch-branch and restore-files
On 11/30, Junio C Hamano wrote:
>
> I am unsure about the wisdom of calling it "--index", though.
>
> The "--index" option is "the command can work only on the index, or
> only on the working tree files, or on both the index and the working
> tree files, and this option tells it to work in the 'both the index
> and the working tree files' mode", but when "restore-files" touches
> paths, it always modifies both the index and the working tree, so
> the "--index" option does not capture the differences well in this
> context [*1*]. As I saw this was described as "not using the usual
> 'overlay' semantics [*2*]", perhaps --overlay/--no-overlay option
> that defaults to --no-overlay is easier to explain.
Agreed, I think --{no-,}overlay is a much better name for the option,
I'll use that for my patch series (I hope to send that soon after 2.20
is released).
I must admit that I was not aware that the mode is called overlay
mode, before you explained it to me, so I wouldn't expect most users
to know either. But as it's easy to explain that probably doesn't
matter much.
> side note 1. I think the original mention of "--index" came in
> the context of contrasting "git reset" with "git checkout".
> "git reset (--hard|--mixed) -- " (that does not move
> HEAD), which does not but perhaps should exist, is very much
> like "git checkout -- ", and if "reset" were written
> after the "--index/--cached" convention was established, "reset
> --hard" would have called "reset --index" while "reset --mixed"
> would have been "reset --cached" (i.e. only work on the index
> and not on the working tree). And "reset --index "
> would have worked by removing paths in that are not
> in the HEAD and updating paths in that are in the
> HEAD, i.e. identical to the non overlay behaviour proposed for
> the "git checkout" command. So calling the non overlay mode
> "--index" makes sense in the context of discussing "git reset",
> and not in the context of "git checkout".
>
> side note 2. "git checkout " grabs entries
> from the that patch and adds them to the
> index and checks them out to the working tree. If the original
> index has entries that match but do not appear in
> , they are left in the result. That is "overlaying
> what was taken from the on top of what is in the
> index".
>
> Having said all that, I will not be looking at the series until 2.20
> final. And I hope more people do the same to concentrate on helping
> us prevent the last minute glitch slipping in the final release.
>
> Thanks.
Hello?
-- Hello? I apologize for invading your privacy, especially by contacting you with this tool. I have a commercial offer (7,800,000.00 dollar left by my last client who worked and lived here in my country, I appeal to you because you share the same last name with the deceased, please reply directly to my personal email address below for more information about this transaction. Yours faithfully, Tep Sereyan Email tepsereya...@gmail.com
RE: [RFC] git clean --local
On December 2, 2018 8:26, Ævar Arnfjörð Bjarmason wrote: > > On Sat, Dec 01 2018, Cameron Boehmer wrote: > > > 1) add a new flag > > -l, --local > > Do not consult git config --global core.excludesFile in > > determining what files git ignores. This is useful in conjunction with > > -x/-X to preserve user files while removing build artifacts. > > Or perhaps a general flag to ignore configuration would be useful for such > cases, see https://public- > inbox.org/git/87zhtqvm66@evledraar.gmail.com/ Would something like git clean --exclude=file-pattern work as a compromise notion? Files matching the pattern would not be cleaned regardless of .gitignore or their potential preciousness status long-term. Multiple repetitions of the --exclude option might be supportable. I could see that being somewhat useful in scripting. Cheers, Randall
Re: "git add -p" versus "git add -i", followed by "p"
On Sun, 2 Dec 2018, Duy Nguyen wrote: > On Sun, Dec 2, 2018 at 6:05 PM Robert P. J. Day wrote: > > > Patch update>> 2 > > > staged unstaged path > > > * 1:unchanged+1/-0 README.md > > > * 2:unchanged+1/-0 contrib/README > > > 3:unchanged+1/-0 t/README > > > Patch update>> > > > > > > Here I hit enter. Did you? > > > > perhaps i'm just not seeing it, but from "man git-add", it > > doesn't seem obvious that you would first select the files to work > > with, then hit a simple CR to get into actual patch mode. > > I think it's the same procedure as the "update" step, which > describes this in more detail. I agree that the "patch" section does > not make this obvious. thanks, i was hoping i wasn't being a complete idiot. given time, i may submit a patch to fix the man page unless someone else gets to it first. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca/dokuwiki Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday
Re: "git add -p" versus "git add -i", followed by "p"
On Sun, Dec 2, 2018 at 6:05 PM Robert P. J. Day wrote: > > Patch update>> 2 > > staged unstaged path > > * 1:unchanged+1/-0 README.md > > * 2:unchanged+1/-0 contrib/README > > 3:unchanged+1/-0 t/README > > Patch update>> > > > > Here I hit enter. Did you? > > perhaps i'm just not seeing it, but from "man git-add", it doesn't > seem obvious that you would first select the files to work with, then > hit a simple CR to get into actual patch mode. I think it's the same procedure as the "update" step, which describes this in more detail. I agree that the "patch" section does not make this obvious. -- Duy
Re: "git add -p" versus "git add -i", followed by "p"
On Sun, 2 Dec 2018, SZEDER Gábor wrote: > On Sun, Dec 02, 2018 at 11:30:19AM -0500, Robert P. J. Day wrote: > > > > testing adding by patch for the very first time (i've just never > > needed this), and reading the "progit" book and reading the man page, > > and the impression i'm getting is that running "git add -p" (going > > straight to patch mode) is supposed to be equivalent to running "git > > add -i", then typing "p" to switch to patch mode. > > > > that is most emphatically not what i'm seeing. if i run "git add > > -p", then i get to what i expect -- the patch subsystem: > > > > $ git add -p > > diff --git a/README.asc b/README.asc > > index fa40bad..840e85b 100644 > > --- a/README.asc > > +++ b/README.asc > > @@ -1,3 +1,9 @@ > > +change 1 > > + > > + > > + > > + > > + > >= Pro Git, Second Edition > > > >Welcome to the second edition of the Pro Git book. > > Stage this hunk [y,n,q,a,d,j,J,g,/,e,?]? > > > > but if i start with "git add -i", there seems to be no way to get to > > patch mode -- certainly "p" doesn't do it. am i stupidly missing > > something trivial? is the explanation misleading or inncomplete? > > Worksforme™: > > $ echo "New content" >>README.md > $ echo "New content" >>t/README > $ echo "New content" >>contrib//README > $ git add -i > staged unstaged path > 1:unchanged+1/-0 README.md > 2:unchanged+1/-0 contrib/README > 3:unchanged+1/-0 t/README > > *** Commands *** > 1: status 2: update 3: revert 4: add untracked > 5: patch6: diff 7: quit 8: help > What now> p > staged unstaged path > 1:unchanged+1/-0 README.md > 2:unchanged+1/-0 contrib/README > 3:unchanged+1/-0 t/README > Patch update>> 1 > staged unstaged path > * 1:unchanged+1/-0 README.md > 2:unchanged+1/-0 contrib/README > 3:unchanged+1/-0 t/README > Patch update>> 2 > staged unstaged path > * 1:unchanged+1/-0 README.md > * 2:unchanged+1/-0 contrib/README > 3:unchanged+1/-0 t/README > Patch update>> > > Here I hit enter. Did you? perhaps i'm just not seeing it, but from "man git-add", it doesn't seem obvious that you would first select the files to work with, then hit a simple CR to get into actual patch mode. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca/dokuwiki Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday
Re: "git add -p" versus "git add -i", followed by "p"
On Sun, 2 Dec 2018, SZEDER Gábor wrote: > On Sun, Dec 02, 2018 at 11:30:19AM -0500, Robert P. J. Day wrote: > > > > testing adding by patch for the very first time (i've just never > > needed this), and reading the "progit" book and reading the man page, > > and the impression i'm getting is that running "git add -p" (going > > straight to patch mode) is supposed to be equivalent to running "git > > add -i", then typing "p" to switch to patch mode. > > > > that is most emphatically not what i'm seeing. if i run "git add > > -p", then i get to what i expect -- the patch subsystem: > > > > $ git add -p > > diff --git a/README.asc b/README.asc > > index fa40bad..840e85b 100644 > > --- a/README.asc > > +++ b/README.asc > > @@ -1,3 +1,9 @@ > > +change 1 > > + > > + > > + > > + > > + > >= Pro Git, Second Edition > > > >Welcome to the second edition of the Pro Git book. > > Stage this hunk [y,n,q,a,d,j,J,g,/,e,?]? > > > > but if i start with "git add -i", there seems to be no way to get to > > patch mode -- certainly "p" doesn't do it. am i stupidly missing > > something trivial? is the explanation misleading or inncomplete? > > Worksforme™: > > $ echo "New content" >>README.md > $ echo "New content" >>t/README > $ echo "New content" >>contrib//README > $ git add -i > staged unstaged path > 1:unchanged+1/-0 README.md > 2:unchanged+1/-0 contrib/README > 3:unchanged+1/-0 t/README > > *** Commands *** > 1: status 2: update 3: revert 4: add untracked > 5: patch6: diff 7: quit 8: help > What now> p > staged unstaged path > 1:unchanged+1/-0 README.md > 2:unchanged+1/-0 contrib/README > 3:unchanged+1/-0 t/README > Patch update>> 1 > staged unstaged path > * 1:unchanged+1/-0 README.md > 2:unchanged+1/-0 contrib/README > 3:unchanged+1/-0 t/README > Patch update>> 2 > staged unstaged path > * 1:unchanged+1/-0 README.md > * 2:unchanged+1/-0 contrib/README > 3:unchanged+1/-0 t/README > Patch update>> > > Here I hit enter. Did you? ah, so after selecting the files to selectively stage, one enters a simple CR. got it. not sure that's obvious from the docs but i'll verify that. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca/dokuwiki Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday
Re: "git add -p" versus "git add -i", followed by "p"
On Sun, 2 Dec 2018, Kevin Daudt wrote: > On Sun, Dec 02, 2018 at 11:30:19AM -0500, Robert P. J. Day wrote: > > > > testing adding by patch for the very first time (i've just never > > needed this), and reading the "progit" book and reading the man page, > > and the impression i'm getting is that running "git add -p" (going > > straight to patch mode) is supposed to be equivalent to running "git > > add -i", then typing "p" to switch to patch mode. > > > > that is most emphatically not what i'm seeing. if i run "git add > > -p", then i get to what i expect -- the patch subsystem: > > > > $ git add -p > > diff --git a/README.asc b/README.asc > > index fa40bad..840e85b 100644 > > --- a/README.asc > > +++ b/README.asc > > @@ -1,3 +1,9 @@ > > +change 1 > > + > > + > > + > > + > > + > >= Pro Git, Second Edition > > > >Welcome to the second edition of the Pro Git book. > > Stage this hunk [y,n,q,a,d,j,J,g,/,e,?]? > > > > but if i start with "git add -i", there seems to be no way to get > > to patch mode -- certainly "p" doesn't do it. am i stupidly > > missing something trivial? is the explanation misleading or > > inncomplete? > > After selecting 'p', what do you get? > > You should see a list of modified files. You can select the files > you want to stage by the listed numbers. After you selected those > files, you press enter, and then you will get the options you'll > also see with git add -p. $ git add -i staged unstaged path 1:unchanged +12/-0 README.asc *** Commands *** 1: [s]tatus 2: [u]pdate 3: [r]evert 4: [a]dd untracked 5: [p]atch 6: [d]iff 7: [q]uit 8: [h]elp What now> p staged unstaged path 1:unchanged +12/-0 [R]EADME.asc Patch update>> 1 staged unstaged path * 1:unchanged +12/-0 [R]EADME.asc Patch update>> 1 staged unstaged path * 1:unchanged +12/-0 [R]EADME.asc Patch update>> and ... then what? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca/dokuwiki Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday
Re: "git add -p" versus "git add -i", followed by "p"
On Sun, Dec 02, 2018 at 11:30:19AM -0500, Robert P. J. Day wrote: > > testing adding by patch for the very first time (i've just never > needed this), and reading the "progit" book and reading the man page, > and the impression i'm getting is that running "git add -p" (going > straight to patch mode) is supposed to be equivalent to running "git > add -i", then typing "p" to switch to patch mode. > > that is most emphatically not what i'm seeing. if i run "git add > -p", then i get to what i expect -- the patch subsystem: > > $ git add -p > diff --git a/README.asc b/README.asc > index fa40bad..840e85b 100644 > --- a/README.asc > +++ b/README.asc > @@ -1,3 +1,9 @@ > +change 1 > + > + > + > + > + >= Pro Git, Second Edition > >Welcome to the second edition of the Pro Git book. > Stage this hunk [y,n,q,a,d,j,J,g,/,e,?]? > > but if i start with "git add -i", there seems to be no way to get to > patch mode -- certainly "p" doesn't do it. am i stupidly missing > something trivial? is the explanation misleading or inncomplete? > > rday > > -- > After selecting 'p', what do you get? You should see a list of modified files. You can select the files you want to stage by the listed numbers. After you selected those files, you press enter, and then you will get the options you'll also see with git add -p. Kevin
Re: "git add -p" versus "git add -i", followed by "p"
On Sun, Dec 02, 2018 at 11:30:19AM -0500, Robert P. J. Day wrote: > > testing adding by patch for the very first time (i've just never > needed this), and reading the "progit" book and reading the man page, > and the impression i'm getting is that running "git add -p" (going > straight to patch mode) is supposed to be equivalent to running "git > add -i", then typing "p" to switch to patch mode. > > that is most emphatically not what i'm seeing. if i run "git add > -p", then i get to what i expect -- the patch subsystem: > > $ git add -p > diff --git a/README.asc b/README.asc > index fa40bad..840e85b 100644 > --- a/README.asc > +++ b/README.asc > @@ -1,3 +1,9 @@ > +change 1 > + > + > + > + > + >= Pro Git, Second Edition > >Welcome to the second edition of the Pro Git book. > Stage this hunk [y,n,q,a,d,j,J,g,/,e,?]? > > but if i start with "git add -i", there seems to be no way to get to > patch mode -- certainly "p" doesn't do it. am i stupidly missing > something trivial? is the explanation misleading or inncomplete? Worksforme™: $ echo "New content" >>README.md $ echo "New content" >>t/README $ echo "New content" >>contrib//README $ git add -i staged unstaged path 1:unchanged+1/-0 README.md 2:unchanged+1/-0 contrib/README 3:unchanged+1/-0 t/README *** Commands *** 1: status 2: update 3: revert 4: add untracked 5: patch6: diff 7: quit 8: help What now> p staged unstaged path 1:unchanged+1/-0 README.md 2:unchanged+1/-0 contrib/README 3:unchanged+1/-0 t/README Patch update>> 1 staged unstaged path * 1:unchanged+1/-0 README.md 2:unchanged+1/-0 contrib/README 3:unchanged+1/-0 t/README Patch update>> 2 staged unstaged path * 1:unchanged+1/-0 README.md * 2:unchanged+1/-0 contrib/README 3:unchanged+1/-0 t/README Patch update>> Here I hit enter. Did you? diff --git a/README.md b/README.md index f920a42fad..63dee5cfc3 100644 --- a/README.md +++ b/README.md @@ -62,3 +62,4 @@ and the name as (depending on your mood): [Documentation/giteveryday.txt]: Documentation/giteveryday.txt [Documentation/gitcvs-migration.txt]: Documentation/gitcvs-migration.txt [Documentation/SubmittingPatches]: Documentation/SubmittingPatches +New content Stage this hunk [y,n,q,a,d,e,?]? y diff --git a/contrib/README b/contrib/README index 05f291c1f1..2b152dfcff 100644 --- a/contrib/README +++ b/contrib/README @@ -41,3 +41,4 @@ submit a patch to create a subdirectory of contrib/ and put your stuff there. -jc +New content Stage this hunk [y,n,q,a,d,e,?]? n *** Commands *** 1: status 2: update 3: revert 4: add untracked 5: patch6: diff 7: quit 8: help What now> q Bye. $ git diff --cached diff --git a/README.md b/README.md index f920a42fad..63dee5cfc3 100644 --- a/README.md +++ b/README.md @@ -62,3 +62,4 @@ and the name as (depending on your mood): [Documentation/giteveryday.txt]: Documentation/giteveryday.txt [Documentation/gitcvs-migration.txt]: Documentation/gitcvs-migration.txt [Documentation/SubmittingPatches]: Documentation/SubmittingPatches +New content $ Arguably the documentation could make it clear that the user can choose multiple files at once, e.g.: diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt index c9623854bf..061f9cbb0d 100644 --- a/Documentation/git-add.txt +++ b/Documentation/git-add.txt @@ -317,9 +317,9 @@ add untracked:: patch:: - This lets you choose one path out of a 'status' like selection. - After choosing the path, it presents the diff between the index - and the working tree file and asks you if you want to stage + This lets you choose one or more paths out of a 'status' like selection. + After choosing the path(s), it presents the diff between the index + and the working tree file(s) and asks you if you want to stage the change of each hunk. You can select one of the following options and type return: And perhaps we could have a dedicated menu entry for "I'm done with selecting paths"? Dunno; I'm a 'git add -p' user myself.
"git add -p" versus "git add -i", followed by "p"
testing adding by patch for the very first time (i've just never needed this), and reading the "progit" book and reading the man page, and the impression i'm getting is that running "git add -p" (going straight to patch mode) is supposed to be equivalent to running "git add -i", then typing "p" to switch to patch mode. that is most emphatically not what i'm seeing. if i run "git add -p", then i get to what i expect -- the patch subsystem: $ git add -p diff --git a/README.asc b/README.asc index fa40bad..840e85b 100644 --- a/README.asc +++ b/README.asc @@ -1,3 +1,9 @@ +change 1 + + + + + = Pro Git, Second Edition Welcome to the second edition of the Pro Git book. Stage this hunk [y,n,q,a,d,j,J,g,/,e,?]? but if i start with "git add -i", there seems to be no way to get to patch mode -- certainly "p" doesn't do it. am i stupidly missing something trivial? is the explanation misleading or inncomplete? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca/dokuwiki Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday
Re: easy way to demonstrate length of colliding SHA-1 prefixes?
On Sun, 2 Dec 2018, Ævar Arnfjörð Bjarmason wrote:
> On Sun, Dec 02 2018, Robert P. J. Day wrote:
>
> > as part of an upcoming git class i'm delivering, i thought it
> > would be amusing to demonstrate the maximum length of colliding
> > SHA-1 prefixes in a repository (in my case, i use the linux kernel
> > git repo for most of my examples).
> >
> > is there a way to display the objects in the object database
> > that clash in the longest object name SHA-1 prefix; i mean, short
> > of manually listing all object names, running that through cut and
> > sort and uniq and ... you get the idea.
> >
> > is there a cute way to do that? thanks.
>
> You'll always need to list them all. It's inherently an operation
> where for each SHA-1 you need to search for other ones with that
> prefix up to a given length.
i assumed as much, just wasn't sure about the esoteric dark corners
of git i've never gotten to yet.
> Perhaps you've missed that you can use --abbrev=N for this, and just
> grep for things that are loger than that N, e.g. for linux.git:
>
> git log --oneline --abbrev=10 --pretty=format:%h |
> grep -E -v '^.{10}$' |
> perl -pe 's/^(.{10}).*/$1/'
>
> This will list the 4 objects that need more than 10 characters to be
> shown unambiguously. If you then "git cat-file -t" them you'll get
> the disambiguation help.
that's pretty close to what i came up with, thanks.
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca/dokuwiki
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
Re: [PATCH v3 01/42] parse-options: support --git-completion-helper
On Fri, Feb 09 2018, Nguyễn Thái Ngọc Duy wrote:
> +static int show_gitcomp(struct parse_opt_ctx_t *ctx,
> + const struct option *opts)
> +{
Says it returns 'static int'...
> [...]
> + exit(0);
Then just exits...
> + /* lone --git-completion-helper is asked by git-completion.bash
> */
> + if (ctx->total == 1 && !strcmp(arg + 1,
> "-git-completion-helper"))
> + return show_gitcomp(ctx, options);
This return value is never used.
Whine from SunCC (not fatal, also this was in v2.17.0 so no need to fix
before 2.20, just saw this now):
"parse-options.c", line 520: warning: Function has no return
statement : show_gitcomp
Re: [RFC] git clean --local
On Sat, Dec 01 2018, Cameron Boehmer wrote: > 1) add a new flag > -l, --local > Do not consult git config --global core.excludesFile in > determining what files git ignores. This is useful in conjunction with > -x/-X to preserve user files while removing build artifacts. Or perhaps a general flag to ignore configuration would be useful for such cases, see https://public-inbox.org/git/87zhtqvm66@evledraar.gmail.com/
Re: easy way to demonstrate length of colliding SHA-1 prefixes?
On Sun, Dec 02 2018, Robert P. J. Day wrote:
> as part of an upcoming git class i'm delivering, i thought it would
> be amusing to demonstrate the maximum length of colliding SHA-1
> prefixes in a repository (in my case, i use the linux kernel git repo
> for most of my examples).
>
> is there a way to display the objects in the object database that
> clash in the longest object name SHA-1 prefix; i mean, short of
> manually listing all object names, running that through cut and sort
> and uniq and ... you get the idea.
>
> is there a cute way to do that? thanks.
You'll always need to list them all. It's inherently an operation where
for each SHA-1 you need to search for other ones with that prefix up to
a given length.
Perhaps you've missed that you can use --abbrev=N for this, and just
grep for things that are loger than that N, e.g. for linux.git:
git log --oneline --abbrev=10 --pretty=format:%h |
grep -E -v '^.{10}$' |
perl -pe 's/^(.{10}).*/$1/'
This will list the 4 objects that need more than 10 characters to be
shown unambiguously. If you then "git cat-file -t" them you'll get the
disambiguation help.
easy way to demonstrate length of colliding SHA-1 prefixes?
as part of an upcoming git class i'm delivering, i thought it would be amusing to demonstrate the maximum length of colliding SHA-1 prefixes in a repository (in my case, i use the linux kernel git repo for most of my examples). is there a way to display the objects in the object database that clash in the longest object name SHA-1 prefix; i mean, short of manually listing all object names, running that through cut and sort and uniq and ... you get the idea. is there a cute way to do that? thanks. rday
Re: [PATCH 8/9] sha1-file: use loose object cache for quick existence check
Am 13.11.2018 um 11:02 schrieb Ævar Arnfjörð Bjarmason: > > On Mon, Nov 12 2018, Ævar Arnfjörð Bjarmason wrote: > >> On Mon, Nov 12 2018, Ævar Arnfjörð Bjarmason wrote: >> >>> I get: >>> >>> Test origin/master >>> peff/jk/loose-cache avar/check-collisions-config >>> >>> >>> 0008.2: index-pack with 256*1 loose objects 4.31(0.55+0.18) >>> 0.41(0.40+0.02) -90.5% 0.23(0.36+0.01) -94.7% >>> 0008.3: index-pack with 256*10 loose objects 4.37(0.45+0.21) >>> 0.45(0.40+0.02) -89.7% 0.25(0.38+0.01) -94.3% >>> 0008.4: index-pack with 256*100 loose objects4.47(0.53+0.23) >>> 0.67(0.63+0.02) -85.0% 0.24(0.38+0.01) -94.6% >>> 0008.5: index-pack with 256*250 loose objects5.01(0.67+0.30) >>> 1.04(0.98+0.06) -79.2% 0.24(0.37+0.01) -95.2% >>> 0008.6: index-pack with 256*500 loose objects5.11(0.57+0.21) >>> 1.81(1.70+0.09) -64.6% 0.25(0.38+0.01) -95.1% >>> 0008.7: index-pack with 256*750 loose objects5.12(0.60+0.22) >>> 2.54(2.38+0.14) -50.4% 0.24(0.38+0.01) -95.3% >>> 0008.8: index-pack with 256*1000 loose objects 4.52(0.52+0.21) >>> 3.36(3.17+0.17) -25.7% 0.23(0.36+0.01) -94.9% >>> >>> I then hacked it to test against git.git, but skipped origin/master for >>> that one because it takes *ages*. So just mine v.s. yours: >>> >>> $ GIT_PERF_REPEAT_COUNT=3 GIT_PERF_MAKE_OPTS='-j56 CFLAGS="-O3"' ./run >>> peff/jk/loose-cache avar/check-collisions-config p0008-index-pack.sh >>> [...] >>> Test peff/jk/loose-cache >>> avar/check-collisions-config >>> >>> --- >>> 0008.2: index-pack with 256*1 loose objects 12.57(28.72+0.61) >>> 12.68(29.36+0.62) +0.9% >>> 0008.3: index-pack with 256*10 loose objects 12.77(28.75+0.61) >>> 12.50(28.88+0.56) -2.1% >>> 0008.4: index-pack with 256*100 loose objects13.20(29.49+0.66) >>> 12.38(28.58+0.60) -6.2% >>> 0008.5: index-pack with 256*250 loose objects14.10(30.59+0.64) >>> 12.54(28.22+0.57) -11.1% >>> 0008.6: index-pack with 256*500 loose objects14.48(31.06+0.74) >>> 12.43(28.59+0.60) -14.2% >>> 0008.7: index-pack with 256*750 loose objects15.31(31.91+0.74) >>> 12.67(29.23+0.64) -17.2% >>> 0008.8: index-pack with 256*1000 loose objects 16.34(32.84+0.76) >>> 13.11(30.19+0.68) -19.8% >>> >>> So not much of a practical difference perhaps. But then again this isn't >>> a very realistic test case of anything. Rarely are you going to push a >>> history of something the size of git.git into a repo with this many >>> loose objects. >>> >>> Using sha1collisiondetection.git is I think the most realistic scenario, >>> i.e. you'll often end up fetching/pushing something roughly the size of >>> its entire history on a big repo, and with it: >>> >>> Test peff/jk/loose-cache >>> avar/check-collisions-config >>> >>> --- >>> 0008.2: index-pack with 256*1 loose objects 0.16(0.04+0.01) >>> 0.05(0.03+0.00) -68.8% >>> 0008.3: index-pack with 256*10 loose objects 0.19(0.04+0.02) >>> 0.05(0.02+0.00) -73.7% >>> 0008.4: index-pack with 256*100 loose objects0.32(0.17+0.02) >>> 0.04(0.02+0.00) -87.5% >>> 0008.5: index-pack with 256*250 loose objects0.57(0.41+0.03) >>> 0.04(0.02+0.00) -93.0% >>> 0008.6: index-pack with 256*500 loose objects1.02(0.83+0.06) >>> 0.04(0.03+0.00) -96.1% >>> 0008.7: index-pack with 256*750 loose objects1.47(1.24+0.10) >>> 0.04(0.02+0.00) -97.3% >>> 0008.8: index-pack with 256*1000 loose objects 1.94(1.70+0.10) >>> 0.04(0.02+0.00) -97.9% >>> >>> As noted in previous threads I have an in-house monorepo where (due to >>> expiry policies) loose objects hover around the 256*250 mark. >>> >>> The script, which is hacky as hell and takes shortcuts not to re-create >>> the huge fake loose object collection every time (takes ages). Perhaps >>> you're interested in incorporating some version of this into a v2. To be >>> useful it should take some target path as an env variable. >> >> I forgot perhaps the most useful metric. Testing against origin/master >> too on the sha1collisiondetection.git repo, which as noted above I think >> is a good stand-in for making a medium sized push to a big repo. This >> shows when the loose cache becomes counterproductive: >> >> Test origin/master >> peff/jk/loose-cache avar/check-collisions-config >> >>
Re: Confusing inconsistent option syntax
On Sun, Dec 2, 2018 at 11:13 AM Robert White wrote: > > `git log --pretty short` gives the error message "ambiguous argument > 'short'". To get the expected result, you need to use `git log > --pretty=short`. However, `git log --since yesterday` and `git log > --since=yesterday` both work as expected. > > When is an = needed? What is the reason for these inconsistencies? --pretty can take no arguments. --pretty alone is the same as --pretty=medium. --since always needs an argument. -- Duy
Confusing inconsistent option syntax
`git log --pretty short` gives the error message "ambiguous argument 'short'". To get the expected result, you need to use `git log --pretty=short`. However, `git log --since yesterday` and `git log --since=yesterday` both work as expected. When is an = needed? What is the reason for these inconsistencies? --- Robert White
