Documentation
-------------
-* Talk about using rsync just once at the beginning when
- initializing a remote repository so that local packs do not
- need to be expanded. I personally do not think we need tool
- support for this (but see below about optimized cloning).
-
-* Maybe update tutorial with a toy project that involves two or
- three developers.
+* No pending issues at the moment. "Revamp Tutorial" initiative
+ by Bruce Fields ongoing and things are looking better.
Design issues
-------------
+* Rehash "git commit" with various parameters to be more
+ intuitive without breaking traditinal users too much. We need
+ to phase this in, especially if we are going to change "git
+ commit" to imply the current "git commit -a" behaviour.
+
+* "intent to add" index entries.
+
* Plug-in file-level merges. On the other hand, we may not even
need this; just tell people to run "xxdiff -U" on the working
tree files.
-* Ref namespace management. Perhaps use refs/local/ suggestion
- by Linus. [Does not seem to be high on people's priority list,
- and not interested myself. People can resurrect this
- discussion if they want.]
+* Doing a merge in a separate directory.
+
+* Make 'format-patch' take revision limiters similar to
+ rev-list. For example:
+
+ A C
+ ....---x---o---o---x---o---o
+ /
+ /
+ /
+ ....---x---o---o
+ B
+
+ we should be able to format commits 'o', without duplicates,
+ by:
+
+ $ git format-patch ^A ^B C
+
+ Currently the closest approximation is
-* Perhaps "everything in config file"? Especially remotes/
- shortcuts. I am modestly negative about this.
+ $ git format-patch A..C B..C
+
+ which results in the last two commits including C formatted
+ twice.
Technical (heavier)
Technical (milder)
------------------
-* send-pack/receive-pack protocol updates, to allow the receiver
- to report what it did to the ref update requests [DONE].
+* Subprojects. I think the "bind commit" approach has been
+ outlined at sufficiently detailed level. Maybe find time to
+ actually start prototyping it?
-* Perhaps a smarter HTTP anonymous download via CGI.
+ <7vacdzkww3.fsf@assigned-by-dhcp.cox.net>
-* Prepare to enable "always use symbolic refs for HEAD" patch.
- We need a timeline to force Porcelains to get ready. Last
- time I looked at them I got an impression that gitweb was not
- ready.
+* Shallow clones.
+
+* Mark entries as "assume unchanged" in the index.
+ New option to update-index to set or drop the bit is needed.
+
+ - update-index --no-stat paths...
+ - update-index --with-stat paths...
+
+ Also a config item '[core] trust_stat = false' would enable
+ this automatically:
+
+ - "update-index" with or without --add would mark the path
+ after registering. Should we make the working tree file
+ read-only at this point?
+
+ - checkout-index -u would mark the path and makes the working
+ tree file read-only.
-* Forbid/ignore pack names that do not conform to the convention
- sha1_pack_name() assumes and reject in check_packed_git_idx()
- [In pu]
+ Impacts to various commands:
-* strip leading directory from ls-tree output, to match ls-files
- output.
+ - update-index --refresh would ignore them.
- I am of two minds about this one. diff output must always be
- -p1 format no matter where the command was started, and
- ls-tree might be easier to use if it matched diff, not
- ls-files.
+ - diff-files would say unchanged.
- [DONE, with --full-name option like ls-files]
+ - diff-index without --cached acts the same way as diff-index
+ --cached.
-* Any Porcelain-ish we forgot or punted to make usable from
- subdirectory? I think the last pass caught everything and
- what are remaining are whole-tree or whole repository
- operations.
+* Decide what to do about rebase applied to merged head. One
+ extreme is to allow rebase if "rev-list ours..theirs" gives
+ anything. This loosens the current merge-base based approach.
+ The other extreme is to refuse rebase if "rev-list
+ theirs..ours" contains any merge commit, which was discussed
+ on the list.
+
+ <43CC695E.2020506@codeweavers.com>
+
+* Decide what the right thing to do upon an empty merge commit,
+ when both branches happen to have obtained the same set of
+ changes through different history. Not recording such keeps
+ the history simpler, and the next merge would soon create a
+ true merge commit anyway, but this does not feel quite right.
+
+ <20060114021800.4688.qmail@web31803.mail.mud.yahoo.com>
+
+* Perhaps a smarter HTTP anonymous download via CGI.
+
+* Prepare to enable "always use symbolic refs for HEAD" patch.
+ We need a timeline to force Porcelains to get ready. All the
+ major ones should be ready now.
* diff stopping at the first output; qgit wants to know if this
tree has any A or D from the other tree and nothing else.
* daemon --strict-symlink.
+* daemon --no-user-dir, to make ~user still work with
+ --base-path. They ought to be independent.
+
+* daemon --base-path does not apply automatically to whitelist
+ somehow feels wrong. If somebody cares enough, accept
+ patches.
+
* Perhaps detect cloning request in upload-pack and cache the
result for next cloning request until any of our refs change.
* Perhaps accept patch to optionally allow '--fuzz' in
- 'git-apply'.
+ 'git-apply'. am/applymbox is _not_ the place to do it.
* Allow 'git apply' to accept GNU diff 2.7 output that forgets
to say '\No newline' if both input ends with incomplete
just the basename, and see the improved clustering results in
better packing [Tried, but did not work out well].
-* Daemon --base-path does not apply automatically to whitelist
- somehow feels wrong. If somebody cares enough, accept
- patches.
-
Technical (trivial)
-------------------
-* Daemon --base-path forbidding user-path automatically feels
- wrong. If somebody cares enough, accept patches.
+* Use parent info in 'diff-tree --stdin'.
* git-proxy should be spawned with sh -c 'command' $1 $2.
-* Versioning scheme. The next maintenance installment will be
- 1.0.3 not 1.0.0c. The next feature release would be 1.1.0 [DONE].
-
-* Either drop supporting Debian myself or coerce patches out of
- the official maintainer [DONE -- DROPPED].
-
-* We would want test scripts for the relative directory path
- stuff Linus has been working on. Most of the C-level
- commands should be usable with relative directory paths.
+* test scripts for the relative directory path stuff.
* In a freshly created empty repository, `git fetch foo:bar`
works OK, but `git checkout bar` afterwards does not (missing