What's cooking in git.git (topics)

What's cooking in git.git (topics)

[Junio C Hamano]

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.

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

[Jakub Narebski]

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

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

[Junio C Hamano]

Jakub Narebski <jnareb@gmail.com> writes:

>> * 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).

This only makes "update; edit; update; commit" to work.  "edit;
commit; edit; commit; edit; update; commit" would not work,
because you would be faced to resolving the conflicts upon the
last update while your working tree is already contaminated with
your own changes (it can be done and experienced people have
done so, but you are talking about "CVS users" here).

We'd be much better off to encourage users to shake "update then
commit" habit, especially if they are on a slow link.

>> * 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?

Have you looked at the code to see what it does?

>> * 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.

Then test it and fix breakage if any please.

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

[Johannes Schindelin]

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

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

[Alexandre Julliard]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

>> * 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.

I'm not sure what reaction you expect, but this is something a lot of
our occasional Wine users are requesting. The Wine full history is
80Mb, and that's a big download if you just want to try a quick
patch. Now of course you won't see these users around here hacking on
shallow clone, most likely they just went and downloaded Wine from the
CVS mirror instead. But it's a shame to have to maintain a CVS mirror
just for that purpose...

-- 
Alexandre Julliard

shallow clones, was Re: What's cooking in git.git (topics)

[Johannes Schindelin]

Hi,

On Thu, 7 Dec 2006, Alexandre Julliard wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> >> * 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.
> 
> I'm not sure what reaction you expect, but this is something a lot of 
> our occasional Wine users are requesting. The Wine full history is 80Mb, 
> and that's a big download if you just want to try a quick patch. Now of 
> course you won't see these users around here hacking on shallow clone, 
> most likely they just went and downloaded Wine from the CVS mirror 
> instead. But it's a shame to have to maintain a CVS mirror just for that 
> purpose...

Sorry, I was just mumbling about the fact that I would _like_ to hear back 
about successes and failures. If there are problems I want to fix them.

So, do you actually know of people who _used_ (as opposed to "tested") 
shallow clones?

Ciao,
Dscho

Re: shallow clones, was Re: What's cooking in git.git (topics)

[Alexandre Julliard]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> Sorry, I was just mumbling about the fact that I would _like_ to hear back 
> about successes and failures. If there are problems I want to fix them.
>
> So, do you actually know of people who _used_ (as opposed to "tested") 
> shallow clones?

No, I'm afraid not. Unfortunately, using it requires an upgraded
server, and I'm reluctant to put an experimental release on the main
Wine server, so I was kind of waiting for it to graduate to master. Of
course that's a bit of a chicken and egg problem...

-- 
Alexandre Julliard

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

[Andy Parkins]

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

> > * 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

Re: shallow clones, was Re: What's cooking in git.git (topics)

[Aneesh Kumar K.V]

Johannes Schindelin wrote:
>.
>> I'm not sure what reaction you expect, but this is something a lot of 
>> our occasional Wine users are requesting. The Wine full history is 80Mb, 
>> and that's a big download if you just want to try a quick patch. Now of 
>> course you won't see these users around here hacking on shallow clone, 
>> most likely they just went and downloaded Wine from the CVS mirror 
>> instead. But it's a shame to have to maintain a CVS mirror just for that 
>> purpose...
> 
> Sorry, I was just mumbling about the fact that I would _like_ to hear back 
> about successes and failures. If there are problems I want to fix them.
> 
>>


How about this. This is already reported 

kvaneesh@kvaneesh-laptop:/tmp$git clone --depth 2 /home/opensource/git git.test
.....
 100% (743/743) done


kvaneesh@kvaneesh-laptop:/tmp$cd git.test/
[master@git.test]$ git fsck-objects



[master@git.test]$ git fetch --depth 4
remote: Generating pack...
remote: Done counting 872 objects.
...
 100% (1/1) done
Total 1 (delta 0), reused 0 (delta 0)
Unpacking 1 objects
 100% (1/1) done


[master@git.test]$ git fsck-objects
dangling commit aca085e577688108a2480b96a2f7077424a74e4d
dangling commit b360cca0b100e14abffa4cae78521b493c783738
dangling commit cd976f5c52694acb4b23c3f2425ed4f0a47ec799