v2.15.0: commits become falsely joined when rebasing (interactively)
Hello again, i see an error with v2.15.0 that happened already back in early October (AlpineLinux [edge] pretty much up-to-date with newest git but please don't ask exact version). I failed to reproduce it back then, but now again, here is how. - It seems related to having a hook (pre-commit), and the "reword" action. - Doing a rebase interactively to move (two) commits back from HEAD downwards in a linear hierarchy, as in * 306b5c7e (HEAD -> refs/heads/notpushed) [-] COMMIT 1 * 7e34d5fa [-] COMMIT 2 the above two to be moved down * 65d216c3 (refs/remotes/origin/notpushed)... ... * 5ff5ef05 (refs/remotes/origin/next, refs/heads/next) [-].. to end up stacked upon and as new [next] - COMMIT 2 is to be picked, but COMMIT 1 shall be "r"eworded. Now what happens is that COMMIT 2 is rebased ok, but instead of simply opening the editor to allow rewording of the commit message of COMMIT 2 the pre-commit hook runs, and it has to complain in this case (lines too long), but i "commit -n" that once i committed first. Anyway git says You can amend the commit now, with git commit --amend Once you are satisfied with your changes, run git rebase --continue Which i have not asked for! More: ?1[steffen@essex nail.git]$ git status interactive rebase in progress; onto 6d437ab6 Last commands done (12 commands done): pick 7e34d5fa [-] COMMIT 2 r 306b5c7e [-] COMMIT 1 (see more in file .git/rebase-merge/done) Next commands to do (27 remaining commands): ... (use "git rebase --edit-todo" to view and edit) You are currently rebasing branch 'notpushed' on '6d437ab6'. (all conflicts fixed: run "git rebase --continue") Changes to be committed: (use "git reset HEAD ..." to unstage) modified: gen-okeys.h Untracked files not listed (use -u option to show untracked files) So far so good, but now: ?0[steffen@essex nail.git]$ git rec alias: rebase --continue [detached HEAD ca77a94a] COMMIT 1 with adjusted commit message Date: Sun Nov 19 02:19:30 2017 +0100 9 files changed, 357 insertions(+), 339 deletions(-) Successfully rebased and updated refs/heads/notpushed. Uh! It joined COMMIT 1 with COMMIT 2! Thanks for git! Ciao, --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: v2.10.0: ls-tree exit status is always 0, this differs from ls(1)
Hello,
Michael J Gruber wrote:
|Steffen Nurpmeso venit, vidit, dixit 22.09.2016 00:46:
|> Junio C Hamano wrote:
|>|Steffen Nurpmeso writes:
...
|>|I think this issue does not need a separate bullet point. The
|>|existing text says:
|> ..
|>|and what caused your surprise is already covered by the first bullet
|>|point, if the reader knows what "patterns to match" means in Git's
...
|>|How about rewriting the first bullet point like so instead:
...
|>|of the arguments does not matter, and a '' argument that
|>|does not match any path is not an error (i.e. if there is no
|>|path that matches any pattern, nothing is shown in the output).
|>
|> Not an error would have been an enlightenment to me.
...
|>
|> But now i'm even getting nervous to read about patterns.
...
|> We have patterns for tags/remotes/branches, author/committer/grep
|> patterns, (most of those, maybe all today, with fixed string,
|> extended or basic regex), the git-grep patterns ("leading paths
|> match and glob(7) patterns are supported"). Is that all?
|> I would assume glob-style for ls-tree:
...
|Maybe "git ls-files" is the command that you are looking for, really.
|
|That and others have glob pathspec enabled by default, see "git help git".
Please rollback all of that, i have only reported something that
seemed odd to me. What i really need is instead
if `git cat-file -e ${relbr}:NEWS 2>/dev/null`; then
and that is what i will end up with.
_But_, now that i am here again, "git help cat-file" says
-e
Suppress all output; instead exit with zero status if
exists and is a valid object.
and
OUTPUT
...
If -e is specified, no output.
But this is not what happens if "output" includes stderr:
?0[steffen@wales ]$ git cat-file -e HEAD:NEWS
?0[steffen@wales ]$ git cat-file -e HEAD:NEWSS
fatal: Not a valid object name HEAD:NEWSS
?128[steffen@wales ]$
I would also not expect $?=128 as an counterpart to EXIT_SUCCESS=0
when performing a qualified "test" action, but EXIT_FAILURE=1 is
just an as-bad non-0 exit status code, anyway. To me
EX_NOINPUT=66 obtrudes itself as the right status, but my own
projects don't adhere to this from a-z or not at all, so what i am
talking about? I mean, some things take time and are eventually
and temporarily a bit odd, so what? That is just how it is. Even
Sparta declined some day, and then it crushed, iirc.
Thanks for git, just yesterday evening i did rebasing and cherry
picking and commit amending and garbage collection and it saved me
days of work, or, to be more exact, i never have been able to work
the way i would work before. Really.
Ciao.
--steffen
Re: v2.10.0: ls-tree exit status is always 0, this differs from ls(1)
Junio C Hamano wrote:
|Steffen Nurpmeso writes:
...
|Sorry, but I did not notice that there was an attached patch when I
|was reading your response for the first time. Risk of using an
|attachment to e-mail ;-)
|
|I think this issue does not need a separate bullet point. The
|existing text says:
..
|and what caused your surprise is already covered by the first bullet
|point, if the reader knows what "patterns to match" means in Git's
|command line tools; it just needs to be extended to be more
|meaningful to those who don't, I think.
|
|How about rewriting the first bullet point like so instead:
|
| - the behaviour is different from that of "/bin/ls" in that the
|'' are actually patterns to match, e.g. so specifying
|directory name (without `-r`) will behave differently, the order
|of the arguments does not matter, and a '' argument that
|does not match any path is not an error (i.e. if there is no
|path that matches any pattern, nothing is shown in the output).
Not an error would have been an enlightenment to me.
But now i'm even getting nervous to read about patterns.
We have patterns for tags/remotes/branches, author/committer/grep
patterns, (most of those, maybe all today, with fixed string,
extended or basic regex), the git-grep patterns ("leading paths
match and glob(7) patterns are supported"). Is that all?
I would assume glob-style for ls-tree:
?0[steffen@wales ]$ git ls-tree HEAD `ls mime*`
100644 blob ee47419c209da789b606ab6d979c22f4ae632712mime.c
100644 blob 0cfe3766bd5f035eac06b728a4f63224455e13camime.types
100644 blob 7d890df7553522691ed09f266ea7f9effb6a2f4emime_enc.c
100644 blob 430e300d9a8887c5cd48d1cc63034168e47e9721mime_param.c
100644 blob 0338a46d3247ea00b5bcedb2d82ff30fe5d18d48mime_parse.c
100644 blob d62fa8defae27240a5ce81ad2239dd7f94b6c5c5mime_types.c
?0[steffen@wales ]$ git ls-tree HEAD 'mime*'
?0[steffen@wales ]$ git ls-tree HEAD 'mime.*'
No, ls-tree is not part of what i use every day, "Git's command
line tools" is (too) wide afield, in that sense.
Thank you (also in general, for git), and ciao from a country with
a pretty real autumn,
--steffen
Re: v2.10.0: ls-tree exit status is always 0, this differs from ls(1)
Hello. Junio C Hamano wrote: |Steffen Nurpmeso writes: |> I think this behaviour contradicts the manual which strongly links |> ls-tree to ls(1): | |Patches to the documentation is very much welcomed. The below could serve this purpose. |Somewhere the similarity must end, and actually it ends a lot |earlier, as "/bin/ls" takes exact paths while "ls-tree" (or any |other Git command for that matter) takes a pathspec pattern, |and not having a path that matches the pathspec pattern is not |an error condition. I was just surprised to see nothing and get no feedback at all. Ciao! --steffen diff --git a/Documentation/git-ls-tree.txt b/Documentation/git-ls-tree.txt index dbc91f9..8ebeced 100644 --- a/Documentation/git-ls-tree.txt +++ b/Documentation/git-ls-tree.txt @@ -33,6 +33,10 @@ in the current working directory. Note that: However, the current working directory can be ignored by passing --full-tree option. + - the behaviour is different to that of "/bin/ls" in sofar as non-existing + '' arguments are silently ignored and not reflected in the exit + status code. + OPTIONS --- ::
Re: v2.9.3 and v2.10.0: `name-ref' HEAD gives wrong branch name
Hello. Jakub Narębski wrote: |W dniu 20.09.2016 o 20:54, Bryan Turner pisze: |> On Tue, Sep 20, 2016 at 9:23 AM, Steffen Nurpmeso \ |> wrote: |>> Hello again, |>> |>> yah, sorry, i'm back again.. |>> I try to find a way to find the name of the current branch in an |>> automated way, because i need to ensure that a commit happens on |>> it and no other branch. Now the problem arises that the commit |>> ref at the time of that commit maybe shared in between several |>> different branches, but no more thereafter, of course: |>> |>> ?0[steffen@wales ]$ git branch|grep '^*' |>> * stable/v14.9 | |Not good, 'git branch' is a porcelain (user facing) command, so it |output may change; e.g. '*' could be replaced with '•'. For example |output for detached HEAD had changed! Ok. I went the road Bryan suggested, i had only forgotten this. Yes, it caused mysterious bugs once rev-parse reversed the output, but i didn't understand the order at first, anyway. With todays' ever-rotating distributions i don't even try to keep up; currently unthinkable to use the same release of an OS for five years, like FreeBSD 5.3. Well. ... |>> Is there another way except looking into .git/HEAD or using sed(1) |>> on the output of `branch' to find the right name? |> |> Have you tried "git symbolic-ref HEAD"? ... |This does not work for detached HEAD, but perhaps you don't need |to worry about this. No, not for me: it will only switch in between two different stable/ which exist. But thanks, just give it to me! | $ git rev-parse --symbolic-full-name HEAD | refs/heads/master This is a really good suggestion, which i will remember. I didn't know this at all yet: $ git rev-parse --symbolic-full-name --abbrev-ref=strict HEAD Seems to do exactly what i want, non-fragile, then. ... |But ... | You are in 'detached HEAD' state. [...] | | $ git rev-parse --symbolic-full-name HEAD | HEAD | | $ git symbolic-ref HEAD | fatal: ref HEAD is not a symbolic ref | | $ git branch | * (HEAD detached at 3e2ebf9) |master And name-rev gives "HEAD master~2" in a test of mine, or only "master~2", or "undefined" if i use --tags, for completeness sake. Thanks, Jakub. I'm using the plumbing. --steffen
v2.10.0: ls-tree exit status is always 0, this differs from ls(1)
I think this behaviour contradicts the manual which strongly links ls-tree to ls(1): ?0[steffen@wales ]$ ls NEWSS ls: cannot access 'NEWSS': No such file or directory ?2[steffen@wales ]$ git ls-tree --name-only master NEWSS ?0[steffen@wales ]$ ls NEWS NEWS ?0[steffen@wales ]$ git ls-tree --name-only master NEWS NEWS ?0[steffen@wales ]$ Ciao. --steffen
Re: v2.9.3 and v2.10.0: `name-ref' HEAD gives wrong branch name
Hey. Bryan Turner wrote: |On Tue, Sep 20, 2016 at 9:23 AM, Steffen Nurpmeso \ |wrote: |> yah, sorry, i'm back again.. |> I try to find a way to find the name of the current branch in an |> automated way, because i need to ensure that a commit happens on |> it and no other branch. Now the problem arises that the commit |> ref at the time of that commit maybe shared in between several |> different branches, but no more thereafter, of course: |> |> ?0[steffen@wales ]$ git branch|grep '^*' |> * stable/v14.9 |> ?0[steffen@wales ]$ git name-rev --name-only HEAD |> stable/v14.8 |> |> Is there another way except looking into .git/HEAD or using sed(1) |> on the output of `branch' to find the right name? | |Have you tried "git symbolic-ref HEAD"? Not until now. |$ git symbolic-ref HEAD |refs/heads/master Works. |If you don't want the fully-qualified ref, you can add --short: | |$ git symbolic-ref --short HEAD |master Yep, works even better. Fantastic. Thank you. And that command was already existing when i have learned to use git(1), it is even in the progit-09.markdown as of 2011-09-22 that i have laying around. Five years, and anything forgotten. That is what you get from working with blinkers on. Shame! Thank you Bryan. --steffen
v2.9.3 and v2.10.0: `name-ref' HEAD gives wrong branch name
Hello again, yah, sorry, i'm back again.. I try to find a way to find the name of the current branch in an automated way, because i need to ensure that a commit happens on it and no other branch. Now the problem arises that the commit ref at the time of that commit maybe shared in between several different branches, but no more thereafter, of course: ?0[steffen@wales ]$ git branch|grep '^*' * stable/v14.9 ?0[steffen@wales ]$ git name-rev --name-only HEAD stable/v14.8 Is there another way except looking into .git/HEAD or using sed(1) on the output of `branch' to find the right name? Thank you. Ciao! --steffen
Re: --abbrev-commit gives longer hash than necessary
Hmhm. Bryan Turner wrote: You now support git too. But say, is that you with the "stay away from the storage backend if you don't have a glue!", long ago on the Mercurial list??? Ha! See how important knowledge of an aggressively garbage-collected storage backend is. I always knew that! Ciao. --steffen -- 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: --abbrev-commit gives longer hash than necessary
Hello Jeff! Jeff King wrote: |On Thu, Jun 30, 2016 at 09:38:45PM +0200, Steffen Nurpmeso wrote: |> For some time (currently with 2.9.0) know see that a single commit |> gives a longer hash than necessary, even though there is no |> ambiguity: |I don't know what your "git longca" alias is, but presumably it's |running "git log". That will show just _commit_ hashes, but the |abbreviation code will consider all objects. Ah! That indeed explains it, i didn't know that! |There are some places you can use an abbreviated sha1 that know they are |looking for a commit, but most places will generally complain if there |is ambiguity between a blob and commit (e.g., "git show $foo"). |Try "git rev-list --objects --all | grep ^786d0c9". It clashes a file blob: ?0[steffen@wales ]$ git rev-list --objects --all | grep ^786d0c9 786d0c9c88e5d69eba603e3ed75d1f9cc6ec4e81 786d0c9d09aaf4107bcaf6c201307ed9db205df5 dotlock.c Thanks for the explanation! It seems the left side of my brain degenerates faster than the right one. Uff. How lucky i am! Ciao. --steffen -- 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
--abbrev-commit gives longer hash than necessary
Hello, for your possible interest.
For some time (currently with 2.9.0) know see that a single commit
gives a longer hash than necessary, even though there is no
ambiguity:
?0[steffen@wales ]$ git longca|
awk 'BEGIN{l7=0;l8=0}\
/^[[:alnum:]]{7} /{++l7;next}\
/^[[:alnum:]]{8} /{++l8;print}\
END{print "L7 " l7 " L8 " l8}'
786d0c9c [mimepipe.2] send.c:sendpart(): force iconv(3)+ for TEXT part
handlers..
L7 3364 L8 1
So it is only this single commit.. but why?
?0[steffen@wales ]$ git long1 786d0c9
786d0c9c [mimepipe.2] send.c:sendpart(): force iconv(3)+ for TEXT part
handlers..
?0[steffen@wales ]$ git long1 786d0c
786d0c9c [mimepipe.2] send.c:sendpart(): force iconv(3)+ for TEXT part
handlers..
?0[steffen@wales ]$ git long1 786d0
786d0c9c [mimepipe.2] send.c:sendpart(): force iconv(3)+ for TEXT part
handlers..
?0[steffen@wales ]$ git long1 786d
786d0c9c [mimepipe.2] send.c:sendpart(): force iconv(3)+ for TEXT part
handlers..
Not really ambiguous:
?0[steffen@wales ]$ git long|cut -f1 -d' '|grep ^786
786d0c9c
786f219
Ciao!
--steffen
--
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: `ab | (cd cd && git apply -)' fails with v2.0.0
Hello and good morning,
Michael J Gruber wrote:
|Junio C Hamano venit, vidit, dixit 24.07.2014 19:19:
|> Michael J Gruber writes:
|>> Steffen Nurpmeso venit, vidit, dixit 24.07.2014 15:29:
|>>> Hello (again, psst, after a long time),
|>>>
|>>> it happened yesterday that i needed to do
|>>>
|>>> $ git diff HEAD:FILE COMMIT:SAME-FILE |
|>>>> (cd src && git apply -)
|>>> ...
|>>
|>> Ah little more context would help. Are you diffing files in the subdir
|>> src, or a file at the root which happens to be present in the subdir src
|>> as well?
|>
|> As the : form is not meant to produce "git apply"
|> applicable patch in the first place, I am not sure what the OP is
|> trying to achieve in the first place. Not just "how many leading
|> levels to strip?" but "which file is being modified?" does not
|> appear in a usable form. For example, here is what you would see:
|>
|> $ git diff HEAD:GIT-VERSION-GEN maint:GIT-VERSION-GEN
|> diff --git a/HEAD:GIT-VERSION-GEN b/maint:GIT-VERSION-GEN
|> index 40adbf7..0d1a86c 100755
|> --- a/HEAD:GIT-VERSION-GEN
|> +++ b/maint:GIT-VERSION-GEN
|> @@ -1,7 +1,7 @@
|> ...
|>
|> and neither "HEAD:GIT-VERSION-GEN" nor "maint:GIT-VERSION-GEN" is
|> the file being modified ("GIT-VERSION-GEN" is).
|
|I thought "git apply" knows how to strip the rev part.
That would brighten the sky of the glorious future. Perfect!
|> I would understand if the upstream of the pipe were
|>
|> $ git diff HEAD maint -- GIT-VERSION-GEN | ...
|>
|> though.
Yes, in this case it applies the patch.
|> Needless to say, if the place "cd" goes is not a worktree controlled
|> by git, then "git apply" would not know where the top-level of the
|> target tree is, so even though the input with the corrected command
|> on the upstream side of the pipe tells it which file is being
|> modified, it needs to be told with the proper -p parameter how
|> many leading levels to strip.
|
|I think it's a common mistake to think of "git apply" as some sort of
|magic extension of "patch" which can do anything that "patch" does and
|more, and can be fed anything that "git diff" produces", figuring out by
|itself what to do with it :)
This was indeed my mistake.
But regardless i think the current behaviour sucks:
?0[steffen@sherwood x.git]$ git diff HEAD:XY 5d0d74:XY |
> (cd src && patch -p4)
can't find file to patch at input line 5
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
?130[steffen@sherwood x.git]$ git diff HEAD:XY 5d0d74:XY |
> (cd src && git apply -p4)
?0[steffen@sherwood x.git]$
and
?0[steffen@sherwood groff.git]$ git diff HEAD:XY 5d0d74:XY |
> (cd src && git apply -p2)
?0[steffen@sherwood groff.git]$ git diff HEAD:XY 5d0d74:XY |
> (cd src && patch -p2)
patching file XY
?0[steffen@sherwood groff.git]$
The number after `?' is the exit status of the last command, btw.
Ciao (and yes, thanks a lot for git(1)!)
--steffen
--
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
`ab | (cd cd && git apply -)' fails with v2.0.0
Hello (again, psst, after a long time), it happened yesterday that i needed to do $ git diff HEAD:FILE COMMIT:SAME-FILE | > (cd src && git apply -) but found that didn't work with v2.0.0 (silently succeeds?, doing nothing). It works without the subshell and the cd(1); i had to use `(cd src && patch -p2)' instead to keep in going. Just in case that is not known yet (i've updated my git(1) repo, but in the 1466 commits in between nothing sprung into my eye regarding apply, and a Gmane search didn't, too). No need to Cc: me, please just fix it; thank you. Ciao, --steffen -- 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
