git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] refs: allow @{n} to work with n-sized reflog

From
SZEDER Gábor <szeder.dev@gmail.com>
Date
Jan 5, 2021, 08:52 UTC
Message-ID
<20210105085221.GM8396@szeder.dev>
In-Reply-To
<0c6885f15f5ce0be28142d9c69724362e72481a9.1609551262.git.liu.denton@gmail.com>
On Fri, Jan 01, 2021 at 05:36:06PM -0800, Denton Liu wrote:
Show 25 quoted lines
> This sequence works
> 
> 	$ git checkout -b newbranch
> 	$ git commit --allow-empty -m one
> 	$ git show -s newbranch@{1}
> 
> and shows the state that was immediately after the newbranch was
> created.
> 
> But then if you do
> 
> 	$ git reflog expire --expire=now refs/heads/newbranch
> 	$ git commit --allow=empty -m two
> 	$ git show -s newbranch@{1}
> 
> you'd be scolded with
> 
> 	fatal: log for 'newbranch' only has 1 entries
> 
> While it is true that it has only 1 entry, we have enough
> information in that single entry that records the transition between
> the state in which the tip of the branch was pointing at commit
> 'one' to the new commit 'two' built on it, so we should be able to
> answer "what object newbranch was pointing at?". But we refuse to
> do so.

Great! I've run into this issue quite a while ago with regular 'git gc' expiring too old reflog entries, and wondered while the @{N} notation errored out while the information was clearly still there in the reflog.

https://public-inbox.org/git/20130619125059.GD20052@goldbirke/T/#u
Show 16 quoted lines
> @@ -139,6 +139,19 @@ test_expect_success 'master@{n} for various n' '
>  	test_must_fail git rev-parse --verify master@{$Np1}
>  '
>  
> +test_expect_success '@{1} works with only one reflog entry' '
> +	git checkout -B newbranch &&
> +	git reflog expire --expire=now refs/heads/newbranch &&
> +	git commit --allow-empty -mexpired &&
> +	git rev-parse --verify newbranch@{1}
> +'
> +
> +test_expect_success '@{0} works with empty reflog' '
> +	git checkout -B newbranch &&
> +	git reflog expire --expire=now refs/heads/newbranch &&
> +	git rev-parse --verify newbranch@{0}
> +'

I agree with Martin about these tests: not failing is one thing, but we should make sure that the right value is printed.

Show 6 quoted lines
>  test_expect_success SYMLINKS 'ref resolution not confused by broken symlinks' '
>  	ln -s does-not-exist .git/refs/heads/broken &&
>  	test_must_fail git rev-parse --verify broken
> -- 
> 2.30.0
> 
Previous: Denton LiuNext: Junio C Hamano
Message 4 of 21 in “refs: allow @{n} to work with n-sized reflog”
  1. refs: allow @{n} to work with n-sized reflogDenton Liu, Jan 2, 2021
  2. Martin ÅgrenJan 2, 2021
  3. Denton LiuJan 3, 2021
  4. SZEDER GáborJan 5, 2021
  5. Junio C HamanoJan 6, 2021
  6. Denton LiuJan 6, 2021
  7. Junio C HamanoJan 6, 2021
  8. 0/2 refs: allow @{n} to work with n-sized reflogDenton Liu, Jan 6, 2021
  9. 1/2 refs: factor out set_read_ref_cutoffs()Denton Liu, Jan 6, 2021
  10. 2/2 refs: allow @{n} to work with n-sized reflogDenton Liu, Jan 6, 2021
  11. SZEDER GáborJan 6, 2021
  12. 0/2 refs: allow @{n} to work with n-sized reflogDenton Liu, Jan 7, 2021
  13. 1/2 refs: factor out set_read_ref_cutoffs()Denton Liu, Jan 7, 2021
  14. 2/2 refs: allow @{n} to work with n-sized reflogDenton Liu, Jan 7, 2021
  15. Simon RuderichJan 10, 2021
  16. fixup! refs: allow @{n} to work with n-sized reflogDenton Liu, Jan 12, 2021
  17. Denton LiuJan 12, 2021
  18. Junio C HamanoJan 12, 2021
  19. SZEDER GáborJan 10, 2021
  20. Junio C HamanoJan 10, 2021
  21. 3/2 fixup! refs: allow @{n} to work with n-sized reflogDenton Liu, Jan 7, 2021

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.