If it is truly only about "submodule update" then the change

seems too intrusive, especially "remotes.default" variable that

affects the way how fetch and merge works in situations that do

not involve submodules.
If it is not limited to "submodule update" but equally valid fix

to non-submodule situations, the changes to the other parts may

very well be justifiable, but that would mean your "Yes" is a

lie and instead should be "No, but these situations are helped

by these changes because...".
In any case, let's step back a bit.
Earlier you said in a response to Dscho that your servers are

named consistently across repositories.  servername.foo.bar has

nickname servername everywhere.
If your top-level repository needs to access a specific server

"frotz.foo.bar" for updates, then you would have bootstrapped

the whole thing with:
	$ git clone git://frotz.foo.bar/toplevel.git
and in that particular instance of the repository, the source

repository on frotz.foo.bar would have been known as 'origin',

right?  I would not object if you also gave another nickname

'frotz' to the same repository for consistency across

developers.
If that is the case, I am wondering why your subprojects are not

pointing at the corresponding repository on that same

'frotz.foo.bar' machine as 'origin'.  I suspect the reason is

that .gitmodules do not say 'frotz.foo.bar' but name some other

machine.
And in-tree .gitmodules can name only one URL, as it is project

global and shared by everybody.  There is no escaping it.
At least as things were designed, "git submodule init" takes URL

recorded in .gitmodules as a hint, but this is for the user to

override in .git/config in the top-level.  Maybe the UI to allow

this overriding is not easy enough to use, and your submodules

ended up pointing at wrong (from the machine's point of view)

URL as 'origin'.  And perhaps that is the root cause of this

issue?
I am looking at the discussion on the list archive when we

discussed the initial design of ...
[ message continues ]

First, I resent the patch series last night, it now uses core.origin to

avoid touching remotes.* namespace.
The changes *do* fix a nit when on a non-tracking branch. With this,

fetch / merge / pull will now honor that the user said (via git clone -o

frotz) "my upstream is nicknamed frotz" and not try to use origin when

origin was never defined.
So, while fixing this minor aggravation wasn't my motivation, I view

this as a nice side-benefit :^).
The driving issues:

1) I deal with too many servers for "origin" to be a useful nick name,

and we have an agreed set of nickname / server pairings across my project.

2) Therefore, we always do git clone -o frotz  frotz.foo.bar/path_to_git.

3) Because of 2, for top-level, "origin" is not defined, tracking

branches set up via git branch --track point to the correct remote, and

we basically understand branch names as <nickname>/branch. In other

words, we *are* aware of what server we are using.

4) git-submodule update breaks the above:

- a) it invokes git clone frotz.foo.bar/path_to_git thus defining

"origin" as the nickname for frotz.foo.bar.

  b) it invokes bare git-fetch on a detached head, so the upstream *has*

Nope, we did it with git clone -o frotz git://frotz.foo.bar/toplevel.git

Actually,

1) We don't use origin because we avoid having to wonder "Is

frotz.foo.bar named "origin" or "frotz" on this client, and thus how do

I get data from frotz?

2) I submitted the change allowing submodules to be recorded into

.gitmodules with a relative url (e.g., ./path_from_parent_to_submodule)

rather than an absolute, so we record the relative path only.

3) Thus, git submodule has set up the submodules to point at the parent

project's default remote. However, in the parent the server is nicknamed

"frotz", but now in the submodule the server is nicknamed "origin"  Oops.
Again, the relative-url patch was to address this so that a project that

is mirrored to another server remains valid on the new server without

modifying ...
[ message continues ]

I like that.  This is a very good argument, especially because

it clarifies very well that the issue is not about "'submodule

init' misbehaves" but "fetch/pull/merge does not play well with

clone -o".
The only remaining (minor) doubt I have (not in the sense that

"I object to it!", but in the sense that "I wish there could be

a better alternative, but I do not think of one offhand") is

polluting the core.* namespace with this configuration variable.
Looking at Documentation/config.txt, I realize that we already

have made a mistake of allowing core.gitproxy, but other than

that single mistake, everything in core.* is still about things

that apply to the use of git even when the repository does not

talk with any other repository.  If we deprecate and rename away

that one mistake, we can again make core.* to mean things that

are _really_ core, but using core.origin for "the default remote

is not called 'origin' but 'frotz' here" is a step backwards

from that ideal.
But that's a minor naming issue.

-

Hi,
FWIW I disagree.
I never understood why people want to complicate things by being able to

name default _keys_ differently.  Why not letting "origin" being the

default being pulled from, and be done with it?
Besides, I _really_ do not understand why we have such a discussion in rc

phase.  There are _many_ more interesting discussions now that _also_ do

not belong into a freeze phase.
Ciao,

Dscho
-

That happens to match my personal feeling.
HOWEVER.
We treat 'origin' in a special way when you do this:
	$ git clone somewhere new.git

        $ cd new.git

        $ git checkout HEAD^0

        $ git pull
And we already have "clone -o" and claim to support that option.

I think that it is very reasonable from the consistency point of

view to make sure that the following sequence treats 'frotz' the

same special way the above treats 'origin' specially:
	$ git clone -o frotz somewhere new.git

        $ cd new.git

        $ git checkout HEAD^0

        $ git pull
A purist alternative is to deprecate "git clone -o" and

eventually remove it.
Note that I was agreeing only with this specific aspect of the

argument.  I am not at all interested in getting involved in

refining or re-defining the existing submodule semantics this

late in the cycle before 1.5.4.  But I can very well see that

fixing this specific inconsistency can be separated out from the

rest of Mark's series and viewed as a set of trivially correct
Currently the ones I looked at and consider possible 1.5.4

material are http-push fixes from Grégoire Barbier and

parse_commit_buffer() tightening from Martin Koegler.
Recently I looked at the following patches and topics but I do

not think any of them belongs to 1.5.4.  None of them is obvious

and trivially correct fix to regressions or serious existing

bugs:
 * compress/decompress abstraction (Marco)
 * crlf (Steffen Prohaska and Dmitry Potapov)
 * whitespace error: "cr at eol is ok" (me)
 * various conflicting submodule changes(Ping Yin, Mark

   Levedahl, Imran M Yousuf)
 * unconfigured ident safety (Stephen Sinclair)
 * gitweb feed from commit to commitdiff (Florian La Rouche --

   Jakub seems to be on top of this so I am not worried about it

   too much).
 * color.ui (Matthias Kestenholz)
 * test scripts to use valgrind (Jeff King, but there was another

   one in the past -- can their efforts compared and coordinated

   better?).

...
[ message continues ]

It seems that for the past few days, people were having too much

fun bashing how broken MacOS X is, and the real work has stalled

in the meantime.  Well, not really stalled but they certainly

made the patches and discussions harder to find in the list

archive.
But that's Ok.  You cannot win every battle.
Now the lack of unsetenv can be autodetected, and coloring

breakage of --color-words has been fixed.  We have also managed

to catch a real breakage in fast-import, but somebody seems to

have managed to bash OS X even in that thread ;-)
But there are still unapplied patches that deserve attention.

The one that I am most worried about is Grégoire Barbier's

http-push changes:
  $gmane/70406 <1200250979-19604-1-git-send-email-gb@gbarbier.org>

  $gmane/70407 <1200250979-19604-2-git-send-email-gb@gbarbier.org>

  $gmane/70405 <1200250979-19604-3-git-send-email-gb@gbarbier.org>
They look sensible on paper. I do not, however, use http-push

myself, and I'd really like an independent success (or failure)

reports on them.  I can also threaten to apply them and see if

it breaks for anybody, which I may end up doing.
Martin Koegler's parse_commit_buffer() tightening is much easier:
  $gname/70478 <12003456313661-git-send-email-mkoegler@auto.tuwien.ac.at>
It needs a proper commit message; the patch itself is good.  I

could write one myself but I'd rather want description from the

real contributor.
  gmane = http://news.gmane.org/gmane.comp.version-control.git
-

Hi,
> > are http-push fixes from Gr

It's rather easy anyway:
First, you need a test git repository availlable over http+webdav, let's

say at http://myhost/myrepo.git/

Then, you do this:

$ git clone http://myhost/myrepo.git/

$ cd myrepo

$ git push http

Fetching remote heads...

  refs/

  refs/heads/

  refs/tags/

No refs in common and none specified; doing nothing.

$ git push http

Fetching remote heads...

  refs/

  refs/heads/

  refs/tags/

No refs in common and none specified; doing nothing.

$
Finally, you look at the web server logs, and will find one LOCK query

and no UNLOCK query, of course the second one will be in 423 return code

instead of 200:

1.2.3.4 - gb [19/Jan/2008:14:24:56 +0100] "LOCK /myrepo.git/info/refs

HTTP/1.1" 200 465

(...)

1.2.3.4 - gb [19/Jan/2008:14:25:10 +0100] "LOCK /myrepo.git/info/refs

HTTP/1.1" 423 363
With my patch, there would have be two UNLOCKs in addition of the LOCKs
 From the user point of view:

- If you realize that you should have typed e.g. "git push http master"

instead of "git push http", you will have to wait for 10 minutes for the

lock to expire by its own.

- Furthermore, if somebody else is dumb enough to type "git push http"

while you need to push "master" branch, then you'll need too to wait for 
I don't know what's wrong but I can't manage to reproduce the segfault,

I'm using the master branch on git.git plus my patches, and with CFLAGS

containing -DUSE_CURL_MULTI, nothing more nothing less.

Is the test case I described above is enough for you to make another test?

What kind of additional information would you need ?
I will resubmit this patch today with a more detailled commit message

including the way to reproduce the issue.

BTW you'll be interested to look at one of the "patches" I will repost

today, since it's related to this one (the patch subject is "http-push:

fail when info/refs exists and is already locked").
--

Grégoire Barbier - gb à gbarbier.org - +33 6 21 35 73 49
-

Hi,
On Sat, 19 Jan 2008, Gr

FWIW, I have a work in progress refactoring the http code, avoiding a

great amount of curl_easy_setopt()s and simplifying the whole thing.

It's been sitting on my hard drive during my (quite long) vacation. I

will probably start working again on this soonish.
Mike

-

Hi,
The segmentation fault occurs due to check_locks() accessing the remote

that was just free()d, due to the new change.
But now I cannot even reproduce the segmentation fault, it seems.

Strange.  Very strange.
Gr

Hi,
On Fri, 18 Jan 2008, Johannes Schindelin wrote:
> Gr

Here is an update to the list I sent earlier.  Topics that I

thought may deserve attention, discussion and eventual inclusion

but are not 1.5.4 material.
I think some of them actually have a slight chance of being

1.5.4 material, if interested parties present good enough

arguments that they are actually good and safe bugfixes.
 * compress/decompress abstraction (Marco)
 * crlf (Steffen Prohaska and Dmitry Potapov)
 * whitespace error: "cr at eol is ok" (me)
 * moving archive related helpers to libgit.a (Lars Hjemli)
 * marking output from "diff --{no,src,dst}-prefix" as a non-git

   diff (me)
 * submodule subcommand parser fix for "git submodule add init

   update" (Imran M Yousuf and me)
 * submodule recursive wrapper (Imran M Yousuf)
 * 'origin' is not so special after "clone -o frotz" (Mark Levedahl)
 * "submodule summary" (Ping Yin)
 * unconfigured ident safety (Stephen Sinclair)
 * gitweb feed from commit to commitdiff (Florian La Rouche --

   Jakub seems to be on top of this so I am not worried about it

   too much).
 * color.ui (Matthias Kestenholz)
 * test scripts to use valgrind (Jeff King)
 * various lstat(2) reduction changes (me).
 * "rebase -i" UI -- should it be simplified to do commit --amend

   itself? (Dscho)
 * "cherry-pick/revert" error message fix (Björn Steinbrink and me)
 * pathname safety on filesystems whose readdir(3) thinks it

   knows better than users (Linus, Robin Rosenberg, me and

   others).
Again, I am hoping that authors will resend the ones they really

care about after 1.5.4, as I do not want to take patches early.

-

I am working on an alternative to the patch I sent last week.

I hope I can present the two approaches soon.
The first approach is a lazy check in crlf_to_git() that warns

about an irreversible conversion; or dies if safecrlf=true.  This

is relatively simple code but at least for git-add a workaround

is needed to suppress printing a warning twice.  The runtime

overhead is negligible.
The second approach adds a new machinery is_worktree_crlfsafe()

that could be run independently of the crlf_to_git() conversion.

The code doing the conversion would stay unmodified.  The

advantage is that the whole work tree could be verified before

any conversion actually happens and we could die() after printing

all the warnings instead of printing only the first one.  The

drawback is that this approach most likely needs more code and

will introduce runtime overhead.  A straight forward

implementation would add another pass over the work tree running

the stats in convert.c.  So the stats would be run twice.

And for a simple "git add <file>" the situation is even worse:

the full work tree would be verified even is only a single file

is to be added.
I haven't found time during the week, so I'll continue to work

on this over the weekend.  Maybe even more time is needed to

discuss the two alternatives.
I do not expect that this topic will be ready for 1.5.4.
	Steffen
-

Hi,
What with our ongoing discussion when to go out of preview phase for

msysGit, I think this makes sense.
Ciao,

Dscho
-

Ok.  I'll start with cleaning up the first approach tomorrow and
I'll work on creating an improved installer that installs only a

subset of the commands.  I'll exclude commands that are not yet

ready for Windows (e.g.  git-svn, ...).
After we have the first version of this installer we can further

discuss if we leave the preview phase.
	Steffen

-

I have good enough arguments to NOT include it in 1.5.4: it's a

cleanup, so it's developer oriented, not user oriented, no

performance/feature benefit, no bug fix.
Please apply only after 1.5.4 is out.
Thanks

Marco

-

BTW I will resend the whole series this time without lines wrapping I

promise (I have learnt git send-mail in the mean time ;-)
Marco

-

What need IMHO to be changed is commit message: state stronger

that the only thing that changed is that feed entry refers now

to 'commitdiff' view rather than 'commit' view. I can agree that

it might be better... but I do not use gitweb feeds myself.
--

Jakub Narebski

Poland

ShadeHawk on #git

-

Yeah, I tend to agree.  I was waiting for an Ack or failure

report from Imran, as I turned the table around.

-

Sorry I forgot to mention it earlier, your patches worked fine :),
--

Imran M Yousuf

-

I read through the patch and it looks good.
I think the documentation should be slightly adjusted.  Patch follows

as a reply to this mail.
	Steffen

-

Only "status" accepts "--cached" and the preferred way of

passing sub-command specific options is after the sub-command.
The documentation is adapted to reflect this.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>

---

 Documentation/git-submodule.txt |    5 +++--

 1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt

index cffc6d4..e818e6e 100644

--- a/Documentation/git-submodule.txt

+++ b/Documentation/git-submodule.txt

@@ -9,8 +9,9 @@ git-submodule - Initialize, update or inspect submodules

 SYNOPSIS

 --------

 [verse]

-'git-submodule' [--quiet] [-b branch] add <repository> [<path>]

-'git-submodule' [--quiet] [--cached] [status|init|update] [--] [<path>...]

+'git-submodule' [--quiet] add [-b branch] [--] <repository> [<path>]

+'git-submodule' [--quiet] status [--cached] [--] [<path>...]

+'git-submodule' [--quiet] [init|update] [--] [<path>...]
 COMMANDS

--

1.5.4.rc4.3.g7c32b
-

Thanks.  That change makes sense to me.
-

Thanks.

-

BTW, how would you like to have a 40+ patch series presented that

implements the port to MinGW? Should I send to the ML despite its volume?

(Of course not before 1.5.4 is released.)
The current state of the series is available here:

http://repo.or.cz/w/git/mingw/j6t.git?a=shortlog;h=upstream
-- Hannes
-

Hi,
Comments from reading the patches briefly (since there are 42 patches, it

needs quite some time to even do it briefly):
- Possibly some of these commits could be folded back into

  f90524e(Add target architecture MinGW):
  96a27f1(MinGW: Implement gettimeofday()),

  2e05f891(Implement a rudimentary poll() emulation for Windows),

  142bda0(Fake implementions of getpwuid(), getuid(), and getpwnam() for

	  Windows),

  e799caf(Implement setitimer() and sigaction()),

  075fee7(Implement a wrapper of execve that can invoke shell scripts),

  495f0af(Work around misbehaved rename() on Windows),

  34cf7fd(Implement a pipe() replacement whose ends are not inherited to

	  children),

  4504323(Implement start_command() for Windows),

  b8e84a6(Implement a work-around for a misbehaved vsnprintf on Windows),

  08bbcb4(Windows: always chmod(, 0666) before unlink()),

  f6bbf12(Windows: Implement a wrapper of the open() function),

  56cedf3(Windows: Fix PRIuMAX definition),

  7458a97(Windows: Implement wrappers for gethostbyname(), socket(), and

	  connect()),

  ef25947(Windows: Fix ntohl() related warnings about printf formatting),

  b9db7ad(Windows: Implement a custom spawnve()), and

  47dacb3(compat/pread.c: Add foward decl to fix warning)
- 142bda0(Fake implementions of getpwuid(), getuid(), and getpwnam() for

	  Windows)

  does not really implement getuid() and getpwnam(), and does not "fake"

  the implementation of getpwuid() either, but has a minimal

  implementation of it (affecting the other two functions, of course).
- d6596ed(gitk: Disable msgfmt on MinGW) and

  004fb4b(Fix renaming .gitk-new to .gitk on Windows if there is already a

	  .gitk)

  are gitk patches.
  Further, I think that d6596ed would be better done as an automatic

  detection of msgfmt's presence; on my Eee PC, there is no msgfmt

  either...
- 20fd16e(Windows: Use a customized struct stat that also has the

	  st_blocks member) should be folded into

  6f97065(Add a new lstat and fstat i...
[ message continues ]

Hi,
IOW I think something like this:
-- snipsnap --

[PATCH] Fall back to po2msg when msgfmt is unavailable
At least on my Eee PC I do not have msgfmt.
This should be split into two patches, one for git-gui and one for gitk.

---

 git-gui/Makefile  |    6 ++++--

 gitk-git/Makefile |    7 +++++--

 2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/git-gui/Makefile b/git-gui/Makefile

index c109eab..c7921e7 100644

--- a/git-gui/Makefile

+++ b/git-gui/Makefile

@@ -193,8 +193,9 @@ $(GITGUI_MAIN): git-gui.sh GIT-VERSION-FILE GIT-GUI-VARS

 	mv $@+ $@
 XGETTEXT   ?= xgettext

+PO2MSG = $(TCL_PATH) po/po2msg.sh

 ifdef NO_MSGFMT

-	MSGFMT ?= $(TCL_PATH) po/po2msg.sh

+	MSGFMT ?= $(PO2MSG)

 else

 	MSGFMT ?= msgfmt

 endif

@@ -210,7 +211,8 @@ $(PO_TEMPLATE): $(SCRIPT_SH) $(ALL_LIBFILES)

 update-po:: $(PO_TEMPLATE)

 	$(foreach p, $(ALL_POFILES), echo Updating $p ; msgmerge -U $p $(PO_TEMPLATE) ; )

 $(ALL_MSGFILES): %.msg : %.po

-	$(QUIET_MSGFMT0)$(MSGFMT) --statistics --tcl -l $(basename $(notdir $<)) -d $(dir $@) $< $(QUIET_MSGFMT1)

+	$(QUIET_MSGFMT0)$(MSGFMT) --statistics --tcl -l $(basename $(notdir $<)) -d $(dir $@) $< $(QUIET_MSGFMT1) || \

+	$(QUIET_MSGFMT0)$(PO2MSG) --statistics --tcl -l $(basename $(notdir $<)) -d $(dir $@) $< $(QUIET_MSGFMT1)
 lib/tclIndex: $(ALL_LIBFILES) GIT-GUI-VARS

 	$(QUIET_INDEX)if echo \

diff --git a/gitk-git/Makefile b/gitk-git/Makefile

index ae2b80b..669ab0e 100644

--- a/gitk-git/Makefile

+++ b/gitk-git/Makefile

@@ -8,6 +8,7 @@ gitk_libdir   ?= $(sharedir)/gitk/lib

 msgsdir    ?= $(gitk_libdir)/msgs

 msgsdir_SQ  = $(subst ','\'',$(msgsdir))
+TCL_PATH ?= tclsh

 TCLTK_PATH ?= wish

 INSTALL ?= install

 RM ?= rm -f

@@ -18,8 +19,9 @@ TCLTK_PATH_SQ = $(subst ','\'',$(TCLTK_PATH))
 ## po-file creation rules

 XGETTEXT   ?= xgettext

+PO2MSG = $(TCL_PATH) po/po2msg.sh

 ifdef NO_MSGFMT

-	MSGFMT ?= $(TCL_PATH) po/po2msg.sh

+	MSGFMT ?= $(PO2MSG)

 else

 	MSGFMT ?= msgfmt

 endif

@@ -59,5 +61,6 @@ update-po::...
[ message continues ]

That will cause the QUIET_MSGFMT0 script to echo twice; once

when we try to run msgfmt and again when we fallback to po2msg.
That messes with the user's display and won't look very nice coming

out of a supposedly quiet make.
In other words this is probably better:
+	$(QUIET_MSGFMT0)($(MSGFMT) --statistics --tcl -l $(basename $(notdir $<)) -d $(dir $@) $< || \

+	$(PO2MSG) --statistics --tcl -l $(basename $(notdir $<)) -d $(dir $@) $< )$(QUIET_MSGFMT1)
But it is a lot uglier to read, and I tend to not like subshells.
--

Shawn.

-

Hi,
It was exactly this ugliness which made me not do it.
Note: There might be yet a better way.  Instead of trying each and every

time, we could detect the presence of msgfmt with something like this:
+ifeq $(shell msgfmt2 2>/dev/null >/dev/null; echo $?) = 127

+	MSGFMT = $(TCL_PATH) po/po2msg.sh

+endif
This is not tested, yet, tough,
Ciao,

Dscho
-

I like it.  I'm applying this diff (which I tested) to git-gui:
diff --git a/Makefile b/Makefile

index 1baf4b0..5f1023e 100644

--- a/Makefile

+++ b/Makefile

@@ -198,6 +198,9 @@ ifdef NO_MSGFMT

 	MSGFMT ?= $(TCL_PATH) po/po2msg.sh

 else

 	MSGFMT ?= msgfmt

+	ifeq ($(shell $(MSGFMT) >/dev/null 2>&1 || echo $$?),127)

+		MSGFMT := $(TCL_PATH) po/po2msg.sh

+	endif

 endif
 msgsdir     = $(gg_libdir)/msgs
--

Shawn.

-

Hi,
Thanks!
Paul, you might want to do something like that for gitk, too.  I imagine

that the diff even applies as-is...
Ciao,

Dscho
-

My gut feeling is that you did your usual great job separating

them into logical chunks and it will be a pleasure to review on
Let me take a look sometime (but I cannot even say when right

now).  I might change my mind about the above.

-

I have one or two patches that could be added, most notably

the gpg/CRLF patch.  Maybe we should discuss them before the

whole series is proposed for git.git?  Maybe not; then I'd

send my patches to the list after Junio applied your series.
	Steffen

-

Hi,
I think it is long enough as it is.  My plan is to look at the 40+

patches, and try to find a sensible subgrouping so that they can be sent

in bite-sized chunks.
Ciao,

Dscho
-

Here's a patch which might have been lost in the noise:
http://thread.gmane.org/gmane.comp.version-control.git/70463
--

larsh

-

Not really.  It came late into rc cycle without fixing any

breakage.  Not 1.5.4 material.

-

Hmm, isn't a nonfunctional libgit considered breakage? Without

something like this patch it is no longer possible to use

write_tar_archive()/write_zip_archive() in libgit.a.
--

larsh

-

Sorry, but libgit.a is not part of what we deliver.  We do not

support linking random stuff against libgit.a.  We never did.

It is not a "library".
It has always been just an implementation detail for us to be

lax about our Makefile, so that we do not have to write down

exactly which *.o files git-foo command depended upon (and it is

ceasing to be useful for that as very many things have moved to

"the single git binary" these days).  Instead we let the linker

pick out the necessary pieces out of the archive.
So, no, there is no breakage.
The code movement you did _should_ not hurt so it may be a fine

material for post 1.5.4, but I haven't carefully compared what

other change might have accidentally snuck in that patch, and I

would rather not have to during the rc cycle.
-

I kind of expected this reply, and I know libgit isn't supposed to be

a stable API aginst git internals, but it still feels like a

regression: cgit has been linking against libgit for over a year now

(initial snapshot support added feb 8, 2007), and git-1.5.4 looks like
Ok, I can't argue with that.
But could the patch then be part of 1.5.4.X or would I have to wait

for 1.5.5 since it's not considered to fix any breakage in 1.5.4? The

reason I'm asking is that cgit relies on offical git releases (or

rather, the tarballs published on kernel.org when a release is cut),

and it would be a shame if the 1.5.4-series becomes unusable for me

(there's always the possibility to link against a forked git, but I'd

rather not).
--

larsh

-

Hi,
So you did something that is unsupported, and now it breaks for you.
I'd almost say: you should have expected that.  HOWEVER, this makes you

the perfect guy to actually do something about libification (which has

been on my mind for some time, with the prospect of GitCheetah), and 
I have.  The 80 lines that were removed are _exactly_ the 80 lines that

were added (prepended with some #includes).
Like Lars said, the prototype of the only non-static function,

sha1_file_to_archive(), was in archive.h, which is included from

builtin-archive.c (where the big hunk was moved from), so there is no

possibility of a breakage there.
It is no _functional_ change, but if Lars _uses_ the function in cgit, I'd

say it would be a "courtesy fix" before 1.5.4.
Mind you, I would not propose to make libgit.a fully functional as a

standalone library before 1.5.4.
But Lars contributed a lot, and did a very good job of collecting git

patches back in October.  Therefore I think that he deserves a little

extra attention, even if it does not fix a bug in git proper.
Ciao,

Dscho
-

Yeah, it was bound to happen. The sad thing is that I didn't notice

earlier; I should probably add a test branch to cgit and run something

like this in a cron-job:
git checkout test && git fetch && git reset --hard origin/master &&

(cd git && git fetch && git reset --hard origin/master) &&

make clean &&

make test &&

git commit -a -m "Updated to latest git" &&

git push --force origin test
Thanks for the review and the kind words!
--

larsh

-

Hi,
My understanding was _always_ that the "-o" option was meant for the case

that you want to clone from somewhere else than where you want to pull 
Yes, that was written in Perl by Christian Couder:
http://article.gmane.org/gmane.comp.version-control.git/69236
Peff's version does not need Perl, and is better integrated with the

testsuite (via the new option -m).  Christian's version parses the output,

and might therefore be nicer to look at.
However, I think that both versions do not account for scripts, and I

imagine that going through Git.pm and git-sh-setup is necessary for that.
Also, it might be a good idea to be able to provide extra arguments, such

as "--attach-db=yes".
Post 1.5.4, definitely.
Ciao,

Dscho

-

I don't think parsing is necessary. Christian's version counts the

errors, whereas I just barf if valgrind has mentioned any errors. And

using the '-q' output of valgrind means the output is fairly cleaned up.
But of course the main difference is that I tried to integrate into the
Both versions use the 'alias' approach. A more comprehensive approach

would be something like:
  mkdir wrapper-bin

  cat >wrapper-bin/git <<EOF

  ...

  EOF

  chmod 755 wrapper-bin/git

  for i in $GIT_PROGRAMS; do

    ln -s git wrapper-bin/git-$i

  done

  PATH=$PWD/wrapper-bin:$PATH
which should get all git calls (though we should probably not wrap

"git-foo" if git-foo is a script (or we should convert it to "git
Yes. I suspect some people will need to add custom suppression files
Agreed.
-Peff

-

Thanks for your update on this.  I agree with your opinion,

although I'd prefer to have the safecrlf option soon.
Without safecrlf I'll not enable core.autocrlf=true in msysgit.

Now that I see a reasonable way of having at least a warning

about potential data corruption when core.autocrlf=true, I'm

even stronger against enabling it without a safety valve.
As I pointed out in the recent CRLF discussion, I believe the

problem is not specific to Windows but is about a reasonable

default configuration for cross-platform projects.  CRLF

conversion must be enabled on all platforms to have good defaults

for a mixed Unix/Windows environment, and hence the safecrlf if

also needed on all platforms.
So I don't see much value in having the safecrlf only in msysgit

and not in official git.
Junio,

Do you see a chance to have safecrlf in 1.5.4.1?
I am currently considering wether it is worth following the maint

series of official git with msysgit.  That is we'd have a maint

branch in msysgit, which would merge from Junio's maint.

Although we're still in preview mode with msysgit I tend to

believe that this would be a good idea.
The preview tag is mostly due to the unspecified set of features

of msysgit, not that I think part of msysgit is not already very

stable and usable.  But msysgit only supports a subset of the

commands of official git and we don't really say or even know

which commands currently work reliably.  It could be worth to

compile such a list and only install the commands that we are

convinced of being ready for production.
	Steffen

-

By definition of 'maint', 1.5.4.X are to fix bugs in the

features that are in 1.5.4, so the answer is no.
But we could end up having a short cycle for 1.5.5 if we agree

that the lack of crlf=safe is a severe bug that is worth fixing

post 1.5.4.
Currently I am not convinced that the lack of crlf=safe is a

severe and urgent bug worth "fixing" for 1.5.4.  I see it as a

new feature, a different variant of crlf behaviour we will be

introducing for audience who are not satisfied with existing the

crlf variants.

-

Hopefully, the cycle for 1.5.5 will be a bit shorter than 1.5.4, because

1.5.4 seems to have the longest development cycle of all versions, and

it already contains almost as much changes as three previous versions

("git diff v1.5.3 master" is almost as big as "git diff v1.5.0 v1.5.3").
Dmitry

-

hehe, though we still do not have Megabytes of changes between two RCs

yet ;)
--=20

=C2=B7O=C2=B7  Pierre Habouzit

=C2=B7=C2=B7O                                                madcoder@debia=

n.org

OOO                                                http://www.madism.org

So I should try harder to find better arguments.  But this has

time until the 1.5.4 release is out.  For now, I am being quiet.
(Well, I'll continue to improve the safecrlf patch and most

likely will send it to the list, too.  But I don't expect to find

it anywhere in your repo before 1.5.4.)
	Steffen

-

Instead, you could be louder and convince people that it is a

severe bug worth fixing before 1.5.4, like Linus did with the

issue with performance regression on a partial commit.  It's
Please do.  "I am currently not convinced" does not mean "I am

always right" nor "I won't reconsider".
-

Carrying the above forward...  Assume I have a checked out project as

above, then in top-level master project I do:
git remote add zoo git://zoo.tar.fu hisfork.git

git fetch zoo

git checkout --track -b fork zoo/fork

git submodule update
I claim the submodule machinery *should* now follow master's default

remote, which is "zoo", for the current branch. In addition, the

submodule machinery should define remote "zoo" in each submodule  where

it does not already exist, using the same logic using in the original

init/update phase. This should only apply to modules defined using

relative urls.
Basically, this formalizes the notion that:
* submodules defined using relative urls are "owned" by the master

project and will exist anywhere the master does.

* submodules defined using absolute urls are incorporated into the

project but are separately managed. (While some improved mechanism to

automate their management from top-level may be proposed, it is not

obvious to me nor addressed here.)
The subsequent patch modifies git-submodule to implement this logic, and

applies on top of my previous series.
(Note: I cannot find my latest series in the git-archives on gmane nor

on marc.info, both have only part, and I am suspicious that something

went wrong in my sending via gmail, so I am resending the series here,

now five patches long. Please excuse if this is redundant).
Mark
-

This introduces a new configuration variable, core.origin, that

defines the name of the default remote to be used. Traditionally, this

is "origin", and could be overridden for a given branch. This change

introduces a way to redefine the default as desired and have that honored

regardless of the currently checked out head (e.g., core.origin is

used when on a detached head or any other non-tracking branch).
Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>

---

 Documentation/config.txt |    6 ++++++

 git-parse-remote.sh      |    5 +++--

 remote.c                 |   11 ++++++++++-

 3 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt

index df091d1..b7241cf 100644

--- a/Documentation/config.txt

+++ b/Documentation/config.txt

@@ -291,6 +291,12 @@ core.editor::

 	`GIT_EDITOR` environment, `core.editor`, `VISUAL` and

 	`EDITOR` environment variables and then finally `vi`.
+core.origin::

+	The name of the remote used by default for fetch / pull. If unset,

+	origin is assumed. This value is used whenever the current branch

+	has no corresponding branch.<name>.remote, such as when working on

+	a detached head.

+

 core.pager::

 	The command that git will use to paginate output.  Can be overridden

 	with the `GIT_PAGER` environment variable.

diff --git a/git-parse-remote.sh b/git-parse-remote.sh

index 695a409..c7ac7c7 100755

--- a/git-parse-remote.sh

+++ b/git-parse-remote.sh

@@ -56,8 +56,9 @@ get_remote_url () {
 get_default_remote () {

 	curr_branch=$(git symbolic-ref -q HEAD | sed -e 's|^refs/heads/||')

-	origin=$(git config --get "branch.$curr_branch.remote")

-	echo ${origin:-origin}

+	git config --get "branch.$curr_branch.remote" ||

+	git config --get "core.origin" ||

+	echo origin

 }
 get_remote_default_refs_for_push () {

diff --git a/remote.c b/remote.c

index 0e00680..302d499 100644

--- a/remote.c

+++ b/remote.c

@@ -10,6 +10,7 @@ static int allocated_branches;
 static struct branc...
[ message continues ]

Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>

---

 git-remote.perl |    5 +++++

 1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/git-remote.perl b/git-remote.perl

index d13e4c1..75d2371 100755

--- a/git-remote.perl

+++ b/git-remote.perl

@@ -328,6 +328,11 @@ sub rm_remote {
 	$git->command('config', '--remove-section', "remote.$name");
+	my $defremote = $git->config("core.origin");

+	if (defined $defremote && $defremote eq $name) {

+	       $git->command("config", "--unset", "core.origin");

+	}

+

 	eval {

 	    my @trackers = $git->command('config', '--get-regexp',

 			'branch.*.remote', $name);

--

1.5.4.rc3.14.gc50f
-

I'm not sure I see the use case that this helps. Presumably you are

doing one of (assuming your core.origin is 'foo'):
  - delete 'foo', and then proceed with usual git commands. In this

    case, your core.origin has reverted to 'origin', but what is the

    chance that you actually have such a remote (since you presumably

    cloned with -o foo)?
  - delete 'foo', then re-add 'foo'. I would expect this to be

    equivalent to editing the config, but as a side effect, your

    core.origin has mysteriously changed.
  - delete 'foo', then re-add 'bar' with the intent of making it your

    new origin. This doesn't help at all, since there's nothing

    automatically setting core.origin to 'bar', so you might as well

    leave it as the bogus 'foo' rather than the bogus 'origin'. And to

    help this use case, something like a "-d" flag to git-remote to set

    the new origin as the default might make sense. I.e.,
      git remote rm foo

      git remote add -d bar git://bar/project.git
    Alternatively, when adding a remote, if it is the _only_ remote (or

    perhaps if the current core.origin doesn't exist), we could set

    core.origin which would automagically cover the latter two cases.

    Although it feels a little too DWIM.
-Peff

-

Just being thorough: the man page claims that "git remote rm foo"

I suspect anything done in this case is going to suffer from DWIM-itis

in some conditions. I can't offer a better argument than the one above.
Mark

-

I was going to respond "by that rationale, 'git remote rm' should be

removing branch.*.remote keys that point to the removed remote". But

looking at the code, it already does that. So your change actually keeps

things consistent.
Not the choice I would have made, but I guess it just goes to show that

I use "vi" instead of "git remote". Consider my objection withdrawn.
-Peff

-

This records the users choice of default remote name (by default "origin")

as given by the -o option.
Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>

---

 Documentation/git-clone.txt |    3 ++-

 git-clone.sh                |    1 +

 2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt

index fdccbd4..6c15fa4 100644

--- a/Documentation/git-clone.txt

+++ b/Documentation/git-clone.txt

@@ -95,7 +95,8 @@ OPTIONS

 --origin <name>::

 -o <name>::

 	Instead of using the remote name 'origin' to keep track

-	of the upstream repository, use <name> instead.

+	of the upstream repository, use <name> instead. The name

+	is recorded in the core.origin config variable.
 --upload-pack <upload-pack>::

 -u <upload-pack>::

diff --git a/git-clone.sh b/git-clone.sh

index b4e858c..7208d68 100755

--- a/git-clone.sh

+++ b/git-clone.sh

@@ -242,6 +242,7 @@ fi &&

 export GIT_DIR &&

 GIT_CONFIG="$GIT_DIR/config" git-init $quiet ${template+"$template"} || usage
+git config core.origin $origin

 if test -n "$bare"

 then

 	GIT_CONFIG="$GIT_DIR/config" git config core.bare true

--

1.5.4.rc3.14.gc50f
-

For submodules defined relative to their parent, it is likely that the

parent's defined default remote is correct for the child as well. This

allows use of remote names other than "origin", important as managed

submodules are typically checked out on a detached head and therefore

submodule-update invokes git-fetch using the default remote. Without this

change, submodules effectively had to have a default remote of "origin."
Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>

---

 Documentation/git-submodule.txt |    8 +++++---

 git-submodule.sh                |   19 +++++++++++++------

 2 files changed, 18 insertions(+), 9 deletions(-)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt

index cffc6d4..440e234 100644

--- a/Documentation/git-submodule.txt

+++ b/Documentation/git-submodule.txt

@@ -36,9 +36,11 @@ status::
 init::

 	Initialize the submodules, i.e. register in .git/config each submodule

-	name and url found in .gitmodules. The key used in .git/config is

-	`submodule.$name.url`. This command does not alter existing information

-	in .git/config.

+	name and url found in .gitmodules, along with the default remote origin.

+	For submodules using a relative url, the default remote is inherited

+	from the parent project, for absolute urls the default "origin" is used.

+	The key used in .git/config is submodule.$name.url`. This command does

+	not alter existing information in .git/config.
 update::

 	Update the registered submodules, i.e. clone missing submodules and

diff --git a/git-submodule.sh b/git-submodule.sh

index ad9fe62..42be4b9 100755

--- a/git-submodule.sh

+++ b/git-submodule.sh

@@ -7,6 +7,7 @@

 USAGE='[--quiet] [--cached] [add <repo> [-b branch]|status|init|update] [--] [<path>...]'

 OPTIONS_SPEC=

 . git-sh-setup

+. git-parse-remote

 require_work_tree
 add=

@@ -43,9 +44,7 @@ get_repo_base() {

 # Resolve relative url by appending to parent's url

 resolve_relative_url ()

 {

-	branch="$(git symbolic-ref ...
[ message continues ]

Modules that are defined using relative urls to the master project are

assumed to be completely owned by the project. When running

"submodule update" from the top level, it is reasonable that the entire

project exists at the current master's remote. Using the

branch.$name.remote machinery, this remote can be different for each

branch and can be different than the current defaults in each submodule.
This teaches submodule to:
1) Possibly define the current master's remote in each submodule, using

the same relative url used by submodule init.

2) Fetch each submodule's updates from the master's remote.
Submodules defined using absolute urls (not relative to the parent) are

not touched by this logic. These modules are assumed to be independent

of the master project so submodule can do no better than to fetch from

their currently defined default remotes as already done.
Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>

---

 git-submodule.sh |   20 +++++++++++++++++++-

 1 files changed, 19 insertions(+), 1 deletions(-)
diff --git a/git-submodule.sh b/git-submodule.sh

index 42be4b9..5b4b16f 100755

--- a/git-submodule.sh

+++ b/git-submodule.sh

@@ -209,11 +209,14 @@ modules_init()
 #

 # Update each submodule path to correct revision, using clone and checkout as needed

+# For owned submodules (defined using relative url), we use master project's remote

+# and define that in each submodule if not already there

 #

 # $@ = requested paths (default to all)

 #

 modules_update()

 {

+	master_remote=$(get_default_remote)

 	git ls-files --stage -- "$@" | grep -e '^160000 ' |

 	while read mode sha1 stage path

 	do

@@ -240,9 +243,24 @@ modules_update()

 			die "Unable to find current revision in submodule path '$path'"

 		fi
+		baseurl="$(GIT_CONFIG=.gitmodules git config submodule."$name".url)"

+		case "$baseurl" in

+		./*|../*)

+			fetch_remote=$master_remote

+			(unset GIT_DIR ; cd "$path" && git config remote."$fetch_remote".url > nul) ||

+			(

+				...
[ message continues ]