Re: Textconv

[Michael J Gruber]

Dmitry Ilin venit, vidit, dixit 11.03.2013 12:30:
> I tried this command and I got following result:
> 
> trace: built-in: git 'show' 'a1bffde'
> trace: run_command: 'openssl enc -d -base64 -aes-256-ecb -k 
> '\''abcde'\'' 2> /dev/null || cat'
> trace: exec: 'sh' '-c' 'openssl enc -d -base64 -aes-256-ecb -k 
> '\''abcde'\'' 2> /dev/null || cat' 'openssl enc -d -base64 -aes-256-ecb 
> -k '\''abcde'\'' 2> /dev/null || cat'
> trace: run_command: 'openssl enc -d -base64 -aes-256-ecb -k 
> '\''abcde'\'' -in $1 2> /dev/null || cat $1' '/tmp/CLPGPk_config.js'
> trace: exec: 'sh' '-c' 'openssl enc -d -base64 -aes-256-ecb -k 
> '\''abcde'\'' -in $1 2> /dev/null || cat $1 "$@"' 'openssl enc -d 
> -base64 -aes-256-ecb -k '\''abcde'\'' -in $1 2> /dev/null || cat $1' 
> '/tmp/CLPGPk_config.js'
> trace: run_command: 'openssl enc -d -base64 -aes-256-ecb -k 
> '\''abcde'\'' 2> /dev/null || cat'
> trace: exec: 'sh' '-c' 'openssl enc -d -base64 -aes-256-ecb -k 
> '\''abcde'\'' 2> /dev/null || cat' 'openssl enc -d -base64 -aes-256-ecb 
> -k '\''abcde'\'' 2> /dev/null || cat'
> trace: run_command: 'openssl enc -d -base64 -aes-256-ecb -k 
> '\''abcde'\'' -in $1 2> /dev/null || cat $1' '/tmp/Uyc2Dj_config.js'
> trace: exec: 'sh' '-c' 'openssl enc -d -base64 -aes-256-ecb -k 
> '\''abcde'\'' -in $1 2> /dev/null || cat $1 "$@"' 'openssl enc -d 
> -base64 -aes-256-ecb -k '\''abcde'\'' -in $1 2> /dev/null || cat $1' 
> '/tmp/Uyc2Dj_config.js'
> diff --git a/path/config.js b/path/config.js
> index c4ad2d4..a67d13f 100644
> --- a/path/config.js
> +++ b/path/config.js
> 
> 
> And also not encrypted data of my commit.
> 
> 
> On 03/11/2013 02:41 PM, Matthieu Moy wrote:
>> Dmitry Ilin  writes:
>>
>>> I mean that our filter doesn't work with 'git show' and I need to
>>> enable it for this command.
>>>
>>> This is part of my git config file:
>>>
>>> [filter "openssl"]
>>> smudge = openssl enc -d -base64 -aes-256-ecb -k 'abcde' 2>
>>> /dev/null || cat
>>> clean = openssl enc -base64 -aes-256-ecb -S '12345' -k 'abcde'
>>> [diff "openssl"]
>>> textconv = openssl enc -d -base64 -aes-256-ecb -k 'abcde' -in "$1"
>>> 2> /dev/null || cat "$1"
>>> [merge]
>>> renormalize = true
>> Maybe a bad interaction between the [filter ...] section and the
>> [textconv ...] one. Can you run:
>>
>> GIT_TRACE=true git show 
>>
>> to see what's going on?
>>
> 

"git show commit" uses textconv by default for the patch, but "git show
blob" does not. There's a series on the list which deals with textconv
for "grep" and "show blob", but I haven't had the time to polish it up.
I don't think it's cooking in pu yet, but I've been running with it
since. "running git with it", that is, not "running away with it" ;)

Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] help: show manpage for aliased command on git --help

[Michael J Gruber]

Jeff King venit, vidit, dixit 05.03.2013 18:38:
> On Tue, Mar 05, 2013 at 02:44:41PM +, Ævar Arnfjörð Bjarmason wrote:
> 
>> Change the semantics of "git  --help" to show the help for the
>> command  is aliased to, instead of just saying:
>>
>> `git ' is aliased to `'
>>
>> E.g. if you have "checkout" aliased to "co" you won't get:
>>
>> $ git co --help
>> `git co' is aliased to `checkout'
>>
>> But will instead get the manpage for git-checkout. The behavior this
>> is replacing was originally added by Jeff King in 2156435. I'm
>> changing it because of this off-the-cuff comment on IRC:
>>
>> 14:27:43 <@Tux> git can be very unhelpful, literally:
>> 14:27:46 <@Tux> $ git co --help
>> 14:27:46 <@Tux> `git co' is aliased to `checkout'
>> 14:28:08 <@Tux> I know!, gimme the help for checkout, please
>>
>> And because I also think it makes more sense than showing you what the
>> thing is aliased to.
> 
> In this simple case, I think it is helpful to show the "checkout"
> manpage, because there is no other information to give (and by showing
> the checkout manpage, you implicitly indicate that "co" maps to
> "checkout").

Well, even in the simple case one has to wonder: Why does the user
invoke help for "co"? There are two very likely cases:

A) User does not remember what "co" is aliased to.
B) User wants to see the man page.

If A is not the case then it's easy for the user to request help for
"checkout" (or "commit" or ...).

Removing the only easy way to look up the definition of an alias is a
major regression. And no, "git config --get alias.co" is not an easy way.

Removing that easy way would be OK only after introducing a "git alias"
command which works similar to shell's alias. You can even set it up as
an alias for git config, of course.

> But like others, I am concerned about the other cases, where there is no
> manpage, it is not a git command with a manpage, or it is a git command
> with options.  You are losing useful information that is currently given
> to the user in all but the single-word case.
> 
> In an ideal world, we could say "here is how the alias expands, and by
> the way, here is the manpage for the expanded command". And obviously
> just omit the latter part when there is no such page. But we are relying
> on external programs to do the presentation and paging. Doing the
> C equivalent of:
> 
>   echo "'git co' is aliased to 'checkout'" &&
>   man checkout
> 
> does not quite work, because "man" will start a pager. We can run our
> own pager (which should suppress man's invocation), but that is a
> regression for anyone who uses MANPAGER.
> 
> The user may also be using help.format to use something besides man. If
> help.format is set to "html", we will spawn a browser. In that case we
> can still output the alias information, but it may or may not be seen
> (though come to think of it, that is probably already a problem for "git
> help " on Windows systems, or anybody invoking git help from a
> GUI porcelain).
> 
> So I'd only be in favor of this patch if it managed to avoid information
> loss in the more complicated cases. And I'm not sure how best to do
> that. The "only trigger for a single-word alias" suggestion seems like
> the least ugly to me.
> 
> -Peff
> 

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Ignore version update changes on git show report?

[Michael J Gruber]

Preben Liland Madsen venit, vidit, dixit 26.02.2013 20:53:
> Hello, 
> 
> I'm trying to investigate some what changes have been done between two 
> versions of a software with the name IP.Board. 
> 
> This proves more troublesome than I thought, since their release builder 
> appearantly updates the version number automatically in all files. 
> 
> This causes a lot of files to have this as the only change: 
> 
> - * IP.Board v3.4.2
> + * IP.Board v3.4.3
> 
> Which is quite annoying to have to go through and therefor is responsible for 
> more than 800 files being changed. 
> 
> Is there some sort of git command or command I can combine together with git 
> show that will ignore files with only these changes? Something along the 
> lines of ignoring files where the only change matches this change or ignore 
> files that've only gotten 1 line removed and 1 line added? 
> 
> Best regards, Preben--
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

First of all, there is

git beat-with-stick

that you should apply to those responsible for that mess ;)

If you have to deal with that sort of situation then a textconv filter
might get you as close as possible. Use "grep -v '^\* IP.Board v*'" as a
textconv filter for those files, and those changes will disappear from
the diff. (I do something like that for tracking my gitk config, which
stores last window sizes.)

Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: clean/smudge filters on .zip/.tgz files

[Michael J Gruber]

Johannes Sixt venit, vidit, dixit 27.02.2013 07:39:
> Am 2/26/2013 23:38, schrieb Tim Chase:
>> Various programs that I use ([Open|Libre]Office, Vym, etc) use a
>> zipped/.tgz'ed file format, usually containing multiple
>> (usually) plain-text files within.
>>
>> I'm trying to figure out a way for git to treat these as virtual
>> directories for purposes of merging/diffing.  
>>
>> Reading up on clean/smudge filters, it looks like they expect one
>> file coming in and one file going out, rather than one file
>> on one side and a directory-tree of files on the other side.
>>
>> I tried creating my own pair of clean/smudge filters that would
>> uncompress the files, but there's no good way put multiple files on
>> stdout.
>>
>> Has anybody else played with such a scheme for uncompressing files as
>> they go into git and recompressing them as they come back out?
> 
> I attempted to do something like this for OpenDocument files (I didn't get
> very far) until I discovered that LibreOffice can save "flat open document
> files". That combined with the option "save files optimized" switched off
> results in fairly readable XML in a single file that can even be merged
> under some circumstances.
> 
> You would still need a clean filter that normalizes the style numbers,
> cross reference marks and other stuff that changes each time LibreOffice
> saves the file.
> 
> -- Hannes
> 

In general, using "zip -0" is a good way of getting something that
delta-compresses well and that can give a meaningful diff (and has no
information loss).

The (my) problem is that recompressing a zip archive (i.e. multi-file)
is a pita, you can't just use a pipe "unzip | zip -0". You'd have to do
that in a temp dir.

Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RFD: concatening textconv filters

[Michael J Gruber]

During my day-to-day UGFWIINIT I noticed that we don't do textconv
iteratively. E.g.: I have a file

SuperSecretButDumbFormat.pdf.gpg

and textconv filters with attributes set for *.gpg and *.pdf (using
"gpg" resp. "pdftotext"). For Git, the file has only the "gpg"
attribute, of course. In this case, I would have wanted to pass the gpg
output through pdftotext.

Now, I can set up an extra filter "gpgtopdftotext" for *.pdf.gpg (hoping
I get the ordering in .gitattributes right), of course, but wondering
whether we could and should support concatenating filters by either

- making it easy to request it (say by setting
"filter.gpgtopdftotext.textconvpipe" to a list of textconv filter names
which are to be applied in sequence)

or

- doing it automatically (remove the pattern which triggered the filter,
and apply attributes again to the resulting pathspec)

Maybe it's just not worth the effort. Or a nice GSoC project ;)

Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Git Merge 2013 Conference, Berlin

[Michael J Gruber]

Junio C Hamano venit, vidit, dixit 20.02.2013 00:47:
> Scott Chacon  writes:
> 
>> Junio, are you interested in attending?
> 
> I am interested in meeting our European contributors, but Berlin is
> kind of very far, so give me a few days to think about it.
> 
> Thanks.
>

Maybe, we can - for the next time - try to coordinate the date with the
various international IT conferences which take place here, like
Linux-Tag in Berlin (just a few weeks apart), CEBIT in Hannover or the
smaller Chemnitzer Linux-Tage (or coordinate with events somewhere else
in Europe). That would give contributors not only more incentive to come
to the Git event, but also a better chance for successful negotiations
with their employers. Extending a business trip by a few days is a minor
issue, granting one in the first place not always.

Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Git Merge 2013 Conference, Berlin

[Michael J Gruber]

Michael J Gruber venit, vidit, dixit 19.02.2013 16:20:
> Scott Chacon venit, vidit, dixit 18.02.2013 22:29:
>> Right now we have:
>>
>> Dev day: 50
>> User day: 295
>> Hack day: 200
>>
>> I'm not sure what the actual turnout will be, but it looks like it's
>> going to be pretty massive.  I wanted to go through the Dev day
>> signups and figure out if everyone really belongs there (is an actual
>> contributor to a core git project) but it's basically on the honor
>> system now.
>>
>> If anyone on this list that should be there (Junio, Shawn, etc) wants
>> to attend and would like sponsorship for the flight/lodging, please
>> let me know.  We would love to have as many of the core people there
>> as possible.  I will also try to record everything and summarize as
>> much as I can after the fact, so if you can't attend it should still
>> be possible to get the general idea of what occurred and was
>> discussed.
>>
>> I'm going to try doing something similar in the SF area in maybe 6-8
>> months from this, assuming it's a success.
>>
>> Scott
>>
>> On Mon, Feb 18, 2013 at 1:17 PM, Jeff King  wrote:
>>> On Mon, Feb 18, 2013 at 09:52:34PM +0100, Thomas Rast wrote:
>>>
>>>> Scott Chacon  writes:
>>>>
>>>>> We're starting off in Berlin, May 9-11th.  GitHub has secured
>>>>> conference space at the Radisson Blu Berlin for those days.  I have a
>>>>> smaller room for the first day so we can get 30-40 Git implementors
>>>>> together to talk about the future of Git and whatnot.
>>>> [...]
>>>>> http://git-merge.com/
>>>>
>>>> So this has been fairly quiet -- is anyone else coming? :-)
>>>
>>> I am. I think Scott may have actual numbers, but my third-hand
>>> impression was that there have been a lot of signups.
>>>
>>> -Peff
> 
> Well, all days are listed as "sold out" on the eventbrite site. Maybe
> it's because eventbrite has "trouble connecting to facebook" because I
> "don't have facebook"?
> 
> I do plan to come (unless I'm out due to lack of an eventbrite ticket)
> but will stay with family rather than at the Radisson Blu.
> 
> Michael
> 

BTW: Is it OK to add that event as an "event" on our Git community page?
Just wanted to ask Scott and Junio before doing it myself.

Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Git Merge 2013 Conference, Berlin

[Michael J Gruber]

Scott Chacon venit, vidit, dixit 18.02.2013 22:29:
> Right now we have:
> 
> Dev day: 50
> User day: 295
> Hack day: 200
> 
> I'm not sure what the actual turnout will be, but it looks like it's
> going to be pretty massive.  I wanted to go through the Dev day
> signups and figure out if everyone really belongs there (is an actual
> contributor to a core git project) but it's basically on the honor
> system now.
> 
> If anyone on this list that should be there (Junio, Shawn, etc) wants
> to attend and would like sponsorship for the flight/lodging, please
> let me know.  We would love to have as many of the core people there
> as possible.  I will also try to record everything and summarize as
> much as I can after the fact, so if you can't attend it should still
> be possible to get the general idea of what occurred and was
> discussed.
> 
> I'm going to try doing something similar in the SF area in maybe 6-8
> months from this, assuming it's a success.
> 
> Scott
> 
> On Mon, Feb 18, 2013 at 1:17 PM, Jeff King  wrote:
>> On Mon, Feb 18, 2013 at 09:52:34PM +0100, Thomas Rast wrote:
>>
>>> Scott Chacon  writes:
>>>
 We're starting off in Berlin, May 9-11th.  GitHub has secured
 conference space at the Radisson Blu Berlin for those days.  I have a
 smaller room for the first day so we can get 30-40 Git implementors
 together to talk about the future of Git and whatnot.
>>> [...]
 http://git-merge.com/
>>>
>>> So this has been fairly quiet -- is anyone else coming? :-)
>>
>> I am. I think Scott may have actual numbers, but my third-hand
>> impression was that there have been a lot of signups.
>>
>> -Peff

Well, all days are listed as "sold out" on the eventbrite site. Maybe
it's because eventbrite has "trouble connecting to facebook" because I
"don't have facebook"?

I do plan to come (unless I'm out due to lack of an eventbrite ticket)
but will stay with family rather than at the Radisson Blu.

Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] l10n: de.po: translate 35 new messages

[Michael J Gruber]

Ralf Thielow venit, vidit, dixit 18.02.2013 19:22:
> Translate 35 new messages came from git.pot update
> in 9caaf23 (l10n: Update git.pot (35 new, 14 removed
> messages)).
> 
> Signed-off-by: Ralf Thielow 
> ---
>  po/de.po | 140 
> +++
>  1 file changed, 68 insertions(+), 72 deletions(-)
> 
> diff --git a/po/de.po b/po/de.po
> index df98a0f..9690cd7 100644
> --- a/po/de.po
> +++ b/po/de.po
> @@ -358,14 +358,14 @@ msgid "gpg failed to sign the data"
>  msgstr "gpg beim Signieren der Daten fehlgeschlagen"
>  
>  #: gpg-interface.c:112
> -#, fuzzy, c-format
> +#, c-format
>  msgid "could not create temporary file '%s': %s"
> -msgstr "konnte Datei '%s' nicht erstellen"
> +msgstr "konnte temporäre Datei '%s' nicht erstellen: %s"
>  
>  #: gpg-interface.c:115
> -#, fuzzy, c-format
> +#, c-format
>  msgid "failed writing detached signature to '%s': %s"
> -msgstr "Fehler beim Erstellen des Pfades '%s'%s"
> +msgstr "Fehler beim Schreiben der Signatur nach '%s': %s"
>  
>  #: grep.c:1622
>  #, c-format
> @@ -1443,9 +1443,8 @@ msgid "failed to unlink '%s'"
>  msgstr "Konnte '%s' nicht entfernen"

Maybe a "." at the end, or begin with lower case.

>  #: builtin/add.c:20
> -#, fuzzy
>  msgid "git add [options] [--] ..."
> -msgstr "git add [Optionen] [--] [...]"
> +msgstr "git add [Optionen] [--] [...]"
>  
>  #: builtin/add.c:63
>  #, c-format
> @@ -1601,6 +1600,21 @@ msgid ""
>  "With the current Git version, the command is restricted to the current "
>  "directory."
>  msgstr ""
> +"Das Verhalten von 'git add %s (oder %s)' ohne ein Pfad-Argument von\n"
> +"einem Unterverzeichnis aus, wird in Git 2.0 geändert und sollte nicht\n"

There should be no "," here because there is no subclause.

> +"mehr verwendet werden.\n"
> +"Um Dateien des gesamten Projektverzeichnisses hinzuzufügen, führen Sie 
> aus:\n"

There can be a comma here, it is a (shortened subclause).

> +"\n"
> +"  git add %s :/\n"
> +"  (oder git add %s :/)\n"
> +"\n"
> +"Zur Einschränkung auf das aktuelle Verzeichnis, führen Sie aus:\n"

There should be no "," here because there is no subclause.

Rest looks fine (Thomas mentioned the missed "rename" already).

> +"\n"
> +"  git add %s .\n"
> +"  (oder git add %s .)\n"
> +"\n"
> +"Mit der aktuellen Version von Git ist das Kommando auf das aktuelle\n"
> +"Verzeichnis beschränkt."
>  
>  #: builtin/add.c:381
>  msgid "-A and -u are mutually incompatible"
> @@ -2412,16 +2426,16 @@ msgstr "[%d voraus, %d hinterher]"
>  
>  #: builtin/branch.c:469
>  msgid "  invalid ref "
> -msgstr ""
> +msgstr "  ungültige Referenz "
>  
>  #: builtin/branch.c:560
>  msgid "(no branch)"
>  msgstr "(kein Zweig)"
>  
>  #: builtin/branch.c:593
> -#, fuzzy, c-format
> +#, c-format
>  msgid "object '%s' does not point to a commit"
> -msgstr "'%s' zeigt auf keine Version"
> +msgstr "Objekt '%s' zeigt auf keine Version"
>  
>  #: builtin/branch.c:625
>  msgid "some refs could not be read"
> @@ -2571,33 +2585,30 @@ msgid "--column and --verbose are incompatible"
>  msgstr "Die Optionen --column und --verbose sind inkompatibel."
>  
>  #: builtin/branch.c:845
> -#, fuzzy
>  msgid "branch name required"
> -msgstr "Kein Zweigname spezifiziert"
> +msgstr "Zweigname erforderlich"
>  
>  #: builtin/branch.c:860
> -#, fuzzy
>  msgid "Cannot give description to detached HEAD"
> -msgstr "Kann Hauptzweig des externen Projektarchivs nicht bestimmen"
> +msgstr "zu losgelöster Zweigspitze (HEAD) kann keine Beschreibung hinterlegt 
> werden"
>  
>  #: builtin/branch.c:865
> -#, fuzzy
>  msgid "cannot edit description of more than one branch"
> -msgstr "bearbeitet die Beschreibung für den Zweig"
> +msgstr "Beschreibung von mehr als einem Zweig kann nicht bearbeitet werden"
>  
>  #: builtin/branch.c:872
> -#, fuzzy, c-format
> +#, c-format
>  msgid "No commit on branch '%s' yet."
> -msgstr "Kein solcher Zweig '%s'"
> +msgstr "Noch keine Version in Zweig '%s'."
>  
>  #: builtin/branch.c:875
> -#, fuzzy, c-format
> +#, c-format
>  msgid "No branch named '%s'."
> -msgstr "Ungültiger Zweig-Name: '%s'"
> +msgstr "Zweig '%s' nicht vorhanden."
>  
>  #: builtin/branch.c:888
>  msgid "too many branches for a rename operation"
> -msgstr ""
> +msgstr "zu viele Zweige angegeben"
>  
>  #: builtin/branch.c:893
>  #, c-format
> @@ -2731,28 +2742,24 @@ msgid "suppress progress reporting"
>  msgstr "unterdrückt Fortschrittsanzeige"
>  
>  #: builtin/check-ignore.c:151
> -#, fuzzy
>  msgid "cannot specify pathnames with --stdin"
> -msgstr "kann -a nicht mit -d benutzen"
> +msgstr "Angabe von Pfadnamen kann nicht gemeinsam mit --stdin verwendet 
> werden"
>  
>  #: builtin/check-ignore.c:154
>  msgid "-z only makes sense with --stdin"
> -msgstr ""
> +msgstr "Die Option -z kann nur mit --stdin verwendet werden."
>  
>  #: builtin/check-ignore.c:156
> -#, fuzzy
>  msgid "no path specified"
> -msgstr "kein externes Projektarchiv angegeben"
> +msgstr "kein Pfad angegeben"
>  
>  #: builtin/c

Re: [PATCH 1/5] gpg-interface: check good signature in a reliable way

[Michael J Gruber]

Junio C Hamano venit, vidit, dixit 14.02.2013 18:22:
> Michael J Gruber  writes:
> 
>> Currently, verify_signed_buffer() only checks the return code of gpg,
>> and some callers implement additional unreliable checks for "Good
>> signature" in the gpg output meant for the user.
>>
>> Use the status output instead and parse for a line beinning with
>> "[GNUPG:] GOODSIG ". This is the only reliable way of checking for a
>> good gpg signature.
>>
>> If needed we can change this easily to "[GNUPG:] VALIDSIG " if we want
>> to take into account the trust model.
> 
> Thanks.  I didn't look beyond "man gpg" nor bother looking at
> DETAILS file in its source, which the manpage refers to.
> 
> I think GOODSIG is a good starting point.  Depending on the context
> (e.g. "%G?") we may also want to consider EXPSIG (but not EXPKEYSIG
> or REVKEYSIG) acceptable, while reading "log --show-signature" on
> ancient part of the history, no?

Yes, we could certainly return a more detailed status to the callers.
Currently, "0" is OK (GOODSIG) and everything else is a fail. We would
need to change the callers to allow more details on the "fail" as well
as the "OK" so that they can decide what is good enough, say:

-1: fail for technical reasons (no sig, can't run gpg etc.)
0: sig present bad (cryptographically) BAD
1: REVKEYSIG
2: EXPKEYSIG
3: EXPSIG
4: GOODSIG
5: VALIDSIG

I'd have to recheck whether a bitmask or ordered values make more sense.

>> Signed-off-by: Michael J Gruber 
>> ---
>>  gpg-interface.c | 13 +++--
>>  1 file changed, 11 insertions(+), 2 deletions(-)
>>
>> diff --git a/gpg-interface.c b/gpg-interface.c
>> index 4559033..c582b2e 100644
>> --- a/gpg-interface.c
>> +++ b/gpg-interface.c
>> @@ -96,15 +96,17 @@ int sign_buffer(struct strbuf *buffer, struct strbuf 
>> *signature, const char *sig
>>  /*
>>   * Run "gpg" to see if the payload matches the detached signature.
>>   * gpg_output, when set, receives the diagnostic output from GPG.
>> + * gpg_status, when set, receives the status output from GPG.
>>   */
>>  int verify_signed_buffer(const char *payload, size_t payload_size,
>>   const char *signature, size_t signature_size,
>>   struct strbuf *gpg_output)
>>  {
>>  struct child_process gpg;
>> -const char *args_gpg[] = {NULL, "--verify", "FILE", "-", NULL};
>> +const char *args_gpg[] = {NULL, "--status-fd=1", "--verify", "FILE", 
>> "-", NULL};
>>  char path[PATH_MAX];
>>  int fd, ret;
>> +struct strbuf buf = STRBUF_INIT;
>>  
>>  args_gpg[0] = gpg_program;
>>  fd = git_mkstemp(path, PATH_MAX, ".git_vtag_tmpXX");
>> @@ -119,9 +121,10 @@ int verify_signed_buffer(const char *payload, size_t 
>> payload_size,
>>  memset(&gpg, 0, sizeof(gpg));
>>  gpg.argv = args_gpg;
>>  gpg.in = -1;
>> +gpg.out = -1;
>>  if (gpg_output)
>>  gpg.err = -1;
>> -args_gpg[2] = path;
>> +args_gpg[3] = path;
>>  if (start_command(&gpg)) {
>>  unlink(path);
>>  return error(_("could not run gpg."));
>> @@ -134,9 +137,15 @@ int verify_signed_buffer(const char *payload, size_t 
>> payload_size,
>>  strbuf_read(gpg_output, gpg.err, 0);
>>  close(gpg.err);
>>  }
>> +strbuf_read(&buf, gpg.out, 0);
>> +close(gpg.out);
>> +
>>  ret = finish_command(&gpg);
>>  
>>  unlink_or_warn(path);
>>  
>> +ret |= !strstr(buf.buf, "\n[GNUPG:] GOODSIG ");
>> +strbuf_release(&buf);
>> +
>>  return ret;
>>  }
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] git.txt: update description of the configuration mechanism

[Michael J Gruber]

Junio C Hamano venit, vidit, dixit 14.02.2013 19:03:
> Matthieu Moy  writes:
> 
>> Junio C Hamano  writes:
>>
>>> But the exact location of per-user and per-repository configuration
>>> files does not matter in this context and is best left to the
>>> git-config documentation.
>>
>> I'm OK with your version.
> 
> I already queued your original with one s/not/now/; perhaps I will
> redo it then.

Yes, I think the new version improves upon Matthieu's which was a good
start to begin with :)

Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] git.txt: update description of the configuration mechanism

[Michael J Gruber]

Matthieu Moy venit, vidit, dixit 14.02.2013 16:36:
> The old Git version where it appeared is not useful only to historians,
> not to normal users. Also, the text was mentioning only the per-repo

I do not think you meant to not remove so many nots ;)

Besides, if history is uninteresting, then so is sociology: "familiar to
some people" can go, too.

> config file, so add a mention of ~/.gitconfig. Describing in details the
> system-wide, XDG and all would be counter-productive here, so reword the

Hmpf, I think this gives a way too prominent role to "~/.gitconfig". The
config files most people will have to deal with are:

- the repo config file
- the one set by "config --global"

And really, it would often be best if the latter was the XDG thing.

So, I'm all for improving git.txt, but somewhat differently ;)

> description of the link to git-config to make it clear that it is not
> only a list of configuration options.
> 
> Signed-off-by: Matthieu Moy 
> ---
>  Documentation/git.txt | 11 ++-
>  1 file changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/Documentation/git.txt b/Documentation/git.txt
> index 0b681d9..e332947 100644
> --- a/Documentation/git.txt
> +++ b/Documentation/git.txt
> @@ -535,10 +535,11 @@ include::cmds-purehelpers.txt[]
>  Configuration Mechanism
>  ---
>  
> -Starting from 0.99.9 (actually mid 0.99.8.GIT), `.git/config` file
> -is used to hold per-repository configuration options.  It is a
> -simple text file modeled after `.ini` format familiar to some
> -people.  Here is an example:
> +Git uses a simple text file format modeled after `.ini` format
> +familiar to some people to store its configuration. The `.git/config`
> +file is used to hold per-repository configuration options, and
> +per-user configuration can be stored in a `~/.gitconfig` file.
> +Here is an example:
>  
>  
>  #
> @@ -559,7 +560,7 @@ people.  Here is an example:
>  
>  Various commands read from the configuration file and adjust
>  their operation accordingly.  See linkgit:git-config[1] for a
> -list.
> +list and more details about the configuration mechanism.
>  
>  
>  Identifier Terminology
> 

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 5/5] pretty: make %GK output the signing key for signed commits

[Michael J Gruber]

Because we can.

No, really: In order to employ signed keys in an automated way it is
absolutely necessary to check which keys the signatures come from. Now
you can.

Signed-off-by: Michael J Gruber 
---
 Documentation/pretty-formats.txt | 1 +
 pretty.c | 9 -
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
index 105f18a..2939655 100644
--- a/Documentation/pretty-formats.txt
+++ b/Documentation/pretty-formats.txt
@@ -133,6 +133,7 @@ The placeholders are:
 - '%GG': raw verification message from GPG for a signed commit
 - '%G?': show either "G" for Good or "B" for Bad for a signed commit
 - '%GS': show the name of the signer for a signed commit
+- '%GK': show the key used to sign a signed commit
 - '%gD': reflog selector, e.g., `refs/stash@{1}`
 - '%gd': shortened reflog selector, e.g., `stash@{1}`
 - '%gn': reflog identity name
diff --git a/pretty.c b/pretty.c
index 973b912..b57adef 100644
--- a/pretty.c
+++ b/pretty.c
@@ -762,6 +762,7 @@ struct format_commit_context {
char *gpg_status;
char good_bad;
char *signer;
+   char *key;
} signature;
char *message;
size_t width, indent1, indent2;
@@ -964,7 +965,9 @@ static void parse_signature_lines(struct 
format_commit_context *ctx)
if (!found)
continue;
ctx->signature.good_bad = signature_check[i].result;
-   found += strlen(signature_check[i].check)+17;
+   found += strlen(signature_check[i].check);
+   ctx->signature.key = xmemdupz(found, 16);
+   found += 17;
next = strchrnul(found, '\n');
ctx->signature.signer = xmemdupz(found, next - found);
break;
@@ -1204,6 +1207,10 @@ static size_t format_commit_one(struct strbuf *sb, const 
char *placeholder,
if (c->signature.signer)
strbuf_addstr(sb, c->signature.signer);
break;
+   case 'K':
+   if (c->signature.key)
+   strbuf_addstr(sb, c->signature.key);
+   break;
}
return 2;
}
-- 
1.8.1.3.797.ge0260c7

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/5] gpg_interface: allow to request status return

[Michael J Gruber]

Currently, verify_signed_buffer() returns the user facing output only.

Allow callers to request the status output also.

Signed-off-by: Michael J Gruber 
---
 builtin/fmt-merge-msg.c |  2 +-
 builtin/verify-tag.c|  2 +-
 gpg-interface.c | 11 +++
 gpg-interface.h |  2 +-
 log-tree.c  |  4 ++--
 pretty.c|  2 +-
 6 files changed, 13 insertions(+), 10 deletions(-)

diff --git a/builtin/fmt-merge-msg.c b/builtin/fmt-merge-msg.c
index b49612f..265a925 100644
--- a/builtin/fmt-merge-msg.c
+++ b/builtin/fmt-merge-msg.c
@@ -492,7 +492,7 @@ static void fmt_merge_msg_sigs(struct strbuf *out)
 
if (size == len)
; /* merely annotated */
-   else if (verify_signed_buffer(buf, len, buf + len, size - len, 
&sig)) {
+   else if (verify_signed_buffer(buf, len, buf + len, size - len, 
&sig, NULL)) {
if (!sig.len)
strbuf_addstr(&sig, "gpg verification 
failed.\n");
}
diff --git a/builtin/verify-tag.c b/builtin/verify-tag.c
index a8eee88..9cdf332 100644
--- a/builtin/verify-tag.c
+++ b/builtin/verify-tag.c
@@ -29,7 +29,7 @@ static int run_gpg_verify(const char *buf, unsigned long 
size, int verbose)
if (size == len)
return error("no signature found");
 
-   return verify_signed_buffer(buf, len, buf + len, size - len, NULL);
+   return verify_signed_buffer(buf, len, buf + len, size - len, NULL, 
NULL);
 }
 
 static int verify_tag(const char *name, int verbose)
diff --git a/gpg-interface.c b/gpg-interface.c
index c582b2e..8b0e874 100644
--- a/gpg-interface.c
+++ b/gpg-interface.c
@@ -100,13 +100,14 @@ int sign_buffer(struct strbuf *buffer, struct strbuf 
*signature, const char *sig
  */
 int verify_signed_buffer(const char *payload, size_t payload_size,
 const char *signature, size_t signature_size,
-struct strbuf *gpg_output)
+struct strbuf *gpg_output, struct strbuf *gpg_status)
 {
struct child_process gpg;
const char *args_gpg[] = {NULL, "--status-fd=1", "--verify", "FILE", 
"-", NULL};
char path[PATH_MAX];
int fd, ret;
struct strbuf buf = STRBUF_INIT;
+   struct strbuf *pbuf = &buf;
 
args_gpg[0] = gpg_program;
fd = git_mkstemp(path, PATH_MAX, ".git_vtag_tmpXX");
@@ -137,15 +138,17 @@ int verify_signed_buffer(const char *payload, size_t 
payload_size,
strbuf_read(gpg_output, gpg.err, 0);
close(gpg.err);
}
-   strbuf_read(&buf, gpg.out, 0);
+   if (gpg_status)
+   pbuf = gpg_status;
+   strbuf_read(pbuf, gpg.out, 0);
close(gpg.out);
 
ret = finish_command(&gpg);
 
unlink_or_warn(path);
 
-   ret |= !strstr(buf.buf, "\n[GNUPG:] GOODSIG ");
-   strbuf_release(&buf);
+   ret |= !strstr(pbuf->buf, "\n[GNUPG:] GOODSIG ");
+   strbuf_release(&buf); /* no matter it was used or not */
 
return ret;
 }
diff --git a/gpg-interface.h b/gpg-interface.h
index b9c3608..cf99021 100644
--- a/gpg-interface.h
+++ b/gpg-interface.h
@@ -2,7 +2,7 @@
 #define GPG_INTERFACE_H
 
 extern int sign_buffer(struct strbuf *buffer, struct strbuf *signature, const 
char *signing_key);
-extern int verify_signed_buffer(const char *payload, size_t payload_size, 
const char *signature, size_t signature_size, struct strbuf *gpg_output);
+extern int verify_signed_buffer(const char *payload, size_t payload_size, 
const char *signature, size_t signature_size, struct strbuf *gpg_output, struct 
strbuf *gpg_status);
 extern int git_gpg_config(const char *, const char *, void *);
 extern void set_signing_key(const char *);
 extern const char *get_signing_key(void);
diff --git a/log-tree.c b/log-tree.c
index 912fe08..3d88823 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -444,7 +444,7 @@ static void show_signature(struct rev_info *opt, struct 
commit *commit)
 
status = verify_signed_buffer(payload.buf, payload.len,
  signature.buf, signature.len,
- &gpg_output);
+ &gpg_output, NULL);
if (status && !gpg_output.len)
strbuf_addstr(&gpg_output, "No signature\n");
 
@@ -513,7 +513,7 @@ static void show_one_mergetag(struct rev_info *opt,
if (verify_signed_buffer(extra->value, payload_size,
 extra->value + payload_size,
 extra->len - payload_size,
-&verify_message)) {
+&verify_message, NULL)) {
if (verif

[PATCH 4/5] pretty: parse the gpg status lines rather than the output

[Michael J Gruber]

Currently, parse_signature_lines() parses the gpg output for strings
which depend on LANG so it fails to recognize good commit signatures
(and thus does not fill in %G? and the like) in most locales.

Make it parse the status lines from gpg instead, which are the proper
machine interface. This fixes the problem described above.

There is a change in behavior for "%GS" which we intentionally do not
work around: "%GS" used to put quotes around the signer's uid (or
rather: it inherited from the gpg user output). We output the uid
without quotes now, just like author and committer names.

Signed-off-by: Michael J Gruber 
---
 pretty.c | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/pretty.c b/pretty.c
index 2a1e174..973b912 100644
--- a/pretty.c
+++ b/pretty.c
@@ -759,6 +759,7 @@ struct format_commit_context {
unsigned commit_signature_parsed:1;
struct {
char *gpg_output;
+   char *gpg_status;
char good_bad;
char *signer;
} signature;
@@ -948,13 +949,13 @@ static struct {
char result;
const char *check;
 } signature_check[] = {
-   { 'G', ": Good signature from " },
-   { 'B', ": BAD signature from " },
+   { 'G', "\n[GNUPG:] GOODSIG " },
+   { 'B', "\n[GNUPG:] BADSIG " },
 };
 
 static void parse_signature_lines(struct format_commit_context *ctx)
 {
-   const char *buf = ctx->signature.gpg_output;
+   const char *buf = ctx->signature.gpg_status;
int i;
 
for (i = 0; i < ARRAY_SIZE(signature_check); i++) {
@@ -963,7 +964,7 @@ static void parse_signature_lines(struct 
format_commit_context *ctx)
if (!found)
continue;
ctx->signature.good_bad = signature_check[i].result;
-   found += strlen(signature_check[i].check);
+   found += strlen(signature_check[i].check)+17;
next = strchrnul(found, '\n');
ctx->signature.signer = xmemdupz(found, next - found);
break;
@@ -975,6 +976,7 @@ static void parse_commit_signature(struct 
format_commit_context *ctx)
struct strbuf payload = STRBUF_INIT;
struct strbuf signature = STRBUF_INIT;
struct strbuf gpg_output = STRBUF_INIT;
+   struct strbuf gpg_status = STRBUF_INIT;
int status;
 
ctx->commit_signature_parsed = 1;
@@ -984,13 +986,15 @@ static void parse_commit_signature(struct 
format_commit_context *ctx)
goto out;
status = verify_signed_buffer(payload.buf, payload.len,
  signature.buf, signature.len,
- &gpg_output, NULL);
+ &gpg_output, &gpg_status);
if (status && !gpg_output.len)
goto out;
ctx->signature.gpg_output = strbuf_detach(&gpg_output, NULL);
+   ctx->signature.gpg_status = strbuf_detach(&gpg_status, NULL);
parse_signature_lines(ctx);
 
  out:
+   strbuf_release(&gpg_status);
strbuf_release(&gpg_output);
strbuf_release(&payload);
strbuf_release(&signature);
-- 
1.8.1.3.797.ge0260c7

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/5] log-tree: rely upon the check in the gpg_interface

[Michael J Gruber]

It's just so much betterer.

Signed-off-by: Michael J Gruber 
---
 log-tree.c | 25 +++--
 1 file changed, 11 insertions(+), 14 deletions(-)

diff --git a/log-tree.c b/log-tree.c
index 5dc45c4..912fe08 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -508,20 +508,17 @@ static void show_one_mergetag(struct rev_info *opt,
gpg_message_offset = verify_message.len;
 
payload_size = parse_signature(extra->value, extra->len);
-   if ((extra->len <= payload_size) ||
-   (verify_signed_buffer(extra->value, payload_size,
- extra->value + payload_size,
- extra->len - payload_size,
- &verify_message) &&
-verify_message.len <= gpg_message_offset)) {
-   strbuf_addstr(&verify_message, "No signature\n");
-   status = -1;
-   }
-   else if (strstr(verify_message.buf + gpg_message_offset,
-   ": Good signature from "))
-   status = 0;
-   else
-   status = -1;
+   status = -1;
+   if (extra->len > payload_size)
+   if (verify_signed_buffer(extra->value, payload_size,
+extra->value + payload_size,
+extra->len - payload_size,
+&verify_message)) {
+   if (verify_message.len <= gpg_message_offset)
+   strbuf_addstr(&verify_message, "No 
signature\n");
+   else
+   status = 0;
+   }
 
show_sig_lines(opt, status, verify_message.buf);
strbuf_release(&verify_message);
-- 
1.8.1.3.797.ge0260c7

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/5] gpg-interface: check good signature in a reliable way

[Michael J Gruber]

Currently, verify_signed_buffer() only checks the return code of gpg,
and some callers implement additional unreliable checks for "Good
signature" in the gpg output meant for the user.

Use the status output instead and parse for a line beinning with
"[GNUPG:] GOODSIG ". This is the only reliable way of checking for a
good gpg signature.

If needed we can change this easily to "[GNUPG:] VALIDSIG " if we want
to take into account the trust model.

Signed-off-by: Michael J Gruber 
---
 gpg-interface.c | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/gpg-interface.c b/gpg-interface.c
index 4559033..c582b2e 100644
--- a/gpg-interface.c
+++ b/gpg-interface.c
@@ -96,15 +96,17 @@ int sign_buffer(struct strbuf *buffer, struct strbuf 
*signature, const char *sig
 /*
  * Run "gpg" to see if the payload matches the detached signature.
  * gpg_output, when set, receives the diagnostic output from GPG.
+ * gpg_status, when set, receives the status output from GPG.
  */
 int verify_signed_buffer(const char *payload, size_t payload_size,
 const char *signature, size_t signature_size,
 struct strbuf *gpg_output)
 {
struct child_process gpg;
-   const char *args_gpg[] = {NULL, "--verify", "FILE", "-", NULL};
+   const char *args_gpg[] = {NULL, "--status-fd=1", "--verify", "FILE", 
"-", NULL};
char path[PATH_MAX];
int fd, ret;
+   struct strbuf buf = STRBUF_INIT;
 
args_gpg[0] = gpg_program;
fd = git_mkstemp(path, PATH_MAX, ".git_vtag_tmpXX");
@@ -119,9 +121,10 @@ int verify_signed_buffer(const char *payload, size_t 
payload_size,
memset(&gpg, 0, sizeof(gpg));
gpg.argv = args_gpg;
gpg.in = -1;
+   gpg.out = -1;
if (gpg_output)
gpg.err = -1;
-   args_gpg[2] = path;
+   args_gpg[3] = path;
if (start_command(&gpg)) {
unlink(path);
return error(_("could not run gpg."));
@@ -134,9 +137,15 @@ int verify_signed_buffer(const char *payload, size_t 
payload_size,
strbuf_read(gpg_output, gpg.err, 0);
close(gpg.err);
}
+   strbuf_read(&buf, gpg.out, 0);
+   close(gpg.out);
+
ret = finish_command(&gpg);
 
unlink_or_warn(path);
 
+   ret |= !strstr(buf.buf, "\n[GNUPG:] GOODSIG ");
+   strbuf_release(&buf);
+
return ret;
 }
-- 
1.8.1.3.797.ge0260c7

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/5] gpg_interface: use the status

[Michael J Gruber]

Currently, we look at the user facing output of gpg, which is LANG dependent as
well as insecure.

After this series, we look at the status output (--status-fd) which is designed
for that purpose. As an additional benefit, we can read off the key which was 
used
for the signature, which is important for assigning trust.

All existing tests pass with this.

BTW: git branch --set-upstream-to= coredumps when on a detached head.

Michael J Gruber (5):
  gpg-interface: check good signature in a reliable way
  log-tree: rely upon the check in the gpg_interface
  gpg_interface: allow to request status return
  pretty: parse the gpg status lines rather than the output
  pretty: make %GK output the signing key for signed commits

 Documentation/pretty-formats.txt |  1 +
 builtin/fmt-merge-msg.c  |  2 +-
 builtin/verify-tag.c |  2 +-
 gpg-interface.c  | 18 +++---
 gpg-interface.h  |  2 +-
 log-tree.c   | 27 ---
 pretty.c | 19 +++
 7 files changed, 46 insertions(+), 25 deletions(-)

-- 
1.8.1.3.797.ge0260c7

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [BUG] Veryfing signatures in git log fails when language is not english

[Michael J Gruber]

XANi venit, vidit, dixit 14.02.2013 01:18:
> Hi,
> 
> any functionality that depends on exact exit msg of program
>  can potentially fail because of that
> ᛯ export |grep LANG
> declare -x LANG="pl_PL.UTF-8"
> 
> ᛯ ~/src/os/git/git log --format="%G? %h" |head -2 
>  0d19377
>  5b9d7f8
> 
> ᛯ unset LANG
> ᛯ ~/src/os/git/git log --format="%G? %h" |head -2
> G 0d19377
> G 5b9d7f8
> 
> tested against maint (d32805d) and master (5bf72ed)
> 
> maybe git should set up some output-changing variables before calling
> external programs? I think setting LC_ALL=C should be enougth.
> 

There are really multiple problems here:

1. git calls gpg without setting LANG but expects output in LANG=C

2. git looks at the textual output from gpg to check the validity.

3. In fact, it does so only for %G and the display of signed merge
commits, in all other cases it checks the return code only.

gpg is not supposed to be used like that.

Since the callers of verify_signed_buffer do that craziness there is
some refactoring to be done.

A false hotfix would be to set LANG=C when calling gpg from git, but
that wouldn't solve the real problem. Besides, we do want LANG dependent
output for the user.

I'll have a closer look.

BTW: Thanks for the clear report :)

Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Pushing a git repository to a new server

[Michael J Gruber]

Jeff King venit, vidit, dixit 12.02.2013 21:42:
> On Tue, Feb 12, 2013 at 12:28:53PM +0100, Michael J Gruber wrote:
> 
>> I'm not sure providers like GitHub would fancy an interface which allows
>> the programmatic creation of repos (giving a new meaning to "fork
>> bomb"). But I bet you know better ;-)
> 
> You can already do that:
> 
>   http://developer.github.com/v3/repos/#create

Nice.

I knew you knew ;)

> We rate-limit API requests, and I imagine we might do something similar
> with create-over-git. But that is exactly the kind of implementation
> detail that can go into a custom create-repo script.
> 
>> An alternative would be to teach git (the client) about repo types and
>> how to create them. After all, a repo URL "ssh://host/path" gives a
>> clear indication that "ssh host git init path" will create a repo.
> 
> But that's the point of a microformat. It _doesn't_ always work, because
> the server may not allow arbitrary commands, or may have special
> requirements on top of the "init". You can make the microformat be "git
> init path", and servers can intercept calls to "git init" and translate
> them into custom magic. But I think the world is a little simpler if we
> define a new service type (alongside git-upload-pack, git-receive-pack,
> etc), and let clients request it. Then it's clear what the client is
> trying to do, it's easy for servers to hook into it, we can request it
> over http, etc. And it can be extended over time to take more fields
> (like repo description, etc).
> 
> I'm really not suggesting anything drastic. The wrapper case for ssh
> would be as simple as a 3-line shell script which calls "git init" under
> the hood, but it provides one level of indirection that makes
> replacing/hooking it much simpler for servers. So the parts that are in
> stock git would not be much work (most of the work would be on _calling_
> it, but that is the same for adding a call to "git init").
> 
> I think the main reason the idea hasn't gone anywhere is that nobody
> really cares _that_ much. People just don't create repositories that
> often. I feel like this is one of those topics that comes up once a
> year, and then nothing happens on it, because people just make their
> repo manually and then stop caring about it.
> 
> Just my two cents, of course. :)

Most repos are probably created by a local "git init" or "git clone", or
by clicking a button on a provider's web interface. The need for
git-create-repo seems to be restricted to:

- "command line folks" who use a provider for it's hosting service and
don't fancy a web interface for repo creation

- noobs who need to get their head wrapped around local, remote,
push/pull 'n' stuff...

For the server side git-create-repo to take off we would probably need
two things (besides the client support):

- Implement and ship a git-create-repo which makes this work for git
over ssh seamlessly. (Will take some to trickle down to servers in the
wild.)

- Get a large provider to offer this.

Gitosis/Gitolite are probably to follow easily. I'm beginning to like
idea ;)

Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Pushing a git repository to a new server

[Michael J Gruber]

Jeff King venit, vidit, dixit 11.02.2013 17:27:
> On Mon, Feb 11, 2013 at 02:57:51AM -0500, Ethan Reesor wrote:
> 
>> On Mon, Feb 11, 2013 at 2:50 AM, Konstantin Khomoutov
>>  wrote:
>>> What's wrong with
>>> $ ssh myuser@remotehost 'mkdir /path/to/MyRepo.git; cd $_; git init --bare'
>>> $ git push --all git@remotehost:MyOtherRepo.git
>>> ?
>>
>> Nothing, I just wanted to make myself a command to do that for me.
> 
> We talked about this a long time ago. One problem is that it's
> inherently unportable, as the procedure to make a repo is potentially
> different on every server (and certainly that is the case between a
> regular user running stock git and something like GitHub or Google Code;
> I imagine even gitolite has some special procedures for creating repos,
> too).
> 
> One proposal made in the previous discussion was to define a microformat
> for repository administration commands. So that you could connect and
> say "git admin-create-repo /path/to/MyRepo.git", and the server-provided
> admin-create-repo command would take care of the details. Then stock git
> could forward it to "git init --bare", GitHub could do the same and
> create the necessary database records, etc.
>
> And once that standardized method was in place, it would be easy to add
> a "--create" option to "git push" to request an "admin-create-repo"
> before pushing.
> 
> I still think that's a reasonable way forward, but nobody was interested
> enough to start writing code for it.
> 
> -Peff
> 

I'm not sure providers like GitHub would fancy an interface which allows
the programmatic creation of repos (giving a new meaning to "fork
bomb"). But I bet you know better ;-)

An alternative would be to teach git (the client) about repo types and
how to create them. After all, a repo URL "ssh://host/path" gives a
clear indication that "ssh host git init path" will create a repo. I'm
wondering whether it's more likely to convince providers (the server
side) or more is gained by covering the simpler cases client-side (our
side).

Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv2] git-bisect.txt: clarify that reset quits bisect

[Michael J Gruber]

"reset" can be easily misunderstood as resetting a bisect session to its
start without finishing it. Clarify that it actually quits the bisect
session.

Reported-by: Andreas Mohr 
Signed-off-by: Michael J Gruber 
---
 Documentation/git-bisect.txt | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt
index b4831bb..f986c5c 100644
--- a/Documentation/git-bisect.txt
+++ b/Documentation/git-bisect.txt
@@ -83,7 +83,7 @@ Bisect reset
 
 
 After a bisect session, to clean up the bisection state and return to
-the original HEAD, issue the following command:
+the original HEAD (i.e., to quit bisecting), issue the following command:
 
 
 $ git bisect reset
@@ -284,6 +284,7 @@ EXAMPLES
 
 $ git bisect start HEAD v1.2 --  # HEAD is bad, v1.2 is good
 $ git bisect run make# "make" builds the app
+$ git bisect reset   # quit the bisect session
 
 
 * Automatically bisect a test failure between origin and HEAD:
@@ -291,6 +292,7 @@ $ git bisect run make# "make" builds the app
 
 $ git bisect start HEAD origin --# HEAD is bad, origin is good
 $ git bisect run make test   # "make test" builds and tests
+$ git bisect reset   # quit the bisect session
 
 
 * Automatically bisect a broken test case:
@@ -302,6 +304,7 @@ make || exit 125 # this skips broken 
builds
 ~/check_test_case.sh # does the test case pass?
 $ git bisect start HEAD HEAD~10 --   # culprit is among the last 10
 $ git bisect run ~/test.sh
+$ git bisect reset   # quit the bisect session
 
 +
 Here we use a "test.sh" custom script. In this script, if "make"
@@ -351,6 +354,7 @@ use `git cherry-pick` instead of `git merge`.)
 
 $ git bisect start HEAD HEAD~10 --   # culprit is among the last 10
 $ git bisect run sh -c "make || exit 125; ~/check_test_case.sh"
+$ git bisect reset   # quit the bisect session
 
 +
 This shows that you can do without a run script if you write the test
@@ -368,6 +372,7 @@ $ git bisect run sh -c '
rm -f tmp.$$
test $rc = 0'
 
+$ git bisect reset   # quit the bisect session
 
 +
 In this case, when 'git bisect run' finishes, bisect/bad will refer to a 
commit that
-- 
1.8.1.2.752.g32d147e

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] git-bisect.txt: clarify that reset finishes bisect

[Michael J Gruber]

Jonathan Nieder venit, vidit, dixit 10.02.2013 02:49:
> Hi,
> 
> Michael J Gruber wrote:
> 
>> "reset" can be easily misunderstood as resetting a bisect session to its
>> start without finishing it. Clarify that it actually finishes the bisect
>> session.
> 
> FWIW,
> Reviewed-by: Jonathan Nieder 
> 
> Addressing Andreas's original concern about the discoverability of
> 'git bisect reset' would presumably require doing two more things:
> 
>  1. adding an example of the normal bisection workflow to the EXAMPLES
> section
> 
>  2. training users to look to the EXAMPLES section
> 
> That is, something like the below.  But I'm not happy with it, because
> it just runs over the same material as the current Description
> section.  Maybe the current tutorial material could be moved to
> examples and replaced with something terser that fleshes out the
> descriptions in "git bisect -h" output.  What do you think?
> 
> diff --git i/Documentation/git-bisect.txt w/Documentation/git-bisect.txt
> index e4f46bc1..b89abd78 100644
> --- i/Documentation/git-bisect.txt
> +++ w/Documentation/git-bisect.txt
> @@ -356,6 +356,54 @@ $ git bisect run sh -c "make || exit 125; 
> ~/check_test_case.sh"
>  This shows that you can do without a run script if you write the test
>  on a single line.
>  
> +* Bisect to find which patch caused a boot failure:
> ++
> +Install a recent kernel:
> ++
> +
> +$ cd ~/src/linux
> +$ git checkout origin/master
> +$ make deb-pkg # or binrpm-pkg, or tar-pkg
> +$ dpkg -i ../ # as root (or rpm -i, or tar -C / -xf)
> +$ reboot # as root
> +
> ++
> +Hopefully it fails to boot, so tell git so and begin bisection:
> ++
> +
> +$ cd ~/src/linux
> +$ git bisect start HEAD v3.2 # assuming 3.2 works fine
> +-
> ++
> +A candidate revision to test is automatically checked out.
> +Test it:
> ++
> +-
> +$ make deb-pkg # or binrpm-pkg, or tar-pkg
> +$ dpkg -i ../ # as root (or rpm -i, or tar -C / -xf)
> +$ reboot # as root
> +-
> ++
> +Record the result:
> ++
> +-
> +$ cd ~/src/linux
> +$ git bisect good # if it booted correctly
> +$ git bisect bad # if it failed to boot
> +$ git bisect skip # if some other bug made it hard to test
> +-
> ++
> +Repeat until bored or git prints the "first bad commit".  When
> +done:
> ++
> +-
> +$ git bisect log >log # let others pick up where you left off
> +$ git bisect reset HEAD # exit the bisecting state
> +-
> ++
> +At any step, you can run `git bisect visualize` to watch the
> +regression range narrowing.
> +
>  * Locate a good region of the object graph in a damaged repository
>  +
>  
> 

[BTW, sorry for failing to set --in-reply-to in the patch e-mail. Need
to get that automated somehow.]

I did not use "stop" for the exact reasons that Junio mentioned. Just
throw in a third alternative: "quit" may convey that it's not possible
to ressume, without sounding as "exceptional" as "abort" does. After
all, it's the normal end to a bisect session much unlike "--abort" for
rebase, for example.

As for the example, we have an example section, and we could simply
throw in "git reset" lines there. I would even amend my patch with that;
the great git-bisect.txt refactoring I'd definitely leave to someone else.

Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] git-bisect.txt: clarify that reset finishes bisect

[Michael J Gruber]

"reset" can be easily misunderstood as resetting a bisect session to its
start without finishing it. Clarify that it actually finishes the bisect
session.

Reported-by: Andreas Mohr 
Signed-off-by: Michael J Gruber 
---
 Documentation/git-bisect.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt
index b4831bb..d50bd89 100644
--- a/Documentation/git-bisect.txt
+++ b/Documentation/git-bisect.txt
@@ -83,7 +83,7 @@ Bisect reset
 
 
 After a bisect session, to clean up the bisection state and return to
-the original HEAD, issue the following command:
+the original HEAD (i.e., to finish bisect), issue the following command:
 
 
 $ git bisect reset
-- 
1.8.1.2.752.g32d147e

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/PATCH 4/4] grep: obey --textconv for the case rev:path

[Michael J Gruber]

Junio C Hamano venit, vidit, dixit 07.02.2013 19:03:
> Michael J Gruber  writes:
> 
>>>> (cd t && git grep GET_SHA1_QUIETLY HEAD:../cache.h)
>>>> ../HEAD:../cache.h:#define GET_SHA1_QUIETLY01
>>>
>>> Yuck.
>>
>> And even more yuck:
>>
>> (cd t && git grep --full-name GET_SHA1_QUIETLY HEAD:../cache.h)
>> HEAD:../cache.h:#define GET_SHA1_QUIETLY01
>>
>> Someone does not expect a "rev:" to be in there, it seems ;)
> 
> I think stepping outside of $(cwd) is an afterthought the code does
> not anticipate.
> 

Well, we do resolve relative paths correctly, and there are even some
"chdir" in the code path. It's just that the output label is incorrect.

Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Proposal: branch..remotepush

[Michael J Gruber]

Junio C Hamano venit, vidit, dixit 08.02.2013 09:16:
> Jonathan Nieder  writes:
> 
>> "Wait, why did the remote rewind?"
> 
> Oh, I am very well aware of that glitch.
> 
> "git push" has this hack to pretend as if the pusher immediately
> turned around and fetched from the remote.
> 
> It shouldn't have been made to do so unconditionally; instead it
> should have been designed to give the pushee a way to optionally
> tell you "I acccept this push, but you may not see it to be updated
> to that exact value you pushed when you fetched from me right now".
> 
> The hack is not my design; it was not even something I accepted
> without complaints, so I can badmouth about it all I want without
> hesitation ;-)
> 
> More importantly, we could fix it if we wanted to.

And this seems to be more natural, too. It can keep the internals (the
auxiliary ref on the server side) hidden from the user.

As for the triangle remote, I really think we should clean up the
situation regarding push, pushurlinsteadof and the various different and
inconclusive output formats of "git remote" (with or without "-v", with
or without a remote name) first, before introducing yet another way to
twist things around. "git push downstream" does not hurt any kittens
(while git remote ouput does, somehwat).

Michael

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/PATCH 4/4] grep: obey --textconv for the case rev:path

[Michael J Gruber]

Jeff King venit, vidit, dixit 07.02.2013 10:55:
> On Thu, Feb 07, 2013 at 10:47:55AM +0100, Michael J Gruber wrote:
> 
>>> I'd be OK if we had an exterior object_context that could be handled
>>> in the same way. But how do we tell setup_revisions that we are
>>> interested in seeing the object_context from each parsed item, where
>>> does the allocation come from (is it malloc'd by setup_revisions?), and
>>> who is responsible for freeing it when we pop pending objects in
>>> get_revisions and similar?
>>
>> Do we really need all of tree, path and mode in object_context (I mean
>> not just here, but other users), or only the path? I'd try and resurrect
>> the virtual path name objects then, they would be just like "item"
>> storage-wise.
> 
> We need at least mode, since that is how the mode parameter of
> object_array_entry gets set. I do not know off-hand who uses "tree". I
> suspect the intent was to do .gitattributes lookups inside that tree,
> but I do not think we actually do in-tree lookups currently.
> 
>>> I don't think it's as clear cut.
>>>
>>> I wonder, though...what we really care about here is just the pathname.
>>> But if it is a pending object that comes from a blob revision argument,
>>> won't it always be of the form "treeish:path"? Could we not even resolve
>>> the sha1 again, but instead just parse out the ":path" bit?
>>
>> Do we have that, and in what form (e.g. magic expanded etc.)?
> 
> Ah, I should have mentioned that. :) We should have the original rev
> name in the object_array_entry's name field, shouldn't we? It's just a
> matter of re-parsing it.
> 
>> Another thing I noted is that our path mangling at least for grep has
>> some issues:
>>
>> (cd t && git grep GET_SHA1_QUIETLY HEAD:../cache.h)
>> ../HEAD:../cache.h:#define GET_SHA1_QUIETLY01
> 
> Yuck.

And even more yuck:

(cd t && git grep --full-name GET_SHA1_QUIETLY HEAD:../cache.h)
HEAD:../cache.h:#define GET_SHA1_QUIETLY01

Someone does not expect a "rev:" to be in there, it seems ;)

Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/PATCH 4/4] grep: obey --textconv for the case rev:path

[Michael J Gruber]

Jeff King venit, vidit, dixit 07.02.2013 10:26:
> On Thu, Feb 07, 2013 at 10:05:57AM +0100, Michael J Gruber wrote:
> 
>>>> @@ -265,9 +260,28 @@ void add_object_array_with_mode(struct object *obj, 
>>>> const char *name, struct obj
>>>>objects[nr].item = obj;
>>>>objects[nr].name = name;
>>>>objects[nr].mode = mode;
>>>> +  objects[nr].context = context;
>>>>array->nr = ++nr;
>>>>  }
>>>
>>> This seems a little gross. Who is responsible for allocating the
>>> context? Who frees it? It looks like we duplicate it in cmd_grep. Which
>>
>> Well, who is responsible for allocating and freeing name and item? I
>> didn't want to introduce a new member which is a struct when all other
>> complex members are pointers. Wouldn't that be confusing?
> 
> We cheat on those two. "item" is always a pointer to a "struct object",
> which lasts forever and never gets freed. When "name" is set by
> setup_revisions, it comes from the argv list, which is assumed to last
> forever (and when we add pending blobs for a "--objects" traversal, it
> is the empty string (literal).

I see, so they are really different.

> I'd be OK if we had an exterior object_context that could be handled
> in the same way. But how do we tell setup_revisions that we are
> interested in seeing the object_context from each parsed item, where
> does the allocation come from (is it malloc'd by setup_revisions?), and
> who is responsible for freeing it when we pop pending objects in
> get_revisions and similar?

Do we really need all of tree, path and mode in object_context (I mean
not just here, but other users), or only the path? I'd try and resurrect
the virtual path name objects then, they would be just like "item"
storage-wise.

> I don't think it's as clear cut.
> 
> I wonder, though...what we really care about here is just the pathname.
> But if it is a pending object that comes from a blob revision argument,
> won't it always be of the form "treeish:path"? Could we not even resolve
> the sha1 again, but instead just parse out the ":path" bit?

Do we have that, and in what form (e.g. magic expanded etc.)?

> That is sort of like what the repeated call to get_sha1_with_context
> does in your first patch. Except that we do not actually want to lookup
> the sha1, and it is harmful to do so (e.g., if the ref had moved on to a
> new tree that does not have that path, get_sha1 would fail, but we do
> not even care what is in the tree; we only want the parsing side effects
> of get_sha1).
> 
> Hmm.
> 
> -Peff
> 
> PS By the way, while looking at the object_array code (which I have not
>really used much before), I noticed that add_pending_commit_list sets
>the "name" field to the result of sha1_to_hex. Which means that it is
>likely to be completely bogus by the time you read it. I'm not even
>sure where it gets read or if this matters. And obviously it's
>completely unrelated to what we were discussing; just something I
>noticed.

Another thing I noted is that our path mangling at least for grep has
some issues:

(cd t && git grep GET_SHA1_QUIETLY HEAD:../cache.h)
../HEAD:../cache.h:#define GET_SHA1_QUIETLY01

Taking everything right of ":" could still work.

Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/PATCH 1/4] show: obey --textconv for blobs

[Michael J Gruber]

Jeff King venit, vidit, dixit 07.02.2013 10:11:
> On Thu, Feb 07, 2013 at 10:05:26AM +0100, Michael J Gruber wrote:
> 
>>> Would it be better if object_array_entry replaced its "mode" member with
>>> an object_context?
>>
>> Do all callers/users want to deal with object_context?
> 
> Wouldn't it just mean replacing "entry->mode" with "entry->oc.mode" at
> each user?

Yes, I meant at the time of creation, i.e. when someone has to create
and pass an o_a_e and maybe only knows a mode, and thus would have to
set the path to NULL or "".

>> I'm wondering why o_c has a mode at all, since it is mostly used in
>> conjunction with an object, isn't it?
> 
> Just as we record the path from the surrounding tree, we record the
> mode. It's that mode which gets put into the pending object list by the
> revision parser (see the very end of handle_revision_arg). Storing an
> object_context instead of the mode would be a strict superset of what we
> store now (right now we just throw the rest away).

Sure. But why does object_context have a mode member at all? Maybe it is
not alway used together with another struct which has the mode already,
then that's a reason.

Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/PATCH 4/4] grep: obey --textconv for the case rev:path

[Michael J Gruber]

Jeff King venit, vidit, dixit 06.02.2013 23:36:
> On Wed, Feb 06, 2013 at 04:08:53PM +0100, Michael J Gruber wrote:
> 
>> -add_object_array(object, arg, &list);
>> +add_object_array_with_context(object, arg, &list, 
>> xmemdupz(&oc, sizeof(struct object_context)));
> 
> If we go this route, this new _with_context variant should be used in
> patch 1, too.
> 
>> @@ -265,9 +260,28 @@ void add_object_array_with_mode(struct object *obj, 
>> const char *name, struct obj
>>  objects[nr].item = obj;
>>  objects[nr].name = name;
>>  objects[nr].mode = mode;
>> +objects[nr].context = context;
>>  array->nr = ++nr;
>>  }
> 
> This seems a little gross. Who is responsible for allocating the
> context? Who frees it? It looks like we duplicate it in cmd_grep. Which

Well, who is responsible for allocating and freeing name and item? I
didn't want to introduce a new member which is a struct when all other
complex members are pointers. Wouldn't that be confusing?

> I think is OK, but it means all of this context infrastructure in
> object.[ch] is just bolted-on junk waiting for somebody to use it wrong
> or get confused.  It does not get set, for example, by the regular
> setup_revisions code path.

Sure, it's NULL when there is no context info, just like in many other
cases.

> It would be nice if we could just always have the context available,
> then setup_revisions could set it up by default (and replace the "mode"
> parameter entirely). But we'd need to do something to avoid the
> PATH_MAX-sized buffer for each entry, as some code paths may have a
> large number of pending objects.

If the information is always available even if we don't need it then it
always takes space. The only way out would be pointing into a pool of
path names rather having a copy in each entry. It's not like I hadn't
talked about providing virtual (blob) objects for path names keyed by
their sha1 before... It's just that I want my grep --textconv now ;)

Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/PATCH 1/4] show: obey --textconv for blobs

[Michael J Gruber]

Jeff King venit, vidit, dixit 06.02.2013 23:06:
> On Wed, Feb 06, 2013 at 04:08:50PM +0100, Michael J Gruber wrote:
> 
>> diff --git a/builtin/log.c b/builtin/log.c
>> index 8f0b2e8..f83870d 100644
>> --- a/builtin/log.c
>> +++ b/builtin/log.c
>> @@ -402,10 +402,28 @@ static void show_tagger(char *buf, int len, struct 
>> rev_info *rev)
>>  strbuf_release(&out);
>>  }
>>  
>> -static int show_blob_object(const unsigned char *sha1, struct rev_info *rev)
>> +static int show_blob_object(const unsigned char *sha1, struct rev_info 
>> *rev, const char *obj_name)
> 
> Should this maybe just take the whole object_array_entry as a cleanup?

It's just a question of one or two/three pointers (I can't count), but
yes, that would be possible.

>>  {
>> +unsigned char sha1c[20];
>> +struct object_context obj_context;
>> +char *buf;
>> +unsigned long size;
>> +
>>  fflush(stdout);
>> -return stream_blob_to_fd(1, sha1, NULL, 0);
>> +if (!DIFF_OPT_TST(&rev->diffopt, ALLOW_TEXTCONV))
>> +return stream_blob_to_fd(1, sha1, NULL, 0);
>> +
>> +if (get_sha1_with_context(obj_name, 0, sha1c, &obj_context))
>> +die("Not a valid object name %s", obj_name);
> 
> It seems a little hacky that we have to look up the sha1 again. What
> should happen in the off chance that "hashcmp(sha1, sha1c) != 0" due to
> a race with a simultaneous update of a ref?

I thought about a check here but didn't bother to because I knew the
refactoring would come up again...

> Would it be better if object_array_entry replaced its "mode" member with
> an object_context?

Do all callers/users want to deal with object_context?

I'm wondering why o_c has a mode at all, since it is mostly used in
conjunction with an object, isn't it?

> The only downside I see is that we might waste a
> significant amount of memory (each context has a PATH_MAX buffer in it).

That's why I used a reference to the struct, see my other reply.

Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/PATCH 1/4] show: obey --textconv for blobs

[Michael J Gruber]

Junio C Hamano venit, vidit, dixit 06.02.2013 17:53:
> Michael J Gruber  writes:
> 
>> Currently, "diff" and "cat-file" for blobs obey "--textconv" options
>> (with the former defaulting to "--textconv" and the latter to
>> "--no-textconv") whereas "show" does not obey this option, even though
>> it takes diff options.
>>
>> Make "show" on blobs behave like "diff", i.e. obey "--textconv" by
>> default and "--no-textconv" when given.
> 
> What does "log -p" do currently, and what should it do?  Does/should
> it also use --textconv?

It invokes "--textconv" by default, and allows to override with
"--no-textconv. That's what I meant to say but seem to have failed to.

I think at some point we decided to have "human output" on by default
for all things diff (porcelain only, of course) unless the diff is meant
for machine consumption, such as in the case of format-patch.

> The --textconv is a natural extension of what --ext-diff provides us,
> so I think it should trigger the same way as how --ext-diff triggers.

This series' aim is to make the textconv behavior the same for all
"human output" commands. I don't see textconv and ext-diff to be
strongly related, and if then the other way round:

textconv is about converting blobs to a (possibly lossy) human
consumable text.

ext-diff is about computing diffs with an external diff "tool" (not in
the sense of diff-tool).

One way of diffing is textconving blobs then using internal diff on the
resulting text blobs, but ext-diff is more general and, really,
orthogonal in a way. (It used to be used often for what textconv does
when that didn't exist.)

> We apply "--ext-diff" for "diff" by default but not for "log -p" and
> "show"; I suspect this may have been for a good reason but I do not
> recall the discussion that led to the current behaviour offhand.

I don't think I changed anything ext-diff related, did I? 1/4 is about
showing blobs, not diffs.

>> Signed-off-by: Michael J Gruber 
>> ---
>>  builtin/log.c | 24 +---
>>  1 file changed, 21 insertions(+), 3 deletions(-)
>>
>> diff --git a/builtin/log.c b/builtin/log.c
>> index 8f0b2e8..f83870d 100644
>> --- a/builtin/log.c
>> +++ b/builtin/log.c
>> @@ -402,10 +402,28 @@ static void show_tagger(char *buf, int len, struct 
>> rev_info *rev)
>>  strbuf_release(&out);
>>  }
>>  
>> -static int show_blob_object(const unsigned char *sha1, struct rev_info *rev)
>> +static int show_blob_object(const unsigned char *sha1, struct rev_info 
>> *rev, const char *obj_name)
>>  {
>> +unsigned char sha1c[20];
>> +struct object_context obj_context;
>> +char *buf;
>> +unsigned long size;
>> +
>>  fflush(stdout);
>> -return stream_blob_to_fd(1, sha1, NULL, 0);
>> +if (!DIFF_OPT_TST(&rev->diffopt, ALLOW_TEXTCONV))
>> +return stream_blob_to_fd(1, sha1, NULL, 0);
>> +
>> +if (get_sha1_with_context(obj_name, 0, sha1c, &obj_context))
>> +die("Not a valid object name %s", obj_name);
>> +if (!obj_context.path[0] ||
>> +!textconv_object(obj_context.path, obj_context.mode, sha1c, 1, 
>> &buf, &size))
>> +return stream_blob_to_fd(1, sha1, NULL, 0);
>> +
>> +if (!buf)
>> +die("git show %s: bad file", obj_name);
>> +
>> +write_or_die(1, buf, size);
>> +return 0;
>>  }
>>  
>>  static int show_tag_object(const unsigned char *sha1, struct rev_info *rev)
>> @@ -491,7 +509,7 @@ int cmd_show(int argc, const char **argv, const char 
>> *prefix)
>>  const char *name = objects[i].name;
>>  switch (o->type) {
>>  case OBJ_BLOB:
>> -ret = show_blob_object(o->sha1, NULL);
>> +ret = show_blob_object(o->sha1, &rev, name);
>>  break;
>>  case OBJ_TAG: {
>>  struct tag *t = (struct tag *)o;
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC/PATCH 4/4] grep: obey --textconv for the case rev:path

[Michael J Gruber]

Make "grep" obey the "--textconv" option also for the object case, i.e.
when used with an argument "rev:path".

Signed-off-by: Michael J Gruber 
---
 builtin/grep.c | 11 ++-
 object.c   | 26 --
 object.h   |  2 ++
 3 files changed, 28 insertions(+), 11 deletions(-)

diff --git a/builtin/grep.c b/builtin/grep.c
index 915c8ef..0f3c4db 100644
--- a/builtin/grep.c
+++ b/builtin/grep.c
@@ -458,10 +458,10 @@ static int grep_tree(struct grep_opt *opt, const struct 
pathspec *pathspec,
 }
 
 static int grep_object(struct grep_opt *opt, const struct pathspec *pathspec,
-  struct object *obj, const char *name)
+  struct object *obj, const char *name, struct 
object_context *oc)
 {
if (obj->type == OBJ_BLOB)
-   return grep_sha1(opt, obj->sha1, name, 0, NULL);
+   return grep_sha1(opt, obj->sha1, name, 0, oc ? oc->path : NULL);
if (obj->type == OBJ_COMMIT || obj->type == OBJ_TREE) {
struct tree_desc tree;
void *data;
@@ -503,7 +503,7 @@ static int grep_objects(struct grep_opt *opt, const struct 
pathspec *pathspec,
for (i = 0; i < nr; i++) {
struct object *real_obj;
real_obj = deref_tag(list->objects[i].item, NULL, 0);
-   if (grep_object(opt, pathspec, real_obj, 
list->objects[i].name)) {
+   if (grep_object(opt, pathspec, real_obj, list->objects[i].name, 
list->objects[i].context)) {
hit = 1;
if (opt->status_only)
break;
@@ -820,14 +820,15 @@ int cmd_grep(int argc, const char **argv, const char 
*prefix)
for (i = 0; i < argc; i++) {
const char *arg = argv[i];
unsigned char sha1[20];
+   struct object_context oc;
/* Is it a rev? */
-   if (!get_sha1(arg, sha1)) {
+   if (!get_sha1_with_context(arg, 0, sha1, &oc)) {
struct object *object = parse_object(sha1);
if (!object)
die(_("bad object %s"), arg);
if (!seen_dashdash)
verify_non_filename(prefix, arg);
-   add_object_array(object, arg, &list);
+   add_object_array_with_context(object, arg, &list, 
xmemdupz(&oc, sizeof(struct object_context)));
continue;
}
if (!strcmp(arg, "--")) {
diff --git a/object.c b/object.c
index 4af3451..1b796c7 100644
--- a/object.c
+++ b/object.c
@@ -245,12 +245,7 @@ int object_list_contains(struct object_list *list, struct 
object *obj)
return 0;
 }
 
-void add_object_array(struct object *obj, const char *name, struct 
object_array *array)
-{
-   add_object_array_with_mode(obj, name, array, S_IFINVALID);
-}
-
-void add_object_array_with_mode(struct object *obj, const char *name, struct 
object_array *array, unsigned mode)
+static void add_object_array_with_mode_context(struct object *obj, const char 
*name, struct object_array *array, unsigned mode, struct object_context 
*context)
 {
unsigned nr = array->nr;
unsigned alloc = array->alloc;
@@ -265,9 +260,28 @@ void add_object_array_with_mode(struct object *obj, const 
char *name, struct obj
objects[nr].item = obj;
objects[nr].name = name;
objects[nr].mode = mode;
+   objects[nr].context = context;
array->nr = ++nr;
 }
 
+void add_object_array(struct object *obj, const char *name, struct 
object_array *array)
+{
+   add_object_array_with_mode(obj, name, array, S_IFINVALID);
+}
+
+void add_object_array_with_mode(struct object *obj, const char *name, struct 
object_array *array, unsigned mode)
+{
+   add_object_array_with_mode_context(obj, name, array, mode, NULL);
+}
+
+void add_object_array_with_context(struct object *obj, const char *name, 
struct object_array *array, struct object_context *context)
+{
+   if (context)
+   add_object_array_with_mode_context(obj, name, array, 
context->mode, context);
+   else
+   add_object_array_with_mode_context(obj, name, array, 
S_IFINVALID, context);
+}
+
 void object_array_remove_duplicates(struct object_array *array)
 {
unsigned int ref, src, dst;
diff --git a/object.h b/object.h
index 6a97b6b..a11d719 100644
--- a/object.h
+++ b/object.h
@@ -13,6 +13,7 @@ struct object_array {
struct object *item;
const char *name;
unsigned mode;
+   struct object_context *context;
} *objects;
 };
 
@@ -74,6 +75,7 @@ int object_list_contains(struct object_list *list, struct 
object *obj);
 /* Object array handling .. */
 void add_object_array(struct object *obj, 

[RFC/PATCH 3/4] grep: allow to use textconv filters

[Michael J Gruber]

From: Jeff King 

Recently and not so recently, we made sure that log/grep type operations
use textconv filters when a userfacing diff would do the same:

ef90ab6 (pickaxe: use textconv for -S counting, 2012-10-28)
b1c2f57 (diff_grep: use textconv buffers for add/deleted files, 2012-10-28)
0508fe5 (combine-diff: respect textconv attributes, 2011-05-23)

"git grep" currently does not use textconv filters at all, that is
neither for displaying the match and context nor for the actual grepping.

Introduce an option "--textconv" which makes git grep use any configured
textconv filters for grepping and output purposes. It is off by default.

Signed-off-by: Michael J Gruber 
---
 builtin/grep.c |   2 ++
 grep.c | 100 +
 grep.h |   1 +
 3 files changed, 89 insertions(+), 14 deletions(-)

diff --git a/builtin/grep.c b/builtin/grep.c
index 8025964..915c8ef 100644
--- a/builtin/grep.c
+++ b/builtin/grep.c
@@ -659,6 +659,8 @@ int cmd_grep(int argc, const char **argv, const char 
*prefix)
OPT_SET_INT('I', NULL, &opt.binary,
N_("don't match patterns in binary files"),
GREP_BINARY_NOMATCH),
+   OPT_BOOL(0, "textconv", &opt.allow_textconv,
+N_("process binary files with textconv filters")),
{ OPTION_INTEGER, 0, "max-depth", &opt.max_depth, N_("depth"),
N_("descend at most  levels"), PARSE_OPT_NONEG,
NULL, 1 },
diff --git a/grep.c b/grep.c
index 4bd1b8b..3880d64 100644
--- a/grep.c
+++ b/grep.c
@@ -2,6 +2,8 @@
 #include "grep.h"
 #include "userdiff.h"
 #include "xdiff-interface.h"
+#include "diff.h"
+#include "diffcore.h"
 
 static int grep_source_load(struct grep_source *gs);
 static int grep_source_is_binary(struct grep_source *gs);
@@ -1321,6 +1323,58 @@ static void std_output(struct grep_opt *opt, const void 
*buf, size_t size)
fwrite(buf, size, 1, stdout);
 }
 
+static int fill_textconv_grep(struct userdiff_driver *driver,
+ struct grep_source *gs)
+{
+   struct diff_filespec *df;
+   char *buf;
+   size_t size;
+
+   if (!driver || !driver->textconv)
+   return grep_source_load(gs);
+
+   /*
+* The textconv interface is intimately tied to diff_filespecs, so we
+* have to pretend to be one. If we could unify the grep_source
+* and diff_filespec structs, this mess could just go away.
+*/
+   df = alloc_filespec(gs->path);
+   switch (gs->type) {
+   case GREP_SOURCE_SHA1:
+   fill_filespec(df, gs->identifier, 1, 0100644);
+   break;
+   case GREP_SOURCE_FILE:
+   fill_filespec(df, null_sha1, 0, 0100644);
+   break;
+   default:
+   die("BUG: attempt to textconv something without a path?");
+   }
+
+   /*
+* fill_textconv is not remotely thread-safe; it may load objects
+* behind the scenes, and it modifies the global diff tempfile
+* structure.
+*/
+   grep_read_lock();
+   size = fill_textconv(driver, df, &buf);
+   grep_read_unlock();
+   free_filespec(df);
+
+   /*
+* The normal fill_textconv usage by the diff machinery would just keep
+* the textconv'd buf separate from the diff_filespec. But much of the
+* grep code passes around a grep_source and assumes that its "buf"
+* pointer is the beginning of the thing we are searching. So let's
+* install our textconv'd version into the grep_source, taking care not
+* to leak any existing buffer.
+*/
+   grep_source_clear_data(gs);
+   gs->buf = buf;
+   gs->size = size;
+
+   return 0;
+}
+
 static int grep_source_1(struct grep_opt *opt, struct grep_source *gs, int 
collect_hits)
 {
char *bol;
@@ -1331,6 +1385,7 @@ static int grep_source_1(struct grep_opt *opt, struct 
grep_source *gs, int colle
unsigned count = 0;
int try_lookahead = 0;
int show_function = 0;
+   struct userdiff_driver *textconv = NULL;
enum grep_context ctx = GREP_CONTEXT_HEAD;
xdemitconf_t xecfg;
 
@@ -1352,19 +1407,36 @@ static int grep_source_1(struct grep_opt *opt, struct 
grep_source *gs, int colle
}
opt->last_shown = 0;
 
-   switch (opt->binary) {
-   case GREP_BINARY_DEFAULT:
-   if (grep_source_is_binary(gs))
-   binary_match_only = 1;
-   break;
-   case GREP_BINARY_NOMATCH:
-   if (grep_source_is_binary(gs))
-   return 0; /* Assume unmatch */
-

[RFC/PATCH 1/4] show: obey --textconv for blobs

[Michael J Gruber]

Currently, "diff" and "cat-file" for blobs obey "--textconv" options
(with the former defaulting to "--textconv" and the latter to
"--no-textconv") whereas "show" does not obey this option, even though
it takes diff options.

Make "show" on blobs behave like "diff", i.e. obey "--textconv" by
default and "--no-textconv" when given.

Signed-off-by: Michael J Gruber 
---
 builtin/log.c | 24 +---
 1 file changed, 21 insertions(+), 3 deletions(-)

diff --git a/builtin/log.c b/builtin/log.c
index 8f0b2e8..f83870d 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -402,10 +402,28 @@ static void show_tagger(char *buf, int len, struct 
rev_info *rev)
strbuf_release(&out);
 }
 
-static int show_blob_object(const unsigned char *sha1, struct rev_info *rev)
+static int show_blob_object(const unsigned char *sha1, struct rev_info *rev, 
const char *obj_name)
 {
+   unsigned char sha1c[20];
+   struct object_context obj_context;
+   char *buf;
+   unsigned long size;
+
fflush(stdout);
-   return stream_blob_to_fd(1, sha1, NULL, 0);
+   if (!DIFF_OPT_TST(&rev->diffopt, ALLOW_TEXTCONV))
+   return stream_blob_to_fd(1, sha1, NULL, 0);
+
+   if (get_sha1_with_context(obj_name, 0, sha1c, &obj_context))
+   die("Not a valid object name %s", obj_name);
+   if (!obj_context.path[0] ||
+   !textconv_object(obj_context.path, obj_context.mode, sha1c, 1, 
&buf, &size))
+   return stream_blob_to_fd(1, sha1, NULL, 0);
+
+   if (!buf)
+   die("git show %s: bad file", obj_name);
+
+   write_or_die(1, buf, size);
+   return 0;
 }
 
 static int show_tag_object(const unsigned char *sha1, struct rev_info *rev)
@@ -491,7 +509,7 @@ int cmd_show(int argc, const char **argv, const char 
*prefix)
const char *name = objects[i].name;
switch (o->type) {
case OBJ_BLOB:
-   ret = show_blob_object(o->sha1, NULL);
+   ret = show_blob_object(o->sha1, &rev, name);
break;
case OBJ_TAG: {
struct tag *t = (struct tag *)o;
-- 
1.8.1.2.752.g32d147e

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC/PATCH 2/4] cat-file: do not die on --textconv without textconv filters

[Michael J Gruber]

When a command is supposed to use textconv filters (by default or with
"--textconv") and none are configured then the blob is output without
conversion; the only exception to this rule is "cat-file --textconv".

Make it behave like the rest of textconv aware commands.

Signed-off-by: Michael J Gruber 
---
 builtin/cat-file.c   |  9 +
 t/t8007-cat-file-textconv.sh | 20 +---
 2 files changed, 10 insertions(+), 19 deletions(-)

diff --git a/builtin/cat-file.c b/builtin/cat-file.c
index 00528dd..6912dc2 100644
--- a/builtin/cat-file.c
+++ b/builtin/cat-file.c
@@ -146,10 +146,11 @@ static int cat_one_file(int opt, const char *exp_type, 
const char *obj_name)
die("git cat-file --textconv %s:  must be 
",
obj_name);
 
-   if (!textconv_object(obj_context.path, obj_context.mode, sha1, 
1, &buf, &size))
-   die("git cat-file --textconv: unable to run textconv on 
%s",
-   obj_name);
-   break;
+   if (textconv_object(obj_context.path, obj_context.mode, sha1, 
1, &buf, &size))
+   break;
+
+   /* otherwise expect a blob */
+   exp_type = "blob";
 
case 0:
if (type_from_string(exp_type) == OBJ_BLOB) {
diff --git a/t/t8007-cat-file-textconv.sh b/t/t8007-cat-file-textconv.sh
index 78a0085..83c6636 100755
--- a/t/t8007-cat-file-textconv.sh
+++ b/t/t8007-cat-file-textconv.sh
@@ -22,11 +22,11 @@ test_expect_success 'setup ' '
 '
 
 cat >expected <result
+   git cat-file --textconv :one.bin >result &&
test_cmp expected result
 '
 
@@ -36,10 +36,6 @@ test_expect_success 'setup textconv filters' '
git config diff.test.cachetextconv false
 '
 
-cat >expected <result &&
test_cmp expected result
@@ -73,25 +69,19 @@ test_expect_success 'cat-file --textconv on previous 
commit' '
 '
 
 test_expect_success SYMLINKS 'cat-file without --textconv (symlink)' '
+   printf "%s" "one.bin" >expected &&
git cat-file blob :symlink.bin >result &&
-   printf "%s" "one.bin" >expected
test_cmp expected result
 '
 
 
 test_expect_success SYMLINKS 'cat-file --textconv on index (symlink)' '
-   ! git cat-file --textconv :symlink.bin 2>result &&
-   cat >expected <<\EOF &&
-fatal: git cat-file --textconv: unable to run textconv on :symlink.bin
-EOF
+   git cat-file --textconv :symlink.bin >result &&
test_cmp expected result
 '
 
 test_expect_success SYMLINKS 'cat-file --textconv on HEAD (symlink)' '
-   ! git cat-file --textconv HEAD:symlink.bin 2>result &&
-   cat >expected <result &&
test_cmp expected result
 '
 
-- 
1.8.1.2.752.g32d147e

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC/PATCH 0/4] textconv for show and grep

[Michael J Gruber]

This min series aims at completing the textconv support of user facing
commands. It is RFC for lack of documentation and tests, to check
whether we really want to go in that direction (I do).

1/4 covers the missing textconv support in the "blob case" of "git
show", which should be (and then is) analogous to "cat-file" and "diff".

2/4 remedies an oddity of "git cat-file --textconv", which errored out
when there is no textconv filter rather than giving an unfiltered blob
(like every other textconv aware command).

3/4 implements "--textconv" for "git grep" sans the blob case; the code
is all Jeff's.

4/4 adds blob support to 3/4 (the "rev:path" case).

3 and 4 can be squashed, of course.

Now I'm quite a happy differ/shower/grepper with my latin1 and OO files ;)

Jeff King (1):
  grep: allow to use textconv filters

Michael J Gruber (3):
  show: obey --textconv for blobs
  cat-file: do not die on --textconv without textconv filters
  grep: obey --textconv for the case rev:path

 builtin/cat-file.c   |   9 ++--
 builtin/grep.c   |  13 +++---
 builtin/log.c|  24 +--
 grep.c   | 100 +--
 grep.h   |   1 +
 object.c |  26 ---
 object.h |   2 +
 t/t8007-cat-file-textconv.sh |  20 +++--
 8 files changed, 148 insertions(+), 47 deletions(-)

-- 
1.8.1.2.752.g32d147e

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Adding Missing Tags to a Repository

[Michael J Gruber]

Neil venit, vidit, dixit 06.02.2013 05:45:
> Hi everyone,
> 
> A while back I did a svn-to-git migration for my team. Our subversion
> repository had about 30K+ commits, 100+ branches, 2K+ tags, all made
> over a 20+ year period. I was doing the migration using git-svn, and
> my big problem was the tags. git-svn seemed to want to traverse the
> entire history of each tag, which was taking a long time. Because time
> and resources were limited, I ended up just migrating the branches and
> trunk, with the idea that I would handle the tags at a later date. My
> original plan to do that was to crawl the subversion log, find where
> the tags were made, and apply a git tag to the commit that was the
> source of the tag. This was a bad idea.
> 
> I've found that over the years, people have made tags that are only
> subdirectories of the source tree, made tags off of other tags, and
> committed to tags. The latter is the biggest problem, since those
> commits don't seem to be stored in the git repository because they
> never appeared in the branches/trunk.

I think it's fair to say that svn encourages the abuse of tags ;)

I've cleaned up other people's mis-tags myself, and it's no fun. If the
tree layout is messed up then git-svn will often create a new root
commit, so that you have to stitch the history yourself.

In the case of "correct" tags, you're often better of converting the tag
creating commit into an annotated tag, provided that the tree is unchanged.

Tags with tree changes are really branches, usually maintenance branches
after a proper tag.

> So, I'm wondering what my options are to bring back this history. One
> idea is to somehow resume the git-svn download, but changing it to
> also scan tags (it sounds like it should be possible, but I haven't
> tried it yet). Or maybe there's some other tool that will more quickly
> clone the repository including tags, and then I can somehow splice the
> tags back into the repository we're already using?
> 
> Any ideas or suggestions?
> 
> Thanks!
> 

If you add a git-svn refspec to your config and rerun git-svn fetch it
might rescan tags, although you may have to poke around to make it
rescan from revision 1.

Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [WIP/RFH/RFD/PATCH] grep: allow to use textconv filters

[Michael J Gruber]

Jeff King venit, vidit, dixit 05.02.2013 12:13:
> On Mon, Feb 04, 2013 at 04:27:31PM +0100, Michael J Gruber wrote:
> 
>> Recently and not so recently, we made sure that log/grep type operations
>> use textconv filters when a userfacing diff would do the same:
>>
>> ef90ab6 (pickaxe: use textconv for -S counting, 2012-10-28)
>> b1c2f57 (diff_grep: use textconv buffers for add/deleted files, 2012-10-28)
>> 0508fe5 (combine-diff: respect textconv attributes, 2011-05-23)
>>
>> "git grep" currently does not use textconv filters at all, that is
>> neither for displaying the match and context nor for the actual grepping.
>>
>> Introduce a binary mode "--textconv" (in addition to "--text" and "-I")
>> which makes git grep use any configured textconv filters for grepping
>> and output purposes.
> 
> Sounds like a reasonable goal.
> 
>> The difficulty is in getting the different cases (blob/sha1 vs.
>> worktree) right, and in making the changes minimally invasive. It seems
>> that some more refactoring could help: "git show --textconv" does not
>> use textconv filters when used on blobs either. (It does for diffs, of
>> course.) Most existing helper functions are tailored for diffs.
> 
> I think "git show" with blobs originally did not because we have no
> filename with which to look up the attributes. IIRC, the patches to
> support "cat-file --textconv" taught get_sha1_with_context to report the
> path at which we found a blob. I suspect it is mostly a matter of
> plumbing that information from the revision parser through to
> show_blob_object.
> 
>> Nota bene: --textconv does not affect "diff --stat" either...
> 
> Yeah, though I wonder if it should be on by default. The diffstat for a
> binary file, unlike the diff, is already useful. The diffstat of the
> textconv'd data may _also_ be useful, of course.
> 
>> @@ -659,6 +659,9 @@ int cmd_grep(int argc, const char **argv, const char 
>> *prefix)
>>  OPT_SET_INT('I', NULL, &opt.binary,
>>  N_("don't match patterns in binary files"),
>>  GREP_BINARY_NOMATCH),
>> +OPT_SET_INT(0, "textconv", &opt.binary,
>> +N_("process binary files with textconv filters"),
>> +GREP_BINARY_TEXTCONV),
> 
> Is this really a new form of GREP_BINARY_*? What happens when a file
> does not have a textconv filter?
> 
> I would expect this to be more like diff's "--textconv" flag, which is
> really "allow textconv to be respected". Then you could do:
> 
>   git grep -I --textconv foo
> 
> to grep in the text version of files which support it, and ignore the
> rest.
> 
>> -static int grep_source_load(struct grep_source *gs);
>> -static int grep_source_is_binary(struct grep_source *gs);
>> +static int grep_source_load(struct grep_source *gs, struct grep_opt *opt);
>> +static int grep_source_is_binary(struct grep_source *gs, struct grep_opt 
>> *opt);
> 
> Hmm. grep_source_load is more or less the analogue of
> diff_populate_filespec, which does not know about textconv at all. So I
> feel like this might be going in at the wrong layer...
> 
>> @@ -1354,14 +1356,15 @@ static int grep_source_1(struct grep_opt *opt, 
>> struct grep_source *gs, int colle
>>  
>>  switch (opt->binary) {
>>  case GREP_BINARY_DEFAULT:
>> -if (grep_source_is_binary(gs))
>> +if (grep_source_is_binary(gs, opt))
>>  binary_match_only = 1;
>>  break;
>>  case GREP_BINARY_NOMATCH:
>> -if (grep_source_is_binary(gs))
>> +if (grep_source_is_binary(gs, opt))
>>  return 0; /* Assume unmatch */
>>  break;
> 
> The is_binary function learned about "opt" so that it could pass it to
> grep_source_load, which might do the textconv for us. But we _know_ that
> we will not here, because we see that we have other GREP_BINARY flags.
> 
> And when we do have _TEXTCONV:
> 
>>  case GREP_BINARY_TEXT:
>> +case GREP_BINARY_TEXTCONV:
>>  break;
> 
> We do not call is_binary. :)
> 
>> -static int grep_source_load_sha1(struct grep_source *gs)
>> +static int grep_source_load_sha1(struct grep_source *gs, struct grep_opt 
>> *opt)
>>  {
>>  enum object_type type;
>> -
>>  grep_read_lock();
>> -gs->buf = read_sha1_file(gs->

Re: [RFC] Should "log --cc" imply "log --cc -p"?

[Michael J Gruber]

Junio C Hamano venit, vidit, dixit 04.02.2013 17:36:
> Michael J Gruber  writes:
> 
>> But diffs are on here ("-p"), it's just that the default diff option for
>> merges is to not display them. Well, I admit there's two different ways
>> of thinking here:
>>
>> A) "git log -p" turns on diffs for all commits, and the default diff
>> options is the (non-existing) "--no-show" diff-option for merges.
>>
>> B) "git log -p" applies "-p" to all commits except merge commits.
>>
>> I'm strongly in the A camp,...
> 
> I can personally be trained to think either way, but I suspect that
> we already came halfway to
> 
>   C) "-p" asks for two-way patches, and "-c/--cc" ask for n-way
>  patches (including but not limited to n==2); it is not that -p
>  asks for patch generation and others modify the finer behaviour
>  of patch generation.
> 
> "git log/diff-files -U8" do not need "-p" to enable textual patches,
> for example.  It is "I already told you that I want 8-line context.

That's a good point that I wasn't aware of.

> For what else, other than showing textual diff, do you think I told
> you that for?" and replacing "8-line context" with various other
> options that affect patch generation will give us a variety of end
> user complaints that would tell us that C) is more intuitive to
> them.
> 
> But I do not feel very strongly that I am *right* on this issue, so
> I won't do anything about it hastily right now.

I'm not sure how many of these we have already, but to me it indicates
that we should turn diffs on for log with any diff option that only
makes sense with a diff. That would make the ui more consistent without
taking anything away.

For scripting/aliasing purposes, we have "-s" in order to override any
implied "-p" (as I just learned).

Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [WIP/RFH/RFD/PATCH] grep: allow to use textconv filters

[Michael J Gruber]

Junio C Hamano venit, vidit, dixit 04.02.2013 18:12:
> Michael J Gruber  writes:
> 
>> Recently and not so recently, we made sure that log/grep type operations
>> use textconv filters when a userfacing diff would do the same:
>>
>> ef90ab6 (pickaxe: use textconv for -S counting, 2012-10-28)
>> b1c2f57 (diff_grep: use textconv buffers for add/deleted files, 2012-10-28)
>> 0508fe5 (combine-diff: respect textconv attributes, 2011-05-23)
>>
>> "git grep" currently does not use textconv filters at all, that is
>> neither for displaying the match and context nor for the actual grepping.
>>
>> Introduce a binary mode "--textconv" (in addition to "--text" and "-I")
>> which makes git grep use any configured textconv filters for grepping
>> and output purposes.
>>
>> Signed-off-by: Michael J Gruber 
>> ---
>>
>> Notes:
>> I'm somehow stuck in textconv/filespec/... hell, so I'm sending this out
>> in request for help. I'm sure there are people for whom it's a breeze to
>> get this right.
> 
> Looks like the patch touches the right places in the codepaths that
> need to be updated from a quick read.

I should have added that this coredumps when used on blobs and that
textconv isn't invoked in any case (because it crashes on blobs, and I
haven't implemented tetxconv on worktree files yet).

I'm somehow struggling to use just the right bits from the more diff
centric helpers like fill_textconv or fill_one (which is static so far).

>> The difficulty is in getting the different cases (blob/sha1 vs.
>> worktree) right, and in making the changes minimally invasive.
> 
> I think grep_source abstraction was intended to be a way for that,
> and if what it gives you is not sufficient for your needs, extending
> it should not be seen as "invasive" at all.

It seems to me that we textconvified the diff versions of these
abstractions, but not the grep_source abstractions. Doing it at the
source appears to be the right thing.

Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[WIP/RFH/RFD/PATCH] grep: allow to use textconv filters

[Michael J Gruber]

Recently and not so recently, we made sure that log/grep type operations
use textconv filters when a userfacing diff would do the same:

ef90ab6 (pickaxe: use textconv for -S counting, 2012-10-28)
b1c2f57 (diff_grep: use textconv buffers for add/deleted files, 2012-10-28)
0508fe5 (combine-diff: respect textconv attributes, 2011-05-23)

"git grep" currently does not use textconv filters at all, that is
neither for displaying the match and context nor for the actual grepping.

Introduce a binary mode "--textconv" (in addition to "--text" and "-I")
which makes git grep use any configured textconv filters for grepping
and output purposes.

Signed-off-by: Michael J Gruber 
---

Notes:
I'm somehow stuck in textconv/filespec/... hell, so I'm sending this out
in request for help. I'm sure there are people for whom it's a breeze to
get this right.

The difficulty is in getting the different cases (blob/sha1 vs.
worktree) right, and in making the changes minimally invasive. It seems
that some more refactoring could help: "git show --textconv" does not
use textconv filters when used on blobs either. (It does for diffs, of
course.) Most existing helper functions are tailored for diffs.

Nota bene: --textconv does not affect "diff --stat" either...

 builtin/grep.c |  5 -
 grep.c | 47 +--
 grep.h |  3 ++-
 3 files changed, 35 insertions(+), 20 deletions(-)

diff --git a/builtin/grep.c b/builtin/grep.c
index 8025964..2181c22 100644
--- a/builtin/grep.c
+++ b/builtin/grep.c
@@ -96,7 +96,7 @@ static void add_work(struct grep_opt *opt, enum 
grep_source_type type,
 
grep_source_init(&todo[todo_end].source, type, name, path, id);
if (opt->binary != GREP_BINARY_TEXT)
-   grep_source_load_driver(&todo[todo_end].source);
+   grep_source_load_driver(&todo[todo_end].source, opt);
todo[todo_end].done = 0;
strbuf_reset(&todo[todo_end].out);
todo_end = (todo_end + 1) % ARRAY_SIZE(todo);
@@ -659,6 +659,9 @@ int cmd_grep(int argc, const char **argv, const char 
*prefix)
OPT_SET_INT('I', NULL, &opt.binary,
N_("don't match patterns in binary files"),
GREP_BINARY_NOMATCH),
+   OPT_SET_INT(0, "textconv", &opt.binary,
+   N_("process binary files with textconv filters"),
+   GREP_BINARY_TEXTCONV),
{ OPTION_INTEGER, 0, "max-depth", &opt.max_depth, N_("depth"),
N_("descend at most  levels"), PARSE_OPT_NONEG,
NULL, 1 },
diff --git a/grep.c b/grep.c
index 4bd1b8b..410b7b8 100644
--- a/grep.c
+++ b/grep.c
@@ -1,10 +1,12 @@
 #include "cache.h"
+#include "diff.h"
+#include "diffcore.h"
 #include "grep.h"
 #include "userdiff.h"
 #include "xdiff-interface.h"
 
-static int grep_source_load(struct grep_source *gs);
-static int grep_source_is_binary(struct grep_source *gs);
+static int grep_source_load(struct grep_source *gs, struct grep_opt *opt);
+static int grep_source_is_binary(struct grep_source *gs, struct grep_opt *opt);
 
 static struct grep_opt grep_defaults;
 
@@ -1174,7 +1176,7 @@ static int match_funcname(struct grep_opt *opt, struct 
grep_source *gs, char *bo
 {
xdemitconf_t *xecfg = opt->priv;
if (xecfg && !xecfg->find_func) {
-   grep_source_load_driver(gs);
+   grep_source_load_driver(gs, opt);
if (gs->driver->funcname.pattern) {
const struct userdiff_funcname *pe = 
&gs->driver->funcname;
xdiff_set_find_func(xecfg, pe->pattern, pe->cflags);
@@ -1354,14 +1356,15 @@ static int grep_source_1(struct grep_opt *opt, struct 
grep_source *gs, int colle
 
switch (opt->binary) {
case GREP_BINARY_DEFAULT:
-   if (grep_source_is_binary(gs))
+   if (grep_source_is_binary(gs, opt))
binary_match_only = 1;
break;
case GREP_BINARY_NOMATCH:
-   if (grep_source_is_binary(gs))
+   if (grep_source_is_binary(gs, opt))
return 0; /* Assume unmatch */
break;
case GREP_BINARY_TEXT:
+   case GREP_BINARY_TEXTCONV:
break;
default:
die("bug: unknown binary handling mode");
@@ -1372,7 +1375,7 @@ static int grep_source_1(struct grep_opt *opt, struct 
grep_source *gs, int colle
 
try_lookahead = should_lookahead(opt);
 
-   if (grep_source_load(gs) < 0)
+   if (grep_source_load(gs, opt) < 0)
   

Re: Feature request: Allow extracting revisions into directories

[Michael J Gruber]

Robert Clausecker venit, vidit, dixit 03.02.2013 15:18:
> Hello!
> 
> git currently has the archive command that allows to save an arbitrary
> revision into a tar or zip file. Sometimes it is useful to not save this
> revision into an archive but to directly put all files into an arbitrary
> directory. Currently this seems to be not possible to archive directly;
> the only way I found to do it is to run git archive and then directly
> unpack the archive into a directory.
> 
> git --git-dir REPO archive REVISION | tar x
> 
> It would be nice to have a command or simply a switch to git archive
> that allows the user to put the files of REVISION into a directory
> instead of making an archive.
> 
> Thank you very much for your help. Yours,
> 
> Robert Clausecker

Sitaram has said much about the Unix philosophy already, and Konstantin
gave a variant of checkout. Just two more cents:

How would you copy a directory tree? I presume you wouldn't use "tar c .
| tar -xC gothere", but what would be your worklflow?

Depending on what you actually want to achieve, "git clone -b branch"
and removing the superfluous .git-dir might be a viable option. (Beware
the hardlinks, though.)

Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] Should "log --cc" imply "log --cc -p"?

[Michael J Gruber]

Junio C Hamano venit, vidit, dixit 04.02.2013 00:10:
> I think a natural way to ask reviewing the recent merges while
> showing tricky ones would be to say:
> 
>   $ git log --first-parent --cc master..pu
> 
> But this does not to show what I expect to see, which is an output
> of:
> 
>   $ git log --first-parent --cc -p master..pu
> 

I'm not Junio, but I guess he would respond that it's a matter of
expectations: "--cc" is a diff option, and just like any other diff
option, it has an effect on "log" only if "log" has been told to show a
diff.

Oh wait, you *are* Junio ;)

> This is only a minor irritation, but I think it might make sense to
> make it notice the --cc in the former and turn -p on automatically.

I think we have a clear distiction between rev-list/log options and diff
options. "log" comes without a diff, "-p" turns on diffs.

"log" passes diff-options to "diff". If the user gives a diff-option to
"log" we can conclude that he meant to request a diff and turn them on
automatically (as if "-p" was there also).

But I'm wondering whether that has adverse effects on scripts/aliases.
For example, I could have a special alias

newpu = log first-parent --cc next..pu

which allows me to use "git newpu" as well as "git newpu -p" to get
those new commits with or without diff in my preferred format, but not
any more after the change you suggest. (I could use a second alias, of
course; and yes, I'm (ab)using current option parser features.)

> The same for
> 
>   $ git log --cc next~3..next
> 
> which may make sense to turn into "git log -p --cc next~3..next".
> 
> When deciding if the above makes sense, there are a few things to
> know to be true as prerequisites for the discussion:
> 
>  * Neither of these
> 
>   $ git log --first-parent -p master..pu
>   $ git log -p master..pu
> 
>shows any patches, and it is not a bug.  No patches are shown for
>merges unless -m is given, and when -m is given, we give pairwise
>2-way diffs for the number of parents.

But diffs are on here ("-p"), it's just that the default diff option for
merges is to not display them. Well, I admit there's two different ways
of thinking here:

A) "git log -p" turns on diffs for all commits, and the default diff
options is the (non-existing) "--no-show" diff-option for merges.

B) "git log -p" applies "-p" to all commits except merge commits.

I'm strongly in the A camp, because I think that this gives a clearer
interface. A really describes the user facing side, whereas B is closer
to the implementation.

>  * We recently tweaked this:
> 
>   $ git log --first-parent -m -p master..pu
> 
>to omit diffs with second and later parents, as that is what the
>user wishes with --first-parent.

That made --first-parent into a dual-purpose option, i.e. it modifies
the rev-listing to one parent as well as the diff creation. It does not
turn on diffs by itself.

>  * The "--cc" option, when comparing two trees (i.e. showing a
>non-merge commit), is designed to show a normal patch.  In other
>words, you can view "--cc" as a modifier when you request a patch
>output format with "-p".  For "git show", "--cc -p" is turned on
>by default, and giving "-m" explicity (i.e. "git show -m") you
>can turn it off and have it do "-m -p" instead.
> 

Yes, I really think of --cc is a diff-option, and that this point of
view gives the clearest ui.

We could argue that any diff-option could switch on diffs (imply -p),
but that change seems to be quite radical. "show" having "-p" as a
default is quite natural, but that is different.

Having only "--cc" imply "-p" would be too much special case auto-magic
for my taste. We have too many of these already.

I really think we should leave it as is.

Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [feature request] git add completion should exclude staged content

[Michael J Gruber]

Manlio Perillo venit, vidit, dixit 28.01.2013 15:02:
> Il 28/01/2013 13:52, Michael J Gruber ha scritto:
>> Manlio Perillo venit, vidit, dixit 28.01.2013 10:26:
>>> Il 28/01/2013 00:00, Junio C Hamano ha scritto:
>>>> wookietreiber  writes:
>>>
>>>>> I have a feature request for `git add` auto completion:
>>>>>
>> [...]
>>> For the OP: the last patch can be found in the mailing list archive,
>>> with the subject:
>>> [PATCH v5] git-completion.bash: add support for path completion
>>> and date:
>>> Fri, 11 Jan 2013 19:48:43 +0100
>>>
>>> Can you please test it?
>>>
> 
>> I haven't looked at the patch, but in the example above, untracked
>> files) could be added as well (unless you use -u), so maybe the scope
>> should depend on the option? If the new completion code kept me from
>> adding untracked files easily it wouldn't be an improvement.
> 
> 
> The patch will suggest (for git add command), all the files that are
> candidate to be added to the index file.
> 
> Please, test it and report any behaviour you think is incorrect.

OK, that seems to work and to be quite helpful.

Minor nit: "git add -u" could use the same fileset as "git commit". But
I don't know whether completion can act upon the presence of options.
Currently, it also includes untracked files (just like without -u) but
omits unmodified and ignored ones, which is already quite an improvement.

I won't be able to review the completion code but may contribute a few
lines to t/t9902-completion.sh, possibly.

Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [feature request] git add completion should exclude staged content

[Michael J Gruber]

Manlio Perillo venit, vidit, dixit 28.01.2013 10:26:
> Il 28/01/2013 00:00, Junio C Hamano ha scritto:
>> wookietreiber  writes:
> 
>>> I have a feature request for `git add` auto completion:
>>>
>>> `git add` auto completion suggests all files / directories,
>>> filtered by nothing. I guess it would be much nicer (as in
>>> increasing productivity) if it would only suggest unstaged
>>> content, as reported by `git status`, because that would be the
>>> only content one would be able to add.
> 
>> I think that is what Manlio Perillo tried to do with the stalled
>> mp/complete-paths topic that is queued in 'pu'.
> 
>> Manlio, any progress?
> 
> Well, I assumed that the patch was stalled due to missing review from
> git completion experts...
> 
> For this reason I have not updated it with your latest suggestions,
> waiting for the review (also, because now I'm busy with other projects).
> 
> For the OP: the last patch can be found in the mailing list archive,
> with the subject:
>   [PATCH v5] git-completion.bash: add support for path completion
> and date:
>   Fri, 11 Jan 2013 19:48:43 +0100
> 
> Can you please test it?
> 
> 
> 
> 
> Regards   Manlio
> 

I haven't looked at the patch, but in the example above, untracked
files) could be added as well (unless you use -u), so maybe the scope
should depend on the option? If the new completion code kept me from
adding untracked files easily it wouldn't be an improvement.

Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3] add: warn when -u or -A is used without filepattern

[Michael J Gruber]

Matthieu Moy venit, vidit, dixit 28.01.2013 10:16:
> Most git commands that can be used with our without a filepattern are
> tree-wide by default, the filepattern being used to restrict their scope.
> A few exceptions are: 'git grep', 'git clean', 'git add -u' and 'git add -A'.

Since I didn't follow this thread, my first reaction was: "Huh? Aren't
they treewide?" (for the relative tree)

So, for someone reading just the commit message, it would be helpful to
say what the others do, i.e. default to the relative tree at pwd (rather
than defaulting to an empty tree, or all files whether tracked or not,
or...).

Otherwise, I'd rather switch sooner than later; it's so easy to take
"git add -u && git commit == git commit -a" for granted and to miss
staging some hunks. But 2.0 is around the corner anyway, isn't it ;)

> The inconsistency of 'git add -u' and 'git add -A' are particularly
> problematic since other 'git add' subcommands (namely 'git add -p' and
> 'git add -e') are tree-wide by default.
> 
> Flipping the default now is unacceptable, so this patch starts training
> users to type explicitely 'git add -u|-A :/' or 'git add -u|-A .', to prepare
> for the next steps:
> 
> * forbid 'git add -u|-A' without filepattern (like 'git add' without
>   option)
> 
> * much later, maybe, re-allow 'git add -u|-A' without filepattern, with a
>   tree-wide scope.
> 
> A nice side effect of this patch is that it makes the :/ special
> filepattern easier to discover for users.
> 
> When the command is called from the root of the tree, there is no
> ambiguity and no need to change the behavior, hence no need to warn.
> 
> Signed-off-by: Matthieu Moy 
> ---
> Changes since v2:
> 
> * Typo consistant -> consistent
> 
> * Mention both short and long option names (Thanks Junio). I went for
>   a two-lines display which I find a bit nicer to read than Junio's
>   version, but I'm fine with both.
> 
>  Documentation/git-add.txt |  7 ---
>  builtin/add.c | 44 +++-
>  2 files changed, 47 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
> index fd9e36b..5333559 100644
> --- a/Documentation/git-add.txt
> +++ b/Documentation/git-add.txt
> @@ -107,9 +107,10 @@ apply to the index. See EDITING PATCHES below.
>   from the index if the corresponding files in the working tree
>   have been removed.
>  +
> -If no  is given, default to "."; in other words,
> -update all tracked files in the current directory and its
> -subdirectories.
> +If no  is given, the current version of Git defaults to
> +"."; in other words, update all tracked files in the current directory
> +and its subdirectories. This default will change in a future version
> +of Git, hence the form without  should not be used.
>  
>  -A::
>  --all::
> diff --git a/builtin/add.c b/builtin/add.c
> index 7cb6cca..7738025 100644
> --- a/builtin/add.c
> +++ b/builtin/add.c
> @@ -321,6 +321,35 @@ static int add_files(struct dir_struct *dir, int flags)
>   return exit_status;
>  }
>  
> +static void warn_pathless_add(const char *option_name, const char 
> *short_name) {
> + /*
> +  * To be consistent with "git add -p" and most Git
> +  * commands, we should default to being tree-wide, but
> +  * this is not the original behavior and can't be
> +  * changed until users trained themselves not to type
> +  * "git add -u" or "git add -A". For now, we warn and
> +  * keep the old behavior. Later, this warning can be
> +  * turned into a die(...), and eventually we may
> +  * reallow the command with a new behavior.
> +  */
> + warning(_("The behavior of 'git add %s (or %s)' with no path argument 
> from a\n"
> +   "subdirectory of the tree will change in Git 2.0 and should 
> not be used anymore.\n"
> +   "To add content for the whole tree, run:\n"
> +   "\n"
> +   "  git add %s :/\n"
> +   "  (or git add %s :/)\n"
> +   "\n"
> +   "To restrict the command to the current directory, run:\n"
> +   "\n"
> +   "  git add %s .\n"
> +   "  (or git add %s .)\n"
> +   "\n"
> +   "With the current Git version, the command is restricted to 
> the current directory."),
> + option_name, short_name,
> + option_name, short_name,
> + option_name, short_name);
> +}
> +
>  int cmd_add(int argc, const char **argv, const char *prefix)
>  {
>   int exit_status = 0;
> @@ -331,6 +360,8 @@ int cmd_add(int argc, const char **argv, const char 
> *prefix)
>   int add_new_files;
>   int require_pathspec;
>   char *seen = NULL;
> + const char *option_with_implicit_dot = NULL;
> + const char *short_option_with_implicit_dot = NULL;
>  
>   git_config(add_config, NULL);
>  
> @@ -350,8 +381,19 @@ int cmd_add(int argc, const char **argv, const char 
> *p

Re: Port 22

[Michael J Gruber]

Kevin venit, vidit, dixit 28.01.2013 09:06:
> This is not really a git problem, but more of an ssh problem.
> 
> Are you in the position to change the port where the SSH daemon
> listens on? Then you could use a different port which isn't blocked
> (443 perhaps?).
> 
> On Sat, Jan 26, 2013 at 7:56 PM, Craig Christensen  wrote:
>> I am currently a student at Brigham Young University - Idaho and we are use 
>> Pagoda Box and Git for our Mobile Apps class.  However, the school's network 
>> has blocked incoming trafic on port 22.  I have been searching through all 
>> the tutorials and documents provided by Pagoda Box and Git but have not been 
>> able to find a solution to solve this problem.  We can use sftp but we then 
>> have to manually deploy the latest using the admin panel.  Can you help 
>> provide a simple solution?

So how is your setup:

- Pagoda Box instance at BYU
- sftp uploads allowed, but not ssh
- drive Git on the box using the admin interface

Or do you use a Pagoda server? Do you have read access to the git repo
on the box?

ssh allows to restrict commands to only a subset, such as ssh only. If
the port were blocked for incoming traffic you wouldn't be able to use
(ssh at all thus) sftp either.

Michael

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Unable to convert a subversion repo to git

[Michael J Gruber]

Timothy Kretschmer venit, vidit, dixit 18.01.2013 17:59:
> The exact names of the branches are "CMT_PHASE3" and
> "BlueSimViewer5.0_20110316_Branch"

Just to be sure, not to doubt you: the svn branch name is
"BlueSimViewer5.0_20110316_Branch" and thus differs from the name
reported by git-svn? Are there maybe unprintable characters/control
codes or something in the svn branch name?

Somehow, git-svn is using an improper refname.

> File system on the converting machine is ext4. SVN server is hosted on
> a Fedora 8 box , running subversion 1.4.x.
> To move forward, I commented out the problematic branches under
> .git/packed-refs. Conversion continued but skipped the troubled
> branches.
> Still on the road of finding a way to include those branches in the 
> conversion.
> 
> On Fri, Jan 18, 2013 at 11:48 AM, Michael J Gruber
>  wrote:
>> Timothy Kretschmer venit, vidit, dixit 16.01.2013 15:06:
>>> I am seeing the following output while converting a subversion repo to git.
>>>
>>>  >Found possible branch point: /trunk =>
>>> /branches/CMT_PHASE3, 18441
>>>> fatal: Not a valid object name refs/remotes/BlueSimViewer 5.0 20110316 
>>>> Branch
>>>> cat-file commit refs/remotes/BlueSimViewer 5.0 20110316 Branch: command 
>>>> returned error: 128
>>>
>>> The command I am running to convert the repo is
>>>
>>>> git svn clone  -A authors-transform.txt --stdlayout bluebox-git 
>>>> > svnlist
>>>
>>> I am running git version 1.8.1.1 on an Ubuntu 12.10 server. I am happy
>>> to provide any other information that would be helpful.
>>>
>>> I appreciate any assistance you can provide in this matter,
>>>   -Tim
>>
>> git-svn should cope with funky branch names. What is the exact name of
>> the "CMT..." and "BlueSimViewer..." branches? Are you using a case
>> challenged file system or just some standard linux fs?
>>
>> Michael
>>
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Unable to convert a subversion repo to git

[Michael J Gruber]

Timothy Kretschmer venit, vidit, dixit 16.01.2013 15:06:
> I am seeing the following output while converting a subversion repo to git.
> 
>  >Found possible branch point: /trunk =>
> /branches/CMT_PHASE3, 18441
>> fatal: Not a valid object name refs/remotes/BlueSimViewer 5.0 20110316 Branch
>> cat-file commit refs/remotes/BlueSimViewer 5.0 20110316 Branch: command 
>> returned error: 128
> 
> The command I am running to convert the repo is
> 
>> git svn clone  -A authors-transform.txt --stdlayout bluebox-git > 
>> svnlist
> 
> I am running git version 1.8.1.1 on an Ubuntu 12.10 server. I am happy
> to provide any other information that would be helpful.
> 
> I appreciate any assistance you can provide in this matter,
>   -Tim

git-svn should cope with funky branch names. What is the exact name of
the "CMT..." and "BlueSimViewer..." branches? Are you using a case
challenged file system or just some standard linux fs?

Michael

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [BUG] Possible bug in `remote set-url --add --push`

[Michael J Gruber]

Phil Hord venit, vidit, dixit 16.01.2013 17:15:
> On Tue, Jan 15, 2013 at 10:53 AM, Junio C Hamano  wrote:
>> Michael J Gruber  writes:
>>
>>> That being said, I don't mind changing the behaviour of set-url.
>>
>> I do not think we want to change the behaviour of set-url.
> 
> I agree with Michael that changing the set-url behavior would be
> appropriate here.  If I say "--add" this pushUrl, don't I mean to
> create an additional url which is pushed to?

I said I wouldn't mind, I didn't vote for it.

> I agree that it makes the config situation messy; this is currently a
> "clean" sequence, in that it leaves the config unchanged after both
> steps are completed:
> 
>   git remote set-url --add --push origin /tmp/foo
>   git remote set-url --delete --push origin /tmp/foo
> 
> If the behavior is changed like Michael suggested, it would not leave
> the config clean (unless heroic steps were taken to keep track).  But
> I'm not sure that's such a bad thing.  In simple command sequences,
> the results would be clean and the only behavior change is that the
> initial "--add" really acts like "add" and not "replace".  But more
> complex sequences could be devised which were affected by this change.
> 
> I'm curious, Junio.  Do you think the set-url behavior is correct
> as-is, or that changing it will cause breakage for some workflows, or
> that it complicates the operation too much for people who are already
> used to the config layout?

For "set url --add --push" on top of a push url only being defaulted
from a fetch url, both behaviours (replace or add, i.e. current or new)
make sense to me. So the questions are:

- Is it worth and possible changing?
- How to best describe it in "remote -v" and "remote show" output?

My patch answered to "no" to the first question and answers the second
one in cases where (push)insteadof is not used to transform one fetch
config into two different urls for fetch and push. I think :)

Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [BUG] Possible bug in `remote set-url --add --push`

[Michael J Gruber]

Junio C Hamano venit, vidit, dixit 16.01.2013 16:50:
> Michael J Gruber  writes:
> 
>> Junio C Hamano venit, vidit, dixit 15.01.2013 16:53:
>> ...
>>>  * When there are more than one URLs, and there is no pushURL, then
>>>show the first URL as (fetch/push), and the remainder in a
>>>notation that says it is used only for push, but it shouldn't be
>>>the same "(push)"; the user has to be able to distinguish it from
>>>the pushURLs in a repository that also has URLs.
>>
>> Maybe "(fetch fallback/push)" if we do use it as a fallback? If we don't
>> we probably should?
> 
> I actually think my earlier "it shouldn't be the same (push)" is not
> needed and probably is actively wrong.  Just like you can tell
> between
> 
> (only one .url) (both .url and .pushurl)
> 
> origin there (fetch/push)   origin there (fetch)
> origin there (push)
> 
> even when the value of the URL/PushURL, i.e. "there", is the same
> between .url and .pushurl, you should be able to tell between
> 
> (two .url, no .pushurl) (one .url and one .pushurl)
> 
> origin there (fetch/push)   origin there (fetch)
> origin another (push)   origin another (push)
> 
> So let's not make it too complex and forget about the different kind
> of "(push)".
> 
> A case that is a potential misconfiguration would look like:
> 
> (two .url, one .pushurl)
> 
> origin there (fetch)
> origin some  (unused)
> origin another (push)
> 
> I think.

I'm sorry but E_NOPARSE. I can't grok the above at all. But I'll try
again tomorrow ;)

In any case, the issue with (push)instead of that John mentions bothers
me: there are "two specified URLs" but one URL in config only; my patch
doesn't make that case clearer at all. My early attempts at amending
struct remote produced too many segfaults to continue today...

Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] git-remote: distinguish between default and configured URLs

[Michael J Gruber]

John Keeping venit, vidit, dixit 16.01.2013 11:42:
> On Wed, Jan 16, 2013 at 11:14:48AM +0100, Michael J Gruber wrote:
>> The current output of "git remote -v" does not distinguish between
>> explicitly configured push URLs and those coming from fetch lines.
>>
>> Revise the output so so that URLs are distinguished by their labels:
>>
>> (fetch): fetch config used for fetching only
>> (fetch/push): fetch config used for fetching and pushing
>> (fetch fallback/push): fetch config used for pushing only
>> (fetch fallback): fetch config which is unused
>> (push): push config used for pushing
> 
> How does this interact with url..pushInsteadOf?
> 
> I have a global rule to convert git:// URLs to ssh:// for pushing:
> 
> [url "g...@example.com:"]
> pushInsteadOf = git://example.com/
> 
> With only a URL configured for a remote (no pushURL), I get (with Git
> 1.8.1):
> 
> origin git://example.com/repository.git (fetch)
> origin g...@example.com:repository.git (push)
> 
> From the original discussion in this thread, I think that if I did
> "git remote set-url --add --push " it would replace my current push
> URL, and the change to "(fetch/push)" doesn't help in this case.
> 
> Should there be special handling for pushInsteadOf here?
> 
> 
> John

Thanks for pointing out this case.

The new code would still list this as two separate URLs because they
really are; whether they come from two config entries or from one being
subject to two different insteadof expansions is completely opaque to
builtin/remote.c, unless remote.c learns to stick that additional info
into struct remote somehow.

In short, the separate listing is correct, but in this case there's no
improvement in readability.

We could still say that (push)InsteadOf is a power feature and we want
to help the "normal" case, but it's a bit half-assed. In the end we
might even have to keep track of insteadof-expansions and display those
also (i.e. "expanded from...")?

Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] git-remote: distinguish between default and configured URLs

[Michael J Gruber]

Michael J Gruber venit, vidit, dixit 16.01.2013 11:14:
> The current output of "git remote -v" does not distinguish between
> explicitly configured push URLs and those coming from fetch lines.
> 
> Revise the output so so that URLs are distinguished by their labels:
> 
> (fetch): fetch config used for fetching only
> (fetch/push): fetch config used for fetching and pushing
> (fetch fallback/push): fetch config used for pushing only
> (fetch fallback): fetch config which is unused
> (push): push config used for pushing
> 
> Signed-off-by: Michael J Gruber 
> ---
> Maybe something like this? It even seems to make the code in get_one_entry
> clearer.
> 
> I yet have to look at the tests, doc and other git-remote invocations.

Okay, so "git remote show remotename" copied the logic from "git remote
-v" but neither reused the code nor the output format. I guess we'd have
to implement the new logic and keep the old format? Refactoring would
require settling on a common format. Both outputs should be
ui-as-ui-can, but I'm afraid people are still grepping the output in
their scripts :(

Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] git-remote: distinguish between default and configured URLs

[Michael J Gruber]

The current output of "git remote -v" does not distinguish between
explicitly configured push URLs and those coming from fetch lines.

Revise the output so so that URLs are distinguished by their labels:

(fetch): fetch config used for fetching only
(fetch/push): fetch config used for fetching and pushing
(fetch fallback/push): fetch config used for pushing only
(fetch fallback): fetch config which is unused
(push): push config used for pushing

Signed-off-by: Michael J Gruber 
---
Maybe something like this? It even seems to make the code in get_one_entry
clearer.

I yet have to look at the tests, doc and other git-remote invocations.

 builtin/remote.c | 31 +--
 1 file changed, 17 insertions(+), 14 deletions(-)

diff --git a/builtin/remote.c b/builtin/remote.c
index 937484d..ec07109 100644
--- a/builtin/remote.c
+++ b/builtin/remote.c
@@ -1509,25 +1509,28 @@ static int get_one_entry(struct remote *remote, void 
*priv)
 {
struct string_list *list = priv;
struct strbuf url_buf = STRBUF_INIT;
-   const char **url;
-   int i, url_nr;
+   char *fetchurl0, *fetchurl1;
+   int i;
+
+   if (remote->pushurl_nr > 0) {
+   fetchurl0 = "fetch";
+   fetchurl1 = "fetch fallback";
+   } else {
+   fetchurl0 = "fetch/push";
+   fetchurl1 = "fetch fallback/push";
+   }
 
-   if (remote->url_nr > 0) {
-   strbuf_addf(&url_buf, "%s (fetch)", remote->url[0]);
+   for (i = 0; i < remote->url_nr; i++) {
+   strbuf_addf(&url_buf, "%s (%s)", remote->url[0], i ? fetchurl1 
: fetchurl0);
string_list_append(list, remote->name)->util =
strbuf_detach(&url_buf, NULL);
-   } else
+   } /* else */
+   if (remote->url_nr == 0)
string_list_append(list, remote->name)->util = NULL;
-   if (remote->pushurl_nr) {
-   url = remote->pushurl;
-   url_nr = remote->pushurl_nr;
-   } else {
-   url = remote->url;
-   url_nr = remote->url_nr;
-   }
-   for (i = 0; i < url_nr; i++)
+
+   for (i = 0; i < remote->pushurl_nr; i++)
{
-   strbuf_addf(&url_buf, "%s (push)", url[i]);
+   strbuf_addf(&url_buf, "%s (push)", remote->pushurl[i]);
string_list_append(list, remote->name)->util =
strbuf_detach(&url_buf, NULL);
}
-- 
1.8.1.1.456.g93e7b0a

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [BUG] Possible bug in `remote set-url --add --push`

[Michael J Gruber]

Junio C Hamano venit, vidit, dixit 15.01.2013 16:53:
> Michael J Gruber  writes:
> 
>> Also there is a conceptual confusion: pushurl is meant to push to the
>> same repo using a different url, e.g. something authenticated
>> (https/ssh) for push and something faster/easier for fetch.
> 
> That is not necessarily true, depending on the definition of your
> "same".  Having multiple URLs/PushURLs that refer to physically
> different locations, as long as "git push there" immediately
> followed by "git fetch here" should work with the repositories that
> are conceptually equivalent, is a supported mode of operation. In

That is my definition of "same", in the sense of "object-and-ref-same"
when "in-sync" (at least regarding all pushed refs; there may be more
there).

> fact, they being physically different _was_ the original motivation
> of the feature. See 755225d (git builtin "push", 2006-04-29).

I thought it was about unauthenticated git-protocol vs. git+ssh but was
wrong.

> The definition of the "immediate" above also depends on your use; it
> could be tens of minutes (you may be fetching from git.k.org that
> can be reached from the general public, which may be a cname for
> multiple machines mirroring a single master.k.org that k.org account
> holders push to, and there may be propagation delays).  In such a
> scenario, your URL may point at the public git.k.org, pushURL may
> point at master.k.org, and you may have other pushURLs that point at
> other places you use as back-up locations (e.g. git.or.cz or
> github.com).

Yes. That is also why we fetch from one fetch URL only, because we
assume they point at the "same" repo and don't need to check.

> As long as you _mean_ to maintain their contents the same, you can
> call them conceptually "the same repo" and your statement becomes
> true.
> 
>> It never was meant to push to several repos.
> 
> This is false.  It _was_ designed to be used that way from day one.

It is very true with me definition of "same" ;)

> (I am not saying using it in other ways is an abuse---I am merely
> saying that pushing to multiple physically different repositories is
> within its scope).
> 
>> That being said, I don't mind changing the behaviour of set-url.
> 
> I do not think we want to change the behaviour of set-url.  What
> needs to be fixed is the output from "remote -v".  It should:
> 
>  * When there is no pushURL but there is a URL, then show it as
>(fetch/push), and you are done;
> 
>  * When there is one or more pushURLs and a URL, then show the URL
>as (fetch), and show pushURLs as (push), and you are done;
> 
>  * When there are more than one URLs, and there is no pushURL, then
>show the first URL as (fetch/push), and the remainder in a
>notation that says it is used only for push, but it shouldn't be
>the same "(push)"; the user has to be able to distinguish it from
>the pushURLs in a repository that also has URLs.

Maybe "(fetch fallback/push)" if we do use it as a fallback? If we don't
we probably should?

>  * When there are more than one URLs, and there are one or more
>pushURLs, then show the first URL as (fetch), the other URLs
>as (unused), and the pushURLs as (push).
> 
> Strictly speaking, the last one could be a misconfiguration.  If you
> have:
> 
>   [remote "origin"]
>   url = one
> url = two
> pushurl = three
> pushurl = four
> 
> then your "git fetch" will go to one, and "git push" will go to
> three and four, and two is never used.

Do we fall back to two if one is unavailable? In any case, people may
use a configuration like that to keep track of mirrors and shuffle
around the fetch lines (rather than commenting/uncommenting) when one
goes offline.

> It should also be stressed that the third one a supported
> configuration.  With
> 
>   [remote "origin"]
>   url = one
> url = two
> 
> your "git fetch" goes to one, and your "git push" will go to one and
> two.  This is the originally intended use case of 755225d.  It is to
> push to and fetch from master.k.org (think of "one" above) and in
> addition to push to backup.github.com ("two").

Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [BUG] Possible bug in `remote set-url --add --push`

[Michael J Gruber]

Junio C Hamano venit, vidit, dixit 15.01.2013 07:39:
> Junio C Hamano  writes:
> 
>> Jardel Weyrich  writes:
>>
>>> If you allow me, I'd like you to forget about the concepts for a minute, 
>>> and focus on the user experience.
>>> Imagine a simple hypothetical scenario in which the user wants to push to 2 
>>> distinct repositories. He already has cloned the repo from the 1st 
>>> repository, thus (theoretically) all he needs to do, is to add a new 
>>> repository for push. He then uses `remote set-url --add --push <2nd-repo>` 
>>> (which I personally thought would suffice). However, if he tries to push a 
>>> new commit to this remote, it would be pushed _only_ to the 2nd-repo.
>>
>> The primary reason behind push-url was that
>>
>>  (1) usually you push to and fetch from the same, so no pushUrl is
>>  ever needed, just a single Url will do (this is often true for
>>  cvs/svn style shared repository workflow); and
>>
>>  (2) sometimes you want to fetch from one place and push to another
>>  (this is often true for "fetch from upstream, push to my own
>>  and ask upstream to pull from it" workflow), and in that case
>>  you want pushUrl in addition to Url.  Most importantly, in this
>>  case, you do *NOT* want to push to Url.  You only push to
>>  pushUrl.
>>
>> Setting *one* pushURL is a way to say "That URL I fetch from is
>> *not* the place I want to push (I may not even be able to push
>> there); when I say 'push', push there instead".  Your proposed
>> semantics will make it impossible to arrange such an asymmetric
>> setting.
> 
> Now I think I finally see where that misunderstanding comes from.
> It is "remote -v" that is misdesigned.
> 
> $ git clone ../there here
> $ cd here
> $ git remote -v
> origin /var/tmp/there (fetch)
> origin /var/tmp/there (push)
> 
> This is totally bogus.  It should report something like this:
> 
> $ git remote -v
> origin /var/tmp/there (fetch/push)
> 
> Then after running "git remote set-url --push origin ../another" we
> should see
> 
> $ git remote -v
> origin /var/tmp/there (fetch)
> origin /var/tmp/another (push)
> 
> which would make it clear that the original fetch/push came from the
> (1) usuall you push and fetch from the same place so there is only
> one setting, and the two lines came from the (2) sometimes you need
> a separate places to fetch from and push to.

Yes, that is one big source of misunderstanding. Cleaning up remote -v
would help, along with the man page.

Also there is a conceptual confusion: pushurl is meant to push to the
same repo using a different url, e.g. something authenticated
(https/ssh) for push and something faster/easier for fetch.

It never was meant to push to several repos. That is what "remotes" are
for, and it would help if we could push to a remote group (which is
difficult because of refspecs etc.) easily.

That being said, I don't mind changing the behaviour of set-url.

> At this point, if you say "set-url --push origin ../third", then
> "another" will disappear and gets replaced by "third"; if you
> instead say "set-url --add --push origin ../third", then we will see
> two (push) lines, in addition to one (fetch), making it clear that
> you are still in (2) above, fetching from and pushing to different
> places, and having two places to push to.
> 
> I misread your response
> 
> From: Jardel Weyrich 
> Subject: Re: [BUG] Possible bug in `remote set-url --add --push`
> Date: Sat, 12 Jan 2013 06:09:35 -0200
> Message-ID: 
> 
> 
> where you showed that there was only remote.origin.url (and no
> pushurl) in the first step, and somehow thought you had a
> remote.origin.pushurl in the first place.
> 
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [BUG] Possible bug in `remote set-url --add --push`

[Michael J Gruber]

Jardel Weyrich venit, vidit, dixit 12.01.2013 10:33:
> On Sat, Jan 12, 2013 at 6:44 AM, Sascha Cunz  wrote:
>> Am Freitag, 11. Januar 2013, 23:10:36 schrieb Junio C Hamano:
>>> Jardel Weyrich  writes:
 I believe `remote set-url --add --push` has a bug. Performed tests
 with v1.8.0.1 and v1.8.1 (Mac OS X).

 Quoting the relevant part of the documentation:
> set-url
>
> Changes URL remote points to. Sets first URL remote points to
> matching regex  (first URL if no  is given) to
> . If  doesn’t match any URL, error occurs and
> nothing is changed.
>
> With --push, push URLs are manipulated instead of fetch URLs.
> With --add, instead of changing some URL, new URL is added.
> With --delete, instead of changing some URL, all URLs matching regex
>  are deleted. Trying to delete all non-push URLs is an error.>
 Here are some steps to reproduce:

 1. Show the remote URLs

 jweyrich@pharao:test_clone1 [* master]$ git remote -v
 origin  /Volumes/sandbox/test (fetch)
 origin  /Volumes/sandbox/test (push)

 2. Add a new push URL for origin

 jweyrich@pharao:test_clone1 [* master]$ git remote set-url --add --push
 origin \>
 /Volumes/sandbox/test_clone2

 3. Check what happened

 jweyrich@pharao:test_clone1 [* master]$ git remote -v
 origin  /Volumes/sandbox/test (fetch)
 origin  /Volumes/sandbox/test_clone2 (push)
>>>
>>> The original pushurl was replaced with the additional one, instead
>>> of being left and the new one getting added.  That looks certainly
>>> wrong.
>>>
>>> However, the result of applying the attached patch (either to
>>> v1.7.12 or v1.8.1) still passes the test and I do not think it is
>>> doing anything differently from what you described above.
>>>
>>> What do you get from
>>>
>>>   git config -l | grep '^remote\.origin'
>>>
>>> in steps 1. and 3. in your procedure?  This question is trying to
>>> tell if your bug is in "git remote -v" or in "git remote set-url".
>>
>> I'm not sure, if there is a bug at all. According to man git-push:
>>
>> The  is used for pushes only. It is optional and defaults to
>>.
>> (From the section REMOTES -> Named remote in configuration file)
>>
>> the command:
>> git remote add foo g...@foo-fetch.org/some.git
>>
>> will set "remote.foo.url" to "g...@foo-fetch.org". Subsequently, fetch and 
>> push
>> will use g...@foo-fetch.org as url.
>> Fetch will use this url, because "remote.foo.url" explicitly sets this. push
>> will use it in absence of a "remote.foo.pushurl".
>>
>> Now, we're adding a push-url:
>> git remote set-url --add --push foo g...@foo-push.org/some.git
>>
>> Relevant parts of config are now looking like:
>> [remote "foo"]
>> url = g...@foo-fetch.org/some.git
>> pushurl = g...@foo-push.org/some.git
>>
>> Since, pushurl is now given explicitly, git push will use that one (and only
>> that one).
>>
>> If we add another push-url now,
>> git remote set-url --add --push foo g...@foo-push-also.org/some.git
>>
>> the next git-push will push to foo-push.org and foo-push-also.org.
>>
>> Now, using --set-url --delete on both of these urls restores the original
>> state: only "remote.foo.url" is set; meaning implicitly pushurl defaults to
>> url again.
>>
>> To me this is exactly what Jardel was observing:
>>
>>> In step 2, Git replaced the original push URL instead of adding a new
>>> one. But it seems to happen only the first time I use `remote set-url
>>> --add --push`. Re-adding the original URL using the same command seems
>>> to work properly.
>>
>>> And FWIW, if I delete (with "set-url --delete") both URLs push, Git
>>> restores the original URL.
>>
>> Or am I missing something here?
> 
> You're right. However, as I quoted earlier, the git-remote man-page states:
> 
>set-url
>Changes URL remote points to. 
>With --push, push URLs are manipulated instead of fetch URLs.
>With --add, instead of changing some URL, new URL is added.
> 
> It explicitly mentions that it should **add a new URL**.
> So when I do `git remote set-url --add --push origin
> git://another/repo.git`, I expect git-push to use both the default
> push URL and the new one. Or am I misinterpreting the man-page?
> 
>>
>> Might be that the "bug" actually is that the expectation was
>>
>> git remote add foo g...@foo-fetch.org/some.git
>>
>> should have created a config like:
>>
>> [remote "foo"]
>> url = g...@foo-fetch.org/some.git
>> pushurl = g...@foo-fetch.org/some.git
>>
>> since that is what "git remote -v" reports.
>>
>> If that is the case, we might want to amend the output of 'git remote -v' 
>> with
>> the information that a pushurl is not explicitly given and thus defaults to
>> url.
> 
> Correct. Adding a remote doesn't automatically generate a pushurl for it.
> 
> To me, it seems th

Re: Right way to import a repo

[Michael J Gruber]

Florian Lindner venit, vidit, dixit 21.12.2012 17:11:
> Hello,
> 
> I have two repositories. tools and flof. I want to merge flof into tools (and 
> flof will be deleted after that) while keeping history intact. Of course I've 
> googled that and found a number of different solution which all seem to be 
> pretty komplex, so I just tried it myself. It seems to work are there any 
> problems with my approach?
> 
> ~/software/tools.test (git)-[master] % git remote add fl ~/flof
> 
> ~/software/tools.test (git)-[master] % git fetch fl
> warning: no common commits
> remote: Counting objects: 475, done.
> remote: Compressing objects: 100% (460/460), done.
> remote: Total 475 (delta 251), reused 0 (delta 0)
> Receiving objects: 100% (475/475), 190.40 KiB, done.
> Resolving deltas: 100% (251/251), done.
> From /home/florian/flof
>  * [new branch]  master -> fl/master
>  * [new branch]  v2-rewrite -> fl/v2-rewrite
> 

Two disjoint histories, nothing wrong with that.

> /software/tools.test (git)-[master] % git checkout -b import fl/master
> Branch import set up to track remote branch master from fl.
> Switched to a new branch 'import'
> 
> Doing some mkdir und git mv for reorganisation.

Here avoid possible problems from both projects using the same root (in
the filesystem/tree sense).

> ~/software/tools.test/flof (git)-[import] % git commit -m "Reorganize flof."
> [import a00ab54] Reorganize flof.
>  152 files changed, 0 insertions(+), 0 deletions(-)
>  rename {doc => flof/doc}/common.rst (100%)
>  rename {doc => flof/doc}/conf.py (100%)
>  [...]
> 
> ~/software/tools.test/flof (git)-[import] % git checkout master
> Switched to branch 'master'
> 
> ~/software/tools.test (git)-[master] % git merge import
> Auto-merging .gitignore
> CONFLICT (add/add): Merge conflict in .gitignore
> Automatic merge failed; fix conflicts and then commit the result.
> 
> Resolving the conflict.
> 
> ~/software/tools.test (git)-[master|merge] % git add .gitignore
> 
> ~/software/tools.test (git)-[master|merge] % git commit -m "Merged flof."
> [master b8c85be] Merged flof.
> 
> ~/software/tools.test (git)-[master] % git remote rm fl
> 
> Are thery any problems with this procedure? The history seems to intact. I'm 
> quite unsure since still being a git beginner. 

It works in the sense that git follows the renames (moves) you had to do
prior to the merge.

Other tools like git-subtree do that history implanting in one step, by
putting the added project into a subtree (rewriting the history). That
way you don't have reorg commits in the history.

Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Opera release Git-splitter, a sub-modularizing tool for Git

[Michael J Gruber]

Yngve Nysaeter Pettersen venit, vidit, dixit 21.12.2012 21:13:
> On Fri, 21 Dec 2012 16:49:21 +0100, Matthieu Moy  
>  wrote:
> 
>> "Yngve Nysaeter Pettersen"  writes:
>>
>>> The split command will create a new repository for all files foo in a
>>> folder (path/foo) and their commit history.
>>>
>>> The replant command reverses that process, re-adding the path prefix
>>> for each file. It may be possible to extend that process into one that
>>> automatically reintegrates the new commits in the original history,
>>> but I never had time to complete that work.
>>>
>>> I did originally add the "replant" functionality into my version of
>>> the git-subtree script, but given the number of commits in the
>>> original repository, git-subtree turned out to be inefficient, due to
>>> the use of temporary files (tens of thousands of files IIRC).
>>>
>>> Those problems led to my development of git-splitter in Python
>>> (bypassing the problem of temporary files), but just including the
>>> functionality I needed, join was not one of those functions.
>>
>> That still doesn't answer the question: why did you need to write a new
>> tool instead of extending git-subtree?
> 
> The primary problem with git-subtree was that I ended up with a temporary  
> file directory containing 100+K files, which I tracked back to being used  
> to manage the commit-to-tree mapping. On Windows, at least, that literally  
> slowed down the process to a crawl.
> 
>> If one doesn't use "replant", is your tool different from git-subtree?
> 
> No, it is not different. However, my tool will use RAM, not diskspace to  
> manage information.

That is some valuable input. It can help improve git-subtree for Windows
users, or replace it by something else.

Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [BUG] Cannot push some grafted branches

[Michael J Gruber]

Junio C Hamano venit, vidit, dixit 21.12.2012 17:58:
> Michael J Gruber  writes:
> 
>> While replace refs are much more general than grafts, it seems the two
>> main uses are:
>>
>> - grafts (change the recorded parents for a commit)
>> - svn cleanup (convert tagging commits into tag objects)
>>
>> The latter one being quite a special case already.
>>
>> The script below has helped me move from grafts to replace objects.
>> While not being super clean, something like it may be fit for contrib.
>>
>> I think we ought to help John Doe get along with parents, while we can
>> safely leave most more advanced operations to people who know how to
>> edit a raw object file. Putting that facility into "git-commit" seems to
>> be too encouraging, though - people would use replace when they should
>> use amend or rebase-i. I'd prefer a special git-replace mode (be it
>> "--graft" or "--graft-commit") which does just what my script does. We
>> could add things like "--commit-tag" later, a full blown
>> "object-factory" seems like overkill.
>>
>> Michael
>>
>> --->%---
>>
>> #!/bin/sh
>>
>> die () {
>>  echo "$@"
>>  rm -f "$commitfile"
>>  exit 1
>> }
>>
>> warn () {
>>  echo "$@"
>> }
>>
>> test $# -gt 0 || die "Usage: $0  []*"
>>
>> for commit
>> do
>>  git rev-parse --verify -q "$commit" >/dev/null || die "Cannot parse
>> $commit."
>>  test x$(git cat-file -t $commit) == "xcommit" || die "$commit is no
>> commit."
> 
> s/==/=/ or you have to say #!/bin/bash on the first line, I think.
> Appears multiple times throughout this script.
> 
> 
>> done
>>
>> commit="$1"
>> shift
>>
>> commitfile=$(mktemp)
>>
>> git cat-file commit "$commit" | while read a b
>> do
>>  if test "$a" != "parent"
>>  then
>>  echo $a $b
> 
> You are losing information on non-header lines by reading without
> "-r" in the above, and also multi-line headers (e.g. mergetag),
> aren't you?
>

Oh yes, it has bashisms and imperfections. It's not a submitted patch,
not even RFC. It's meant to show the git-replace mode that many users
could benefit from: works for commits only and replaces the parent list,
but takes any rev arguments as the new parents, rather than forcing the
user to specify a full sha1.

>>  fi
>>  if test "$a" == "tree"
>>  then
>>  for parent
>>  do
>>  echo "parent $(git rev-parse $parent)"
>>  done
>>  fi
>> done >$commitfile
>> hash=$(git hash-object -t commit -w "$commitfile") || die "Cannot create
>> commit object."
>> git replace "$commit" $hash
>> rm -f $commitfile
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Opera release Git-splitter, a sub-modularizing tool for Git

[Michael J Gruber]

Yngve Nysaeter Pettersen venit, vidit, dixit 21.12.2012 13:43:
> Hi,
> 
> On Fri, 21 Dec 2012 13:23:46 +0100, Michael J Gruber
>  wrote:
> 
>> Yngve N. Pettersen (Developer Opera Software ASA) venit, vidit, dixit
>> 18.12.2012 15:51:
>>> Hello all,
>>>
>>> Today Opera Software released the "Git-splitter", a small tool for
>>> sub-modularizing code in a git repo, with complete commit history, under
>>> the Apache 2.0 license.
>>>
>>> It's functionality is similar to "git-subtree", but also include a  
>>> command
>>> for reversing the process.
>>
>> Is there something keeping you technically from adding a join command to
>> git-subtree?
> 
> Probably not, but within the process I was working I did not want to merge
> the branch with the recreated history for that path into the existing
> codebase (I don't like duplicate histories) so I used rebasing to move the
> new commits over, instead, and therefore did not need a join command.
> 
> Feel free to add a join command, if you want one.

Im sorry, but that was a total misunderstanding. You said git-splitter
is like git-subtree but adds a command for reversing the process. My
question was: What kept you from adding that to git-subtree (rather than
redoing stiff that git-subtree does)?

I just assumed that reversing the process of splitting must be joining.

It may very well be that git-splitter does things differently, i.e. that
there are more differences than just added functionality (compared to
git-subtree), but that is not clear from the announcement.

>>> The code is hosted on GitHub:
>>> <https://github.com/operasoftware/git-splitter>
>>>
>>> We have announced the release as part of another announcement of  
>>> released
>>> code at the Opera Security Group home page:
>>> <http://my.opera.com/securitygroup/blog/2012/12/18/tls-prober-source-released-under-apache-2-0-license>
>>>
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [BUG] Cannot push some grafted branches

[Michael J Gruber]

While replace refs are much more general than grafts, it seems the two
main uses are:

- grafts (change the recorded parents for a commit)
- svn cleanup (convert tagging commits into tag objects)

The latter one being quite a special case already.

The script below has helped me move from grafts to replace objects.
While not being super clean, something like it may be fit for contrib.

I think we ought to help John Doe get along with parents, while we can
safely leave most more advanced operations to people who know how to
edit a raw object file. Putting that facility into "git-commit" seems to
be too encouraging, though - people would use replace when they should
use amend or rebase-i. I'd prefer a special git-replace mode (be it
"--graft" or "--graft-commit") which does just what my script does. We
could add things like "--commit-tag" later, a full blown
"object-factory" seems like overkill.

Michael

--->%---

#!/bin/sh

die () {
echo "$@"
rm -f "$commitfile"
exit 1
}

warn () {
echo "$@"
}

test $# -gt 0 || die "Usage: $0  []*"

for commit
do
git rev-parse --verify -q "$commit" >/dev/null || die "Cannot parse
$commit."
test x$(git cat-file -t $commit) == "xcommit" || die "$commit is no
commit."
done

commit="$1"
shift

commitfile=$(mktemp)

git cat-file commit "$commit" | while read a b
do
if test "$a" != "parent"
then
echo $a $b
fi
if test "$a" == "tree"
then
for parent
do
echo "parent $(git rev-parse $parent)"
done
fi
done >$commitfile
hash=$(git hash-object -t commit -w "$commitfile") || die "Cannot create
commit object."
git replace "$commit" $hash
rm -f $commitfile
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Opera release Git-splitter, a sub-modularizing tool for Git

[Michael J Gruber]

Yngve N. Pettersen (Developer Opera Software ASA) venit, vidit, dixit
18.12.2012 15:51:
> Hello all,
> 
> Today Opera Software released the "Git-splitter", a small tool for  
> sub-modularizing code in a git repo, with complete commit history, under  
> the Apache 2.0 license.
> 
> It's functionality is similar to "git-subtree", but also include a command  
> for reversing the process.

Is there something keeping you technically from adding a join command to
git-subtree?

> The code is hosted on GitHub:  
> 
> 
> We have announced the release as part of another announcement of released  
> code at the Opera Security Group home page:  
> 
> 

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: How to avoid the ^M induced by Meld and Git

[Michael J Gruber]

Karl Brand venit, vidit, dixit 12.12.2012 16:34:
> 
> 
> On 12/12/12 15:57, Michael J Gruber wrote:
>> Karl Brand venit, vidit, dixit 11.12.2012 13:33:
>>> Esteemed Git users,
>>>
>>> What i do:
>>>
>>> 1. Create a script.r using Emacs/ESS.
>>> 2. Make some modifications to script.r with the nice diff gui, Meld
>>> 3. Commit these modifications using git commit -am "my message"
>>> 4. Reopen script.r in Emacs/ESS to continue working.
>>>
>>> The lines added (&/edited ?) using Meld all end with ^M which i
>>> certainly don't want. Lines not added/edited with Meld do NOT end with ^M.
>>
>> What happens if you leave out step 3? If the same happens then Meld is
>> the culprit. (Unless you've set some special options, git does not
>> modify your file on commit, so this can't be git related.)
>>
> 
> Leaving out step 3. results in exactly the same thing. Thus Git doesn't 
> appear to be responsible for the ^M's. Thanks a lot for your effort on 
> this and my apologies for not taking the care to dissect this more 
> carefully as you suggested. Over to the Meld mailing list...

I didn't mean to shy you away ;)

Could it be that there is a ^M very early in the file (or rather
something else which isn't covered by dos2unix) so that Meld thinks it's
DOS and inserts line endings as DOS? At least that's what vim would do.

In any case, Meld people over there should know (or get to know) that
effect.

>>> There are plenty of posts around about these being line endings used for
>>> windows which can appear when working on a script under a *nix OS which
>>> has previously been edited in a Windows OS. This is not the case here -
>>> everything is taking place on Ubuntu 12.04.
>>>
>>> FWIW: the directory is being synced by dropbox; and in Meld, Preferences
>>>   > Encoding tab, "utf8" is entered in the text box.
>>>
>>> Current work around is running in a terminal: dos2unix /path/to/script.r
>>> which strips the ^M's
>>>
>>> But this just shouldn't be necessary and I'd really appreciate the
>>> reflections & advice on how to stop inducing these ^M's !
>>>
>>> With thanks,
>>>
>>> Karl
>>>
>>> (re)posted here as suggested off topic at SO:
>>> http://stackoverflow.com/questions/13799631/create-script-r-in-emacs-modify-with-meld-git-commit-reopen-in-emacs-m
>>>
>>
> 
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] submodule: add 'deinit' command

[Michael J Gruber]

Jens Lehmann venit, vidit, dixit 04.12.2012 22:48:
> With "git submodule init" the user is able to tell git he cares about one
> or more submodules and wants to have it populated on the next call to "git
> submodule update". But currently there is no easy way he could tell git he
> does not care about a submodule anymore and wants to get rid of his local
> work tree (except he knows a lot about submodule internals and removes the
> "submodule.$name.url" setting from .git/config himself).
> 
> Help those users by providing a 'deinit' command. This removes the whole
> submodule. section from .git/config either for the given
> submodule(s) or for all those which have been initialized if none were
> given. Complain only when for a submodule given on the command line the
> url setting can't be found in .git/config.

Whoaaa, so why not have "git rm" remove everything unless I specify a
file to be removed?

I know I'm exaggerating a bit, but defaulting to "--all" for a
destructive operation seems to be a bit harsh, especially when the
command is targeted at "those" users that you mention.

> Add tests and link the man pages of "git submodule deinit" and "git rm"
> to assist the user in deciding whether removing or unregistering the
> submodule is the right thing to do for him.
> 
> Signed-off-by: Jens Lehmann 
> ---
> 
> Am 03.12.2012 08:58, schrieb Junio C Hamano:
>> Jens Lehmann  writes:
>>
>>> Maybe the principle of least surprise is better followed when we
>>> nuke the whole section, as it might surprise the user more to have
>>> a setting resurrected he customized in the last life cycle of the
>>> submodule than seeing that after an deinit followed by an init all
>>> former customizations are consistently gone. So I tend to think now
>>> that removing the whole section would be the better solution here.
>>
>> I tend to agree; I suspect that a "deinit" would be mostly done
>> either to
>>
>>  (1) correct mistakes the user made during a recent "init" and
>>  perhaps "sync"; or
>>
>>  (2) tell Git that the user has finished woing with this particular
>>  submodule and does not intend to use it for quite a while.
>>
>> For both (1) and (2), I think it would be easier to users if we gave
>> them a clean slate, the same state as the one the user who never had
>> ran "init" on it would be in.  A user in situation (1) is asking for
>> a clean slate, and a user in situation (2) is better served if he
>> does not have to worry about leftover entries in $GIT_DIR/config he
>> has long forgotten from many months ago (during which time the way
>> the project uses the particular submodule may well have changed)
>> giving non-standard experience different from what other project
>> participants would get.
> 
> Changes in v2:
> - Remove the whole submodule section instead of only removing the
>   "url" setting and explain why we do that in a comment
> - Reworded commit message and git-submodule.txt to reflect that
> - Extend the test to check that a custom settings are removed
> 
> 
>  Documentation/git-rm.txt|  4 
>  Documentation/git-submodule.txt | 12 ++
>  git-submodule.sh| 52 
> -
>  t/t7400-submodule-basic.sh  | 12 ++
>  4 files changed, 79 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/git-rm.txt b/Documentation/git-rm.txt
> index 262436b..ec42bf5 100644
> --- a/Documentation/git-rm.txt
> +++ b/Documentation/git-rm.txt
> @@ -149,6 +149,10 @@ files that aren't ignored are present in the submodules 
> work tree.
>  Ignored files are deemed expendable and won't stop a submodule's work
>  tree from being removed.
> 
> +If you only want to remove the local checkout of a submodule from your
> +work tree without committing that use `git submodule deinit` instead
> +(see linkgit:git-submodule[1]).
> +
>  EXAMPLES
>  
>  `git rm Documentation/\*.txt`::
> diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
> index b1de3ba..08b55a7 100644
> --- a/Documentation/git-submodule.txt
> +++ b/Documentation/git-submodule.txt
> @@ -13,6 +13,7 @@ SYNOPSIS
> [--reference ] [--]  []
>  'git submodule' [--quiet] status [--cached] [--recursive] [--] [...]
>  'git submodule' [--quiet] init [--] [...]
> +'git submodule' [--quiet] deinit [--] [...]
>  'git submodule' [--quiet] update [--init] [-N|--no-fetch] [--rebase]
> [--reference ] [--merge] [--recursive] [--] 
> [...]
>  'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit) 
> ]
> @@ -134,6 +135,17 @@ init::
>   the explicit 'init' step if you do not intend to customize
>   any submodule locations.
> 
> +deinit::
> + Unregister the submodules, i.e. remove the whole `submodule.$name`
> + section from .git/config. Further calls to `git submodule update`,
> + `git submodule foreach` and `git submodule sync` will skip any
> + unregistered submodules until they are initialized again, s

Re: How to avoid the ^M induced by Meld and Git

[Michael J Gruber]

Karl Brand venit, vidit, dixit 11.12.2012 13:33:
> Esteemed Git users,
> 
> What i do:
> 
> 1. Create a script.r using Emacs/ESS.
> 2. Make some modifications to script.r with the nice diff gui, Meld
> 3. Commit these modifications using git commit -am "my message"
> 4. Reopen script.r in Emacs/ESS to continue working.
> 
> The lines added (&/edited ?) using Meld all end with ^M which i 
> certainly don't want. Lines not added/edited with Meld do NOT end with ^M.

What happens if you leave out step 3? If the same happens then Meld is
the culprit. (Unless you've set some special options, git does not
modify your file on commit, so this can't be git related.)

> There are plenty of posts around about these being line endings used for 
> windows which can appear when working on a script under a *nix OS which 
> has previously been edited in a Windows OS. This is not the case here - 
> everything is taking place on Ubuntu 12.04.
> 
> FWIW: the directory is being synced by dropbox; and in Meld, Preferences 
>  > Encoding tab, "utf8" is entered in the text box.
> 
> Current work around is running in a terminal: dos2unix /path/to/script.r 
> which strips the ^M's
> 
> But this just shouldn't be necessary and I'd really appreciate the 
> reflections & advice on how to stop inducing these ^M's !
> 
> With thanks,
> 
> Karl
> 
> (re)posted here as suggested off topic at SO:
> http://stackoverflow.com/questions/13799631/create-script-r-in-emacs-modify-with-meld-git-commit-reopen-in-emacs-m
> 

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] RFC Optionally handle symbolic links as copies

[Michael J Gruber]

Robin Rosenberg venit, vidit, dixit 06.12.2012 02:23:
> 
> 
> - Ursprungligt meddelande -
>> Robin Rosenberg  writes:
>>
>>> If core.symlinks is set to copy then symbolic links in a git
>>> repository
>>> will be checked out as copies of the file it points to.
>>
>> That all sounds nice on surface when the primary thing you care
>> about is to fetch and check out other people's code and extract it
>> to the working tree, but how well would that work on the checkin
>> side?  What happens if I check out a symlink that points at a file
>> (either in-tree or out-of-tree), make some changes that do not
>> involve the symlink, and before I make the commit, an unrelated
>> change is made to the file the symlink is pointing at?
>>
>>> - git status - when do we report a diff.
>>> - After checkout we should probably not
>>> - if the "linked" files change?
>>
>> Yeah, exactly.
>>
>>> - if a change in the copied directory chsnges
>>
>> That, too.
>>
>>> - if a file in the copied diretory is added/removed
>>> - update, should we update the copied structure automatically
>>>   when the link target changes
> 
> Some of the questions have proposals in the includes test script. A 
> little more dangerous than having real symlinks ofcourse, but regardless
> of what one does with or without copied symlinks one can make mistakes
> and I feel letting Git do the copying is way better than having real
> copies in the git repository. Another crappy scm which the users are
> converting from does this and it works. A difference to git is that
> it (ok clearcase) makes all files read-only so there are fewer mays
> of making mistakes with the copies.
> 
>> I personally do not think this is worth it.  It would be very useful
>> on the export/checkout side, so it may make sense to add it to "git
>> archive", though.
> 
> It makes sense, but it does not solve the problem at hand.
> 
> -- robin
> 

Well, what is the problem at hand?

Your commit message begins in present tense as if it described the
current state of git, when in fact it describes what the patch is about
to achieve. This is confusing enough already,

I don't see any mention of the purpose, other than "content may be
used", which would be served perfectly by a copy-on-link feature on the
export side, as mentioned by Junio. Is git-archive|tar an option?

Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [ANNOUNCE] Git v1.8.1-rc0

[Michael J Gruber]

While not being a huge problem, you may or may not want to correct one
commit message:

*   aaf5ad5 (origin/next, gitster/next) Sync with 1.8.0-rc0
|\
| * ee26a6e (tag: v1.8.1-rc0, origin/master, origin/HEAD,
gitster/master) Git 1.8.1-rc0

Cheers,
Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] l10n: de.po: translate 22 new messages

[Michael J Gruber]

Ralf Thielow venit, vidit, dixit 03.12.2012 05:49:
> Translate 22 new messages came from git.pot
> updates in 9306b5b (l10n: Update git.pot (3 new,
> 6 removed messages)), fe52cd6 (l10n: Update git.pot
> (14 new, 3 removed messages)) and f9472e3
> (l10n: Update git.pot (5 new, 1 removed messages)).
> 
> Signed-off-by: Ralf Thielow 
> ---
>  po/de.po | 68 
> ++--
>  1 file changed, 36 insertions(+), 32 deletions(-)
> 
> diff --git a/po/de.po b/po/de.po
> index a0bf3da..7350818 100644
> --- a/po/de.po
> +++ b/po/de.po
...
>  #: remote.c:1659
> -#, fuzzy
>  msgid "  (use \"git pull\" to merge the remote branch into yours)\n"
>  msgstr ""
> -"  (benutze \"git am --abort\" um den ursprünglichen Zweig 
> wiederherzustellen)"
> +"  (benutze \"git pull\" um den externen Zweig mit Deinem 
> zusammenzuführen)\n"

That sounds as if git-pull did something to the remote branch, whereas
it would do something with your local branch. Reverting the roles may help:

+"  (benutze \"git pull\" um Deinen Zweig mit dem externen
zusammenzuführen)\n"

BTW: Is there a standard about capitalising or not "Deine/Du" in de.pot?
I think I've seen both here. (New spelling after the reform(s)
recommends du/deine but Sie/Ihr, me thinks.)


>  #: builtin/grep.c:740
>  msgid "pager"
> @@ -8029,6 +8024,9 @@ msgid ""
>  "submodule '%s' (or one of its nested submodules) uses a .git directory\n"
>  "(use 'rm -rf' if you really want to remove it including all of its history)"
>  msgstr ""
> +"Unterprojekt '%s' (oder ein geschachteltes Unterprojekt dessen) verwendet 
> \n"

s/dessen/hiervon/ ?

> +"ein .git-Verzeichnis (benutze 'rm -rf' wenn du dieses wirklich mit seiner\n"
> +"Historie löschen möchtest)"

s/mit/mitsamt/ ?

(to emphasize "including" like in the original and avoid "mit=by"
misinterpretation)

Michael


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/PATCH] l10n: de.po: translate 825 new messages

[Michael J Gruber]

Ralf Thielow venit, vidit, dixit 03.12.2012 05:48:
> Thanks Thomas and Michael!
> 
> 2012/11/30 Thomas Rast :
> 
>>>  #: builtin/update-index.c:756
>>>  msgid "mark files as \"index-only\""
>>> -msgstr ""
>>> +msgstr "markiert Dateien als \"index-only\""
>>
>> Likewise, but here I don't even understand what the manpage is trying to
>> tell me, in particular I don't see how it would be different from
>> assume-unchanged.  Maybe "see manpage" would be the best documentation.
> 
> I'm not really sure what to do with it. In this version (see below) I kept
> it. Did you mean we should add "(siehe Hilfeseite)" or something in the
> translation, or does it belong to the original message and the translation
> would just follow?
>

I'd say the translation above is fine, and no matter what language the
user messages are in, the user would have to consult the man page for
this very special feature, but I don't think we have to say so explicitly.

>>> +"wiederholte Ausführung der Phasen #2 und #3 für die aufgelisteten Pfade"
>>
>> ISTR we settled on something for 'stage', but it's not in the glossary.
>> Either way I don't think this is it.  "Ausführung der Phasen" would mean
>> that it's some part of a process, whereas the stages are a state.
>>
> I've changed it to
> "wiederholtes Einpflegen der Zustände #2 und #3 für die aufgelisteten Pfade"
> What do you think?
> 
> ---
>  po/de.po | 123 
> +++
>  1 file changed, 61 insertions(+), 62 deletions(-)
...
>  #: builtin/fsck.c:620
>  msgid "also consider packs and alternate objects"
> -msgstr "betrachtet auch Pakete und wechselnde Objekte"
> +msgstr ""

Oops ;)

>  #: builtin/push.c:391
>  msgid "check"
> -msgstr "Überprüfung"
> +msgstr ""

Is this meant to omit the text? (I may have missed the pertaining
discussion.)


>  #: builtin/update-index.c:753
>  msgid "clear assumed-unchanged bit"
> @@ -8568,7 +8567,7 @@ msgstr "fügt Einträge von der Standard-Eingabe der 
> Bereitstellung hinzu"
>  #: builtin/update-index.c:776
>  msgid "repopulate stages #2 and #3 for the listed paths"
>  msgstr ""
> -"wiederholte Ausführung der Phasen #2 und #3 für die aufgelisteten Pfade"
> +"wiederholtes Einpflegen der Zustände #2 und #3 für die aufgelisteten Pfade"

I can't seem to find the other occurence in de.po, but state should be
the same as in

"copy out the files from named stage" (checkout-index).

"Zustand" seems to be appropriate.

Cheers,
Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git describe not matching git log

[Michael J Gruber]

Steven Penny venit, vidit, dixit 29.11.2012 10:04:
> It seems "git describe" is not matching "git log" as detailed in the help, in
> some cases. From git describe --help
> 
>   [torvalds@g5 git]$ git describe parent
>   v1.0.4-14-g2414721
> 
>   The number of additional commits is the number of commits which would
>   be displayed by "git log v1.0.4..parent".
> 
> GOOD
> 
>   $ git clone git://github.com/antirez/redis.git
> 
>   $ cd redis
> 
>   $ git describe unstable
>   with-deprecated-diskstore-1050-g7383c3b
> 
>   $ git log --oneline with-deprecated-diskstore..unstable | wc
>  1050   11779   78709
> 
> BAD
> 
>   $ git clone git://github.com/git/git.git
> 
>   $ cd git
> 
>   $ git describe master
>   v1.8.0.1-264-g226dcb5
> 
>   $ git log --oneline v1.8.0.1..master | wc
>   2601650   14154
> 

This is due to date skew: git-describe uses "insert_by_date" when it
traverses the dag, and this can go wrong.

Interestingling, this seems to get fixed by using Jeff's generation
numbers and "insert_by_generation" instead, so it does seem go wrong for
226dcb5~60 or so. git-describe's logic is a bit convoluted and may
depend on how we insert when generation numbers are the same... Have to
do more testing.

Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/PATCH] l10n: de.po: translate 825 new messages

[Michael J Gruber]

Ralf Thielow venit, vidit, dixit 28.11.2012 19:22:
>> Hi Ralf,
>>
>> This is the middle third of my review.  Sorry for the long wait!  I hope
>> it can still be useful.
>>
> 
> Hi Thomas,
> 
> no problem. Thanks for your review. Of course it's very useful.
> Some of the mistakes I made are so obvious that I can't say what
> I've had in mind when translation these messages :/ But some aren't,
> so thanks for the further explanations within your review.
> 
>> I don't really share your apparent aversion to just using "" :-)
> I don't really have one :) so I'm fine with using .
> 
>> This would be a good time to settle on a good translation for
>> "rewriting".  Perhaps "neu schreiben".  "Überschreiben" to me implies
> On some other places we actually use "neu schreiben".

How about "umschreiben"? "neu schreiben" is more like "write from
scratch", whereas "rewrite" is more often about taking a given base and
modifying it.

>>> -msgstr ""
>>> +msgstr "erzeugt kleinere Pakete"
>>
>> Smaller is not really the point: they are packs that do not have the
> [...]
>> You could call them "abgespeckt" ;-)
> I used "dünner"!?
> 
> Furthermore I've unified the translation of "email" to "Email",
> not "eMail". You'll see the result below. I hope I haven't missed
> something.
> 
> Thanks,
> Ralf
> 
> ---
>  po/de.po | 95 
> 
>  1 file changed, 47 insertions(+), 48 deletions(-)
> 
> diff --git a/po/de.po b/po/de.po
> index fe6e8cf..1a75ea2 100644
> --- a/po/de.po
> +++ b/po/de.po
...
>  #: builtin/fsck.c:608
>  msgid "git fsck [options] [...]"
> @@ -4521,7 +4521,7 @@ msgstr "erzeugt Kopfknoten des Referenzprotokolls 
> (Standard)"
>  
>  #: builtin/fsck.c:620
>  msgid "also consider packs and alternate objects"
> -msgstr "betrachtet auch Pakete und wechselnde Objekte"
> +msgstr ""

"alternate objects" (hopefully) don't change much, so that "wechselnde"
is misleading.

Is there a set translation standard for the "alternative object store"
mechanism in git (alternates)? Otherwise "alternative Objekte" may be
choice which is close to the original and conveys the aspect that they
are objects from an alternative store.


>  #: builtin/grep.c:817
>  msgid "indicate hit with exit status without output"
> -msgstr "kennzeichnet Übereinstimmungen mit Beendigungsstatus, ohne Ausgabe"
> +msgstr "zeigt Übereinstimmungen mit Beendigungsstatus, ohne Ausgabe"

maybe "zeigt Übereinstimmungen nur durch Beendigungsstatus an"

"mit" sounds like "including", "additionally". Also, nothing is shown
("zeigt"), but something is indicated ("zeigt an").


>  #: builtin/log.c:102
>  msgid "decorate options"
> -msgstr "Ausgabeoptionen"
> +msgstr "decorate Optionen"

"decorate-Optionen" (unless we want to match the standard set by the bad
old K&R translation ;) )


>  #: builtin/log.c:1098
>  msgid "add To: header"
> -msgstr "fügt Kopfteil \"To:\" hinzu"
> +msgstr "fügt  \"To:\" Header hinzu"

Here and in the following I'd a "-", e.g.

msgstr "fügt  \"To:\"-Header hinzu"

>  #: builtin/log.c:1100
>  msgid "add Cc: header"
> -msgstr "fügt Kopteil \"Cc:\" hinzu"
> +msgstr "fügt \"Cc:\" Header hinzu"
...
> -"lädt Konfiguration für  beim Überschreiben von Versionen "
> +"lädt Konfiguration für  beim Neuschreiben von Versionen "
>  "(impliziert --stdin)"

"Umschreiben" (if that becomes the agreed upon term for "rewrite").

Just my two Pfennig ;)

Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/4] git-svn: Note about tags.

[Michael J Gruber]

Sebastian Leske venit, vidit, dixit 23.11.2012 08:29:
> Document that 'git svn' will import SVN tags as branches.
> 
> Signed-off-by: Sebastian Leske 
> ---
>  Documentation/git-svn.txt |6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
> index 92780ef..6212b24 100644
> --- a/Documentation/git-svn.txt
> +++ b/Documentation/git-svn.txt
> @@ -938,6 +938,12 @@ the possible corner cases (git doesn't do it, either).  
> Committing
>  renamed and copied files is fully supported if they're similar enough
>  for git to detect them.
>  
> +In SVN, it is possible (though discouraged) to commit changes to a tag
> +(because a tag is just a directory copy, thus technically the same as a
> +branch). When cloning an SVN repository, 'git svn' cannot know if such a
> +commit to a tag will happen in the future. Thus it acts conservatively
> +and imports all SVN tags as branches, prefixing the tag name with 'tags/'.
> +

If git-svn turned SVN tags in git lightweight tags it would be just as
conservative, because they can be rewritten also... It's just a ref.
Note that the above assumes standard refspecs.

But, importing SVN tags as branches conveys their character much more
precisely. If r8 is being tagged then svn creates r9, which may or may
not be treesame to r8; different projects do different things in this step.

Even if they are treesame, r9 still carries a separate commit message.
This is probably the most typical case, and converting the r9 commit
into a git tag object would be appropriate (but is left to the user of
git-svn).

A lightweight tag pointing to an "off-branch" commit (r9) would be a
strange thing, so git-svn creates a new branch instead, pointing at r9,
branching off r8.

>  CONFIGURATION
>  -
>  
> 

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/4] git-svn: Expand documentation for --follow-parent

[Michael J Gruber]

Sebastian Leske venit, vidit, dixit 23.11.2012 08:13:
> Describe what the option --follow-parent does, and what happens if it is
> set or unset.
> 
> Signed-off-by: Sebastian Leske 
> ---
>  Documentation/git-svn.txt |   16 
>  1 file changed, 12 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
> index 928a961..92780ef 100644
> --- a/Documentation/git-svn.txt
> +++ b/Documentation/git-svn.txt
> @@ -628,11 +628,19 @@ ADVANCED OPTIONS
>   Default: "svn"
>  
>  --follow-parent::
> + This option is only relevant if we are tracking branches (using
> + one of the repository layout options --trunk, --tags,
> + --branches, --stdlayout). For each tracked branch, try to find
> + out where its revision was copied (i.e. branched) from, and set
> + a suitable parent in the first git commit for the branch.
>   This is especially helpful when we're tracking a directory
> - that has been moved around within the repository, or if we
> - started tracking a branch and never tracked the trunk it was
> - descended from. This feature is enabled by default, use
> - --no-follow-parent to disable it.
> + that has been moved around within the repository (note that you
> + must track both the old and the new name for the whole history
> + to be imported).  If this feature is disabled, the branches
> + created by 'git svn' will all be linaear and not share any

linear

> + history, meaning that there will be no information on where
> + branches where branched off or merged. This feature is enabled
> + by default, use --no-follow-parent to disable it.
>  +
>  [verse]
>  config key: svn.followparent
> 

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/4] Recommend use of structure options for git svn.

[Michael J Gruber]

Sebastian Leske venit, vidit, dixit 21.11.2012 08:13:
> Document that when using git svn, one should usually either use the
> directory structure options to import branches as branches, or only
> import one subdirectory. The default behaviour of cloning all branches
> and tags as subdirectories in the working copy is usually not what the
> user wants.

"Usually" assumes that usually svn repos follow a branch/tag structure.
That may be quite true nowadays (but wasn't in the beginning).

In fact I would suggest to emphasize "--stdlayout" as the most standard
choice nowadays, followed by specifying a specific branch (usually
trunk) as the repo uri.

> Signed-off-by: Sebastian Leske 
> ---
>  Documentation/git-svn.txt |   10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
> index 482d60d..928a961 100644
> --- a/Documentation/git-svn.txt
> +++ b/Documentation/git-svn.txt
> @@ -871,6 +871,16 @@ already dcommitted.  It is considered bad practice to 
> --amend commits
>  you've already pushed to a remote repository for other users, and
>  dcommit with SVN is analogous to that.
>  
> +When cloning an SVN repository, if none of the options for describing
> +the repository layout is used (--trunk, --tags, --branches,
> +--stdlayout), 'git svn clone' will create a git repository with
> +completely linear history, where branches and tags appear as separate
> +folders in the working copy.  For projects with many branches this will
> +lead to a working copy many times larger than just the trunk.  It is
> +recommended to either use the the options for trunk / tag / branch
> +directory, or to only clone the trunk (or a subdirectory of the
> +trunk).
> +
>  When using multiple --branches or --tags, 'git svn' does not automatically
>  handle name collisions (for example, if two branches from different paths 
> have
>  the same name, or if a branch and a tag have the same name).  In these cases,
> 

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/4] git-svn: Document branches with at-sign(@).

[Michael J Gruber]

Sebastian Leske venit, vidit, dixit 18.11.2012 18:08:
> git svn will sometimes create branches with an at-sign in the name
> (branchname@revision). These branches confuse many users and it is a FAQ
> why they are created. Document when git svn will create them.
> 
> Signed-off-by: Sebastian Leske 
> ---
> 
> I found various important features of git-svn that are not documented.
> Thus I created a series of patches to add and update documentation for
> git-svn. I am sending this as four patches (of which this mail is the
> first). I have tried my best to make the patches ready for inclusion
> into git, but if there's any feedback, I'll gladly incorporate it.
> 
> 
>  Documentation/git-svn.txt |   26 ++
>  1 file changed, 26 insertions(+)
> 
> diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
> index 8b0d3ad..482d60d 100644
> --- a/Documentation/git-svn.txt
> +++ b/Documentation/git-svn.txt
> @@ -881,6 +881,32 @@ different name spaces.  For example:
>   branches = stable/*:refs/remotes/svn/stable/*
>   branches = debug/*:refs/remotes/svn/debug/*
>  
> +If 'git svn' is configured to fetch branches (and --follow-branches
> +is in effect), it will sometimes create multiple branches for one SVN
> +branch, where the addtional branches have names of the form
> +'branchname@nnn' (with nnn an SVN revision number).  These additional
> +branches are created if 'git svn' cannot find a parent commit for the
> +first commit in the branch, to connect the branch to the history of the
> +other branches. Normally, 'git svn' will find the git commit that
> +corresponds to the SVN revision a branch was created (copied) from and
> +use that as the parent. However, it is possible that there is no
> +suitable git commit to serve as parent.  This will happen, among other
> +reasons, if the SVN branch is a copy of a revision that was not fetched
> +by 'git svn' (e.g. because it is an old revision that was skipped with
> +'--revision'), or if in SVN a directory was copied that is not tracked
> +by 'git svn' (a branch that is not tracked at all, or a subdirectory of
> +a tracked branch). In these cases, 'git svn' will still create a git
> +branch, but the branch will not be connected to the history of the other
> +branches.  'git svn' will also create a commit from the SVN revision the
> +branch was copied from, and use that as the parent commit of the branch
> +(this is indicated by the message "Initializing parent: ").
> +Additionally, it will create a special branch named
> +'@', where  is the SVN revision
> +number the branch was copied from.  This branch will point to the
> +specially created parent commit.
> +If in SVN the branch was deleted and later recreated from a different
> +version, there will be multiple such branches with an '@'.
> +
>  BUGS
>  
>  
> 

In fact, the most typical reason for at-branches is a botched branching
or tagging operation on the svn side: since they are simply "copy"
operations it's too easy to copy a tree into the wrong directory.

Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Requirements for integrating a new git subcommand

[Michael J Gruber]

Eric S. Raymond venit, vidit, dixit 22.11.2012 23:11:
> Shawn Pearce :
>> [Lots of helpful stuff ended by]
>>> 4. How does "git help" work?  That is, how is a subcommand expected
>>> to know when it is being called to export its help text?
>>
>> IIRC "git help foo" runs "man git-foo".
> 
> OK, that makes sense.
> 
>>> 5. I don't see any extensions written in Python.  Are there any special
>>> requirements or exclusions for Python scripts?
>>
>> Nope, it just has to be executable. We don't have any current Python
>> code. IIRC the last Python code was the implementation of
>> git-merge-recursive, which was ported to C many years ago. We avoid
>> Python because it is not on every platform where Git is installed. Yes
>> Python is very portable and can be installed in many places, but we
>> prefer not to make it a requirement.
> 
> I find that odd.  You avoid Python but use shellscripts?  *blink*
> 
> One would think shellscripts were a much more serious portability problem.

Different versions of python can be a mess to deal with, also, at least
with respect to standard modules being "standard" or not for a specific
version.

In any case, the point is that we try to avoid *additional*
dependencies. Shell and perl are given with the status quo.

That being said, we also have remote helpers in python. The testsuite
can run tests depending on the availability of python.

Regarding git-weave, I'm wondering (without having looked at the code)
how this relates to git-archiv and git-fast-import/export, i.e. how much
this leverages existing infrastructure rather than reinventing the
wheel. Do your "trees" correspond to a "git tree"?

Again, without having looked at the code, it seems to me that exploding
blob and tree objects might give you a structure not much unlike
weave's, and your instruction sheet resembles that of fast-import quite
a bit (plus date fill-in etc.).

One could even dream about implementing this as a remote helper instead...

Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Local clones aka forks disk size optimization

[Michael J Gruber]

Sitaram Chamarty venit, vidit, dixit 15.11.2012 04:44:
> On Thu, Nov 15, 2012 at 7:04 AM, Andrew Ardill  
> wrote:
>> On 15 November 2012 12:15, Javier Domingo  wrote:
>>> Hi Andrew,
>>>
>>> Doing this would require I got tracked which one comes from which. So
>>> it would imply some logic (and db) over it. With the hardlinking way,
>>> it wouldn't require anything. The idea is that you don't have to do
>>> anything else in the server.
>>>
>>> I understand that it would be imposible to do it for windows users
>>> (but using cygwin), but for *nix ones yes...
>>> Javier Domingo
>>
>> Paraphrasing from git-clone(1):
>>
>> When cloning a repository, if the source repository is specified with
>> /path/to/repo syntax, the default is to clone the repository by making
>> a copy of HEAD and everything under objects and refs directories. The
>> files under .git/objects/ directory are hardlinked to save space when
>> possible. To force copying instead of hardlinking (which may be
>> desirable if you are trying to make a back-up of your repository)
>> --no-hardlinks can be used.
>>
>> So hardlinks should be used where possible, and if they are not try
>> upgrading Git.
>>
>> I think that covers all the use cases you have?
> 
> I am not sure it does.  My understanding is this:
> 
> 'git clone -l' saves space on the initial clone, but subsequent pushes
> end up with the same objects duplicated across all the "forks"
> (assuming most of the forks keep up with some canonical repo).
> 
> The alternates mechanism can give you ongoing savings (as long as you
> push to the "main" repo first), but it is dangerous, in the words of
> the git-clone manpage.  You have to be confident no one will delete a
> ref from the "main" repo and then do a gc or let it auto-gc.
> 
> He's looking for something that addresses both these issues.
> 
> As an additional idea, I suspect this is what the namespaces feature
> was created for, but I am not sure, and have never played with it till
> now.
> 
> Maybe someone who knows namespaces very well will chip in...
> 

I dunno about namespaces, but a safe route with alternates seems to be:

Provide one "main" clone which is bare, pulls automatically, and is
there to stay (no pruning), so that all others can use that as a
reliable alternates source.

Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: push branch descriptions

[Michael J Gruber]

Ramkumar Ramachandra venit, vidit, dixit 14.11.2012 11:33:
> Hi,
> 
> Angelo Borsotti wrote:
>> currently, there is no means to push a branch description to a remote
>> repository. It is possible to create a branch, but not to set its
>> description.
>> Would not be more correct to push also branch descriptions when
>> branches are pushed?
> 
> Branch descriptions are currently stored in .git/config (see
> branch..description), and are hence intended to be local.
> But yes, it would be nice to have it synced with the remote- I have no
> clue how to make that possible though.

I find that nice, too, but back then I seemed to be the only one, "then"
being the time when I proposed (and implemented) branch notes as notes
(git notes) being attached to the (sha1 of the) branch name (or any
other refname). They are versioned/shareable/syncable just like notes
are. I had all of this working (git branch --notes display, git
format-patch --cover-letter and such); what was missing was a way to
attach/look-up notes for remote branches, which is related to our
current lack of default handling of remote notes refs. That's not a
fundamental problem, just a matter of agreeing about a proper default
setup for remote notes refs.

As I said, others preferred local branch descriptions (no git notes) in
config, and that's what is in git.git now.

Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: bug? git format-patch -M -D then git am fails

[Michael J Gruber]

Junio C Hamano venit, vidit, dixit 14.11.2012 00:22:
> Joe Perches  writes:
> 
>> I don't believe that reversibility
>> is a really useful aspect of deletion patches
>> when there are known git repositories involved.
> 
> You can read "reversibility" as "safety" if you want.  We would want
> to make sure we know what we are deleting before deleting a path.
> 
> The history that the receiver of such a patch has may have further
> changes that are relevant that the sender of the deletion patch did
> not know about, and removing the path in such a case would make the
> result inconsistent.  If the sender did his work on top of the newer
> version with the change in the path, the sender's patch may still
> have deleted the path but would have had changes to other paths to
> compensate for the loss of that change.
> 

Just in case someone wants to hack on this: To be safe, "git am" would
need to read the blob's sha1 from something like

diff --git a/Makefile b/Makefile
deleted file mode 100644
index 1b6d84d..000

and check that the file to be deleted matches.

Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Notes in format-patch

[Michael J Gruber]

Junio C Hamano venit, vidit, dixit 13.11.2012 19:09:
> Junio C Hamano  writes:
> 
>> ... and it is broken X-<.
>>
>> The blank line should be added before the diffstat, not after the
>> notes message (t3307 shows a case where we give notes without
>> diffstat, and we shouldn't be adding an extra blank line in that
>> case.
> 
> Second try.
> 
> -- >8 --
> Subject: format-patch: add a blank line between notes and diffstat
> 
> The last line of the note text comes immediately before the diffstat
> block, making the latter unnecessarily harder to view.
> 
> Signed-off-by: Junio C Hamano 
> ---
> 
>  log-tree.c | 31 +--
>  1 file changed, 21 insertions(+), 10 deletions(-)

Thanks, that patch works. I'm curious, though, where the empty line
between the --- and your diffstat comes from. Do you have an empty note?
I'm not getting any (origin/next+your patch).

The fact that we don't usually have that empty line was the reason why I
preferred to have no empty line between the --- and the "Note:".

Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv4] replace: parse revision argument for -d

[Michael J Gruber]

'git replace' parses the revision arguments when it creates replacements
(so that a sha1 can be abbreviated, e.g.) but not when deleting
replacements.

Make it parse the argument to 'replace -d' in the same way.

Signed-off-by: Michael J Gruber 
---

Notes:
v4 names the aux variable more concisely and does away with a superfluous
assignment.
 builtin/replace.c  | 15 +--
 t/t6050-replace.sh | 11 +++
 2 files changed, 20 insertions(+), 6 deletions(-)

diff --git a/builtin/replace.c b/builtin/replace.c
index e3aaf70..398ccd5 100644
--- a/builtin/replace.c
+++ b/builtin/replace.c
@@ -46,24 +46,27 @@ typedef int (*each_replace_name_fn)(const char *name, const 
char *ref,
 
 static int for_each_replace_name(const char **argv, each_replace_name_fn fn)
 {
-   const char **p;
+   const char **p, *full_hex;
char ref[PATH_MAX];
int had_error = 0;
unsigned char sha1[20];
 
for (p = argv; *p; p++) {
-   if (snprintf(ref, sizeof(ref), "refs/replace/%s", *p)
-   >= sizeof(ref)) {
-   error("replace ref name too long: %.*s...", 50, *p);
+   if (get_sha1(*p, sha1)) {
+   error("Failed to resolve '%s' as a valid ref.", *p);
had_error = 1;
continue;
}
+   full_hex = sha1_to_hex(sha1);
+   snprintf(ref, sizeof(ref), "refs/replace/%s", full_hex);
+   /* read_ref() may reuse the buffer */
+   full_hex = ref + strlen("refs/replace/");
if (read_ref(ref, sha1)) {
-   error("replace ref '%s' not found.", *p);
+   error("replace ref '%s' not found.", full_hex);
had_error = 1;
continue;
}
-   if (fn(*p, ref, sha1))
+   if (fn(full_hex, ref, sha1))
had_error = 1;
}
return had_error;
diff --git a/t/t6050-replace.sh b/t/t6050-replace.sh
index 5c87f28..decdc33 100755
--- a/t/t6050-replace.sh
+++ b/t/t6050-replace.sh
@@ -140,6 +140,17 @@ test_expect_success '"git replace" replacing' '
  test "$HASH2" = "$(git replace)"
 '
 
+test_expect_success '"git replace" resolves sha1' '
+ SHORTHASH2=$(git rev-parse --short=8 $HASH2) &&
+ git replace -d $SHORTHASH2 &&
+ git replace $SHORTHASH2 $R &&
+ git show $HASH2 | grep "O Thor" &&
+ test_must_fail git replace $HASH2 $R &&
+ git replace -f $HASH2 $R &&
+ test_must_fail git replace -f &&
+ test "$HASH2" = "$(git replace)"
+'
+
 # This creates a side branch where the bug in H2
 # does not appear because P2 is created by applying
 # H2 and squashing H5 into it.
-- 
1.8.0.311.gdd08018

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Notes in format-patch (was: Re: [PATCHv3] replace: parse revision argument for -d)

[Michael J Gruber]

Michael J Gruber venit, vidit, dixit 12.11.2012 15:18:
> 'git replace' parses the revision arguments when it creates replacements
> (so that a sha1 can be abbreviated, e.g.) but not when deleting
> replacements.
> 
> Make it parse the argument to 'replace -d' in the same way.
> 
> Signed-off-by: Michael J Gruber 
> ---
> 
> Notes:
> v3 safeguards the hex buffer against reuse
>  builtin/replace.c  | 16 ++--
>  t/t6050-replace.sh | 11 +++
>  2 files changed, 21 insertions(+), 6 deletions(-)
> 
> diff --git a/builtin/replace.c b/builtin/replace.c

By the way - Junio, is that the intented outcome of "format-patch
--notes"? I would rather put the newline between the note and the
diffstat (and omit the one after the ---) but may have goofed up a rebase:

...

Signed-off-by: Michael J Gruber 
---
Notes:
v3 safeguards the hex buffer against reuse

 builtin/replace.c  | 16 ++--
...
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv3] replace: parse revision argument for -d

[Michael J Gruber]

Jeff King venit, vidit, dixit 12.11.2012 21:42:
> On Mon, Nov 12, 2012 at 03:18:02PM +0100, Michael J Gruber wrote:
> 
>> 'git replace' parses the revision arguments when it creates replacements
>> (so that a sha1 can be abbreviated, e.g.) but not when deleting
>> replacements.
>>
>> Make it parse the argument to 'replace -d' in the same way.
>>
>> Signed-off-by: Michael J Gruber 
>> ---
>>
>> Notes:
>> v3 safeguards the hex buffer against reuse
> 
> Thanks, I don't see any other functional problems.
> 
>> diff --git a/builtin/replace.c b/builtin/replace.c
>> index e3aaf70..33e6ec3 100644
>> --- a/builtin/replace.c
>> +++ b/builtin/replace.c
>> @@ -46,24 +46,28 @@ typedef int (*each_replace_name_fn)(const char *name, 
>> const char *ref,
>>  
>>  static int for_each_replace_name(const char **argv, each_replace_name_fn fn)
>>  {
>> -const char **p;
>> +const char **p, *q;
> 
> I find this readable today, but I wonder if in six months we will wonder
> what in the world "q" means. Maybe "short_refname" or something would be
> appropriate?

That would be sooo inappropriate! ;)

Maybe "full_hex"?

I should also do away with the first replacement which really made sense
in v1 only.

v4 to follow.

Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: RFD: fast-import is picky with author names (and maybe it should - but how much so?)

[Michael J Gruber]

Felipe Contreras venit, vidit, dixit 12.11.2012 23:47:
> On Mon, Nov 12, 2012 at 10:41 PM, Jeff King  wrote:
>> On Sun, Nov 11, 2012 at 07:48:14PM +0100, Felipe Contreras wrote:
>>
   3. Exporters should not use it if they have any broken-down
  representation at all. Even knowing that the first half is a human
  name and the second half is something else would give it a better
  shot at cleaning than fast-import would get.
>>>
>>> I'm not sure what you mean by this. If they have name and email, then
>>> sure, it's easy.
>>
>> But not as easy as just printing it. What if you have this:
>>
>>   name="Peff  King"
>>   email=""
>>
>> Concatenating them does not produce a valid git author name. Sending the
>> concatenation through fast-import's cleanup function would lose
>> information (namely, the location of the boundary between name and
>> email).
> 
> Right. Unfortunately I'm not aware of any DSCM that does that.
> 
>> Similarly, one might have other structured data (e.g., CVS username)
>> where the structure is a useful hint, but some conversion to name+email
>> is still necessary.
> 
> CVS might be the only one that has such structured data. I think in
> subversion the username has no meaning. A 'felipec' subversion
> username is as bad as a mercurial 'felipec' username.

In subversion, the username has the clearly defined meaning of being a
username on the subversion host. If the host is, e.g., a sourceforge
site then I can easily look up the user profile and convert the username
into a valid e-mail address (@users.sf.net). That is the
advantage that the exporter (together with user knowledge) has over the
importer.

If the initial clone process aborts after every single "unknown" user
it's no fun, of course. On the other hand, if an incremental clone
(fetch) let's commits with unknown author sneak in it's no fun either
(because I may want to fetch in crontab and publish that converted beast
automatically). That is why I proposed neither approach.

Most conveniently, the export side of a remote helper would

- do "obvious" automatic lossless transformations
- use an author map for other names
- For names not covered by the above (or having an empty map entry):
Stop exporting commits but continue parsing commits and amend the author
map with any unknown usernames (empty entry), and warn the user.
(crontab script can notify me based on the return code.)

If the cloning involves a "foreign clone" (like the hg clone behind the
scene) then the runtime of the second pass should be much smaller. In
principle, one could even store all blobs and trees on the first run and
skip that step on the second, but that would rely on immutability on the
foreign side, so I dunno. (And to check the sha1, we have to get the
blob anyways.)

As for the format for incomplete entries (foo ), a technical
guideline should suffice for those that follow guidelines.

Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv3] replace: parse revision argument for -d

[Michael J Gruber]

'git replace' parses the revision arguments when it creates replacements
(so that a sha1 can be abbreviated, e.g.) but not when deleting
replacements.

Make it parse the argument to 'replace -d' in the same way.

Signed-off-by: Michael J Gruber 
---

Notes:
v3 safeguards the hex buffer against reuse
 builtin/replace.c  | 16 ++--
 t/t6050-replace.sh | 11 +++
 2 files changed, 21 insertions(+), 6 deletions(-)

diff --git a/builtin/replace.c b/builtin/replace.c
index e3aaf70..33e6ec3 100644
--- a/builtin/replace.c
+++ b/builtin/replace.c
@@ -46,24 +46,28 @@ typedef int (*each_replace_name_fn)(const char *name, const 
char *ref,
 
 static int for_each_replace_name(const char **argv, each_replace_name_fn fn)
 {
-   const char **p;
+   const char **p, *q;
char ref[PATH_MAX];
int had_error = 0;
unsigned char sha1[20];
 
for (p = argv; *p; p++) {
-   if (snprintf(ref, sizeof(ref), "refs/replace/%s", *p)
-   >= sizeof(ref)) {
-   error("replace ref name too long: %.*s...", 50, *p);
+   q = *p;
+   if (get_sha1(q, sha1)) {
+   error("Failed to resolve '%s' as a valid ref.", q);
had_error = 1;
continue;
}
+   q = sha1_to_hex(sha1);
+   snprintf(ref, sizeof(ref), "refs/replace/%s", q);
+   /* read_ref() may reuse the buffer */
+   q = ref + strlen("refs/replace/");
if (read_ref(ref, sha1)) {
-   error("replace ref '%s' not found.", *p);
+   error("replace ref '%s' not found.", q);
had_error = 1;
continue;
}
-   if (fn(*p, ref, sha1))
+   if (fn(q, ref, sha1))
had_error = 1;
}
return had_error;
diff --git a/t/t6050-replace.sh b/t/t6050-replace.sh
index 5c87f28..decdc33 100755
--- a/t/t6050-replace.sh
+++ b/t/t6050-replace.sh
@@ -140,6 +140,17 @@ test_expect_success '"git replace" replacing' '
  test "$HASH2" = "$(git replace)"
 '
 
+test_expect_success '"git replace" resolves sha1' '
+ SHORTHASH2=$(git rev-parse --short=8 $HASH2) &&
+ git replace -d $SHORTHASH2 &&
+ git replace $SHORTHASH2 $R &&
+ git show $HASH2 | grep "O Thor" &&
+ test_must_fail git replace $HASH2 $R &&
+ git replace -f $HASH2 $R &&
+ test_must_fail git replace -f &&
+ test "$HASH2" = "$(git replace)"
+'
+
 # This creates a side branch where the bug in H2
 # does not appear because P2 is created by applying
 # H2 and squashing H5 into it.
-- 
1.8.0.311.gdd08018

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git merge commits are non-deterministic? what changed?

[Michael J Gruber]

Ulrich Spörlein venit, vidit, dixit 09.11.2012 19:27:
> On Fri, 2012-11-09 at 11:16:47 -0500, Jeff King wrote:
>> On Fri, Nov 09, 2012 at 04:52:48PM +0100, Matthieu Moy wrote:
>>
>>> Ulrich Spörlein  writes:
>>>
>> 2. Why the hell is the commit hash dependent on the ordering of the
>> parent commits? IMHO it should sort the set of parents before
>> calculating the hash ...
>
> What would be the sort key?

 Trivially, the hash of the parents itself. So you'd always get

 ...
 parent 
 parent 
 parent 
 parent 
>>>
>>> That would change the behavior of --first-parent. Or you'd need to
>>> compute the sha1 of the sorted list, but keep the unsorted one in the
>>> commit. Possible, but weird ;-).
>>
>> Right. The reason that merge parents are stored in the order given on
>> the command line is not random or because it was not considered. It
>> encodes a valuable piece of information: did the user merge "foo" into
>> "bar", or did they merge "bar" into "foo"?
>>
>> So I think this discussion is going in the wrong direction; git should
>> never sort the parents, because the order is meaningful. The original
>> complaint was that a run of svn2git produced different results on two
>> different git versions. The important question to me is: did svn2git
>> feed the parents to git in the same order?
>>
>> If it did, and git produced different results, then that is a serious
>> bug.
>>
>> If it did not, then the issue needs to be resolved in svn2git (which
>> _may_ want to sort the parents that it feeds to git, but it would depend
>> on whether the order it is currently presenting is meaningful).
> 
> Yeah, thanks, looks like I have some more work to do. I don't quite get
> how it could come up with a different order, seeing that it is using svn
> as the base.
> 
> Will run some more experiments, thanks for the info so far.

There was a change in the order in which "git cherry-pick A B C" applies
the commits. It's the only odering affecting change in 1.8.0 that I can
think of right now.

Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2] replace: parse revision argument for -d

[Michael J Gruber]

Jeff King venit, vidit, dixit 09.11.2012 17:48:
> On Mon, Oct 29, 2012 at 02:23:27PM +0100, Michael J Gruber wrote:
> 
>> 'git replace' parses the revision arguments when it creates replacements
>> (so that a sha1 can be abbreviated, e.g.) but not when deleting
>> replacements.
>>
>> Make it parse the arguments to 'replace -d' in the same way.
>>
>> Signed-off-by: Michael J Gruber 
>> ---
>> v2 has the simplified error check as per Jeff, and a reworded message.
>> Comes with a free test case, too.
> 
> I noticed this today in my pile of "to look at" patches. Sorry for being
> slow.

No problem. This is not urgent, and it takes some effort to look at code
amongst all those black-and-white discussions. [It even takes effort to
refrain from responding when you words are being twisted around...]

>>  for (p = argv; *p; p++) {
>> -if (snprintf(ref, sizeof(ref), "refs/replace/%s", *p)
>> ->= sizeof(ref)) {
>> -error("replace ref name too long: %.*s...", 50, *p);
>> +q = *p;
>> +if (get_sha1(q, sha1)) {
>> +error("Failed to resolve '%s' as a valid ref.", q);
>>  had_error = 1;
>>  continue;
>>  }
> 
> Looks reasonable.
> 
>> +q = sha1_to_hex(sha1);
>> +snprintf(ref, sizeof(ref), "refs/replace/%s", q);
>>  if (read_ref(ref, sha1)) {
>> -error("replace ref '%s' not found.", *p);
>> +error("replace ref '%s' not found.", q);
> 
> I worry a little about assuming that "q", which points to a static
> internal buffer of sha1_to_hex, is still valid after calling read_ref.
> We'll end up in resolve_ref, which might need to do considerable work
> (e.g., loading the whole packed refs file). Just grepping for
> sha1_to_hex, I don't think it is a problem currently, but it might be
> worth copying the value (you could even point into the "ref" buffer to
> avoid dealing with an extra allocation).

We could just leave '*p' as it is (after all, that was the user input),
or use 'ref+strlen("refs/replace/")'.

I wasn't aware of the volatile nature of the return value. Thanks for
spotting!

Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: RFD: fast-import is picky with author names (and maybe it should - but how much so?)

[Michael J Gruber]

Felipe Contreras venit, vidit, dixit 09.11.2012 15:34:
> On Fri, Nov 9, 2012 at 10:28 AM, Michael J Gruber
>  wrote:
> 
>> Hg seems to store just anything in the author field ("committer"). The
>> various interfaces that are floating around do some behind-the-back
>> conversion to git format. The more conversions they do, the better they
>> seem to work (no erroring out) but I'm wondering whether it's really a
>> good thing, or whether we should encourage a more diligent approach
>> which requires a user to map non-conforming author names wilfully.
> 
> So you propose that when somebody does 'git clone hg::hg hg-git' the
> thing should fail. I hope you don't think it's too unbecoming for me
> to say that I disagree.

There is no need to disagree with a proposal I haven't made. I would
disagree with the proposal that I haven't made, too.

> IMO it should be git fast-import the one that converts these bad
> authors, not every single tool out there. Maybe throw a warning, but
> that's all. Or maybe generate a list of bad authors ready to be filled
> out. That way when a project is doing a real conversion, say, when
> moving to git, they can run the conversion once and see which authors
> are bad and not multiple times, each try taking longer than the next.

As Jeff pointed out, git-fast-import expects output conforming to a
certain standard, and that's not going to change. import is agnostic to
where its import stream is coming from. Only the producer of that stream
can have additional information about the provenience of the stream's
data which may aid (possibly together with user input or choices) in
transforming that into something conforming.

Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: RFD: fast-import is picky with author names (and maybe it should - but how much so?)

[Michael J Gruber]

Jeff King venit, vidit, dixit 08.11.2012 21:09:
> On Fri, Nov 02, 2012 at 03:43:24PM +0100, Michael J Gruber wrote:
> 
>> It seems that our fast-import is super picky with regards to author
>> names. I've encountered author names like
>>
>> Foo Bar
>> Foo Bar > foo@dev.null
>>
>> in the self-hosting repo of some other dvcs, and the question is how to
>> translate them faithfully into a git author name.
> 
> It is not just fast-import. Git's author field looks like an rfc822
> address, but it's much simpler. It fundamentally does not allow angle
> brackets in the "name" field, regardless of any quoting. As you noted in
> your followup, we strip them out if you provide them via
> GIT_AUTHOR_NAME.
> 
> I doubt this will change anytime soon due to the compatibility fallout.
> So it is up to generators of fast-import streams to decide how to encode
> what they get from another system (you could come up with an encoding
> scheme that represents angle brackets).

I don't expect our requirements to change. For one thing, I was
surprised that git-commit is more tolerant than git-fast-import, but it
makes a lot of sense to avoid any behind-the-back conversions in the
importer.

>> In general, we try to do
>>
>> fullotherdvcsname 
>>
>> if the other system's entry does not parse as a git author name, but
>> fast-import does not accept either of
>>
>> Foo Bar 
>> "Foo Bar" 
>>
>> because of the way it parses for <>. While the above could be easily
>> turned into
>>
>> Foo Bar 
>>
>> it would not be a faithful representation of the original commit in the
>> other dvcs.
> 
> I'd think that if a remote system has names with angle brackets and
> email-looking things inside them, we would do better to stick them in
> the email field rather than putting in a useless . The latter
> should only be used for systems that lack the information.
> 
> But that is a quality-of-implementation issue for the import scripts
> (and they may even want to have options, just like git-cvsimport allows
> mapping cvs usernames into full identities).

That was more my real concern. In our cvs and svn interfaces, we even
encourage the use of author maps. For example, if you use an author map,
git-svn errors out if it encounters an svn user name which is not in the
map. On the other hand, we can map all (most?) svn user names faithfully
without using a map (e.g. to "username ").

Hg seems to store just anything in the author field ("committer"). The
various interfaces that are floating around do some behind-the-back
conversion to git format. The more conversions they do, the better they
seem to work (no erroring out) but I'm wondering whether it's really a
good thing, or whether we should encourage a more diligent approach
which requires a user to map non-conforming author names wilfully.

Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] push/pull: adjust missing upstream help text to changed interface

[Michael J Gruber]

Junio C Hamano venit, vidit, dixit 06.11.2012 15:45:
> 
> 
> Michael J Gruber  wrote:
> 
>> Yes, I'm in low hanging fruits mood.
>>
>> Signed-off-by: Michael J Gruber 
> 
> It is called tying loose ends, and is very important. Very much appreciated.

;)

By the way: The gotcha with the signed-off-by after the note is due to
my old format-patch-notes being tripped up by the recent restructuring;
your version in next get's it right. I've dumped my old branch, and I
hope the maintainer in chief will shuffle around the s-o-b where it belongs.

Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] push/pull: adjust missing upstream help text to changed interface

[Michael J Gruber]

In case of a missing upstream, the git-parse-remote script suggests:

If you wish to set tracking information for this branch you can do so
with:

git branch --set-upstream nsiv2 origin/

But --set-upstream is deprectated. Change the suggestion to:

git branch --set-upstream-to=origin/ nsiv2

Reported-by: Jeroen van der Ham 
---
Yes, I'm in low hanging fruits mood.

Signed-off-by: Michael J Gruber 
---
 git-parse-remote.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/git-parse-remote.sh b/git-parse-remote.sh
index 484b2e6..0e87e09 100644
--- a/git-parse-remote.sh
+++ b/git-parse-remote.sh
@@ -80,7 +80,7 @@ See git-${cmd}(1) for details
 
 If you wish to set tracking information for this branch you can do so with:
 
-git branch --set-upstream ${branch_name#refs/heads/} $remote/
+git branch --set-upstream-to=$remote/ ${branch_name#refs/heads/}
 "
fi
exit 1
-- 
1.8.0.226.gba44ac5

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Lack of netiquette, was Re: [PATCH v4 00/13] New remote-hg helper

[Michael J Gruber]

[trimmed down heavily by mjg]
Felipe Contreras venit, vidit, dixit 05.11.2012 16:22:
> On Mon, Nov 5, 2012 at 10:25 AM, Michael J Gruber
>  wrote:
>> Felipe Contreras venit, vidit, dixit 02.11.2012 17:09:
>>> On Fri, Nov 2, 2012 at 12:03 PM, Michael J Gruber
>>>  wrote:

> There is no lack of openness from my part. I hear all technical
> arguments, and I reply on a technical basis. The problem seems to be
> is that you expect the code submitted to be criticized, but not the
> criticism it receives. IOW; the submitter has to put up with anything
> anybody says about his/her code and ideas, but the *reviewer* is
> untouchable; the submitter cannot ever criticize the reviewer. I can

Feel free to criticize the criticism, just don't offend the criticizer
(be it the reviewer or the submitter).

> tell you that doesn't happen in the Linux kernel; the review process
> is a _discussion_, not a one-way communication, and discussions can be
> heated up, but the end result is better code, *both* sides are open to
> criticism, the submitter, *and* the reviewer.

Exactly, both.

>> And no, using the same or similar language does not make us the same at
>> all. Using the same language is the natural prerequisite for successful
>> communication.
> 
> Nobody said otherwise.

Well, you did in the post I responded to:

>>> The dangers of "everyone" following the same style of communication,
>>> and making "everyone" feel comfortable, is that "everyone" ends up
>>> being the same kind of people

In any case, I feel I've showed enough efforts and there's no point in
dragging this on.

Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Support for a series of patches, i.e. patchset or changeset?

[Michael J Gruber]

Eric Miao venit, vidit, dixit 05.11.2012 15:12:
> The problem is, most cases we have no idea of the base rev1, and commit rev2
> which it's leading up to. E.g. for a single patch which is between
> commit rev1..rev2,
> how do we find out rev1 and rev2.

So, then the question is: What do you know/have? Is your patch the
output of "git format-patch", "git diff", or just some sort of diff
without any git information?

Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git log --graph --oneline - false parent-child visualization

[Michael J Gruber]

martyone venit, vidit, dixit 05.11.2012 13:57:
> Hello,
> 
> the combination of --graph and --oneline sometimes produces output
> which is -- at least for me -- not clear about parent-child relation
> between commits. I noticed it when using with --simplify-by-decoration
> switch but it should not be specific to the use of this switch.
> 
> See this example output (git version 1.7.11.3)
> 
> | | | * eead15f (origin/branchA) Lorem ipsum dolor sit amet
> | |_|/
> |/| |
> | | | * 8da3b9f (origin/branchB) Consectetur adipisicing elit
> | | |/
> | | | * c4d6b9a (origin/branchC) Sed do eiusmod tempor incididunt ut labore
> | | | * d623246 (origin/branchD) Ut enim ad minim veniam
> | | |/
> | | | * 458d305 (origin/btanchE) Quis nostrud exercitation ullamco laboris
> | | |/
> 
> Here it seems commit c4d6b9a is based on d623246. But when the format
> is more-than-oneline (or when checked with gitk), it is clear there is
> no relation between commits c4d6b9a and d623246.
> 
> | | | * commit eead15f (origin/branchA)
> | |_|/  Author: John Doe 
> |/| |
> | | |   Lorem ipsum dolor sit amet
> | | |
> | | | * commit 8da3b9f (origin/branchB)
> | | |/  Author: John Doe 
> | | |
> | | |   Consectetur adipisicing elit
> | | |
> | | | * commit c4d6b9a (origin/branchC)
> | | |   Author: John Doe 
> | | |
> | | |   Sed do eiusmod tempor incididunt ut labore
> | | |
> | | | * commit d623246 (origin/branchD)
> | | |/  Author: John Doe 
> | | |
> | | |   Ut enim ad minim veniam
> | | |
> | | | * commit 458d305 (origin/branchE)
> | | |/  Author: John Doe 
> | | |
> | | |   Quis nostrud exercitation ullamco laboris
> | | |
> 
> Correct output produced with --oneline switch should output an extra
> newline when commit has no parent listed:
> 
> | | | * eead15f (origin/branchA) Lorem ipsum dolor sit amet
> | |_|/
> |/| |
> | | | * 8da3b9f (origin/branchB) Consectetur adipisicing elit
> | | |/
> | | | * c4d6b9a (origin/branchC) Sed do eiusmod tempor incididunt ut labore
> | | |
> | | | * d623246 (origin/branchD) Ut enim ad minim veniam
> | | |/
> | | | * 458d305 (origin/btanchE) Quis nostrud exercitation ullamco laboris
> | | |/
> 
> Best Regards,
> Martin
> 

Yes, you have the same problem when you simply have two disjoint
branches: They're listed "concatenated". The problem is that log --graph
uses the single symbol "*" for many different cases, independent of the
number of ingoing or outgoing lines. There are two solutions:

- use more spacing
- use more symbols (like tig does) and stay compact

Feel free to experiment ;)

Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 00/13] New remote-hg helper

[Michael J Gruber]

Felipe Contreras venit, vidit, dixit 02.11.2012 19:01:
> On Fri, Nov 2, 2012 at 5:41 PM, Felipe Contreras
>  wrote:
>> On Fri, Nov 2, 2012 at 3:48 PM, Jeff King  wrote:
>>> On Thu, Nov 01, 2012 at 05:08:52AM +0100, Felipe Contreras wrote:
>>>
> Turns out msysgit's remote-hg is not exporting the whole repository,
> that's why it's faster =/

 It seems the reason is that it would only export to the point where
 the branch is checked out. After updating the to the tip I noticed
 there was a performance difference.

 I investigated and found two reasons:

 1) msysgit's version doesn't export files twice, I've now implemented the 
 same
 2) msysgit's version uses a very simple algorithm to find out file changes

 This second point causes msysgit to miss some file changes. Using the
 same algorithm I get the same performance, but the output is not
 correct.
>>>
>>> Do you have a test case that demonstrates this? It would be helpful for
>>> reviewers, but also helpful to msysgit people if they want to fix their
>>> implementation.
>>
>> Cloning the mercurial repo:
>>
>> % hg log --stat -r 131
>> changeset:   131:c9d51742471c
>> parent:  127:44538462d3c8
>> user:j...@edge2.net
>> date:Sat May 21 11:35:26 2005 -0700
>> summary: moving hgweb to mercurial subdir
>>
>>  hgweb.py   |  377
>> --
>>  mercurial/hgweb.py |  377
>> ++
>>  2 files changed, 377 insertions(+), 377 deletions(-)
>>
>> % git show --stat 1f9bcfe7cc3d7af7b4533895181acd316ce172d8
>> commit 1f9bcfe7cc3d7af7b4533895181acd316ce172d8
>> Author: j...@edge2.net 
>> Date:   Sat May 21 11:35:26 2005 -0700
>>
>> moving hgweb to mercurial subdir
>>
>>  mercurial/hgweb.py | 377
>> ++
>>  1 file changed, 377 insertions(+)
> 
> I talked with some people in #mercurial, and apparently there is a
> concept of a 'changelog' that is supposed to store these changes, but
> since the format has changed, the content of it is unreliable. That's
> not a big problem because it's used mostly for reporting purposes
> (log, query), not for doing anything reliable.

Is the changelog stored in the repo (i.e. generated by the hg version at
commit time) or generated on the fly (i.e. generated by the hg version
at hand)? See also below.

> To reliably see the changes, one has to compare the 'manifest' of the
> revisions involved, which contain *all* the files in them.

'manifest' == '(exploded) tree', right? Just making sure my hg fu is not
subzero.

> That's what I was doing already, but I found a more efficient way to
> do it. msysGit is using the changelog, which is quite fast, but not
> reliable.
> 
> Unfortunately while going trough mercurial's code, I found an issue,
> and it turns out that 1) is not correct.
> 
> In mercurial, a file hash contains also the parent file nodes, which
> means that even if two files have the same content, they would not
> have the same hash, so there's no point in keeping track of them to
> avoid extracting the data unnecessarily, because in order to make sure
> they are different, you need to extract the data anyway, defeating the
> purpose.

Do I understand correctly that neither the msysgit version nor yours can
detect duplicate blobs (without requesting them) because of that sha1 issue?

I'm really wondering why a file blob hash carries its history along in
the sha1. This appears completely strange to gitters (being brain washed
about "content tracking"), but may be due to hg's extensive use of
delta, or really: delta chains (which do have their merit on the server
side).

> Which means mercurial doesn't really behave as one would expect:
> 
> # add files with the same content
> 
>  $ echo a > a
>   $ hg ci -Am adda
>   adding a
>   $ echo a >> a
>   $ hg ci -m changea
>   $ echo a > a
>   $ hg st --rev 0
>   $ hg ci -m reverta
>   $ hg log -G --template '{rev} {desc}\n'
>   @  2 reverta
>   |
>   o  1 changea
>   |
>   o  0 adda
> 
> # check the difference between the first and the last revision
> 
>   $ hg st --rev 0:2
>   M a
>   $ hg cat -r 0 a
>   a
>   $ hg cat -r 2 a
>   a

That is really scary. What use is "hg stat --rev" then? Not blaming you
for hg, of course.

On that tangent, I just noticed recently that hg has no python api.
Seriously [1]. They even tell us not to use the internal python api.
msysgit has been lacking support for newer hg, and you've had to add
support for older versions (hg 1.9 will be around on quite some
stable/LTS/EL distro releases) after developing on newer/current ones.
I'm wondering how well that scales in the long term (telling from
git-svn experience: it does not scale well), or whether using some
stable api like 'hgapi' would be a huge bottleneck

Re: Support for a series of patches, i.e. patchset or changeset?

[Michael J Gruber]

Eric Miao venit, vidit, dixit 05.11.2012 03:26:
> Hi All,
> 
> Does anyone know if git has sort of support for a series of patches, i.e.
> a patchset or changeset? So whenever we know the SHA1 id of a single
> patch/commit, we know the patchset it belongs to. This is normal when
> we do big changes and split that into smaller pieces and doing only one
> simple thing in a single commit.
> 
> This will be especially useful when tracking and cherry-picking changes,
> i.e. monitoring on the changes of some specific files, and if a specific
> patch is interesting, we may want to apply the whole changeset, not only
> that specific one.

First of all, if you know the sha1 of a commit, then all its ancestors
are determined by that. If you want to describe a set of patches, say
based on rev1 and leading up to rev2, then the expression

rev2 ^rev1

describes that set uniquely. Often you can do without ^rev1, e.g. if you
know that all patch series are developed bases on origin/master, then
specifying rev2 is enough as "git rev-list rev2 ^origin/master" will
give you all commits in the series (unless they have been integrated,
i.e. merged).

Or are you thinking about patches "independent" of a base?

Cheers,
Michael

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Lack of netiquette, was Re: [PATCH v4 00/13] New remote-hg helper

[Michael J Gruber]

Felipe Contreras venit, vidit, dixit 02.11.2012 17:09:
> On Fri, Nov 2, 2012 at 12:03 PM, Michael J Gruber
>  wrote:
>> Andreas Ericsson venit, vidit, dixit 02.11.2012 10:38:
>>> On 11/01/2012 02:46 PM, René Scharfe wrote:
>>>>
>>>> Also, and I'm sure you didn't know that, "Jedem das Seine" (to each
>>>> his own) was the slogan of the Buchenwald concentration camp.  For
>>>> that reason some (including me) hear the unspoken cynical
>>>> half-sentence "and some people just have to be sent to the gas
>>>> chamber" when someone uses this proverb.
>>>>
>>>
>>> It goes further back than that.
>>>
>>> "Suum cuique pulchrum est" ("To each his own is a beautiful thing") is
>>> a latin phrase said to be used frequently in the roman senate when
>>> senators politely agreed to disagree and let a vote decide the outcome
>>> rather than debating further.
>>>
>>> Please don't let the twisted views of whatever nazi idiot thought it
>>> meant "you may have the wrong faith and therefore deserve to die, so you
>>> shall" pollute it. The original meaning is both poetic and democratic,
>>> and I firmly believe most people have the original meaning to the fore
>>> of their mind when using it. After all, very few people knowingly quote
>>> nazi concentration camp slogans.
>>>
>>
>> In fact, many German terms and words are "forbidden area" since Nazi
>> times, but I don't think this one carries the same connotation.
>>
>> But that is a side track.
>>
>> Collaboration (and code review is a form of collaboration) requires
>> communication. The linked code of conduct pages describe quite well how
>> to ensure a productive environment in which "everyone" feels comfortable
>> communicating and collaborating.
> 
> Yes, but that's assuming we want "everyone" to feel comfortable
> communicating and collaborating.

I put "everyone" in quotes because you can never reach 100%, so
"everyone" means almost everyone.

Undeniably, the answers in this and the other threads show that on the
git mailing list, "everyone" wants "everyone" to feel comfortable
communicating and collaborating.

> I cite again the example of the Linux
> kernel, where certainly not "everyone" feels that way. But somehow

It's a different list with different standards and tone, so it doesn't
really matter for our list. That being said:

> they manage to be perhaps the most successful software project in
> history. And I would argue even more: it's _because_ not everyone
> feels comfortable, it's because ideas and code are criticized freely,
> and because only the ones that do have merit stand. If you are able to
> take criticism, and you are not emotionally and personally attacked to
> your code and your ideas, you would thrive in this environment. If you
> don't want your precious little baby code to fight against the big
> guys, then you shouldn't send it out to the world.

For one thing, contributors on the kernel list are open to technical
arguments, and that includes the arguments of others; just like we are
here. On the other hand, you seem to rebuke "any" (most) technical
argument in harsh words as if it were a personal attack; at least that's
how your answers come across to me (and apparently others). That really
makes it difficult for most of us here to argue with you technically,
which is a pity. That lack of openness for the arguments of others would
make your life difficult on the kernel list also.

A completely different issue is that of language. You talk German on a
German list and English on an international list. You talk "kernel
English" on the kernel list, which is full of words and phrases you
would never use in a normal social setting where you talk to people in
person; it would be completely unacceptable. Here on the Git list, we
prefer to talk like in a normal, albeit colloquial social setting. If
you're open for advice: just imagine talking to the people here in
person, to colleagues across your desk, and you have a good guideline.

And no, using the same or similar language does not make us the same at
all. Using the same language is the natural prerequisite for successful
communication.

Felipe, please try to see the efforts many of us are making here in
order to keep you as a contributor, and reward it by accepting the
advice to revise your language: colleague to colleague.

Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: RFD: fast-import is picky with author names (and maybe it should - but how much so?)

[Michael J Gruber]

Some additional input:

[mjg@localhost git]$ git commit --author='"is this"
' --allow-empty -m test
[detached HEAD 0734308] test
 Author: is thi...@or.not 
[mjg@localhost git]$ git show
commit 0734308b7bf372227bf9f5b9fd6b4b403df33b9e
Author: is thi...@or.not 
Date:   Fri Nov 2 15:45:23 2012 +0100

test

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html