What's cooking in git.git (Mar 2009, #01; Tue, 03)

What's cooking in git.git (Mar 2009, #01; Tue, 03)

[Junio C Hamano]

Here are the topics that have been cooking.  Commits prefixed with '-' are
only in 'pu' while commits prefixed with '+' are in 'next'.  The ones
marked with '.' do not appear in any of the branches, but I am still
holding onto them.

The topics list the commits in reverse chronological order.  The topics
meant to be merged to the maintenance series have "maint-" in their names.

The master branch is slightly past 1.6.2-rc2.  It's been a week and I
think I can declare the final on this Wednesday, *if* I am not too mired
by the day job, but I do not know what would happen yet.

As an experiment, 'next' and 'pu' stayed open during this release freeze;
new topics have been accepted.  I have to say that the experiment was a
moderate success, and many topics in 'next' seem to be of fairly high
quality already, which would mean that we will have a shorter cycle before
1.6.3.

----------------------------------------------------------------
[New Topics]

* jk/clone-post-checkout (Tue Mar 3 00:37:51 2009 -0500) 1 commit
 - clone: run post-checkout hook when checking out

* hv/cvsimport (Mon Mar 2 18:59:36 2009 +0100) 1 commit
 - cvsimport: add test illustrating a bug in cvsps

* jc/push-to-create (Mon Mar 2 22:36:16 2009 -0800) 1 commit
 - Push to create

* fc/parseopt-config (Sat Feb 21 02:49:29 2009 +0200) 11 commits
 - git config: don't allow --get-color* and variable type
 - git config: don't allow extra arguments for -e or -l.
 - git config: don't allow multiple variable types
 - git config: don't allow multiple config file locations
 - git config: reorganize to use parseopt
 - git config: reorganize get_color*
 - git config: trivial rename in preparation for parseopt
 - git_config(): not having a per-repo config file is not an error
 + git config: trivial cleanup for editor action
 + git config: codestyle cleanups
 + config: Add new option to open an editor.

* tr/format-patch-thread (Thu Feb 19 22:26:33 2009 +0100) 4 commits
 - format-patch: support deep threading
 - format-patch: thread as reply to cover letter even with in-reply-
   to
 - format-patch: track several references
 - format-patch: threading test reactivation

* ns/pretty-format (Tue Feb 24 15:33:29 2009 +0200) 5 commits
 + bash completion: add --format= and --oneline options for "git log"
 + Add tests for git log --pretty, --format and --oneline.
 + Add --oneline that is a synonym to "--pretty=oneline --abbrev-
   commit"
 + Give short-hands to --pretty=tformat:%formatstring
 + Add --format that is a synonym to --pretty

* mh/cvsimport-tests (Mon Feb 23 06:08:14 2009 +0100) 5 commits
 - Add a test of "git cvsimport"'s handling of tags and branches
 - Add some tests of git-cvsimport's handling of vendor branches
 - Test contents of entire cvsimported "master" tree contents
 - Use CVS's -f option if available (ignore user's ~/.cvsrc file)
 - Start a library for cvsimport-related tests

* tr/maint-1.6.0-send-email-irt (Sun Mar 1 23:45:41 2009 +0100) 1 commit
 - send-email: respect in-reply-to regardless of threading

* jc/maint-1.6.0-keep-pack (Sat Feb 28 00:37:19 2009 -0800) 6 commits
 + is_kept_pack(): final clean-up
 + Simplify is_kept_pack()
 + Consolidate ignore_packed logic more
 + has_sha1_kept_pack(): take "struct rev_info"
 + has_sha1_pack(): refactor "pretend these packs do not exist"
   interface
 + git-repack: resist stray environment variable

* en/maint-hash-object (Sat Feb 28 12:56:49 2009 -0700) 1 commit
 + Ensure proper setup of git_dir for git-hash-object

* el/blame-date (Fri Feb 20 14:51:11 2009 -0800) 1 commit
 - Make git blame's date output format configurable, like git log

* js/remote-improvements (Wed Feb 25 03:32:28 2009 -0500) 22 commits
 - builtin-remote: new show output style for push refspecs
 - builtin-remote: new show output style
 - remote: make guess_remote_head() use exact HEAD lookup if it is
   available
 - builtin-remote: add set-head subcommand
 - builtin-remote: teach show to display remote HEAD
 - builtin-remote: fix two inconsistencies in the output of "show
   <remote>"
 - builtin-remote: make get_remote_ref_states() always populate
   states.tracked
 - builtin-remote: rename variables and eliminate redundant function
   call
 - builtin-remote: remove unused code in get_ref_states
 - builtin-remote: refactor duplicated cleanup code
 - string-list: new for_each_string_list() function
 - remote: make match_refs() not short-circuit
 - remote: make match_refs() copy src ref before assigning to
   peer_ref
 - remote: let guess_remote_head() optionally return all matches
 - remote: make copy_ref() perform a deep copy
 - remote: simplify guess_remote_head()
 - move locate_head() to remote.c
 - move duplicated ref_newer() to remote.c
 - move duplicated get_local_heads() to remote.c
 - refactor find_ref_by_name() to accept const list
 - add basic http clone/fetch tests
 - test scripts: refactor start_httpd helper

* js/clone-depth-local (Fri Feb 27 00:04:06 2009 -0800) 3 commits
 . parse_options(): do not "increment" boolean
 . clone: ignore --depth when cloning locally (implicitly --local)
 . clone: do not ignore --no-local option

Jeff had a good suggestion for this series but it was tripped by
a misfeature in parse_options().

* rs/memmem (Tue Mar 3 00:19:30 2009 +0100) 2 commits
 - optimize compat/ memmem()
 - diffcore-pickaxe: use memmem()

As always with patches from René, this is already next material.

* mv/parseopt-ls-files (Tue Feb 17 15:27:11 2009 +0100) 2 commits
 - parse-opt: migrate builtin-ls-files.
 - Turn the flags in struct dir_struct into a single variable

* jk/sane-relative-time (Tue Feb 24 00:42:16 2009 -0500) 1 commit
 + never fallback relative times to absolute

* tv/rebase-stat (Sun Mar 1 22:28:28 2009 +0100) 2 commits
 - git-pull: Allow --stat and --no-stat to be used with --rebase
 - git-rebase: Add --stat and --no-stat for producing diffstat on
   rebase

----------------------------------------------------------------
[Discarded]

* jc/fsck (Fri Jan 30 02:33:47 2009 -0800) 4 commits
 - fsck: three levels of validation
 - verify-pack: add --quick
 - verify_pack(): allow a quicker verification for a pack with
   version 2 idx
 - pack-check.c: minor formatting fix to match coding style

J6t has a good point that if this had any value then medium level should
replace the default.  I am tempted to actually dropping this as a failed
experiment.

* js/remote-set-head (Sat Feb 14 05:30:30 2009 -0500) 5 commits
 - builtin-remote: better handling of multiple remote HEADs
 - builtin-remote: add set-head subcommand
 - builtin-remote: teach show to display remote HEAD
 - builtin-remote: move duplicated cleanup code its own function
 - builtin-clone: move locate_head() to remote.c so it can be re-used

* jk/head-lookup (Sun Feb 15 01:18:18 2009 -0500) 5 commits
 - remote: use exact HEAD lookup if it is available
 - remote: refactor guess_remote_head
 - refactor find_refs_by_name to accept const list
 - add basic http clone/fetch tests
 - test scripts: refactor start_httpd helper

These two are now consolidated into Jay's remove-improvements series
listed above.

----------------------------------------------------------------
[Stalled and may need help and prodding to go forward]

* gb/gitweb-base (Sun Feb 15 10:18:36 2009 +0100) 1 commit
 - gitweb: fix wrong base URL when non-root DirectoryIndex

* ns/stash-keep (Thu Feb 12 06:25:14 2009 +0900) 1 commit
 - stash: --keep option just saves

Do we want to keep this one?

* lh/submodule-tree-traversal (Sun Jan 25 01:52:06 2009 +0100) 1 commit
 - archive.c: add support for --submodules[=(all|checkedout)]

Discussion stalled on the submodule selection criteria.

* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 2 commits
 + blame: show "previous" information in --porcelain/--incremental
   format
 + git-blame: refactor code to emit "porcelain format" output

This gives Porcelains (like gitweb) the information on the commit _before_
the one that the final blame is laid on, which should save them one
rev-parse to dig further.  The line number in the "previous" information
may need refining, and sanity checking code for reference counting may
need to be resurrected before this can move forward.

I thought recent tig discussion may blow new life into it, but is this
unneeded?  If so I'd rather revert it (or discard after 1.6.2).

* db/foreign-scm (Sun Jan 11 15:12:10 2009 -0500) 3 commits
 - Support fetching from foreign VCSes
 - Add specification of git-vcs helpers
 - Add "vcs" config option in remotes

The "spec" did not seem quite well cooked yet, but in the longer term I
think something like this to allow interoperating with other SCMs as if
the other end is a native git repository is a very worthy goal.

* cc/replace (Mon Feb 2 06:13:06 2009 +0100) 11 commits
 - builtin-replace: use "usage_msg_opt" to give better error messages
 - parse-options: add new function "usage_msg_opt"
 - builtin-replace: teach "git replace" to actually replace
 - Add new "git replace" command
 - environment: add global variable to disable replacement
 - mktag: call "check_sha1_signature" with the replacement sha1
 - replace_object: add a test case
 - object: call "check_sha1_signature" with the replacement sha1
 - sha1_file: add a "read_sha1_file_repl" function
 - replace_object: add mechanism to replace objects found in
   "refs/replace/"
 - refs: add a "for_each_replace_ref" function

I think the code is much cleaner than the first round, but I am not
convinced it is doing the right thing in the connectivity traverser.  
Independent review sorely needed.

* sc/gitweb-category (Fri Dec 12 00:45:12 2008 +0100) 3 commits
 - gitweb: Optional grouping of projects by category
 - gitweb: Split git_project_list_body in two functions
 - gitweb: Modularized git_get_project_description to be more generic

Design discussion between Jakub and Sebastien seems to have stalled, but
Jakub seems to be taking this over.

----------------------------------------------------------------
[Reverted]

* mh/unify-color (Fri Jan 23 01:25:23 2009 -0800) 3 commits
 ? Revert previous two commits
 ? move the color variables to color.c
 ? handle color.ui at a central place

This broke git-format-patch badly.

* js/rebase-error-a-bit-more-verbose (Sun Feb 8 21:22:18 2009 -0800) 2 commits
 ? Revert "rebase: explain why when the HEAD could not be detached"
 ? rebase: explain why when the HEAD could not be detached

This turned out to be unnecessary.

* rs/maint-1.6.0-windows-ceiling (Sat Feb 7 12:40:40 2009 -0800) 2 commits
 ? Revert "fix t1504 on Windows"
 ? fix t1504 on Windows

I'm giving a fresh start to J6t's series which contains this.

* lh/reverted-submodule-tree-traversal (Sun Jan 25 18:39:55 2009 -0800) 4 commits
 ? Revert round #1 of the series
 ? builtin-ls-tree: enable traversal of submodules
 ? archive.c: enable traversal of submodules
 ? tree.c: add support for traversal of submodules

I'm giving a fresh start to Lars's second iteration.

----------------------------------------------------------------
[Will merge to 'next' soon]

* js/send-email (Mon Mar 2 23:52:18 2009 -0500) 5 commits
 - send-email: add --confirm option and configuration setting
 + send-email: don't create temporary compose file until it is needed
 + send-email: --suppress-cc improvements
 + send-email: handle multiple Cc addresses when reading mbox message
 + send-email: allow send-email to run outside a repo

----------------------------------------------------------------
[Ready for 'master' after 1.6.2]

* sg/rerere-cleanup (Sat Feb 14 23:21:04 2009 +0100) 1 commit
 + rerere: remove duplicated functions

* jc/add-p-unquote (Mon Feb 16 22:43:43 2009 -0800) 1 commit
 + git-add -i/-p: learn to unwrap C-quoted paths

* jw/imap-preformatted-html (Thu Feb 12 08:58:12 2009 -0600) 1 commit
 + imap.preformattedHTML to tell Thunderbird to send non-flowed text

The patch text should be identical to Jeremy's "Virtual Patch", except
that the configuration variable was renamed per list discussion.

* jw/format-patch-attach (Thu Feb 12 09:51:55 2009 -0600) 1 commit
 + Enable setting attach as the default in .gitconfig for git-format-
   patch.

* sr/force-rebase (Fri Feb 13 23:48:01 2009 +0100) 1 commit
 + Teach rebase to rebase even if upstream is up to date

* fg/exclude-bq (Tue Feb 10 15:20:17 2009 +0100) 1 commit
 + Support "\" in non-wildcard exclusion entries

* dm/add-i-edit-abort (Thu Feb 12 00:19:41 2009 -0500) 1 commit
 + add -i: revisit hunk on editor failure

* tp/completion (Sat Feb 21 15:48:43 2009 +0100) 6 commits
 + Fixup: Add bare repository indicator for __git_ps1
 + Add bare repository indicator for __git_ps1
 + completion: More fixes to prevent unbound variable errors
 + completion: Better __git_ps1 support when not in working directory
 + completion: Use consistent if [...] convention, not "test"
 + completion: For consistency, change "git rev-parse" to __gitdir
   calls

* js/branch-symref (Wed Feb 18 22:34:44 2009 -0500) 4 commits
 + add basic branch display tests
 + branch: clean up repeated strlen
 + Avoid segfault with 'git branch' when the HEAD is detached
 + builtin-branch: improve output when displaying remote branches

* al/ansi-color (Fri Feb 13 22:53:41 2009 +0100) 2 commits
 + builtin-branch.c: Rename branch category color names
 + Clean up use of ANSI color sequences

* kb/checkout-optim (Mon Feb 23 19:02:57 2009 +0100) 14 commits
 + write_index(): update index_state->timestamp after flushing to
   disk
 + verify_uptodate(): add ce_uptodate(ce) test
 + make USE_NSEC work as expected
 + fix compile error when USE_NSEC is defined
 + check_updates(): effective removal of cache entries marked
   CE_REMOVE
 + lstat_cache(): print a warning if doing ping-pong between cache
   types
 + show_patch_diff(): remove a call to fstat()
 + write_entry(): use fstat() instead of lstat() when file is open
 + write_entry(): cleanup of some duplicated code
 + create_directories(): remove some memcpy() and strchr() calls
 + unlink_entry(): introduce schedule_dir_for_removal()
 + lstat_cache(): swap func(length, string) into func(string, length)
 + lstat_cache(): generalise longest_match_lstat_cache()
 + lstat_cache(): small cleanup and optimisation

* js/valgrind (Thu Feb 5 22:03:00 2009 +0100) 9 commits
 + valgrind: do not require valgrind 3.4.0 or newer
 + test-lib: avoid assuming that templates/ are in the GIT_EXEC_PATH
 + Tests: let --valgrind imply --verbose and --tee
 + Add a script to coalesce the valgrind outputs
 + t/Makefile: provide a 'valgrind' target
 + test-lib.sh: optionally output to test-results/$TEST.out, too
 + Valgrind support: check for more than just programming errors
 + valgrind: ignore ldso and more libz errors
 + Add valgrind support in test scripts

----------------------------------------------------------------
[Actively cooking]

* tr/gcov (Thu Feb 19 12:13:42 2009 +0100) 8 commits
 - Test git-patch-id
 - Test rev-list --parents/--children
 - Test log --decorate
 - Test fsck a bit harder
 - Test log --graph
 - Test diff --dirstat functionality
 - Test that diff can read from stdin
 - Support coverage testing with GCC/gcov

* js/notes (Sat Feb 14 21:23:25 2009 +0100) 13 commits
 - notes: refuse to edit notes outside refs/notes/
 - t3301: use test_must_fail instead of !
 - t3301: fix confusing quoting in test for valid notes ref
 - notes: use GIT_EDITOR and core.editor over VISUAL/EDITOR
 - notes: only clean up message file when editing
 - handle empty notes gracefully
 + git notes show: test empty notes
 + git-notes: fix printing of multi-line notes
 + notes: fix core.notesRef documentation
 + Add an expensive test for git-notes
 + Speed up git notes lookup
 + Add a script to edit/inspect notes
 + Introduce commit notes

Earlier part was merged to master and then reverted there.  Will be
rebased 1.6.2 to keep my sanity.

* fc/config-editor (Sat Feb 21 02:48:54 2009 +0200) 3 commits
 + git config: trivial cleanup for editor action
 + git config: codestyle cleanups
 + config: Add new option to open an editor.

Rerolled and looked sane.

----------------------------------------------------------------
[On Hold]

* jc/deny-delete-current-1.7.0 (Mon Feb 9 00:19:46 2009 -0800) 1 commit
 - receive-pack: default receive.denyDeleteCurrent to refuse

* jc/refuse-push-to-current-1.7.0 (Wed Feb 11 02:28:03 2009 -0800) 1 commit
 - Refuse updating the current branch in a non-bare repository via
   push

This is for 1.7.0.

* jc/commit-assume-also-during-merge (Thu Jan 22 22:21:49 2009 -0800) 3 commits
 - git commit: pathspec without -i/-o implies -i semantics during a
   merge
 - builtin-commit: shorten eye-sore overlong lines
 - Add "partial commit" tests during a conflicted merge

This was only meant as a weatherballoon to help facilitate discussion.

* jc/merge-convert (Mon Jan 26 16:45:01 2009 -0800) 1 commit
 - git-merge-file: allow converting the results for the work tree

This is a feature waiting for a user.  I do not need it in 1.6.2

We did not give scripted Porcelains a way to say "this temporary file I am
using for merging is for this path, so use the core.autocrlf and attributes
rules for that final path".  Instead, merge-file simply wrote out the
data in the canonical repository representation.

rerere has the same issue, but it is a lot worse.  It reads the three
files (preimage, postimage and thisimage) from the work tree in the work
tree representation, merges them without converting them to the canonical
representation first but inserts the conflict markers with the canonical
representation and writes the resulting mess out.  It needs to be fixed to
read with convert_to_git(), merge them while they are still in the
canonical representation and possibly add conflict markers, and then write
the results out after convert_to_working_tree().  It also needs to write
in binary mode as well.

Re: What's cooking in git.git (Mar 2009, #01; Tue, 03)

[Jeff King]

On Tue, Mar 03, 2009 at 01:01:45AM -0800, Junio C Hamano wrote:

> As an experiment, 'next' and 'pu' stayed open during this release freeze;
> new topics have been accepted.  I have to say that the experiment was a
> moderate success, and many topics in 'next' seem to be of fairly high
> quality already, which would mean that we will have a shorter cycle before
> 1.6.3.

I was going to stay quiet on this issue until after 1.6.3 released, but
now you have opened the topic. :)

I think seeing the quality of topics in 'next' is only half of
"success". You have to also consider how much attention was given to the
about-to-be-released version (and its impact on quality). And I think we
won't know about that until we see how quickly we need 1.6.3.1. :)

Personally, I know that I have spent much less time focusing on
'master'. Like everyone else, I have limited git bandwidth, and topics
in 'next' are simply more interesting. I think it's easier to put them
aside for a few weeks if everybody agrees to do so (rather than having
interesting discussion proceeding without you if you choose to focus on
'master').

-Peff

Re: What's cooking in git.git (Mar 2009, #01; Tue, 03)

[Jakub Narebski]

Junio C Hamano <gitster@pobox.com> writes:

> ----------------------------------------------------------------
> [Stalled and may need help and prodding to go forward]
> 
> * gb/gitweb-base (Sun Feb 15 10:18:36 2009 +0100) 1 commit
>  - gitweb: fix wrong base URL when non-root DirectoryIndex

Errrr... isn't this already in 'master' as v1.6.2-rc1-3-g81d3fe9 ?

> * jc/blame (Wed Jun 4 22:58:40 2008 -0700) 2 commits
>  + blame: show "previous" information in --porcelain/--incremental
>    format
>  + git-blame: refactor code to emit "porcelain format" output
> 
> This gives Porcelains (like gitweb) the information on the commit _before_
> the one that the final blame is laid on, which should save them one
> rev-parse to dig further.  The line number in the "previous" information
> may need refining, and sanity checking code for reference counting may
> need to be resurrected before this can move forward.
> 
> I thought recent tig discussion may blow new life into it, but is this
> unneeded?  If so I'd rather revert it (or discard after 1.6.2).

This would be nice to have for gitweb.

-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: What's cooking in git.git (Mar 2009, #01; Tue, 03)

[Johannes Schindelin]

Hi,

On Tue, 3 Mar 2009, Junio C Hamano wrote:

> * js/clone-depth-local (Fri Feb 27 00:04:06 2009 -0800) 3 commits
>  . parse_options(): do not "increment" boolean
>  . clone: ignore --depth when cloning locally (implicitly --local)
>  . clone: do not ignore --no-local option
> 
> Jeff had a good suggestion for this series but it was tripped by
> a misfeature in parse_options().

If the issue is that you cannot discern between implicit --no-local and 
--no-local, maybe the solution is to start with option_local = 1.

> * ns/stash-keep (Thu Feb 12 06:25:14 2009 +0900) 1 commit
>  - stash: --keep option just saves
> 
> Do we want to keep this one?

AFAIAC no.

I'd like a shorter way to say "git stash save --keep-index".  But that's 
OT.

Ciao,
Dscho

Re: What's cooking in git.git (Mar 2009, #01; Tue, 03)

[Christian Couder]

Le mardi 3 mars 2009, Junio C Hamano a écrit :
> * cc/replace (Mon Feb 2 06:13:06 2009 +0100) 11 commits
>  - builtin-replace: use "usage_msg_opt" to give better error messages
>  - parse-options: add new function "usage_msg_opt"
>  - builtin-replace: teach "git replace" to actually replace
>  - Add new "git replace" command
>  - environment: add global variable to disable replacement
>  - mktag: call "check_sha1_signature" with the replacement sha1
>  - replace_object: add a test case
>  - object: call "check_sha1_signature" with the replacement sha1
>  - sha1_file: add a "read_sha1_file_repl" function
>  - replace_object: add mechanism to replace objects found in
>    "refs/replace/"
>  - refs: add a "for_each_replace_ref" function
>
> I think the code is much cleaner than the first round, but I am not
> convinced it is doing the right thing in the connectivity traverser.
> Independent review sorely needed.

I haven't look much at connectivity traverser lately but I think I
should first describe some of the issues in other areas.

There are command to reproduce all the steps. (You have to use pu.)

#
# Let's start by creating a good environment to test a few things:
#

$ cd git/t
$ sed -e 's/test_done/exit 1\ntest_done/' t6050-replace.sh > tt.sh
$ ./tt.sh
*   ok 1: set up buggy branch
*   ok 2: replace the author
*   ok 3: tag replaced commit
*   ok 4: "git fsck" works
*   ok 5: repack, clone and fetch work
*   ok 6: "git replace" listing and deleting
*   ok 7: "git replace" replacing
FATAL: Unexpected exit with code 1
$ cd trash\ directory.tt

#
# Now let's see what happens when we replace an object:
#

$ git rev-parse HEAD
ffccc9d552388844dbe94a361c07e7cb1731e12f
$ git cat-file commit ffccc
tree 5c37393794868bc8e708cccd7c9d9aaa7a5e53cb
parent 14ac020163ea60a9d683ce68e36c946f31ecc856
author A U Thor <author@example.com> 1112912353 -0700
committer C O Mitter <committer@example.com> 1112912353 -0700

hello: again 3 more lines
$ git ls-tree 5c37
100644 blob 47ea9c3df4682ae7d2c9139fa9ac6dbc9b6eb43d    hello
$ git cat-file blob 47ea9c3df4682ae7d2c9139fa9ac6dbc9b6eb43d | 
sed -e 's/line 7/changed line 7/' > new_hello
$ cat new_hello | git hash-object -t blob --stdin -w
201722c515afacad101b62525a9e57899eac5182
$ git replace 47ea9c3df4682ae7d2c9139fa9ac6dbc9b6eb43d 
201722c515afacad101b62525a9e57899eac5182

#
# So now the tree of the current commit has a blob that is replaced.
# The problem is that we don't see it, except if we "touch" the file: 
#

$ git diff
$ touch hello
$ git diff
diff --git a/hello b/hello
--- a/hello
+++ b/hello
@@ -4,7 +4,7 @@ line 3
 line 4
 line 5
 line 6
-changed line 7
+line 7
 line 8
 line 9
 line 10

#
# And now we cannot create a commit with the above diff:
#

$ git commit hello
...
nothing added to commit but untracked files present (use "git add" to track)
$ git add hello
$ git status
...
nothing added to commit but untracked files present (use "git add" to track)

#
# So I am not sure if that is a big problem, because that happens only
# if we want to commit something exactly like what we replaced. And in
# this case the best thing to do might be to simply remove the replace
# ref.
#

$ git replace -d 47ea9c3df4682ae7d2c9139fa9ac6dbc9b6eb43d
$ git diff
$ touch hello
$ git diff

#
# We got back to a normal situation.
#
# Now let's try something different
# First let's replace the current commit:
#

$ git rev-parse HEAD
ffccc9d552388844dbe94a361c07e7cb1731e12f
$ git cat-file commit ffccc | sed -e "s/A U/O/" | git hash-object -t 
commit --stdin -w
$ git cat-file commit dd1ca
tree 5c37393794868bc8e708cccd7c9d9aaa7a5e53cb
parent 14ac020163ea60a9d683ce68e36c946f31ecc856
author O Thor <author@example.com> 1112912353 -0700
committer C O Mitter <committer@example.com> 1112912353 -0700

hello: again 3 more lines
$ git replace HEAD dd1ca

#
# Let's create a commit based on the current one:
#

$ echo 'line 17' >> hello
$ git commit -m 'Add line 17' hello
[master 8f60c7e] Add line 17
 1 files changed, 1 insertions(+), 0 deletions(-)
$ git rev-parse HEAD^
ffccc9d552388844dbe94a361c07e7cb1731e12f
$ git reset --hard HEAD^
HEAD is now at dd1ca8e hello: again 3 more lines

#
# We are now on the replacement commit, though before the last
# command we were on a commit on top of the original one.
#

$ echo 'line 17' >> hello
$ git commit -m 'Add line 17' hello
[master c4a823a] Add line 17
 1 files changed, 1 insertions(+), 0 deletions(-)

#
# We build on top of the replacement commit, not the original one.
# This means that the original one may be dangling:
#

$ git fsck --full --no-reflogs
dangling commit 8f60c7ee5d6e0379ff813a26a2479289605eb935
...

#
# Of course on a published history, where "git replace" might
# be most usefull, you don't want to use "git reset --hard". So
# this might not be a big problem either.
#

Anyway, thanks in advance for advise/opinion about this.

Best regards,
Christian.

Re: What's cooking in git.git (Mar 2009, #01; Tue, 03)

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> On Tue, Mar 03, 2009 at 01:01:45AM -0800, Junio C Hamano wrote:
>
>> As an experiment, 'next' and 'pu' stayed open during this release freeze;
>> new topics have been accepted.  I have to say that the experiment was a
>> moderate success, and many topics in 'next' seem to be of fairly high
>> quality already, which would mean that we will have a shorter cycle before
>> 1.6.3.
>
> I was going to stay quiet on this issue until after 1.6.3 released, but
> now you have opened the topic. :)
>
> I think seeing the quality of topics in 'next' is only half of
> "success". You have to also consider how much attention was given to the
> about-to-be-released version (and its impact on quality). And I think we
> won't know about that until we see how quickly we need 1.6.3.1. :)
>
> Personally, I know that I have spent much less time focusing on
> 'master'. Like everyone else, I have limited git bandwidth, and topics
> in 'next' are simply more interesting. I think it's easier to put them
> aside for a few weeks if everybody agrees to do so (rather than having
> interesting discussion proceeding without you if you choose to focus on
> 'master').

With the first maintenance release after 1.6.2 behind us, I think we can
start to judge how successful the 1.6.2 cycle was fairly objectively.

During the pre-release freeze, we would want to encorage people to spend
as much time as possible on finding and fixing bugs and regressions in the
frozen 'master', and that was the reason why traditionally we closed
'next' during the pre-release freeze.

But in reality, contributors who had leftover topics on 'next' simply
stopped working on their topics on 'next' without spending the freed up
time on concentrating on 'master'.  In an ideal world, the choice would be
between "git time on 'next'" vs "git time on 'master'", and closing 'next'
was meant to force the choice, but instead the outcome became "less git
time until 'next' reopens".

My suspicion, when deciding to keep the 'next' branch open during the
freeze, was that as long as people look at _any_ git code, even if it is
because they are working on their own topic that will never be in the
upcoming release, it would increase the chance of bugs getting discovered.

I do not know the exact count of bugfixes after 1.6.2-rc0 are attributable
to people who happened to notice glitches by accident while working on an
unrelated enhancements, but for me personally, I tend to notice more bugs
when I am not hunting for one but working on something else.

Also as a side effect, we had many topics on 'next' that are already
reasonably mature after 1.6.2, and I think we can have a short cycle for
the next one.

Re: What's cooking in git.git (Mar 2009, #01; Tue, 03)

[Jeff King]

On Sun, Mar 15, 2009 at 09:53:19PM -0700, Junio C Hamano wrote:

> But in reality, contributors who had leftover topics on 'next' simply
> stopped working on their topics on 'next' without spending the freed up
> time on concentrating on 'master'.  In an ideal world, the choice would be
> between "git time on 'next'" vs "git time on 'master'", and closing 'next'
> was meant to force the choice, but instead the outcome became "less git
> time until 'next' reopens".

I think that is a reasonable argument for keeping 'next' open, and it
seems to be borne out by this experiment (the post-1.6.2 period seemed
no better or worse for bugfixes to me).

Now the only problem with keeping next open is that the maintainer
misses out on the relative lull in activity during release freeze to
catch up on his day job work. But if you can handle that, I'm certainly
in no position to complain. :)

-Peff