What's cooking in git.git (Jan 2009, #07; Wed, 28)

What's cooking in git.git (Jan 2009, #07; Wed, 28)

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

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

* jc/maint-1.6.0-split-diff-metainfo (Mon Jan 26 00:08:24 2009 -0800) 1 commit
 + diff.c: output correct index lines for a split diff

This is slated for maintenance series 1.6.0.X, 1.6.1.X and also for
'master'.  I think the change is pretty safe and sane to go directly to
'master' but I had too many other topoics to look at that I did not feel
comfortable enough to do so.

* jc/maint-split-diff-metainfo (Tue Jan 27 01:08:02 2009 -0800) 2 commits
 + Merge branch 'jc/maint-1.6.0-split-diff-metainfo' into jc/maint-
   split-diff-metainfo
 + diff.c: output correct index lines for a split diff

Early conflict resolution branch for the above to carry it to 1.6.1X
series.

* js/maint-rebase-i-submodule (Tue Jan 27 12:42:31 2009 +0100) 2 commits
 + Fix submodule squashing into unrelated commit
 + rebase -i squashes submodule changes into unrelated commit

* jg/tag-contains (Mon Jan 26 09:13:25 2009 -0500) 3 commits
 + git-tag: Add --contains option
 + Make has_commit() non-static
 + Make opt_parse_with_commit() non-static

* jk/maint-cleanup-after-exec-failure (Wed Jan 28 02:38:14 2009 -0500) 4 commits
 + git: use run_command() to execute dashed externals
 + run_command(): help callers distinguish errors
 + run_command(): handle missing command errors more gracefully
 + git: s/run_command/run_builtin/

* jc/maint-allow-uninteresting-missing (Tue Jan 27 23:19:30 2009 -0800) 1 commit
 + revision traversal: allow UNINTERESTING objects to be missing

This is a small follow-up to the fix to send-pack in 1.6.1; meant to go in
1.6.1.X maintenance series and newer.

* am/maint-push-doc (Mon Jan 26 00:45:33 2009 +0100) 3 commits
 + Documentation: rework src/dst description in git push
 + Documentation: more git push examples
 + Documentation: simplify refspec format description

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

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.

* jc/maint-add-u-remove-conflicted (Wed Jan 28 14:24:53 2009 -0800) 1 commit
 - add -u: do not fail to resolve a path as deleted

This has been updated from the posted version with a correction.

* ns/am-slacker (Sat Jan 24 10:18:02 2009 +0900) 2 commits
 + git-am: Add --ignore-date option
 + am: Add --committer-date-is-author-date option

It is a (probably) useful new feature with a sort-of cute explanation.

* jc/maint-apply-fix (Sun Jan 25 23:41:26 2009 -0800) 1 commit
 + builtin-apply.c: do not set bogus mode in check_preimage() for
   deleted path

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

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

* 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 (Fri Jan 23 10:07:46 2009 +0100) 7 commits
 - 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

Nobody has review comments on this yet.

* lh/submodule-tree-traversal (Sun Jan 25 01:52:06 2009 +0100) 6 commits
 - archive.c: add support for --submodules[=(all|checkedout)]
 - tree.c: allow read_tree_recursive() to traverse gitlink entries
 + 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

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

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

* js/valgrind (Wed Jan 21 02:36:40 2009 +0100) 2 commits
 - valgrind: ignore ldso errors
 - Add valgrind support in test scripts

Dscho and Peff had further exchanges on the list; I am sort of waiting for
the conclusion before picking any intermediate version up.

* ks/maint-mailinfo-folded (Tue Jan 13 01:21:04 2009 +0300) 4 commits
 + mailinfo: tests for RFC2047 examples
 + mailinfo: add explicit test for mails like '<a.u.thor@example.com>
   (A U Thor)'
 + mailinfo: 'From:' header should be unfold as well
 + mailinfo: correctly handle multiline 'Subject:' header

I just got tired of waiting and cleaned up the series myself.

* js/notes (Tue Jan 13 20:57:16 2009 +0100) 6 commits
 + 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

It would be nice to hear a real world success story using the notes
mechanism; Dscho says he also wants to make sure the current choice
of the structure scales well before casting it in stone.

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

----------------------------------------------------------------
[Graduated to "master"]

* sr/clone-empty (Fri Jan 23 01:07:32 2009 +0100) 1 commit
 + Allow cloning an empty repository

Has anybody actually tried this and made sure the resulting empty clone
works fine after the clone source gets updated with some contents?

* kb/lstat-cache (Sun Jan 18 16:14:54 2009 +0100) 5 commits
 + lstat_cache(): introduce clear_lstat_cache() function
 + lstat_cache(): introduce invalidate_lstat_cache() function
 + lstat_cache(): introduce has_dirs_only_path() function
 + lstat_cache(): introduce has_symlink_or_noent_leading_path()
   function
 + lstat_cache(): more cache effective symlink/directory detection

* tr/previous-branch (Wed Jan 21 00:37:38 2009 -0800) 10 commits
 + Simplify parsing branch switching events in reflog
 + Introduce for_each_recent_reflog_ent().
 + interpret_nth_last_branch(): plug small memleak
 + Fix reflog parsing for a malformed branch switching entry
 + Fix parsing of @{-1}@{1}
 + interpret_nth_last_branch(): avoid traversing the reflog twice
 + checkout: implement "-" abbreviation, add docs and tests
 + sha1_name: support @{-N} syntax in get_sha1()
 + sha1_name: tweak @{-N} lookup
 + checkout: implement "@{-N}" shortcut name for N-th last branch

* js/maint-all-implies-HEAD (Sat Jan 17 22:27:08 2009 -0800) 2 commits
 + bundle: allow the same ref to be given more than once
 + revision walker: include a detached HEAD in --all

* cb/add-pathspec (Wed Jan 14 15:54:35 2009 +0100) 2 commits
 + remove pathspec_match, use match_pathspec instead
 + clean up pathspec matching

* js/diff-color-words (Tue Jan 20 22:59:54 2009 -0600) 9 commits
 + Change the spelling of "wordregex".
 + color-words: Support diff.wordregex config option
 + color-words: make regex configurable via attributes
 + color-words: expand docs with precise semantics
 + color-words: enable REG_NEWLINE to help user
 + color-words: take an optional regular expression describing words
 + color-words: change algorithm to allow for 0-character word
   boundaries
 + color-words: refactor word splitting and use ALLOC_GROW()
 + Add color_fwrite_lines(), a function coloring each line
   individually

----------------------------------------------------------------
[Will merge to "master" soon]

* jg/mergetool (Sat Jan 24 00:12:45 2009 +0100) 1 commit
 + mergetool: Don't repeat merge tool candidates

* cb/mergetool (Wed Jan 21 22:57:48 2009 +0000) 1 commit
 + mergetool: respect autocrlf by using checkout-index

Now Ted told us not to wait for him, we'll go ahead by ourselves ;-).

* jk/signal-cleanup (Thu Jan 22 01:03:28 2009 -0500) 5 commits
 + pager: do wait_for_pager on signal death
 + refactor signal handling for cleanup functions
 + chain kill signals for cleanup functions
 + diff: refactor tempfile cleanup handling
 + Windows: Fix signal numbers

* sp/runtime-prefix (Sun Jan 18 13:00:15 2009 +0100) 7 commits
 + Windows: Revert to default paths and convert them by
   RUNTIME_PREFIX
 + Compute prefix at runtime if RUNTIME_PREFIX is set
 + Modify setup_path() to only add git_exec_path() to PATH
 + Add calls to git_extract_argv0_path() in programs that call
   git_config_*
 + git_extract_argv0_path(): Move check for valid argv0 from caller
   to callee
 + Refactor git_set_argv0_path() to git_extract_argv0_path()
 + Move computation of absolute paths from Makefile to runtime (in
   preparation for RUNTIME_PREFIX)

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

* 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 is only meant as a weatherballoon to help facilitate discussion.

* jk/renamelimit (Sat May 3 13:58:42 2008 -0700) 1 commit
 . diff: enable "too large a rename" warning when -M/-C is explicitly
   asked for

* jc/stripspace (Sun Mar 9 00:30:35 2008 -0800) 6 commits
 . git-am --forge: add Signed-off-by: line for the author
 . git-am: clean-up Signed-off-by: lines
 . stripspace: add --log-clean option to clean up signed-off-by:
   lines
 . stripspace: use parse_options()
 . Add "git am -s" test
 . git-am: refactor code to add signed-off-by line for the committer

* jc/post-simplify (Fri Aug 15 01:34:51 2008 -0700) 2 commits
 . revision --simplify-merges: incremental simplification
 . revision --simplify-merges: prepare for incremental simplification

* jk/valgrind (Thu Oct 23 04:30:45 2008 +0000) 2 commits
 . valgrind: ignore ldso errors
 . add valgrind support in test scripts

* wp/add-patch-find (Thu Nov 27 04:08:03 2008 +0000) 3 commits
 . In add --patch, Handle K,k,J,j slightly more gracefully.
 . Add / command in add --patch
 . git-add -i/-p: Change prompt separater from slash to comma

Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)

[Jeff King]

On Wed, Jan 28, 2009 at 06:06:45PM -0800, Junio C Hamano wrote:

> * js/valgrind (Wed Jan 21 02:36:40 2009 +0100) 2 commits
>  - valgrind: ignore ldso errors
>  - Add valgrind support in test scripts
> 
> Dscho and Peff had further exchanges on the list; I am sort of waiting for
> the conclusion before picking any intermediate version up.

I think I gave an OK to the last version posted, but then the last thing
I saw from Dscho was "I have a new patch, but I'm not posting it right
this second":

  http://article.gmane.org/gmane.comp.version-control.git/107300

followed by much "is zlib broken" discussion which I think doesn't hold
us up (either it is a bug in zlib, in which case it is not our problem,
or it is a false positive, in which case we just add a suppression).

So I think we are waiting for the next round from Johannes.

> * jk/valgrind (Thu Oct 23 04:30:45 2008 +0000) 2 commits
>  . valgrind: ignore ldso errors
>  . add valgrind support in test scripts

I think it probably makes sense to drop these at this point. Dscho's
more recent work should be the basis to which new patches are compared.

-Peff

Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)

[Jeff King]

On Wed, Jan 28, 2009 at 06:06:45PM -0800, Junio C Hamano wrote:

> * sr/clone-empty (Fri Jan 23 01:07:32 2009 +0100) 1 commit
>  + Allow cloning an empty repository
> 
> Has anybody actually tried this and made sure the resulting empty clone
> works fine after the clone source gets updated with some contents?

Hmm. It sort of works:

  $ mkdir parent && (cd parent && git init)
  Initialized empty Git repository in /home/peff/parent/.git/

  $ git clone parent child
  Initialized empty Git repository in /home/peff/child/.git/
  warning: You appear to have cloned an empty repository.

So far so good...

  $ (cd parent && echo content >file && git add file && git commit -m one)
  [normal commit output]
  $ (cd child && git fetch)
  [normal fetch output]

But:

  $ (cd child && git pull)
  You asked me to pull without telling me which branch you
  want to merge with, and 'branch.master.merge' in
  ...

So it's not quite seamless. The problem is that we're not setting up the
branch.master.* config on the empty clone. Nor do we set up
refs/remotes/origin/HEAD.

On top of that, I get funniness between versions:

  $ ssh peff.net 'git version && mkdir foo && cd foo && git init'
  git version 1.5.6.5
  Initialized empty Git repository in /mnt/data/home/peff/foo/.git/

  $ git clone peff.net:foo
  Initialized empty Git repository in /home/peff/foo/.git/
  warning: You appear to have cloned an empty repository.
  $ fatal: The remote end hung up unexpectedly

-Peff

Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)

[Jeff King]

On Wed, Jan 28, 2009 at 10:51:38PM -0500, Jeff King wrote:

> But:
> 
>   $ (cd child && git pull)
>   You asked me to pull without telling me which branch you
>   want to merge with, and 'branch.master.merge' in
>   ...
> 
> So it's not quite seamless. The problem is that we're not setting up the
> branch.master.* config on the empty clone. Nor do we set up
> refs/remotes/origin/HEAD.

Hrm. I was thinking we checked out "master" as a branch yet to be born,
but of course that doesn't work because we don't even know that the name
"master" exists on the other side (to do that, we would need an
extension to transmit symref information for a ref yet to be born).

We could always assume the remote side is going to eventually put
content on "master" (we know they aren't using another branch _now_, or
the repo wouldn't be empty, so we are just guessing they will follow the
usual convention). That feels a bit hack-ish, though.

So the current behavior is probably sane. But it is not obvious to a
user how to extend their repo one the upstream isn't empty. Maybe the
"empty repo" warning could mention "git fetch && git checkout -b master
origin/master" (which is the most obvious way I can think of)?

-Peff

Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> We could always assume the remote side is going to eventually put
> content on "master" (we know they aren't using another branch _now_, or
> the repo wouldn't be empty, so we are just guessing they will follow the
> usual convention). That feels a bit hack-ish, though.

Now, doesn't "The other end is empty" error start looking much saner than
everybody seems to have thought ;-)?

Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)

[Charles Bailey]

On Wed, Jan 28, 2009 at 06:06:45PM -0800, Junio C Hamano wrote:
> * cb/mergetool (Wed Jan 21 22:57:48 2009 +0000) 1 commit
>  + mergetool: respect autocrlf by using checkout-index
> 

Can you hold off on merging this one? I now think that there's a
cleaner way of doing this and I would like the opportunity for a
rethink.

-- 
Charles Bailey
http://ccgi.hashpling.plus.com/blog/

Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)

[Junio C Hamano]

Charles Bailey <charles@hashpling.org> writes:

> On Wed, Jan 28, 2009 at 06:06:45PM -0800, Junio C Hamano wrote:
>> * cb/mergetool (Wed Jan 21 22:57:48 2009 +0000) 1 commit
>>  + mergetool: respect autocrlf by using checkout-index
>> 
>
> Can you hold off on merging this one? I now think that there's a
> cleaner way of doing this and I would like the opportunity for a
> rethink.

Sure, it is not in 'master' yet.

But it's in 'next', so incremental updates from now on, please.

Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)

[Charles Bailey]

On Thu, Jan 29, 2009 at 12:26:39AM -0800, Junio C Hamano wrote:
> Charles Bailey <charles@hashpling.org> writes:
> 
> > On Wed, Jan 28, 2009 at 06:06:45PM -0800, Junio C Hamano wrote:
> >> * cb/mergetool (Wed Jan 21 22:57:48 2009 +0000) 1 commit
> >>  + mergetool: respect autocrlf by using checkout-index
> >> 
> >
> > Can you hold off on merging this one? I now think that there's a
> > cleaner way of doing this and I would like the opportunity for a
> > rethink.
> 
> Sure, it is not in 'master' yet.
> 
> But it's in 'next', so incremental updates from now on, please.
> 

OK, I've thought again and I still think that this patch is good.

Just so you know what I was thinking...

I felt that the new shell function that calls git checkout-index was a
bit clunky. git checkout-index --temp creates its own temporary file
and then the git mergetool renames this file to the temporary filename
that it had already decided on.

An earlier patch to mergetool was careful to ensure that mergetool
temporaries maintained the file extension of the target file in order
to help syntax highlighting merge tools. For this reason, just using
checkout-index generated filenames is not a sufficient solution.

I had two ideas, the first was that perhaps git mergetool could choose
a temporary naming scheme that could be matched by the appropriate use
of checkout-index --prefix. This would obviously preserve the file
extension but it's fairly obvious that it would have surprising
behaviour for merging files in subfolders.

My last idea would be to add an explicit --to-path= to git
checkout-index. It would make the mergetool code simpler but I'm not
sure how useful it would be in any other circumstance.

-- 
Charles Bailey
http://ccgi.hashpling.plus.com/blog/

Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)

[Sverre Rabbelier]

On Thu, Jan 29, 2009 at 04:51, Jeff King <peff@peff.net> wrote:
>  $ mkdir parent && (cd parent && git init)
>  Initialized empty Git repository in /home/peff/parent/.git/
>
>  $ git clone parent child
>  Initialized empty Git repository in /home/peff/child/.git/
>  warning: You appear to have cloned an empty repository.
>
> So far so good...
>
>  $ (cd parent && echo content >file && git add file && git commit -m one)
>  [normal commit output]
>  $ (cd child && git fetch)
>  [normal fetch output]

I thought instead we wanted to support the following workflow:

$ (cd child && echo content >file && git add file && git commit -m one)
[normal commit output]

Which is what the testcase tests. E.g., we want to support cloning an
empty repo so that the user can then _push_ to that repository to make
it non-empty, no?

-- 
Cheers,

Sverre Rabbelier

Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)

[Jeff King]

On Thu, Jan 29, 2009 at 12:27:23PM +0100, Sverre Rabbelier wrote:

> I thought instead we wanted to support the following workflow:
> 
> $ (cd child && echo content >file && git add file && git commit -m one)
> [normal commit output]
> 
> Which is what the testcase tests. E.g., we want to support cloning an
> empty repo so that the user can then _push_ to that repository to make
> it non-empty, no?

True, that is probably going to be more common (otherwise, why would the
person who is going to push into the empty repo advertise it to you
before they have put any content in it).

But it will probably still be surprising not to have the branch merging
setup:

  mkdir parent && (cd parent && git init) &&
  git clone parent child && cd child &&
  echo content >file && git add file && git commit -m one &&
  git push origin master ;# note we have to explicitly mention the branch

  ... time passes ...

  git pull

produces the "you haven't asked me which branch to merge" message.

Which does make some sense, given how tracking configuration is set up.
It's just that it's a little sad that cloning an empty repository and
then later getting commits out of it (whether commits you put in or
somebody else) does not behave the same as cloning a repository with
commits.

Which I thought was sort of the point, that this would work seamlessly.
Otherwise, there is not much advantage over:

  mkdir parent && (cd parent && git init) &&
  mkdir child && cd child && git init &&
  echo content >file && git add file && git commit -m one &&
  git push origin master ;# note we have to explicitly mention the branch

With the empty clone, you get your "origin" remote set up, but in both
cases you are missing the branch tracking.

I don't know if there is a good solution, though. Perhaps it's best to
just let what's there get released and see if people complain.

-Peff

Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)

[Pieter de Bie]

On 29 jan 2009, at 11:37, Jeff King wrote:

>  git push origin master ;# note we have to explicitly mention the  
> branch
>
>  ... time passes ...
>
>  git pull
>
> produces the "you haven't asked me which branch to merge" message.
>
> Which does make some sense, given how tracking configuration is set  
> up.
> It's just that it's a little sad that cloning an empty repository and
> then later getting commits out of it (whether commits you put in or
> somebody else) does not behave the same as cloning a repository with
> commits.

This is true in all cases. If you create a new branch in any repository,
push that, and later do a 'git pull', you get that message. I agree it's
not the nicest way to handle things, but this is not an issue with the  
clone,
it's an issue of pushing new branches in general.

Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)

[Sverre Rabbelier]

On Thu, Jan 29, 2009 at 12:40, Pieter de Bie <pdebie@ai.rug.nl> wrote:
> This is true in all cases. If you create a new branch in any repository,
> push that, and later do a 'git pull', you get that message. I agree it's
> not the nicest way to handle things, but this is not an issue with the
> clone, it's an issue of pushing new branches in general.

Mhhh, so maybe we want a way to set up tracking branches when pushing,
yes? From what I've seen a patch to do that shouldn't be too hard, so
if there's interest in that I could look into that.

-- 
Cheers,

Sverre Rabbelier

Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)

[Jeff King]

On Thu, Jan 29, 2009 at 11:40:42AM +0000, Pieter de Bie wrote:

> This is true in all cases. If you create a new branch in any
> repository, push that, and later do a 'git pull', you get that
> message. I agree it's not the nicest way to handle things, but this is
> not an issue with the  clone, it's an issue of pushing new branches in
> general.

Right. I guess I was hoping by cloning an existing repository, even one
with no commits on the branch, that we could somehow remember that we
are "on" the master branch. I think that is what people who ask for
empty cloning really want:

  1. make a bare upstream

  2. clone empty repo

  3. create commits

  4. git push / git pull, as if we had cloned non-empty repo

And I know that it is not very "git" to talk about empty branches, since
branches are pointers into the DAG. But we already do similar trickery
with "yet to be born" branches by putting a dangling symref into HEAD.
But I don't think there's any way currently to send those dangling
symrefs across the git protocol, which is what would be required to do
the above accurately.

-Peff

Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)

[Jeff King]

On Thu, Jan 29, 2009 at 12:45:23PM +0100, Sverre Rabbelier wrote:

> On Thu, Jan 29, 2009 at 12:40, Pieter de Bie <pdebie@ai.rug.nl> wrote:
> > This is true in all cases. If you create a new branch in any repository,
> > push that, and later do a 'git pull', you get that message. I agree it's
> > not the nicest way to handle things, but this is not an issue with the
> > clone, it's an issue of pushing new branches in general.
> 
> Mhhh, so maybe we want a way to set up tracking branches when pushing,
> yes? From what I've seen a patch to do that shouldn't be too hard, so
> if there's interest in that I could look into that.

I think that would be reasonable. It wouldn't help the case of "somebody
else pushed some content that you want to pull", but like you said, I
think the primary workflow is that you immediately push after cloning
the empty repo.

-Peff

Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)

[Nico -telmich- Schottelius]

[-- Attachment #1: Type: text/plain, Size: 1502 bytes --]

Jeff King [Thu, Jan 29, 2009 at 06:48:34AM -0500]:
> [...] I think that is what people who ask for empty cloning really want:
> 
>   1. make a bare upstream
> 
>   2. clone empty repo
> 
>   3. create commits
> 
>   4. git push / git pull, as if we had cloned non-empty repo

I must confess, as a user I would like to do

1. create local repo

2. create a remote

3. push it

I don't care about creating empty repos somewhere:
My aim is to publish my work, that's it.

Comments on the steps:

  1.1. I don't care whether I push a empty repo or not. But pushing an empty
       one does not make much sense, so refusing this would be reasonable

  1.2. When creating a new repo, it would be helpful if I can directly add a
       description: git init [description] would be nice to have

  2.1. I (as a user) understand that I need to create a remote where I have to
       push to. It would be helpful to specify --track-this/--merge-this to
       have it automatically connected to the current branch

  3.1.  I would really like to see something like git push
        --create[-if-not-exists]. This makes sense for me, but could also
        be a global configuration option (push.autocreate = true|false).


Just a comment from a user's point of view ;-)

Sincerly,

Nico

-- 
Think about Free and Open Source Software (FOSS).
http://nico.schottelius.org/documentations/foss/the-term-foss/

PGP: BFE4 C736 ABE5 406F 8F42  F7CF B8BE F92A 9885 188C

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)

[Sverre Rabbelier]

On Thu, Jan 29, 2009 at 12:50, Jeff King <peff@peff.net> wrote:
> I think that would be reasonable.

Yay :).

> It wouldn't help the case of "somebody
> else pushed some content that you want to pull", but like you said, I
> think the primary workflow is that you immediately push after cloning
> the empty repo.

Also, the only way to support the "somebody else pushed already"
workflow would be to assume the user wants to name the branch
'master', which might not be the case at all.

-- 
Cheers,

Sverre Rabbelier

Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)

[Jeff King]

On Thu, Jan 29, 2009 at 01:20:20PM +0100, Sverre Rabbelier wrote:

> > It wouldn't help the case of "somebody
> > else pushed some content that you want to pull", but like you said, I
> > think the primary workflow is that you immediately push after cloning
> > the empty repo.
> 
> Also, the only way to support the "somebody else pushed already"
> workflow would be to assume the user wants to name the branch
> 'master', which might not be the case at all.

You could make a guess that they will use "master", and if you are
wrong, it behaves as now. But if you are right, "git pull" pulls down
master automatically.

But that is getting a little confusing. So let's push this "git push
--track" idea to completion and see how people like it.

-Peff

Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)

[Jeff King]

On Thu, Jan 29, 2009 at 01:04:55PM +0100, Nico -telmich- Schottelius wrote:

> I must confess, as a user I would like to do
> 
> 1. create local repo
> 
> 2. create a remote
> 
> 3. push it
> 
> I don't care about creating empty repos somewhere:
> My aim is to publish my work, that's it.

I think people have asked for that before, too. The fundamental problem
is that we don't necessarily know how to create the remote repo, or even
have permissions to do so.

If your transport is vanilla ssh, then in theory we could turn
"host:path.git" into "ssh host 'GIT_DIR=path.git git init'". But for
other transports we are out of luck. And for hosting sites like github,
we are out of luck, as you use the web interface to make a new repo.

>   1.2. When creating a new repo, it would be helpful if I can directly add a
>        description: git init [description] would be nice to have

I don't think there is any fundamental reason not to allow more setup of
internal .git/* files through 'init'. In most cases, you could just as
easily "echo description >.git/description" afterwards, but it might be
slightly more convenient if you are ssh'ing to do it all in one shot.

>   2.1. I (as a user) understand that I need to create a remote where I have to
>        push to. It would be helpful to specify --track-this/--merge-this to
>        have it automatically connected to the current branch

  git remote add -t master origin $URL ?

>   3.1.  I would really like to see something like git push
>         --create[-if-not-exists]. This makes sense for me, but could also
>         be a global configuration option (push.autocreate = true|false).

I think this would be better as a feature of "git remote". I.e.:

  git remote add --create -t master origin $URL

but again, we can only sanely do creation magic in a subset of cases.
Which is why I think nobody has implemented it so far.

-Peff

Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)

[Johannes Schindelin]

Hi,

On Thu, 29 Jan 2009, Jeff King wrote:

> On Thu, Jan 29, 2009 at 01:20:20PM +0100, Sverre Rabbelier wrote:
> 
> > > It wouldn't help the case of "somebody
> > > else pushed some content that you want to pull", but like you said, I
> > > think the primary workflow is that you immediately push after cloning
> > > the empty repo.
> > 
> > Also, the only way to support the "somebody else pushed already"
> > workflow would be to assume the user wants to name the branch
> > 'master', which might not be the case at all.
> 
> You could make a guess that they will use "master", and if you are
> wrong, it behaves as now. But if you are right, "git pull" pulls down
> master automatically.
> 
> But that is getting a little confusing. So let's push this "git push
> --track" idea to completion and see how people like it.

How about installing

	[branch "master"]
		remote = origin
		merge = refs/heads/master

by default?  It is a safe bet that this will be the case for 99% of all 
users that want to clone an empty repository (especially if they are 
putting their public repositories on something like repo.or.cz, where you 
cannot change the default branch from "master" to something else).

And if somebody wants to track another branch, tough, she has to call 
this:

	$ git checkout -t origin/blablabla

Ciao,
Dscho

Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)

[Jeff King]

On Fri, Jan 30, 2009 at 02:18:32PM +0100, Johannes Schindelin wrote:

> > You could make a guess that they will use "master", and if you are
> > wrong, it behaves as now. But if you are right, "git pull" pulls down
> > master automatically.
> > 
> > But that is getting a little confusing. So let's push this "git push
> > --track" idea to completion and see how people like it.
> 
> How about installing
> 
> 	[branch "master"]
> 		remote = origin
> 		merge = refs/heads/master
> 
> by default?  It is a safe bet that this will be the case for 99% of all 
> users that want to clone an empty repository (especially if they are 
> putting their public repositories on something like repo.or.cz, where you 
> cannot change the default branch from "master" to something else).
> 
> And if somebody wants to track another branch, tough, she has to call 
> this:
> 
> 	$ git checkout -t origin/blablabla

I was tempted to suggest that, but I haven't thought through whether
there are any lurking corner cases (which empty clone seems to be
fraught with). So I think it is a reasonable thing to try and play with.

-Peff

Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)

[Charles Bailey]

On Thu, Jan 29, 2009 at 09:16:11AM +0000, Charles Bailey wrote:
> On Thu, Jan 29, 2009 at 12:26:39AM -0800, Junio C Hamano wrote:
> > Charles Bailey <charles@hashpling.org> writes:
> > 
> > > On Wed, Jan 28, 2009 at 06:06:45PM -0800, Junio C Hamano wrote:
> > >> * cb/mergetool (Wed Jan 21 22:57:48 2009 +0000) 1 commit
> > >>  + mergetool: respect autocrlf by using checkout-index
> > >> 
> > >
> > > Can you hold off on merging this one? I now think that there's a
> > > cleaner way of doing this and I would like the opportunity for a
> > > rethink.
> > 
> > Sure, it is not in 'master' yet.
> > 
> > But it's in 'next', so incremental updates from now on, please.
> > 
> 
> OK, I've thought again and I still think that this patch is good.

Except that I was completely wrong. Please continue to hold off
merging into master until you've rolled in the future patch that fixes
mergetool in subdirectories which I'll clean-up and send later today.

Sorry about this.

-- 
Charles Bailey
http://ccgi.hashpling.plus.com/blog/

Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)

[Junio C Hamano]

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

> How about installing
>
> 	[branch "master"]
> 		remote = origin
> 		merge = refs/heads/master
>
> by default?  It is a safe bet that this will be the case for 99% of all 
> users that want to clone an empty repository (especially if they are 
> putting their public repositories on something like repo.or.cz, where you 
> cannot change the default branch from "master" to something else).

I think this is a reasonable thing to do.  Even though cloning from a void
is not entirely a reasonable thing to do to begin with, because we are
going ahead to allow it now, it would be the best thing to do when cloning
a repository served by the currently deployed git.

We _could_ do better if we were to resurrect my earlier series to add
"where does the HEAD point at" protocol extension, but even then we would
need a fallback like your suggestion when talking to older servers anyway.

Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)

[Kirill Smelkov]

On Wed, Jan 28, 2009 at 06:06:45PM -0800, Junio C Hamano wrote:

[...]

> * ks/maint-mailinfo-folded (Tue Jan 13 01:21:04 2009 +0300) 4 commits
>  + mailinfo: tests for RFC2047 examples
>  + mailinfo: add explicit test for mails like '<a.u.thor@example.com>
>    (A U Thor)'
>  + mailinfo: 'From:' header should be unfold as well
>  + mailinfo: correctly handle multiline 'Subject:' header
> 
> I just got tired of waiting and cleaned up the series myself.

Sorry about that. Here is the missing bit (based on master)

--- 8< ---

Subject: [PATCH] mailinfo: cleanup extra spaces for complex 'From:'

currently for cases like

    From: A U Thor <a.u.thor@example.com> (Comment)

mailinfo extracts the following 'Author:' field:

    Author: A U Thor   (Comment)
                     ^^
which has two extra spaces left in there after removed email part.

I think this is wrong so here is a fix.

Signed-off-by: Kirill Smelkov <kirr@landau.phys.spbu.ru>
---
 builtin-mailinfo.c        |   19 +++++++++++++++----
 t/t5100/info0001          |    2 +-
 t/t5100/rfc2047-info-0004 |    2 +-
 t/t5100/sample.mbox       |    4 ++--
 4 files changed, 19 insertions(+), 8 deletions(-)

diff --git a/builtin-mailinfo.c b/builtin-mailinfo.c
index d4dc23a..2789ccd 100644
--- a/builtin-mailinfo.c
+++ b/builtin-mailinfo.c
@@ -29,6 +29,9 @@ static struct strbuf **p_hdr_data, **s_hdr_data;
 #define MAX_HDR_PARSED 10
 #define MAX_BOUNDARIES 5
 
+static void cleanup_space(struct strbuf *sb);
+
+
 static void get_sane_name(struct strbuf *out, struct strbuf *name, struct strbuf *email)
 {
 	struct strbuf *src = name;
@@ -109,11 +112,19 @@ static void handle_from(const struct strbuf *from)
 	strbuf_add(&email, at, el);
 	strbuf_remove(&f, at - f.buf, el + (at[el] ? 1 : 0));
 
-	/* The remainder is name.  It could be "John Doe <john.doe@xz>"
-	 * or "john.doe@xz (John Doe)", but we have removed the
-	 * email part, so trim from both ends, possibly removing
-	 * the () pair at the end.
+	/* The remainder is name.  It could be
+	 *
+	 * - "John Doe <john.doe@xz>"			(a), or
+	 * - "john.doe@xz (John Doe)"			(b), or
+	 * - "John (zzz) Doe <john.doe@xz> (Comment)"	(c)
+	 *
+	 * but we have removed the email part, so
+	 *
+	 * - remove extra spaces which could stay after email (case 'c'), and
+	 * - trim from both ends, possibly removing the () pair at the end
+	 *   (cases 'a' and 'b').
 	 */
+	cleanup_space(&f);
 	strbuf_trim(&f);
 	if (f.buf[0] == '(' && f.len && f.buf[f.len - 1] == ')') {
 		strbuf_remove(&f, 0, 1);
diff --git a/t/t5100/info0001 b/t/t5100/info0001
index 8c05277..f951538 100644
--- a/t/t5100/info0001
+++ b/t/t5100/info0001
@@ -1,4 +1,4 @@
-Author: A U Thor
+Author: A (zzz) U Thor (Comment)
 Email: a.u.thor@example.com
 Subject: a commit.
 Date: Fri, 9 Jun 2006 00:44:16 -0700
diff --git a/t/t5100/rfc2047-info-0004 b/t/t5100/rfc2047-info-0004
index 0ca7ff0..f67a90a 100644
--- a/t/t5100/rfc2047-info-0004
+++ b/t/t5100/rfc2047-info-0004
@@ -1,4 +1,4 @@
-Author: Nathaniel Borenstein   (םולש ןב ילטפנ)
+Author: Nathaniel Borenstein (םולש ןב ילטפנ)
 Email: nsb@thumper.bellcore.com
 Subject: Test of new header generator
 
diff --git a/t/t5100/sample.mbox b/t/t5100/sample.mbox
index 85df55f..c5ad206 100644
--- a/t/t5100/sample.mbox
+++ b/t/t5100/sample.mbox
@@ -2,10 +2,10 @@
 	
     
 From nobody Mon Sep 17 00:00:00 2001
-From: A
+From: A (zzz)
       U
       Thor
-      <a.u.thor@example.com>
+      <a.u.thor@example.com> (Comment)
 Date: Fri, 9 Jun 2006 00:44:16 -0700
 Subject: [PATCH] a commit.
 
-- 
1.6.1.284.g5dc13

--- 8< ---


Thanks,
Kirill

Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)

[Junio C Hamano]

Thanks, will apply.

Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)

[Junio C Hamano]

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

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>> How about installing
>>
>> 	[branch "master"]
>> 		remote = origin
>> 		merge = refs/heads/master
>>
>> by default?  It is a safe bet that this will be the case for 99% of all 
>> users that want to clone an empty repository (especially if they are 
>> putting their public repositories on something like repo.or.cz, where you 
>> cannot change the default branch from "master" to something else).
>
> I think this is a reasonable thing to do.

So I've been sort of waiting for a trivial patch to materialize, and then
almost forgot about it like everybody else did.  Before all of us forget,
here is my attempt to do the above.

We seem to have acquired a bad habit of discussing and agreeing on a
potential improvement and then not following through, forgetting it
altogether.

Exciting new features we can count on original submitters to stick to them
and push them forward whether we go into a release freeze, but the more
boring kind of patches that we already know what we want to see by the
next release are actually the more important to the overall project;
sadly, they tend to get lost somewhere in the crack.  I wonder if we can
do anything about it.

And no, a bug tracker is not the answer, even though it could be a (small)
part of the solution.

-- >8 --
Subject: Install the default "master" branch configuration after cloning a void

After "cloning from an empty repository", we have a configuration to
describe the remote's URL and the default ref mappings, but we lack the
branch configuration for the default branch we create on our end,
"master".

It is likely that the empty repository we cloned from will point the
default "master" branch with its HEAD, so prepare the local configuration
to match.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 builtin-clone.c |   22 +++++++++++++++++-----
 1 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/builtin-clone.c b/builtin-clone.c
index f73029e..431c136 100644
--- a/builtin-clone.c
+++ b/builtin-clone.c
@@ -350,6 +350,18 @@ static struct ref *write_remote_refs(const struct ref *refs,
 	return local_refs;
 }
 
+static void install_branch_config(const char *origin, const char *local,
+				  const char *remote)
+{
+	struct strbuf key = STRBUF_INIT;
+	strbuf_addf(&key, "branch.%s.remote", local);
+	git_config_set(key.buf, origin);
+	strbuf_reset(&key);
+	strbuf_addf(&key, "branch.%s.merge", local);
+	git_config_set(key.buf, remote);
+	strbuf_release(&key);
+}
+
 int cmd_clone(int argc, const char **argv, const char *prefix)
 {
 	int use_local_hardlinks = 1;
@@ -539,6 +551,9 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
 		head_points_at = NULL;
 		remote_head = NULL;
 		option_no_checkout = 1;
+		if (!option_bare)
+			install_branch_config(option_origin, "master",
+					      "refs/heads/master");
 	}
 
 	if (head_points_at) {
@@ -567,11 +582,8 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
 				      head_points_at->peer_ref->name,
 				      reflog_msg.buf);
 
-			strbuf_addf(&key, "branch.%s.remote", head);
-			git_config_set(key.buf, option_origin);
-			strbuf_reset(&key);
-			strbuf_addf(&key, "branch.%s.merge", head);
-			git_config_set(key.buf, head_points_at->name);
+			install_branch_config(option_origin, head,
+					      head_points_at->name);
 		}
 	} else if (remote_head) {
 		/* Source had detached HEAD pointing somewhere. */

Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)

[Sverre Rabbelier]

Heya,

On Thu, Feb 12, 2009 at 07:42, Junio C Hamano <gitster@pobox.com> wrote:
> Exciting new features we can count on original submitters to stick to them
> and push them forward whether we go into a release freeze, but the more
> boring kind of patches that we already know what we want to see by the
> next release are actually the more important to the overall project;
> sadly, they tend to get lost somewhere in the crack.  I wonder if we can
> do anything about it.

I'm sorry for not picking up on this, the deadline Melange being done
is getting closer (GSoC org applications are starting in less than a
month), that together with school having started again results in me
having little time left.

Thanks for following up on this!

-- 
Cheers,

Sverre Rabbelier

Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)

[Johannes Schindelin]

Hi,

On Wed, 11 Feb 2009, Junio C Hamano wrote:

> Junio C Hamano <gitster@pobox.com> writes:
> 
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> >
> >> How about installing
> >>
> >> 	[branch "master"]
> >> 		remote = origin
> >> 		merge = refs/heads/master
> >>
> >> by default?  It is a safe bet that this will be the case for 99% of all 
> >> users that want to clone an empty repository (especially if they are 
> >> putting their public repositories on something like repo.or.cz, where you 
> >> cannot change the default branch from "master" to something else).
> >
> > I think this is a reasonable thing to do.
> 
> So I've been sort of waiting for a trivial patch to materialize, and then
> almost forgot about it like everybody else did.  Before all of us forget,
> here is my attempt to do the above.

Thanks.

> We seem to have acquired a bad habit of discussing and agreeing on a 
> potential improvement and then not following through, forgetting it 
> altogether.

Yeah, I am pretty excited at my rebase -i -p branch at the moment, so I am 
prone to forget other things (push --track included).

> And no, a bug tracker is not the answer, even though it could be a 
> (small) part of the solution.

If you really want to know how much a bug tracker is not the solution, 
because it is a fire-and-forget (as in post, and never come back, 
even with a small little message that the fix actually worked) place for 
many bug reporters, just look at msysGit's bug tracker and weep.

> diff --git a/builtin-clone.c b/builtin-clone.c
> index f73029e..431c136 100644
> --- a/builtin-clone.c
> +++ b/builtin-clone.c
> @@ -350,6 +350,18 @@ static struct ref *write_remote_refs(const struct ref *refs,
>  	return local_refs;
>  }
>  
> +static void install_branch_config(const char *origin, const char *local,
> +				  const char *remote)

I would have used a different order (local, origin, remote), but that's 
okay, I guess.

Ciao,
Dscho

Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)

[Jeff King]

On Wed, Feb 11, 2009 at 10:42:27PM -0800, Junio C Hamano wrote:

> We seem to have acquired a bad habit of discussing and agreeing on a
> potential improvement and then not following through, forgetting it
> altogether.
> 
> Exciting new features we can count on original submitters to stick to them
> and push them forward whether we go into a release freeze, but the more
> boring kind of patches that we already know what we want to see by the
> next release are actually the more important to the overall project;
> sadly, they tend to get lost somewhere in the crack.  I wonder if we can
> do anything about it.

I used to be more diligent about making a note of such things in my todo
list and then actually trying to reduce the size of that todo list
occasionally. But my git time has shrunk a bit lately due to my day job,
and I have been spending more time reviewing patches and discussing
ideas on the list, so it has been a while since I have actually sat down
to check something off of my todo.

I think in this case it was a matter of "it didn't make it onto
anybody's todo list". So I think it is nice that you put together the
patch; but I also think a gentle nudge of "so is anybody going to do
this?" would have worked, since it gives another chance for people to
claim ownership.

> And no, a bug tracker is not the answer, even though it could be a (small)
> part of the solution.

Maybe it would be sufficient to simply keep a public record of
intent-to-work on certain topics. Usually it is obvious from the mail
exchange what is going to happen next, but sometimes (as I think in this
case) it is left somewhat ambiguous.

> -- >8 --
> Subject: Install the default "master" branch configuration after cloning a void

The patch looks good to me.

-Peff

Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)

[Junio C Hamano]

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

>> diff --git a/builtin-clone.c b/builtin-clone.c
>> index f73029e..431c136 100644
>> --- a/builtin-clone.c
>> +++ b/builtin-clone.c
>> @@ -350,6 +350,18 @@ static struct ref *write_remote_refs(const struct ref *refs,
>>  	return local_refs;
>>  }
>>  
>> +static void install_branch_config(const char *origin, const char *local,
>> +				  const char *remote)
>
> I would have used a different order (local, origin, remote), but that's 
> okay, I guess.

Ok, here is an incremental that will be squashed.

 builtin-clone.c  |    7 ++++---
 t/t5601-clone.sh |   15 +++++++++++++++
 2 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/builtin-clone.c b/builtin-clone.c
index 431c136..c338910 100644
--- a/builtin-clone.c
+++ b/builtin-clone.c
@@ -350,7 +350,8 @@ static struct ref *write_remote_refs(const struct ref *refs,
 	return local_refs;
 }
 
-static void install_branch_config(const char *origin, const char *local,
+static void install_branch_config(const char *local,
+				  const char *origin,
 				  const char *remote)
 {
 	struct strbuf key = STRBUF_INIT;
@@ -552,7 +553,7 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
 		remote_head = NULL;
 		option_no_checkout = 1;
 		if (!option_bare)
-			install_branch_config(option_origin, "master",
+			install_branch_config("master", option_origin,
 					      "refs/heads/master");
 	}
 
@@ -582,7 +583,7 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
 				      head_points_at->peer_ref->name,
 				      reflog_msg.buf);
 
-			install_branch_config(option_origin, head,
+			install_branch_config(head, option_origin,
 					      head_points_at->name);
 		}
 	} else if (remote_head) {
diff --git a/t/t5601-clone.sh b/t/t5601-clone.sh
index fe287d3..44793f2 100755
--- a/t/t5601-clone.sh
+++ b/t/t5601-clone.sh
@@ -144,4 +144,19 @@ test_expect_success 'clone to an existing path' '
 	test_must_fail git clone src target-5
 '
 
+test_expect_success 'clone a void' '
+	mkdir src-0 &&
+	(
+		cd src-0 && git init
+	) &&
+	git clone src-0 target-6 &&
+	(
+		cd src-0 && test_commit A
+	) &&
+	git clone src-0 target-7 &&
+	# There is no reason to insist they are bit-for-bit
+	# identical, but this test should suffice for now.
+	test_cmp target-6/.git/config target-7/.git/config
+'
+
 test_done

Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)

[Johannes Schindelin]

Hi,

On Thu, 12 Feb 2009, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> >> diff --git a/builtin-clone.c b/builtin-clone.c
> >> index f73029e..431c136 100644
> >> --- a/builtin-clone.c
> >> +++ b/builtin-clone.c
> >> @@ -350,6 +350,18 @@ static struct ref *write_remote_refs(const struct ref *refs,
> >>  	return local_refs;
> >>  }
> >>  
> >> +static void install_branch_config(const char *origin, const char *local,
> >> +				  const char *remote)
> >
> > I would have used a different order (local, origin, remote), but that's 
> > okay, I guess.
> 
> Ok, here is an incremental that will be squashed.

Thanks, very much appreciated,
Dscho