What's cooking in git.git (topics)

Here is a list of topics that are cooking; the commits marked
with '+' are in 'next', '-' are in 'pu'.  Dates are when the
topic was last touched [*1*].

----------------------------------------------------------------

* ap/clone-origin (Wed Dec 6 12:07:23 2006 +0000)
 + Explicitly add the default "git pull" behaviour to .git/config on clone

 This makes 'git clone' to mark the local 'master' to explicitly
 merge with the corresponding remote branch, which would be a
 sensible default.

 As discussed on the list earlier, I think it also would make
 sense to forbid 'git pull' to make a merge when:

 (1) branch.*.merge entries exist in $GIT_DIR/config (which
     signals that the user is using this new mechanism), and
 (2) branch.<current-branch>.merge entry does not exist for the
     current branch.

 I think it is sensible to merge to 'master' after that change.

* jc/3way (Wed Nov 29 18:53:13 2006 -0800)
 + git-merge: preserve and merge local changes when doing fast forward

 This allows you to run a 'git merge' (or 'git pull') that
 results in a fast-forward merge that updates a path your
 working tree has modified locally; it merges your local changes
 into the updated version, in the same way the branch switching
 'git checkout -m' works.  It has been in next for some time and
 unless we hear somebody scream I think it is Ok to merge to
 'master'.
 
* jc/blame-boundary (Fri Dec 1 20:45:45 2006 -0800)
 - git-blame: show lines attributed to boundary commits differently.

 This was discussed in a thread on grouping the short-log entries
 differently and measuring the importance of each commit.  While
 it does not break things per-se, nobody seems to want to use it
 for scripting yet, so it is staying in 'pu'.

* jc/commit-careful (Tue Oct 24 21:48:55 2006 -0700)
 + git-commit: show --summary after successful commit.

 I think this is safe to merge to 'master'.

* jc/diff (Mon Sep 25 23:03:34 2006 -0700)
 - para-walk: walk n trees, index and working tree in parallel

 This has been backburnered for a long time.  No time to work on
 and no immediate need to use it for scripts myself yet.

* jc/diff-apply-patch (Fri Sep 22 16:17:58 2006 -0700)
 + git-diff/git-apply: make diff output a bit friendlier to GNU patch (part 2)

 This changes the output of "git diff" for a filename with
 embedded SP and requires everybody to switch to its predecessor
 commit ce74618d (which is in v1.4.4 but not in v1.4.3 series)
 which prepared for this change.  Perhaps sometime in February.

* jc/explain (Mon Dec 4 19:35:04 2006 -0800)
 - git-explain

 This was just a discussion starter.  I tried to reuse existing
 status markers various existing command leaves, but it might be
 a good idea to invent a unified status marker to help 'git
 explain' (or 'git wtf') command, so that everybody can write
 into the same file and 'explain' has to know only about that
 file.  I dunno.

* jc/fpc (Sun Nov 26 16:29:07 2006 -0800)
 - (experimental) per-topic shortlog.

 This was my attempt to give a different grouping of the
 short-log entries.  Will drop soon from 'pu'.

* jc/leftright (Sun Oct 22 17:32:47 2006 -0700)
 - rev-list --left-right.

 When reviewing "git log --merge" I often wish which side each
 of the commits comes from, and this is to achieve that.  I
 haven't met with an enthusiastic support for it, though.
 Perhaps people do not find need for that, or do not do
 complicated merges, or have other tools that I do not regularly
 use that is better than this approach; in which case I should
 probably drop this.

* jc/pickaxe (Sun Nov 5 11:52:43 2006 -0800)
 - blame: --show-stats for easier optimization work.

* jc/read-tree-ignore (Tue Dec 5 23:44:23 2006 -0800)
 + read-tree: document --exclude-per-directory
 + Loosen "working file will be lost" check in Porcelain-ish
 + read-tree: further loosen "working file will be lost" check.

 I think this is a 'master' material modulo bugs.  Will cook
 further in 'next'.

* jc/web (Wed Nov 8 14:54:09 2006 -0800)
 - gitweb: steal loadavg throttle from kernel.org

* js/merge (Wed Dec 6 16:45:42 2006 +0100)
 + merge-file: support -p and -q; fix compile warnings
 + Add builtin merge-file, a minimal replacement for RCS merge
 + xdl_merge(): fix and simplify conflict handling
 + xdl_merge(): fix thinko
 + xdl_merge(): fix an off-by-one bug
 + merge-recursive: use xdl_merge().
 + xmerge: make return value from xdl_merge() more usable.
 + xdiff: add xdl_merge()

 merge-recursive that does not rely on RCS "merge".  I use this
 exclusively these days.  Perhaps cook a little further and
 merge to 'master'.

* js/shallow (Fri Nov 24 16:00:13 2006 +0100)
 + fetch-pack: Do not fetch tags for shallow clones.
 + get_shallow_commits: Avoid memory leak if a commit has been reached already.
 + git-fetch: Reset shallow_depth before auto-following tags.
 + upload-pack: Check for NOT_SHALLOW flag before sending a shallow to the client.
 + fetch-pack: Properly remove the shallow file when it becomes empty.
 + shallow clone: unparse and reparse an unshallowed commit
 + Why didn't we mark want_obj as ~UNINTERESTING in the old code?
 + Why does it mean we do not have to register shallow if we have one?
 + We should make sure that the protocol is still extensible.
 + add tests for shallow stuff
 + Shallow clone: do not ignore shallowness when following tags
 + allow deepening of a shallow repository
 + allow cloning a repository "shallowly"
 + support fetching into a shallow repository
 + upload-pack: no longer call rev-list

 The shallow clone.  I do not use it myself but it does not seem
 to break the system for users that do not use shallow
 repositories.  Probably with a better documentation of its
 limitations and caveats, this should be mergeable to 'master'.

* lh/branch-rename (Thu Nov 30 03:16:56 2006 +0100)
 + git-branch: let caller specify logmsg
 + rename_ref: use lstat(2) when testing for symlink
 + git-branch: add options and tests for branch renaming

 I do not rename branches myself and do not see a need for this
 nor I have tested it in real-world setting.  The code seemed
 clean and may be 'master' material.

* np/addcommit (Mon Dec 4 11:13:39 2006 -0500)
 + make 'git add' a first class user friendly interface to the index

* sv/git-svn (Tue Dec 5 16:17:38 2006 +1100)
 - git-svn: re-map repository URLs and UUIDs on SVK mirror paths
 - git-svn: collect revision properties when fetching
 - git-svn: collect SVK source URL on mirror paths
 - git-svn: let libsvn_ls_fullurl return properties too
 - git-svn: make test for SVK mirror path import

 Eric already commented on them but no progress since then.
 Parked in 'pu' only for discussion and these will be replaced
 when resubmitted.


[Footnote]

*1* I am trying out an alternative to short-log.  I think the
above format is easier to see what is going on than separate
short-log for 'next' and 'pu'.  It is based on the "TO" script
found in 'todo' branch but hand edited.

Junio C Hamano wrote:

Here is a list of topics that are cooking; the commits marked
with '+' are in 'next', '-' are in 'pu'.  Dates are when the
topic was last touched [*1*].

----------------------------------------------------------------

* jc/3way (Wed Nov 29 18:53:13 2006 -0800)
 + git-merge: preserve and merge local changes when doing fast forward

 This allows you to run a 'git merge' (or 'git pull') that
 results in a fast-forward merge that updates a path your
 working tree has modified locally; it merges your local changes
 into the updated version, in the same way the branch switching
 'git checkout -m' works.  It has been in next for some time and
 unless we hear somebody scream I think it is Ok to merge to
 'master'.

Very nice. Less suprises for CVS users (with "update then commit"
mentality/habits).
  

* jc/explain (Mon Dec 4 19:35:04 2006 -0800)
 - git-explain

 This was just a discussion starter.  I tried to reuse existing
 status markers various existing command leaves, but it might be
 a good idea to invent a unified status marker to help 'git
 explain' (or 'git wtf') command, so that everybody can write
 into the same file and 'explain' has to know only about that
 file.  I dunno.

I think it would be nice to have... but as it is very fresh
it probably should cook for a while in next.
 

* jc/leftright (Sun Oct 22 17:32:47 2006 -0700)
 - rev-list --left-right.

 When reviewing "git log --merge" I often wish which side each
 of the commits comes from, and this is to achieve that.  I
 haven't met with an enthusiastic support for it, though.
 Perhaps people do not find need for that, or do not do
 complicated merges, or have other tools that I do not regularly
 use that is better than this approach; in which case I should
 probably drop this.

Looks nice, as an alternative to git-cherry-pick (which sometimes
doesn't do - because it cannot - it's work).
 

* jc/web (Wed Nov 8 14:54:09 2006 -0800)
 - gitweb: steal loadavg throttle from kernel.org

Is having loadavg in gitweb, and not configured in server good idea?
What next, log generation in gitweb? Just kidding.
 

* js/merge (Wed Dec 6 16:45:42 2006 +0100)
 + merge-file: support -p and -q; fix compile warnings
 + Add builtin merge-file, a minimal replacement for RCS merge
 + xdl_merge(): fix and simplify conflict handling
 + xdl_merge(): fix thinko
 + xdl_merge(): fix an off-by-one bug
 + merge-recursive: use xdl_merge().
 + xmerge: make return value from xdl_merge() more usable.
 + xdiff: add xdl_merge()

 merge-recursive that does not rely on RCS "merge".  I use this
 exclusively these days.  Perhaps cook a little further and
 merge to 'master'.

Very nice, especially with zealous (tight) merge conflicts.

* lh/branch-rename (Thu Nov 30 03:16:56 2006 +0100)
 + git-branch: let caller specify logmsg
 + rename_ref: use lstat(2) when testing for symlink
 + git-branch: add options and tests for branch renaming

 I do not rename branches myself and do not see a need for this
 nor I have tested it in real-world setting.  The code seemed
 clean and may be 'master' material.

I'd like to have this, but it MUST work well with reflogs for me.
 

[Footnote]

*1* I am trying out an alternative to short-log.  I think the
above format is easier to see what is going on than separate
short-log for 'next' and 'pu'.  It is based on the "TO" script
found in 'todo' branch but hand edited.

It looks and reads better. I usually read only description,
as shortlog is not that useful unless you are interested in
given topic. At least for me.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

On Wednesday 2006, December 06 23:42, Johannes Schindelin wrote:

quoted

* js/shallow (Fri Nov 24 16:00:13 2006 +0100)

 Probably with a better documentation of its limitations and caveats,
 this should be mergeable to 'master'.

The more I see the missing reaction, the less sure I am this is a sensible
thing to do.

Don't be too downhearted.  I am certainly looking forward to using shallow 
clones; but by their very nature they are going to be used on big established 
projects (otherwise why would one need a shallow clone?), so until those 
projects upgrade their servers the news will be quiet

Also; it's probably going to be casual developers that find shallow clones 
useful, as the main developers will clone the whole repository.  This might 
also mean that they aren't going to be around on the git mailing list.

I certainly wouldn't say that the shallow clone work is not being appreciated.  
It's just being appreciated quietly.


Andy


-- 
Dr Andrew Parkins, M Eng (Hons), AMIEE

Hi,

On Wed, 6 Dec 2006, Junio C Hamano wrote:

Here is a list of topics that are cooking; the commits marked
with '+' are in 'next', '-' are in 'pu'.  Dates are when the
topic was last touched [*1*].

I like the combined pu/next "What's new".

* ap/clone-origin (Wed Dec 6 12:07:23 2006 +0000)
[...]
 I think it is sensible to merge to 'master' after that change.

Me, too. I really would like this to go in.

* jc/3way (Wed Nov 29 18:53:13 2006 -0800)
 + git-merge: preserve and merge local changes when doing fast forward
[...]
 It has been in next for some time and unless we hear somebody scream I 
 think it is Ok to merge to 'master'.

This is something I am looking forward to to test. Maybe in "next" for 
while before putting it into "master"?

* jc/explain (Mon Dec 4 19:35:04 2006 -0800)
 - git-explain

I vote for putting this into "next" for a wider audience. It also would 
help people to submit patches (it is kind of a hassle to branch "pu", so I 
rarely do it myself, whereas my git is based on "next" at all times).

* js/merge (Wed Dec 6 16:45:42 2006 +0100)

 merge-recursive that does not rely on RCS "merge".  I use this
 exclusively these days.  Perhaps cook a little further and
 merge to 'master'.

Yes, definitely cook it for at least a week; maybe I find the time to 
check the conflicted merges in git.git at least.

* js/shallow (Fri Nov 24 16:00:13 2006 +0100)

 Probably with a better documentation of its limitations and caveats, 
 this should be mergeable to 'master'.

The more I see the missing reaction, the less sure I am this is a sensible 
thing to do.

And it would need more safety valves, not just documentation. For example, 
I am not sure if a push from/to a shalow repo is safe.

Ciao,
Dscho