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

Re: What's cooking in git.git (topics)

From
Johannes Schindelin <johannes.schindelin@gmx.de>
Date
Sep 26, 2007, 21:44 UTC
Message-ID
<Pine.LNX.4.64.0709262159430.28395@racer.site>
In-Reply-To
<7vfy11yyxk.fsf@gitster.siamese.dyndns.org>
Hi,
On Wed, 26 Sep 2007, Junio C Hamano wrote:
Show 7 quoted lines
> * mv/unknown (Tue Sep 25 16:38:46 2007 +0200) 1 commit
>  + Don't use "<unknown>" for placeholders and suppress printing of
>    empty user formats.
> 
> Parked in 'next'; I was already burned by it not passing one of the test 
> cases, and I am not absolutely certain what else this subtly breaks.  
> Hopefully minor.

I guess a few scripts could maybe rely on this behaviour. We should advertise it as such.

Show 11 quoted lines
> * lh/merge (Mon Sep 24 00:51:45 2007 +0200) 6 commits
>  + git-merge: add --ff and --no-ff options
>  + git-merge: add support for --commit and --no-squash
>  + git-merge: add support for branch.<name>.mergeoptions
>  + git-merge: refactor option parsing
>  + git-merge: fix faulty SQUASH_MSG
>  + Add test-script for git-merge porcelain
> 
> Comments?  I personally never felt need for --no-ff but the series is 
> reasonably clean so I do not see strong objection against this series 
> either.

Together with a resubmitted git-merge-rebase.sh (hint, hint), the mergeOptions would be quite useful for a workflow where you want to rebase on top of an upstream quite often.

Show 5 quoted lines
> * js/rebase-i (Tue Sep 25 16:43:15 2007 +0100) 1 commit
>  + rebase -i: work on a detached HEAD
> 
> Waiting for autogc change as this textually interacts with it, and the 
> additional convenience can wait.

Sure. I never used it anyway, but you specifically requested it ;-) BTW thanks for merging the rest; especially the progress meter was a sore point for me since long.

Show 14 quoted lines
> * jc/autogc (Mon Sep 17 00:55:13 2007 -0700) 10 commits
>  + git-gc --auto: run "repack -A -d -l" as necessary.
>  + git-gc --auto: restructure the way "repack" command line is built.
>  + git-gc --auto: protect ourselves from accumulated cruft
>  + git-gc --auto: add documentation.
>  + git-gc --auto: move threshold check to need_to_gc() function.
>  + repack -A -d: use --keep-unreachable when repacking
>  + pack-objects --keep-unreachable
>  + Export matches_pack_name() and fix its return value
>  + Invoke "git gc --auto" from commit, merge, am and rebase.
>  + Implement git gc --auto
> 
> I think the only remaining thing left with this thing is to prevent more 
> than one instances of it from running at the same time.  Any takers?
You mean, just creating a throw-away lock file?
Show 15 quoted lines
> * ph/strbuf (Tue Sep 25 10:22:44 2007 +0200) 37 commits
>  + Small cache_tree_write refactor.
>  + Make builtin-rerere use of strbuf nicer and more efficient.
>  + Add strbuf_cmp.
>  + strbuf_setlen(): do not barf on setting length of an empty buffer
>    to 0
>  + sq_quote_argv and add_to_string rework with strbuf's.
>  + Full rework of quote_c_style and write_name_quoted.
>  + ...
> 
> I had to make a small fix-up to strbuf_setlen() last night to this 
> series; this should be ready for 'master'.
> 
> And it is better to push this out early, as the series touches 
> everywhere and conflicts with peoples' patches.
Hehe.  Indeed, I had to fix the notes series after rebasing it...
Show 11 quoted lines
> * db/fetch-pack (Tue Sep 25 00:13:25 2007 -0400) 45 commits
>  + Prevent send-pack from segfaulting when a branch doesn't match
>  + Cleanup unnecessary break in remote.c
>  + Cleanup style nit of 'x == NULL' in remote.c
>  + Fix memory leaks when disconnecting transport instances
>  + Ensure builtin-fetch honors {fetch,transfer}.unpackLimit
>  + ...
> 
> Two issues known to me are:
> 
>  - "rsync" transport is not supported yet;
I promised to do this, and so I will today.
Show 8 quoted lines
> * jc/stash-create (Mon Jul 9 00:51:23 2007 -0700) 2 commits
>  + rebase: allow starting from a dirty tree.
>  + stash: implement "stash create"
> 
> I think "stash create" is going in a good direction, but I do not think 
> rebase should unstash unconditionally on the resulting work tree.  A 
> good compromise might be not to unstash if the user asked to switch 
> branches first and to unstash if he didn't.

Sounds like a sensible change to me; maybe a little warning after the rebase?

I have no idea if I come around to do the same for rebase--interactive any time soon, though.

Ciao, Dscho

Previous: Junio C HamanoNext: Tom Clarke
Message 8 of 44 in “What's cooking in git.git (topics)”
  1. Junio C HamanoSep 6, 2007
  2. Shawn O. PearceSep 14, 2007
  3. Shawn O. PearceSep 15, 2007
  4. Shawn O. PearceSep 16, 2007
  5. Johannes SchindelinSep 14, 2007
  6. Carlos RicaSep 26, 2007
  7. Junio C HamanoSep 26, 2007
  8. Johannes SchindelinSep 26, 2007
  9. Tom ClarkeSep 26, 2007
  10. Jeff KingSep 27, 2007
  11. David KastrupSep 27, 2007
  12. David KastrupSep 27, 2007
  13. Jeff KingSep 27, 2007
  14. David KastrupSep 27, 2007
  15. Jeff KingOct 2, 2007
  16. Junio C HamanoOct 2, 2007
  17. Jeff KingOct 2, 2007
  18. Jeff KingOct 2, 2007
  19. David KastrupOct 2, 2007
  20. Jeff KingOct 2, 2007
  21. David KastrupOct 2, 2007
  22. Jeff KingOct 2, 2007
  23. David KastrupOct 2, 2007
  24. Linus TorvaldsOct 3, 2007
  25. Jeff KingOct 3, 2007
  26. Linus TorvaldsOct 3, 2007
  27. David KastrupOct 3, 2007
  28. Jeff KingOct 3, 2007
  29. Linus TorvaldsOct 3, 2007
  30. David KastrupOct 3, 2007
  31. Junio C HamanoOct 4, 2007
  32. Daniel BarkalowSep 28, 2007
  33. Junio C HamanoOct 2, 2007
  34. Steven GrimmOct 2, 2007
  35. Steffen ProhaskaOct 2, 2007
  36. Matthieu MoyOct 2, 2007
  37. Junio C HamanoOct 2, 2007
  38. David KågedalOct 2, 2007
  39. Matthieu MoyOct 2, 2007
  40. Junio C HamanoOct 2, 2007
  41. rebase: make the warning more useful when the work tree is unclean.Junio C Hamano, Oct 3, 2007
  42. Matthieu MoyOct 3, 2007
  43. Johannes SchindelinOct 2, 2007
  44. Daniel BarkalowOct 2, 2007

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.