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

[Ralf Thielow]

2015-12-28 20:32 GMT+01:00 Matthias Rüster :
> Hi Ralf,
>
>>   #: builtin/submodule--helper.c:273
>>   msgid "fatal: submodule--helper subcommand must be called with a
>> subcommand"
>> -msgstr ""
>> +msgstr "fatal: submodule-helper muss mit einem Unterkommando aufgerufen
>> werden"
>>
>>   #: builtin/submodule--helper.c:280
>>   #, c-format
>>   msgid "fatal: '%s' is not a valid submodule--helper subcommand"
>> -msgstr ""
>> +msgstr "fatal: '%s' ist kein gültiges Unterkommando von submodule-helper"
>
>
> submodule--helper (at both lines: one minus sign is missing)
>
> Everything else looks great!
>
> Acked-by: Matthias Rüster 
>

Thanks!

>
> Kind regards,
> Matthias
--
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] notes: allow merging from arbitrary references

[Junio C Hamano]

Junio C Hamano  writes:

> OK, will try to queue again (but I am cutting an -rc today so it may
> have to wait a bit).  Those who have been involved in the notes topics
> need to review it before the patch can make progress, though.

Just FYI, with this the tip of 'pu' seems to fail a few tests in
t3310.

--
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 V5 2/2] user-manual: add section documenting shallow clones

[Stephen P. Smith]

Rather than merely pointing readers at the 1.5 release notes to
learn about shallow clones, document them formally.

Signed-off-by: Stephen P. Smith 
---

Notes:
Added a paragraph about the fundamental limitation with merging
histories that do not have a merge base in the shallow repository.

The review comment implied that since the first two limitations have
been lifted they would not need to be noted [1].

[1] http://article.gmane.org/gmane.comp.version-control.git/283052

 Documentation/user-manual.txt | 22 +++---
 1 file changed, 19 insertions(+), 3 deletions(-)

diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 1c790ac..78f878d 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -2128,6 +2128,25 @@ The gitweb cgi script provides users an easy way to 
browse your
 project's files and history without having to install Git; see the file
 gitweb/INSTALL in the Git source tree for instructions on setting it up.
 
+[[how-to-get-a-git-repository-with-minimal-history]]
+How to get a Git repository with minimal history
+
+
+A <>, with its truncated
+history, is useful when one is interested only in recent history
+of a project and getting full history from the upstream is
+expensive.
+
+A <> is created by specifying
+the linkgit:git-clone[1] `--depth` switch. The depth can later be
+changed with the linkgit:git-fetch[1] `--depth` switch, or full
+history restored with `--unshallow`.
+
+Merging inside a <> will work as long
+as the merge base is in the resent history.  If the merge base is not
+present then the merge would be of un-related histories.  This
+limitaion is fundamental and will not be removed.
+
 [[sharing-development-examples]]
 Examples
 
@@ -4645,9 +4664,6 @@ standard end-of-chapter section?
 
 Include cross-references to the glossary, where appropriate.
 
-Document shallow clones?  See draft 1.5.0 release notes for some
-documentation.
-
 Add a section on working with other version control systems, including
 CVS, Subversion, and just imports of series of release tarballs.
 
-- 
2.7.0-rc2

--
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 stash pop" is doing an unwanted "git add" when there are conflicts.

[Junio C Hamano]

Jeff King  writes:

> Yeah, I think I agree. But keep in mind that we have to mention the
> conflicts _somewhere_, so we're going to touch the index regardless (and
> the user is going to have to erase the conflicts in the index
> eventually, either with `git add` or `git reset`).

I do not think there is much we can do at this point in time (but
notice that I did say "much", and didn't say "anything").

The way we replay any potentially conflicting change and present the
result to the end user in Git is uniformly to add the cleanly
applied parts to the index while leaving the conflicted ones as
unmerged index entries, but "git stash apply/pop" does not follow
this pattern.  I think this is partly because the command is also
used to "stash away" a work-in-progress changes to the index, and
avoiding to touch the index with the changes in the working tree
would more closely match the behaviour of the command when there is
no conflict.

I notice that I said the same thing long time ago, i.e. in the
initial round of review:

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

| However, I think it is a bit counterintuitive to update the
| working tree change to the index if the merge did not conflict.
| It might be better to run an equivalent of "git reset", so that
| after "git save restore", the user can say "git diff" (not "git
| diff HEAD") to view the local changes.  Perhaps...

In the above, I suggested to "git reset" when there is no conflict.
I think this line of thinking can be followed even further to
selectively reset the paths that were cleanly merged (which is added
by the call to merge-recursive), leaving _only_ the conflicted paths.

Would that give us a better outcome?  I dunno.

>> Are there any prospects of this getting fixed?
>
> Somebody needs to write a patch. I am not 100% convinced that it
> _should_ be fixed, but I am leaning that way. But I am not planning to
> work on it myself anytime soon. The best way to get more discussion
> going is to post a patch. :)
--
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 V4 1/2] glossary: define the term shallow clone

[Stephen P. Smith]

There are several places in the documentation that
the term shallow clone is used. Defining the term
enables its use elsewhere with a known definition.

Signed-off-by: Stephen P. Smith 
---

Notes:
The review comments for the user guide update[1] suggested a change
in the definition of a shallow clone to:
   - note differences between a shallow clone and a shallow repository and
   - define it as a noun (which is the way the user guide update
 patch uses the term)

[1] http://article.gmane.org/gmane.comp.version-control.git/283052

 Documentation/glossary-content.txt | 5 +
 1 file changed, 5 insertions(+)

diff --git a/Documentation/glossary-content.txt 
b/Documentation/glossary-content.txt
index e225974..cafc284 100644
--- a/Documentation/glossary-content.txt
+++ b/Documentation/glossary-content.txt
@@ -531,6 +531,11 @@ The most notable example is `HEAD`.
"Secure Hash Algorithm 1"; a cryptographic hash function.
In the context of Git used as a synonym for <>.
 
+[[def_shallow_clone]]shallow clone::
+   Mostly a synonym to <>
+   but the phrase makes it more explicit that it was created by
+   running `git clone --depth=...` command.
+
 [[def_shallow_repository]]shallow repository::
A shallow <> has an incomplete
history some of whose <> have 
<> cauterized away (in other
-- 
2.7.0-rc2

--
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 v3] l10n: de.po: translate 68 new messages

[Ralf Thielow]

Translate 68 new messages came from git.pot update in
f4f2c8f (l10n: git.pot: v2.7.0 round 1 (66 new, 29 removed)) and
2c0ca05 (l10n: git.pot: v2.7.0 round 2 (2 new, 2 removed)).

Signed-off-by: Ralf Thielow 
Acked-by: Matthias Rüster 
---
 po/de.po | 190 ---
 1 file changed, 84 insertions(+), 106 deletions(-)

diff --git a/po/de.po b/po/de.po
index 1ce4193..8c5f05d 100644
--- a/po/de.po
+++ b/po/de.po
@@ -32,17 +32,16 @@ msgstr ""
 "und zu committen."
 
 #: advice.c:101 builtin/merge.c:1225
 msgid "You have not concluded your merge (MERGE_HEAD exists)."
 msgstr "Sie haben Ihren Merge nicht abgeschlossen (MERGE_HEAD existiert)."
 
 #: advice.c:103
-#, fuzzy
 msgid "Please, commit your changes before merging."
-msgstr "Bitte committen Sie Ihre Änderungen, bevor Sie den Merge ausführen."
+msgstr "Bitte committen Sie Ihre Änderungen, bevor Sie mergen."
 
 #: advice.c:104
 msgid "Exiting because of unfinished merge."
 msgstr "Beende wegen nicht abgeschlossenem Merge."
 
 #: archive.c:12
 msgid "git archive []  [...]"
@@ -1110,54 +1109,54 @@ msgstr "Konnte Referenzen nicht entfernen: %s"
 #, c-format
 msgid "could not remove reference %s"
 msgstr "Konnte Referenz %s nicht löschen"
 
 #: ref-filter.c:245
 #, c-format
 msgid "format: %%(end) atom used without corresponding atom"
-msgstr ""
+msgstr "Format: %%(end) Atom ohne zugehöriges Atom verwendet"
 
 #: ref-filter.c:704
 #, c-format
 msgid "positive value expected contents:lines=%s"
-msgstr ""
+msgstr "Positiver Wert erwartet contents:lines=%s"
 
 #: ref-filter.c:833
 #, c-format
 msgid "expected format: %%(color:)"
-msgstr ""
+msgstr "Erwartetes Format: %%(color:)"
 
 #: ref-filter.c:835
 msgid "unable to parse format"
 msgstr "Konnte Format nicht parsen."
 
 #: ref-filter.c:870
 #, c-format
 msgid "expected format: %%(align:,)"
-msgstr ""
+msgstr "Erwartetes Format: %%(align:,)"
 
 #: ref-filter.c:893
 #, c-format
 msgid "improper format entered align:%s"
-msgstr ""
+msgstr "Sie haben ein ungültiges Format eingegeben align:%s"
 
 #: ref-filter.c:898
 #, c-format
 msgid "positive width expected with the %%(align) atom"
-msgstr ""
+msgstr "Positive Breitenangabe für %%(align) erwartet"
 
 #: ref-filter.c:1219
 #, c-format
 msgid "malformed object at '%s'"
 msgstr "fehlerhaftes Objekt bei '%s'"
 
 #: ref-filter.c:1561
 #, c-format
 msgid "format: %%(end) atom missing"
-msgstr ""
+msgstr "Format: %%(end) Atom fehlt"
 
 #: ref-filter.c:1615
 #, c-format
 msgid "malformed object name %s"
 msgstr "Missgebildeter Objektname %s"
 
 #: remote.c:756
@@ -2632,22 +2631,20 @@ msgstr ""
 
 #: builtin/am.c:2220
 #, c-format
 msgid "Invalid value for --patch-format: %s"
 msgstr "Ungültiger Wert für --patch-format: %s"
 
 #: builtin/am.c:2253
-#, fuzzy
 msgid "git am [] [(|)...]"
-msgstr "git am [Optionen] [(|)...]"
+msgstr "git am [] [(|)...]"
 
 #: builtin/am.c:2254
-#, fuzzy
 msgid "git am [] (--continue | --skip | --abort)"
-msgstr "git am [Optionen] (--continue | --skip | --abort)"
+msgstr "git am [] (--continue | --skip | --abort)"
 
 #: builtin/am.c:2260
 msgid "run interactively"
 msgstr "interaktiv ausführen"
 
 #: builtin/am.c:2262
 msgid "historical option -- no-op"
@@ -3476,17 +3473,16 @@ msgid "git branch [] [-r] (-d | -D) 
..."
 msgstr "git branch [] [-r] (-d | -D) ..."
 
 #: builtin/branch.c:28
 msgid "git branch [] (-m | -M) [] "
 msgstr "git branch [] (-m | -M) [] "
 
 #: builtin/branch.c:29
-#, fuzzy
 msgid "git branch [] [-r | -a] [--points-at]"
-msgstr "git branch [] [-r | -a] [--merged | --no-merged]"
+msgstr "git branch [] [-r | -a] [--points-at]"
 
 #: builtin/branch.c:142
 #, c-format
 msgid ""
 "deleting branch '%s' that has been merged to\n"
 " '%s', but not yet merged to HEAD."
 msgstr ""
@@ -3738,22 +3734,20 @@ msgid "edit the description for the branch"
 msgstr "die Beschreibung für den Branch bearbeiten"
 
 #: builtin/branch.c:644
 msgid "force creation, move/rename, deletion"
 msgstr "Erstellung, Verschiebung/Umbenennung oder Löschung erzwingen"
 
 #: builtin/branch.c:645
-#, fuzzy
 msgid "print only branches that are merged"
-msgstr "nur Branches ausgeben, welche diesen Commit beinhalten"
+msgstr "nur zusammengeführte Branches ausgeben"
 
 #: builtin/branch.c:646
-#, fuzzy
 msgid "print only branches that are not merged"
-msgstr "nur Branches ausgeben, welche diesen Commit beinhalten"
+msgstr "nur nicht zusammengeführte Branches ausgeben"
 
 #: builtin/branch.c:647
 msgid "list branches in columns"
 msgstr "Branches in Spalten auflisten"
 
 #: builtin/branch.c:648 builtin/for-each-ref.c:38 builtin/tag.c:366
 msgid "key"
@@ -3766,17 +3760,16 @@ msgstr "sortiere nach diesem Feld"
 #: builtin/branch.c:651 builtin/for-each-ref.c:41 builtin/notes.c:398
 #: builtin/notes.c:401 builtin/notes.c:561 builtin/notes.c:564
 #: builtin/tag.c:369
 msgid "object"
 msgstr "Objekt"
 
 #: builtin/branch.c:652
-#, fuzzy
 msgid "print only 

Re: [PATCH v2 0/3] improve symbolic-ref robustness

[Junio C Hamano]

Michael Haggerty  writes:

> On 12/29/2015 06:55 AM, Jeff King wrote:
>
>> The patches are:
>> 
>>   [1/3]: create_symref: modernize variable names
>>   [2/3]: create_symref: use existing ref-lock code
>>   [3/3]: create_symref: write reflog while holding lock
>
> Thanks, Peff. The whole series is
>
> Reviewed-by: Michael Haggerty 
>
> Michael

Thanks, both.
--
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/6] apply: fix adding new files on i-t-a entries

[Junio C Hamano]

Duy Nguyen  writes:

> Not enough energy to go through this. Will do later and post new
> proposed commit message.

I do not have as much issue with the log message as what the patch
does, actually; this change does not look like a good one, which is
a more serious problem.

--
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 v2 0/2] add regex match flags to git describe

[Junio C Hamano]

Mostyn Bramley-Moore  writes:

>> I do not think it is wrong per-se to add an option to use regular
>> expressions instead of globs, but if we are to do so, the endgame we
>> aim for MUST be that we do so consistently to all the other commands
>> that iterate over refs and limit their output to the ones that match
>> given pattern (or a set of patterns), not just 'describe'.
>
> There is one important distinction between 'git describe' and the
> other commands that iterate through refs- it applies an internal
> search strategy and outputs at most one match.  This makes it
> difficult to search for the closest matching tag...

If that was what you were trying to solve, then it sounds like a
typical XY problem.  You do not need custom matching flags; you need
a "give me N (or all) names based on possible tags" option.

And I do not think it is a bad thing to add.  I already
said that an option to match with a regular expression is not a bad
thing to add, either ;-)

> Besides 'git grep', the only regex type flag that is given a short
> option seems to be -E for 'git log' and 'git rev-list'.  I have no
> objection to dropping the short options, or leaving only -E.

They also take -F, but "log" and friends do not pattern match the
refnames, so I do not think you have to worry about them at the
moment.

It is more important to envision what we would do in the future when
a command that takes a pattern (or a set of patterns) to match the
refnames with _and_ another pattern (or a set of patterns) to match
something else, and take that into account when designing this
"allowing matching logic for refnames to be customized from glob to
something else" feature, so that we do not paint outselves into a
corner we cannot later get out of.  Imagine a hypothetical command
'git mgrep' that can look for a pattern in tips of multiple branches
that can be used this way:

$ git mgrep -e 'froo*tz' --refs 'refs/heads/release/*'

which may look for strings that match "froo*tz" in the trees of
all branches whose name match the pattern 'release/*'.  In this
example, the pattern to match strings is a BRE (same default as 
"git grep"), and the pattern to match refnames is a glob.

Consistency & similarity with "git grep" would most likely lead us
to add -E/-F/-G/-P options to this command and to make it affect how
the pattern to match strings works.  For example:

$ git mgrep -E -e 'fro+tz' --match-refs 'refs/heads/release/*'

may look for the same strings that would match the first example,
but the pattern is expressed in ERE.  "-P", "-G", and "-F" options
would also work the same way.

Now, the question is what this "-E" (or -P/-G/-F) should do with the
matching the command does with the refnames.  The easiest (and
laziest) way out from the implementors' point of view might be to
declare that they affect both at the same time.  But is that useful
in practice?  It probably isn't, as it forces the users to write

$ git mgrep -E -e 'fro+tz' --match-refs 'refs/heads/release/.*'

because the ref matching suddenly starts to use ERE (not glob),
which most likely is not something users would expect.  So we may
need a separate set of options to affect the way how refs are
matched.

We cannot just say "but we do not have that 'mgrep' command yet, so
we can do whatever we want to do with 'describe' today".  When the
need eventually arises that requires us to be able to specify how
strings are matched and how refnames are matched independently, we
would end up with an inconsistent UI where 'describe' takes '-P' (or
'--perl-regexp') to affect the way how refnames are matched, while
commands like 'mgrep' would need to use '--refmatch-perl-regexp' (or
any other name that can be distinguished from '--perl-regexp') to do
the same thing because they do not want '--perl-regexp' to affect
the matching of refnames.

And at that point in the future, it is too late to fix 'describe',
as people are so used to use '--perl-regexp' to match with refs.  We
will forever regret that we did not give the option a name that can
be used independently from the existing '--perl-regexp' that is
about matching for strings, not refnames.

That is exactly the kind of thing that would paint us in a corner
that we cannot get out of, which we need to avoid, hence we need to
think ahead now.
 

--
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 00/20] More flexibility in making shallow clones

[Junio C Hamano]

Nguyễn Thái Ngọc Duy   writes:

> This series brings three new options to shallow clone/fetch. --since
> lets you specify cut point by time. --not cuts by excluding specified
> refs. And --deepen= extends shallow boundary in a more predictable
> way. Some of these were requested in the past.

Hmm, is this --deepen= a response to the "--depth= after too
long a time since the clone may even lose the originally acquired
history because the tip has advanced more than "?  If that is so,
I guess it is a welcome change ;-)

> An important point of this series is it starts to use rev-list behind
> the scene to define shallow boundary, which opens doors to even more
> ways of cutting a repository.
>
> The series is good enough to look at but I don't think I have stared
> long enough to spot all the bugs. This mail is mostly about checking
> if the design (at both code and protocol levels) and the UI make
> sense. I'm thinking --since and --not may be too generic, but I don't
> see any better names, for example.
>
> Refactor/cleanup patches are sprinkled throughout (bad?). The meat is
> in 05, 09, 12, 13, 16, 17, 18 and 20.

Thanks.  As an initial "how about going in this direction?"
weatherbaloon, the order of changes are less important, but as the
topic gets closer to the final, it would be nicer to see preparatory
things done as, eh, preparatory steps ;-)

> HTTP support is not in this series (and I don't intend to do soon).
> The amount of filler code just to pass some info from UI down to the
> protocol seems too much, and it's even more so when HTTP support is
> added. But I don't see anyway around it. Maybe we can share some code
> between git-clone, git-fetch and git-fetch-pack, at least the argument
> parsing..
>
> Nguyễn Thái Ngọc Duy (20):
>   upload-pack: move shallow deepen code out of receive_needs()
>   upload-pack: move "shallow" sending code out of deepen()
>   upload-pack: remove unused variable "backup"
>   upload-pack: move "unshallow" sending code out of deepen()
>   shallow.c: implement a generic shallow boundary finder based on rev-list
>   upload-pack: glue code to use get_shallow_commits_by_rev_list
>   upload-pack: use skip_prefix() instead of starts_with() when possible
>   upload-pack: tighten number parsing at "deepen" lines
>   upload-pack: add deepen-since to cut shallow repos based on time
>   fetch-pack: use a common function for verbose printing
>   fetch-pack: use a separate flag for fetch in deepening mode
>   fetch: define shallow boundary with --since
>   clone: define shallow clone boundary based on time with --since
>   Add test_repo_expect_success for running tests in a new repository
>   t5500: test for shallow depth since a specific date
>   upload-pack: support define shallow boundary by excluding revisions
>   fetch: define shallow boundary with --not
>   clone: define shallow clone boundary with --not
>   t5500: test for shallow depth excluding a ref
>   fetch: add --deepen= to extend shallow boundary by  commits
>
>  Documentation/fetch-options.txt   |  14 ++
>  Documentation/git-clone.txt   |   8 +
>  Documentation/technical/pack-protocol.txt |   4 +-
>  Documentation/technical/protocol-capabilities.txt |  25 +++
>  builtin/clone.c   |  32 +++-
>  builtin/fetch.c   |  44 -
>  commit.h  |   2 +
>  fetch-pack.c  | 128 --
>  fetch-pack.h  |   4 +
>  shallow.c |  92 ++
>  t/README  |  15 ++
>  t/t5500-fetch-pack.sh |  36 
>  t/t5510-fetch.sh  |  12 ++
>  t/test-lib-functions.sh   |  20 +++
>  transport.c   |  11 ++
>  transport.h   |  14 ++
>  upload-pack.c | 206 
> --
>  17 files changed, 550 insertions(+), 117 deletions(-)
--
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/3] create_symref: drop support for writing symbolic links

[Junio C Hamano]

Jeff King  writes:

> A conservative choice would probably be to issue a deprecation warning
> when we see it defined, wait a few versions, and then apply the patch
> below.

I agree with the analysis below.  And I agree that in the ideal
world, it would have been better not to add "prefer symlink refs"
configuration in the first place.  But we do not live in the ideal
world, and we already have it, so deprecation would need the usual
multi-step process.

Thanks.

> -- >8 --
> Long ago, in 2fabd21 (Disable USE_SYMLINK_HEAD by default,
> 2005-11-15), we switched git's default behavior to writing
> text symrefs instead of symbolic links. Any scripts
> accustomed to looking directly at .git/HEAD were updated to
> use `rev-parse` instead. The Linux kernel's setlocalversion
> script was one, and it was fixed in 117a93d (kbuild: Use git
> in scripts/setlocalversion, 2006-01-04).
>
> However, the problem still happened when bisecting the
> kernel; pre-117a93d kernels would not build properly with a
> newer git, because they wanted to look directly at HEAD. To
> solve this, we added 9f0bb90 (core.prefersymlinkrefs: use
> symlinks for .git/HEAD, 2006-05-02), which lets the user
> turn on the old behavior, theoretically letting you bisect
> older kernel history.
>
> But there are a few complications with this solution:
>
>   - packed-refs means you are limited in what you can do
> with .git/HEAD. If it is a symlink, you may `readlink`
> it to see where it points, but you cannot necessarily
> `cat .git/HEAD` to get the sha1, as the pointed-to ref
> may be packed.
>
> In particular, this means that the pre-117a93d kbuild
> script would sometimes work and sometimes not.
>
>   - These days, we bisect on a detached HEAD. So during
> bisection, .git/HEAD _is_ a regular file with the
> sha1, and it works to `cat` it, whether or not you set
> core.preferSymlinkRefs.
>
> Such scripts will all be broken again if we move to
> alternate ref backends. They should have learned to use
> `rev-parse` long ago, and it is only bisecting ancient
> history that is a problem.
>
> Now that almost ten years have passed, it seems less likely
> that developers will bisect so far back in history. And
> moreover, this is but one of many possible problems
> developers run into when trying to build versions. The
> standard solution is to apply a "fixup" patch or other
> workaround while test-building the project, and that would
> work here, too.
>
> This patch therefore drops core.preferSymlinkRefs
> completely. There are a few reasons to want to do so:
>
>   1. It drops some code that is probably exercised very
>  rarely.
>
>   2. The symlink code is not up to the same standards as the
>  rest of the ref code. In particular, it is racy with
>  respect to simultaneous readers and writers.
>
>   3. If we want to eventually drop the symlink-reading code,
>  this is a good first step to deprecating it.
>
> Signed-off-by: Jeff King 
> ---
>  Documentation/config.txt   |  6 --
>  cache.h|  1 -
>  config.c   |  5 -
>  contrib/completion/git-completion.bash |  1 -
>  environment.c  |  1 -
>  refs/files-backend.c   | 20 
>  t/t7201-co.sh  | 12 
>  t/t9903-bash-prompt.sh |  9 -
>  8 files changed, 55 deletions(-)
>
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index f617886..06a2f2a 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -433,12 +433,6 @@ CIFS/Microsoft Windows.
>  +
>  False by default.
>  
> -core.preferSymlinkRefs::
> - Instead of the default "symref" format for HEAD
> - and other symbolic reference files, use symbolic links.
> - This is sometimes needed to work with old scripts that
> - expect HEAD to be a symbolic link.
> -
>  core.bare::
>   If true this repository is assumed to be 'bare' and has no
>   working directory associated with it.  If this is the case a
> diff --git a/cache.h b/cache.h
> index c63fcc1..5ff7df2 100644
> --- a/cache.h
> +++ b/cache.h
> @@ -625,7 +625,6 @@ extern int has_symlinks;
>  extern int minimum_abbrev, default_abbrev;
>  extern int ignore_case;
>  extern int assume_unchanged;
> -extern int prefer_symlink_refs;
>  extern int log_all_ref_updates;
>  extern int warn_ambiguous_refs;
>  extern int warn_on_object_refname_ambiguity;
> diff --git a/config.c b/config.c
> index 86a5eb2..f479eaa 100644
> --- a/config.c
> +++ b/config.c
> @@ -726,11 +726,6 @@ static int git_default_core_config(const char *var, 
> const char *value)
>   return 0;
>   }
>  
> - if (!strcmp(var, "core.prefersymlinkrefs")) {
> - prefer_symlink_refs = git_config_bool(var, value);
> - return 0;
> - }
> -
>   if (!strcmp(var, 

Re: [PATCH V5 2/2] user-manual: add section documenting shallow clones

[Junio C Hamano]

Junio C Hamano  writes:

> Thanks for working on this.  Perhaps the last paragraph can be like
> this?
>
> Merging inside a <> will work
> as long as a merge base is found in the resent history.
> Otherwise, it will be like merging unrelated histories and may
> have to result in huge conflicts.  This limitation may make such
> a repository unsuitable to be used in merge based workflows.

I forgot to say this, but "a" merge base above is very much
deliberate.  There can be (and indeed are in real life projects)
multiple merge bases between two commits being merged, and an
automatic merge wouldn't "be like merging unrelated histories" as
long as one of them exists in the shallowed history.

--
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 V7 2/2] user-manual: add section documenting shallow clones

[Stephen P. Smith]

Signed-off-by: Stephen P. Smith 
---
 Documentation/user-manual.txt | 23 ---
 1 file changed, 20 insertions(+), 3 deletions(-)

diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 1c790ac..ce347ff 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -2128,6 +2128,26 @@ The gitweb cgi script provides users an easy way to 
browse your
 project's files and history without having to install Git; see the file
 gitweb/INSTALL in the Git source tree for instructions on setting it up.
 
+[[how-to-get-a-git-repository-with-minimal-history]]
+How to get a Git repository with minimal history
+
+
+A <>, with its truncated
+history, is useful when one is interested only in recent history
+of a project and getting full history from the upstream is
+expensive.
+
+A <> is created by specifying
+the linkgit:git-clone[1] `--depth` switch. The depth can later be
+changed with the linkgit:git-fetch[1] `--depth` switch, or full
+history restored with `--unshallow`.
+
+Merging inside a <> will work as long
+as a merge base is in the recent history.
+Otherwise, it will be like merging unrelated histories and may
+have to result in huge conflicts.  This limitation may make such
+a repository unsuitable to be used in merge based workflows.
+
 [[sharing-development-examples]]
 Examples
 
@@ -4645,9 +4665,6 @@ standard end-of-chapter section?
 
 Include cross-references to the glossary, where appropriate.
 
-Document shallow clones?  See draft 1.5.0 release notes for some
-documentation.
-
 Add a section on working with other version control systems, including
 CVS, Subversion, and just imports of series of release tarballs.
 
-- 
2.7.0-rc2

--
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/2] avoid shifting signed integers 31 bits

[Junio C Hamano]

Jeff King  writes:

> diff --git a/diff.h b/diff.h
> index f7208ad..893f446 100644
> --- a/diff.h
> +++ b/diff.h
> @@ -91,7 +91,7 @@ typedef struct strbuf *(*diff_prefix_fn_t)(struct 
> diff_options *opt, void *data)
>  #define DIFF_OPT_DIRSTAT_BY_LINE (1 << 28)
>  #define DIFF_OPT_FUNCCONTEXT (1 << 29)
>  #define DIFF_OPT_PICKAXE_IGNORE_CASE (1 << 30)
> -#define DIFF_OPT_DEFAULT_FOLLOW_RENAMES (1 << 31)
> +#define DIFF_OPT_DEFAULT_FOLLOW_RENAMES (1U << 31)
>  
>  #define DIFF_OPT_TST(opts, flag)((opts)->flags & DIFF_OPT_##flag)
>  #define DIFF_OPT_TOUCHED(opts, flag)((opts)->touched_flags & 
> DIFF_OPT_##flag)

Thanks.

Seeing (1 << 30) and (1U <<31) together made me feel that we are way
_too_ explicit being careful about 32-bit archs (iow, it would be
more consistent to turn all of these "1 <<" into "1U <<"), but at
the same time, (1 << 30) won't be broken unless we are on 31-bit
arch in the sense that if we are on 30-bit or smaller arch the
expression is already broken with or without "U", and if we are on
32-bit or more, then with or without "U" we are OK---which made me
feel somewhat funny.

In any case, these two are good changes.  Thanks.
--
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 01/10] dir: free untracked cache when removing it

[Junio C Hamano]

Christian Couder  writes:

> Signed-off-by: Christian Couder 
> ---
>  builtin/update-index.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/builtin/update-index.c b/builtin/update-index.c
> index 7431938..a6fff87 100644
> --- a/builtin/update-index.c
> +++ b/builtin/update-index.c
> @@ -1123,6 +1123,7 @@ int cmd_update_index(int argc, const char **argv, const 
> char *prefix)
>   add_untracked_ident(the_index.untracked);
>   the_index.cache_changed |= UNTRACKED_CHANGED;
>   } else if (!untracked_cache && the_index.untracked) {
> + free_untracked_cache(the_index.untracked);
>   the_index.untracked = NULL;
>   the_index.cache_changed |= UNTRACKED_CHANGED;
>   }

Looks good.
--
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 V6 2/2] user-manual: add section documenting shallow clones

[Stephen P. Smith]

Signed-off-by: Stephen P. Smith 
---
 Documentation/user-manual.txt | 23 ---
 1 file changed, 20 insertions(+), 3 deletions(-)

diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 1c790ac..15e97d3 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -2128,6 +2128,26 @@ The gitweb cgi script provides users an easy way to 
browse your
 project's files and history without having to install Git; see the file
 gitweb/INSTALL in the Git source tree for instructions on setting it up.
 
+[[how-to-get-a-git-repository-with-minimal-history]]
+How to get a Git repository with minimal history
+
+
+A <>, with its truncated
+history, is useful when one is interested only in recent history
+of a project and getting full history from the upstream is
+expensive.
+
+A <> is created by specifying
+the linkgit:git-clone[1] `--depth` switch. The depth can later be
+changed with the linkgit:git-fetch[1] `--depth` switch, or full
+history restored with `--unshallow`.
+
+Merging inside a <> will work as long
+as the merge base is in the recent history.
+Otherwise, it will be like merging unrelated histories and may
+have to result in huge conflicts.  This limitation may make such
+a repository unsuitable to be used in merge based workflows.
+
 [[sharing-development-examples]]
 Examples
 
@@ -4645,9 +4665,6 @@ standard end-of-chapter section?
 
 Include cross-references to the glossary, where appropriate.
 
-Document shallow clones?  See draft 1.5.0 release notes for some
-documentation.
-
 Add a section on working with other version control systems, including
 CVS, Subversion, and just imports of series of release tarballs.
 
-- 
2.7.0-rc2

--
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 V5 2/2] user-manual: add section documenting shallow clones

[Junio C Hamano]

Stephen & Linda Smith  writes:

> On Tuesday, December 29, 2015 11:24:00 AM Junio C Hamano wrote:
>> "Stephen P. Smith"  writes:
>> 
>> > Rather than merely pointing readers at the 1.5 release notes to
>> > learn about shallow clones, document them formally.
>> >
>> > Signed-off-by: Stephen P. Smith 
>> > ---
>> 
>> Thanks.  I do not think the reference to RelNotes were meant for the
>> end-user readers, though.  That was a hint for whoever is working to
>> clear the "todo" items from that list i.e. you ;-> ).
>
> Actually that was a suggested update[1].   Do you still think I should 
> replace it?
>
> [1] http://article.gmane.org/gmane.comp.version-control.git/282831

Sorry, but I am not sure what you mean by "it".

If you mean "replace the proposed log message", yes, I do.  The way
I read "Document X?  See Y" in the "todo" section is that it is a
hint for later contributors that X might be worth documenting, and
whoever wants to do so should look at Y while working on it.  It is
not at all telling the readers of the docuement to go read Y.

This commit follows through a "todo" item and what it did is
sufficiently described by its title.  I did not think there is
anything to add in the body of the message, and I found what was
there more confusing than enlightening, because the document wasn't
even pointing readers at the 1.5 Release Notes.

Thanks for working on this.  Perhaps the last paragraph can be like
this?

Merging inside a <> will work
as long as a merge base is found in the resent history.
Otherwise, it will be like merging unrelated histories and may
have to result in huge conflicts.  This limitation may make such
a repository unsuitable to be used in merge based workflows.

--
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 stash pop" is doing an unwanted "git add" when there are conflicts.

[Alan Mackenzie]

Hello, Jeff.

On Tue, Dec 29, 2015 at 02:53:30AM -0500, Jeff King wrote:
> On Thu, Dec 24, 2015 at 09:20:38AM +, Alan Mackenzie wrote:

> > > It seems to be a side effect of merge-recursive to stage the results,
> > > and in the no-conflict path we explicitly reset the index. For the
> > > conflicting case, it's trickier, because we would want to retain the
> > > unmerged entries.

> > > So I agree it's kind of weird, but the conflicting case is inherently
> > > going to touch the index, and you'd generally have to `git add` to mark
> > > the resolutions (but if you really want to just touch the working tree,
> > > you'd need to `git reset`).

> > From the point of view of a user, this is suboptimal.  git stash is an
> > abstraction: the preservation of uncomitted changes for later.  Staging
> > previously unstaged changes with git stash pop severely damages this
> > abstraction.

> Yeah, I think I agree. But keep in mind that we have to mention the
> conflicts _somewhere_, so we're going to touch the index regardless (and
> the user is going to have to erase the conflicts in the index
> eventually, either with `git add` or `git reset`).

When the stash consists entirely of changes in the working directory,
and "git stash pop" has conflicts, why can't these conflicts simply be
marked by "" (etc.) in the working directory, leaving the index
unchanged?  The index is left unchanged when there are no conlicts.

> > Are there any prospects of this getting fixed?

> Somebody needs to write a patch. I am not 100% convinced that it
> _should_ be fixed, but I am leaning that way. But I am not planning to
> work on it myself anytime soon. The best way to get more discussion
> going is to post a patch. :)

Hmm.  I would very much prefer to remain just a user of git.

> -Peff

-- 
Alan Mackenzie (Nuremberg, Germany).
--
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 0/3] improve symbolic-ref robustness

[Junio C Hamano]

Jeff King  writes:

> On Sun, Dec 20, 2015 at 02:26:37AM -0500, Jeff King wrote:
>
>> I noticed that an interrupt "git symbolic-ref" will not clean up
>> "HEAD.lock". So I started this series as an attempt to convert
>> create_symref() to "struct lock_file" to get the usual tempfile cleanup.
>
> Here's version 2, based on comments from Michael. The first two patches
> were picked out separately for jk/symbolic-ref-maint, so I've dropped
> them here (so 1+2 here are the original 3+4).
>
> The other differences from v1 are:
>
>   - use "refname" instead of "ref" to match surrounding code
>
>   - drop adjust_shared_perm, as lockfile does it for us
>
>   - adjust reflog writing order (done in a new patch)
>
> The patches are:
>
>   [1/3]: create_symref: modernize variable names
>   [2/3]: create_symref: use existing ref-lock code
>   [3/3]: create_symref: write reflog while holding lock

This is queued as an early part of 'pu', and some refactoring in
David's refs-backend-lmdb topic conflicts with it when merged to
'pu'.  I think I resolved the conflicts correctly, but please double
check the result when I push it out later today.

Thanks.
--
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 03/10] update-index: add --test-untracked-cache

[Junio C Hamano]

Christian Couder  writes:

> It is nice to just be able to test if untracked cache is
> supported without enabling it.
>
> Signed-off-by: Christian Couder 
> ---
>  Documentation/git-update-index.txt | 12 +++-
>  builtin/update-index.c |  5 +
>  2 files changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/git-update-index.txt 
> b/Documentation/git-update-index.txt
> index f4e5a85..a0afe17 100644
> --- a/Documentation/git-update-index.txt
> +++ b/Documentation/git-update-index.txt
> @@ -18,7 +18,7 @@ SYNOPSIS
>[--[no-]skip-worktree]
>[--ignore-submodules]
>[--[no-]split-index]
> -  [--[no-|force-]untracked-cache]
> +  [--[no-|test-|force-]untracked-cache]
>[--really-refresh] [--unresolve] [--again | -g]
>[--info-only] [--index-info]
>[-z] [--stdin] [--index-version ]
> @@ -180,6 +180,16 @@ may not support it yet.
>   system must change `st_mtime` field of a directory if files
>   are added or deleted in that directory.
>  
> +--test-untracked-cache::
> + Only perform tests on the working directory to make sure
> + untracked cache can be used. You have to manually enable
> + untracked cache using `--force-untracked-cache` (or
> + `--untracked-cache` but this will run the tests again)
> + afterwards if you really want to use it. If a test fails
> + the exit code is 1 and a message explains what is not
> + working as needed, otherwise the exit code is 0 and OK is
> + printed.
> +

Looks good.

>  --force-untracked-cache::
>   For safety, `--untracked-cache` performs tests on the working
>   directory to make sure untracked cache can be used. These
> diff --git a/builtin/update-index.c b/builtin/update-index.c
> index 1e546a3..6dd 100644
> --- a/builtin/update-index.c
> +++ b/builtin/update-index.c
> @@ -40,6 +40,7 @@ enum uc_mode {
>   UC_UNSPECIFIED = -1,
>   UC_DISABLE = 0,
>   UC_ENABLE,
> + UC_TEST,
>   UC_FORCE
>  };
>  
> @@ -1004,6 +1005,8 @@ int cmd_update_index(int argc, const char **argv, const 
> char *prefix)
>   N_("enable or disable split index")),
>   OPT_BOOL(0, "untracked-cache", _cache,
>   N_("enable/disable untracked cache")),
> + OPT_SET_INT(0, "test-untracked-cache", _cache,
> + N_("test if the filesystem supports untracked 
> cache"), UC_TEST),
>   OPT_SET_INT(0, "force-untracked-cache", _cache,
>   N_("enable untracked cache without testing the 
> filesystem"), UC_FORCE),
>   OPT_END()
> @@ -1119,6 +1122,8 @@ int cmd_update_index(int argc, const char **argv, const 
> char *prefix)
>   setup_work_tree();
>   if (!test_if_untracked_cache_is_supported())
>   return 1;
> + if (untracked_cache == UC_TEST)
> + return 0;
>   }
>   if (!the_index.untracked) {
>   uc = xcalloc(1, sizeof(*uc));
--
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-p4.py: add support for filetype change

[Romain Picard]

Le 26.12.2015 11:26, Luke Diamand a écrit :
On 21 December 2015 at 13:09, Romain Picard  
wrote:
After changing the type of a file in the git repository, it is not 
possible to
"git p4 publish" the commit to perforce. This is due to the fact that 
the git
"T" status is not handled in git-p4.py. This can typically occur when 
replacing

an existing file with a symbolic link.

The "T" modifier is now supported in git-p4.py. When a file type has 
changed,

inform perforce with the "p4 edit -f auto" command.


Romain,

Thanks for looking at this. It looks like a reasonable change.

Do you think you could add a unit test as well?


Yes, I will look at the existing tests to see how to add some new ones.



Thanks
Luke




Signed-off-by: Romain Picard 
---
 git-p4.py | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/git-p4.py b/git-p4.py
index a7ec118..b7a3494 100755
--- a/git-p4.py
+++ b/git-p4.py
@@ -240,8 +240,8 @@ def p4_add(f):
 def p4_delete(f):
 p4_system(["delete", wildcard_encode(f)])

-def p4_edit(f):
-p4_system(["edit", wildcard_encode(f)])
+def p4_edit(f, *options):
+p4_system(["edit"] + list(options) + [wildcard_encode(f)])

 def p4_revert(f):
 p4_system(["revert", wildcard_encode(f)])
@@ -1344,6 +1344,7 @@ class P4Submit(Command, P4UserMap):

 diff = read_pipe_lines("git diff-tree -r %s \"%s^\" \"%s\"" % 
(self.diffOpts, id, id))

 filesToAdd = set()
+filesToChangeType = set()
 filesToDelete = set()
 editedFiles = set()
 pureRenameCopy = set()
@@ -1404,6 +1405,8 @@ class P4Submit(Command, P4UserMap):
 os.unlink(dest)
 filesToDelete.add(src)
 editedFiles.add(dest)
+elif modifier == "T":
+filesToChangeType.add(path)
 else:
 die("unknown modifier %s for %s" % (modifier, path))

@@ -1463,6 +1466,8 @@ class P4Submit(Command, P4UserMap):
 #
 system(applyPatchCmd)

+for f in filesToChangeType:
+p4_edit(f, "-t", "auto")
 for f in filesToAdd:
 p4_add(f)
 for f in filesToDelete:
--
2.6.4

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

--
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 0/3] nd/clear-gitenv-upon-use-of-alias

[Junio C Hamano]

Jeff King  writes:

> The outer git wrapper doesn't start the pager, so its stderr still gets
> seen by the user. But the _inner_ git-log does start the pager, and then
> dies of SIGPIPE.
>
> So yeah, I think we want something like this on top of
> nd/clear-gitenv-upon-use-of-alias.

That makes sense to me.

> -- >8 --
> Subject: [PATCH] run-command: don't warn on SIGPIPE deaths
>
> When git executes a sub-command, we print a warning if the
> command dies due to a signal, but make an exception for
> "uninteresting" cases like SIGINT and SIGQUIT (since the
> user presumably just hit ^C).
>
> We should make a similar exception for SIGPIPE, because it's
> an expected and uninteresting return in most cases; it
> generally means the user quit the pager before git had
> finished generating all output.  This used to be very hard
> to trigger in practice, because:
>
>   1. We only complain if we see a real SIGPIPE death, not
>  the shell-induced 141 exit code. This means that
>  anything we run via the shell does not trigger the
>  warning, which includes most non-trivial aliases.
>
>   2. The common case for SIGPIPE is the user quitting the
>  pager before git has finished generating all output.
>  But if the user triggers a pager with "-p", we redirect
>  the git wrapper's stderr to that pager, too.  Since the
>  pager is dead, it means that the message goes nowhere.
>
>   3. You can see it if you run your own pager, like
>  "git foo | head". But that only happens if "foo" is a
>  non-builtin (so it doesn't work with "log", for
>  example).
>
> However, it may become more common after 86d26f2, which
> teaches alias to re-exec builtins rather than running them
> in the same process. This case doesn't trigger (1), as we
> don't need a shell to run a git command. It doesn't trigger
> (2), because the pager is not started by the original git,
> but by the inner re-exec of git. And it doesn't trigger (3),
> because builtins are treated more like non-builtins in this
> case.
>
> Given how flaky this message already is (e.g., you cannot
> even know whether you will see it, as git optimizes out some
> shell invocations behind the scenes based on the contents of
> the command!), and that it is unlikely to ever provide
> useful information, let's suppress it for all cases of
> SIGPIPE.
>
> Signed-off-by: Jeff King 
> ---
>  run-command.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/run-command.c b/run-command.c
> index 13fa452..694a6ff 100644
> --- a/run-command.c
> +++ b/run-command.c
> @@ -245,7 +245,7 @@ static int wait_or_whine(pid_t pid, const char *argv0, 
> int in_signal)
>   error("waitpid is confused (%s)", argv0);
>   } else if (WIFSIGNALED(status)) {
>   code = WTERMSIG(status);
> - if (code != SIGINT && code != SIGQUIT)
> + if (code != SIGINT && code != SIGQUIT && code != SIGPIPE)
>   error("%s died of signal %d", argv0, code);
>   /*
>* This return value is chosen so that code & 0xff
--
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 V5 2/2] user-manual: add section documenting shallow clones

[Junio C Hamano]

"Stephen P. Smith"  writes:

> Rather than merely pointing readers at the 1.5 release notes to
> learn about shallow clones, document them formally.
>
> Signed-off-by: Stephen P. Smith 
> ---

Thanks.  I do not think the reference to RelNotes were meant for the
end-user readers, though.  That was a hint for whoever is working to
clear the "todo" items from that list i.e. you ;-).

> +[[how-to-get-a-git-repository-with-minimal-history]]
> +How to get a Git repository with minimal history
> +
> +
> +A <>, with its truncated
> +history, is useful when one is interested only in recent history
> +of a project and getting full history from the upstream is
> +expensive.
> +
> +A <> is created by specifying
> +the linkgit:git-clone[1] `--depth` switch. The depth can later be
> +changed with the linkgit:git-fetch[1] `--depth` switch, or full
> +history restored with `--unshallow`.
> +
> +Merging inside a <> will work as long
> +as the merge base is in the resent history.  If the merge base is not

recent?

> +present then the merge would be of un-related histories.  This
> +limitaion is fundamental and will not be removed.

I think "fundamental and will not change" is much less important
than the "huge conflicts, making the result of 'clone --depth='
not very useful to perform merges in", which is what the users would
need to know before deciding to use this feature.

> +
>  [[sharing-development-examples]]
>  Examples
>  
> @@ -4645,9 +4664,6 @@ standard end-of-chapter section?
>  
>  Include cross-references to the glossary, where appropriate.
>  
> -Document shallow clones?  See draft 1.5.0 release notes for some
> -documentation.
> -
>  Add a section on working with other version control systems, including
>  CVS, Subversion, and just imports of series of release tarballs.
--
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 V5 2/2] user-manual: add section documenting shallow clones

[Stephen & Linda Smith]

On Tuesday, December 29, 2015 11:24:00 AM Junio C Hamano wrote:
> "Stephen P. Smith"  writes:
> 
> > Rather than merely pointing readers at the 1.5 release notes to
> > learn about shallow clones, document them formally.
> >
> > Signed-off-by: Stephen P. Smith 
> > ---
> 
> Thanks.  I do not think the reference to RelNotes were meant for the
> end-user readers, though.  That was a hint for whoever is working to
> clear the "todo" items from that list i.e. you ;-> ).

Actually that was a suggested update[1].   Do you still think I should replace 
it?

[1] http://article.gmane.org/gmane.comp.version-control.git/282831
> 
> > +[[how-to-get-a-git-repository-with-minimal-history]]
> > +How to get a Git repository with minimal history
> > +
> > +
> > +A <>, with its truncated
> > +history, is useful when one is interested only in recent history
> > +of a project and getting full history from the upstream is
> > +expensive.
> > +
> > +A <> is created by specifying
> > +the linkgit:git-clone[1] `--depth` switch. The depth can later be
> > +changed with the linkgit:git-fetch[1] `--depth` switch, or full
> > +history restored with `--unshallow`.
> > +
> > +Merging inside a <> will work as long
> > +as the merge base is in the resent history.  If the merge base is not
> 
> recent?

I had that fixed and then managed to corrupt my working branch losing the 
change.

> 
> > +present then the merge would be of un-related histories.  This
> > +limitaion is fundamental and will not be removed.
> 
> I think "fundamental and will not change" is much less important
> than the "huge conflicts, making the result of 'clone --depth='
> not very useful to perform merges in", which is what the users would
> need to know before deciding to use this feature.

OK

> 
> > +
> >  [[sharing-development-examples]]
> >  Examples
> >  
> > @@ -4645,9 +4664,6 @@ standard end-of-chapter section?
> >  
> >  Include cross-references to the glossary, where appropriate.
> >  
> > -Document shallow clones?  See draft 1.5.0 release notes for some
> > -documentation.
> > -
> >  Add a section on working with other version control systems, including
> >  CVS, Subversion, and just imports of series of release tarballs.
> --
> 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

--
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 08/10] dir: simplify untracked cache "ident" field

[Junio C Hamano]

Christian Couder  writes:

> -static int ident_in_untracked(const struct untracked_cache *uc)
> +static int ident_current_location_in_untracked(const struct untracked_cache 
> *uc)
>  {
> - const char *end = uc->ident.buf + uc->ident.len;
> - const char *p   = uc->ident.buf;
> + struct strbuf cur_loc = STRBUF_INIT;
> + int res = 0;
>  
> - for (p = uc->ident.buf; p < end; p += strlen(p) + 1)
> - if (!strcmp(p, get_ident_string()))
> - return 1;
> - return 0;
> + /*
> +  * Previous git versions may have saved many strings in the
> +  * "ident" field, but it is insane to manage many locations,
> +  * so just take care of the first one.
> +  */
> +
> + strbuf_addf(_loc, "Location %s, system ", get_git_work_tree());
> +
> + if (starts_with(uc->ident.buf, cur_loc.buf))
> + res = 1;
> +
> + strbuf_release(_loc);
> +
> + return res;
>  }

The ", system " part looks funny.  I think I know what you are
trying to do, though.

If the path to the working tree has ", system " as a substring,
I wonder if funny things may happen with this starts_with()?
--
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 v2] notes: allow merging from arbitrary references

[Jacob Keller]

From: Jacob Keller 

Create a new expansion function, expand_loose_notes_ref which will first
check whether the ref can be found using get_sha1. If it can't be found
then it will fallback to using expand_notes_ref. The content of the
strbuf will not be changed if the notes ref can be located using
get_sha1. Otherwise, it may be updated as done by expand_notes_ref.

Since we now support merging from non-notes refs, remove the test case
associated with that behavior. Add a test case for merging from a
non-notes ref.

Signed-off-by: Jacob Keller 
---

Notes:
- v2
* don't expand notes-ref to the sha1, in order to support get-ref better
* fix failed tests due to mis-use of argv[0] instead of remote_ref.buf

 builtin/notes.c|  2 +-
 notes.c| 10 ++
 notes.h|  7 +++
 t/t3308-notes-merge.sh | 22 +++---
 4 files changed, 29 insertions(+), 12 deletions(-)

diff --git a/builtin/notes.c b/builtin/notes.c
index 515cebbeb8a3..c090e33dcadb 100644
--- a/builtin/notes.c
+++ b/builtin/notes.c
@@ -806,7 +806,7 @@ static int merge(int argc, const char **argv, const char 
*prefix)
 
o.local_ref = default_notes_ref();
strbuf_addstr(_ref, argv[0]);
-   expand_notes_ref(_ref);
+   expand_loose_notes_ref(_ref);
o.remote_ref = remote_ref.buf;
 
t = init_notes_check("merge");
diff --git a/notes.c b/notes.c
index db77922130b4..086cc483e518 100644
--- a/notes.c
+++ b/notes.c
@@ -1303,3 +1303,13 @@ void expand_notes_ref(struct strbuf *sb)
else
strbuf_insert(sb, 0, "refs/notes/", 11);
 }
+
+void expand_loose_notes_ref(struct strbuf *sb)
+{
+   unsigned char object[20];
+
+   if (get_sha1(sb->buf, object)) {
+   /* fallback to expand_notes_ref */
+   expand_notes_ref(sb);
+   }
+}
diff --git a/notes.h b/notes.h
index 2a3f92338076..431f14378817 100644
--- a/notes.h
+++ b/notes.h
@@ -294,4 +294,11 @@ void string_list_add_refs_from_colon_sep(struct 
string_list *list,
 /* Expand inplace a note ref like "foo" or "notes/foo" into "refs/notes/foo" */
 void expand_notes_ref(struct strbuf *sb);
 
+/*
+ * Similar to expand_notes_ref, but will check whether the ref can be located
+ * via get_sha1 first, and only falls back to expand_notes_ref in the case
+ * where get_sha1 fails.
+ */
+void expand_loose_notes_ref(struct strbuf *sb);
+
 #endif
diff --git a/t/t3308-notes-merge.sh b/t/t3308-notes-merge.sh
index 24d82b49bbea..19aed7ec953b 100755
--- a/t/t3308-notes-merge.sh
+++ b/t/t3308-notes-merge.sh
@@ -18,7 +18,9 @@ test_expect_success setup '
git notes add -m "Notes on 1st commit" 1st &&
git notes add -m "Notes on 2nd commit" 2nd &&
git notes add -m "Notes on 3rd commit" 3rd &&
-   git notes add -m "Notes on 4th commit" 4th
+   git notes add -m "Notes on 4th commit" 4th &&
+   # Copy notes to remote-notes
+   git fetch . refs/notes/*:refs/remote-notes/origin/*
 '
 
 commit_sha1=$(git rev-parse 1st^{commit})
@@ -66,7 +68,9 @@ test_expect_success 'verify initial notes (x)' '
 '
 
 cp expect_notes_x expect_notes_y
+cp expect_notes_x expect_notes_v
 cp expect_log_x expect_log_y
+cp expect_log_x expect_log_v
 
 test_expect_success 'fail to merge empty notes ref into empty notes ref (z => 
y)' '
test_must_fail git -c "core.notesRef=refs/notes/y" notes merge z
@@ -84,16 +88,12 @@ test_expect_success 'fail to merge into various non-notes 
refs' '
test_must_fail git -c "core.notesRef=refs/notes/foo^{bar" notes merge x
 '
 
-test_expect_success 'fail to merge various non-note-trees' '
-   git config core.notesRef refs/notes/y &&
-   test_must_fail git notes merge refs/notes &&
-   test_must_fail git notes merge refs/notes/ &&
-   test_must_fail git notes merge refs/notes/dir &&
-   test_must_fail git notes merge refs/notes/dir/ &&
-   test_must_fail git notes merge refs/heads/master &&
-   test_must_fail git notes merge x: &&
-   test_must_fail git notes merge x:foo &&
-   test_must_fail git notes merge foo^{bar
+test_expect_success 'merge non-notes ref into empty notes ref 
(remote-notes/origin/x => v)' '
+   git config core.notesRef refs/notes/v &&
+   git notes merge refs/remote-notes/origin/x &&
+   verify_notes v &&
+   # refs/remote-notes/origin/x and v should point to the same notes commit
+   test "$(git rev-parse refs/remote-notes/origin/x)" = "$(git rev-parse 
refs/notes/v)"
 '
 
 test_expect_success 'merge notes into empty notes ref (x => y)' '
-- 
2.6.3.505.g5cc1fd1

--
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 09/10] config: add core.untrackedCache

[Junio C Hamano]

Christian Couder  writes:

> +core.untrackedCache::
> + Determines if untracked cache will be automatically enabled or
> + disabled. It can be `keep`, `true` or `false`. Before setting
> + it to `true`, you should check that mtime is working properly
> + on your system.
> + See linkgit:git-update-index[1]. `keep` by default.
> +

Before "Before setting it to `true`", the reader needs to be told
what would happen when this is set to each of these three values (as
well as what happens when this is not set at all).

> diff --git a/Documentation/git-update-index.txt 
> b/Documentation/git-update-index.txt
> index a0afe17..813f6cc 100644
> --- a/Documentation/git-update-index.txt
> +++ b/Documentation/git-update-index.txt
> @@ -174,27 +174,31 @@ may not support it yet.
>  
>  --untracked-cache::
>  --no-untracked-cache::
> - Enable or disable untracked cache extension. This could speed
> - up for commands that involve determining untracked files such
> - as `git status`. The underlying operating system and file
> - system must change `st_mtime` field of a directory if files
> - are added or deleted in that directory.
> + Enable or disable untracked cache extension. Please use
> + `--test-untracked-cache` before enabling it.

"extension" is a term that is fairly close to the machinery.  In
other parts of the documentation (like the added text below in this
patch), it is called "untracked cache FEATURE", which probably is a
better word to use here as well.

> ++
> +These options cannot override the `core.untrackedCache` configuration
> +variable when it is set to `true` or `false` (see
> +linkgit:git-config[1]). They can override it only when it is unset or
> +set to `keep`. If you want untracked cache to persist, it is better
> +anyway to just set this configuration variable to `true` or `false`
> +directly.

While the above is not wrong per-se, from the point of those who
looked for these options (that is, those who wanted to do a one-shot
enabling or disabling of the feature, perhaps to try it out to see
how well it helps on their system), I think the explanation of the
interaction between the option and the config is backwards.  For
their purpose, setting it to `true` or `false` will be hinderance,
because the options are made no-op by such a setting.  IOW, the
advertisement "once you decided that you want to use the feature,
configuration is a better place to set it" does not belong here.

If I were writing this documentation, I'd probably rephrase the
second paragraph like so:

These options take effect only when the
`core.untrackedCache` configuration variable (see
linkgit:git-config[1]) is set to `keep` (or it is left
unset).  When the configuration variable is set to `true`,
the untracked cache feature is always enabled (and when it
is set to `false`, it is always disabled), making these
options no-op.

perhaps.

> @@ -385,6 +389,34 @@ Although this bit looks similar to assume-unchanged bit, 
> its goal is
>  different from assume-unchanged bit's. Skip-worktree also takes
>  precedence over assume-unchanged bit when both are set.
>  
> +Untracked cache
> +---
> +
> +This cache could speed up commands that involve determining untracked
> +...
> +It is recommended to use the `core.untrackedCache` configuration
> +variable (see linkgit:git-config[1]) to enable or disable this feature
> +instead of using the `--[no-|force-]untracked-cache`, as it is more
> +persistant and visible with a configuration variable.

s/persistant/persistent/; but more importantly, I do not think
persistence has much to do with the choice between the option and
configuration.  Once it is set with `--untracked-cache`, it should
persist until you explicitly use `--no-untracked-cache` to disable
it, no?  Otherwise you have a bug that needs to be fixed.

The reason you'd want to use a configuration is because the effect
of using the `--untracked-cache` option is per repository (rather,
per index-file).

If you want to enable (or disable) this feature, it is easier to
use the `core.untrackedCache` configuration variable than using
the `--untracked-cache` option to `git update-index` in each
repository, especially if you want to do so across all
repositories you use, because you can set the configuration
variable to `true` (or `false`) in your `$HOME/.gitconfig` just
once and have it affect all repositories you touch.

or something, perhaps.

> +When the `core.untrackedCache` configuration variable is changed, the
> +untracked cache is added to or removed from the index the next time
> +"git status" is run; while when `--[no-|force-]untracked-cache` are
> +used, the untracked cache is immediately added to or removed from the
> +index.

Is it only "git status", or anything that writes/updates the index
file?  The above makes it sound as if you are saying "If you change

Re: [RFC/PATCH 4/3] create_symref: drop support for writing symbolic links

[Jeff King]

On Wed, Dec 30, 2015 at 01:53:43AM -0500, Jeff King wrote:

> On Tue, Dec 29, 2015 at 10:32:04AM -0800, Junio C Hamano wrote:
> 
> > Jeff King  writes:
> > 
> > > A conservative choice would probably be to issue a deprecation warning
> > > when we see it defined, wait a few versions, and then apply the patch
> > > below.
> > 
> > I agree with the analysis below.  And I agree that in the ideal
> > world, it would have been better not to add "prefer symlink refs"
> > configuration in the first place.  But we do not live in the ideal
> > world, and we already have it, so deprecation would need the usual
> > multi-step process.
> 
> Here's the first step of that multi-step process. The commit message
> will look familiar, as the rationale for deprecating is the same as for
> dropping.

And here's the second step, which would obviously want to wait a while
before being merged.

A third possible step would be removing the reading side from
resolve_ref(). But that would want to wait a few more cycles past this
one. And I'm hesitant to do it while the ref code is in flux. It will be
easier to just write the patch later on. :)

-- >8 --
Subject: [PATCH] create_symref: drop support for writing symbolic links

The parent commit deprecated the writing of symbolic links
for symrefs.  Now that some time has passed, we can follow
through by dropping the code.

Signed-off-by: Jeff King 
---
 Documentation/config.txt   |  6 --
 Makefile   |  6 --
 cache.h|  1 -
 config.c   |  5 -
 config.mak.uname   |  3 ---
 configure.ac   |  3 ---
 contrib/completion/git-completion.bash |  1 -
 environment.c  |  1 -
 refs/files-backend.c   | 35 --
 t/t7201-co.sh  | 12 
 t/t9903-bash-prompt.sh |  9 -
 11 files changed, 82 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index f617886..06a2f2a 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -433,12 +433,6 @@ CIFS/Microsoft Windows.
 +
 False by default.
 
-core.preferSymlinkRefs::
-   Instead of the default "symref" format for HEAD
-   and other symbolic reference files, use symbolic links.
-   This is sometimes needed to work with old scripts that
-   expect HEAD to be a symbolic link.
-
 core.bare::
If true this repository is assumed to be 'bare' and has no
working directory associated with it.  If this is the case a
diff --git a/Makefile b/Makefile
index fd19b54..05ffd60 100644
--- a/Makefile
+++ b/Makefile
@@ -113,9 +113,6 @@ all::
 #
 # Define NO_SYS_SELECT_H if you don't have sys/select.h.
 #
-# Define NO_SYMLINK_HEAD if you never want .git/HEAD to be a symbolic link.
-# Enable it on Windows.  By default, symrefs are still used.
-#
 # Define NO_SVN_TESTS if you want to skip time-consuming SVN interoperability
 # tests.  These tests take up a significant amount of the total test time
 # but are not needed unless you plan to talk to SVN repos.
@@ -1200,9 +1197,6 @@ ifdef FREAD_READS_DIRECTORIES
COMPAT_CFLAGS += -DFREAD_READS_DIRECTORIES
COMPAT_OBJS += compat/fopen.o
 endif
-ifdef NO_SYMLINK_HEAD
-   BASIC_CFLAGS += -DNO_SYMLINK_HEAD
-endif
 ifdef GETTEXT_POISON
BASIC_CFLAGS += -DGETTEXT_POISON
 endif
diff --git a/cache.h b/cache.h
index c63fcc1..5ff7df2 100644
--- a/cache.h
+++ b/cache.h
@@ -625,7 +625,6 @@ extern int has_symlinks;
 extern int minimum_abbrev, default_abbrev;
 extern int ignore_case;
 extern int assume_unchanged;
-extern int prefer_symlink_refs;
 extern int log_all_ref_updates;
 extern int warn_ambiguous_refs;
 extern int warn_on_object_refname_ambiguity;
diff --git a/config.c b/config.c
index 86a5eb2..f479eaa 100644
--- a/config.c
+++ b/config.c
@@ -726,11 +726,6 @@ static int git_default_core_config(const char *var, const 
char *value)
return 0;
}
 
-   if (!strcmp(var, "core.prefersymlinkrefs")) {
-   prefer_symlink_refs = git_config_bool(var, value);
-   return 0;
-   }
-
if (!strcmp(var, "core.logallrefupdates")) {
log_all_ref_updates = git_config_bool(var, value);
return 0;
diff --git a/config.mak.uname b/config.mak.uname
index f34dcaa..9b77e2c 100644
--- a/config.mak.uname
+++ b/config.mak.uname
@@ -169,7 +169,6 @@ ifeq ($(uname_O),Cygwin)
NO_STRCASESTR = YesPlease
NO_MEMMEM = YesPlease
NO_MKSTEMPS = YesPlease
-   NO_SYMLINK_HEAD = YesPlease
NO_IPV6 = YesPlease
OLD_ICONV = UnfortunatelyYes
# There are conflicting reports about this.
@@ -338,7 +337,6 @@ ifeq ($(uname_S),Windows)
NEEDS_CRYPTO_WITH_SSL = YesPlease
NO_LIBGEN_H 

Re: [PATCH v2 0/3] improve symbolic-ref robustness

[Jeff King]

On Tue, Dec 29, 2015 at 01:24:42PM -0800, Junio C Hamano wrote:

> > The patches are:
> >
> >   [1/3]: create_symref: modernize variable names
> >   [2/3]: create_symref: use existing ref-lock code
> >   [3/3]: create_symref: write reflog while holding lock
> 
> This is queued as an early part of 'pu', and some refactoring in
> David's refs-backend-lmdb topic conflicts with it when merged to
> 'pu'.  I think I resolved the conflicts correctly, but please double
> check the result when I push it out later today.

Looks sane to me. It seems like the change was just the renaming of the
functions. We _could_ match the renaming of the static-local functions
(e.g., create_symref_locked would become files_create_symref_locked),
but I don't think it's necessary for file-local functions.

-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: [RFC/PATCH 4/3] create_symref: drop support for writing symbolic links

[Jeff King]

On Tue, Dec 29, 2015 at 10:32:04AM -0800, Junio C Hamano wrote:

> Jeff King  writes:
> 
> > A conservative choice would probably be to issue a deprecation warning
> > when we see it defined, wait a few versions, and then apply the patch
> > below.
> 
> I agree with the analysis below.  And I agree that in the ideal
> world, it would have been better not to add "prefer symlink refs"
> configuration in the first place.  But we do not live in the ideal
> world, and we already have it, so deprecation would need the usual
> multi-step process.

Here's the first step of that multi-step process. The commit message
will look familiar, as the rationale for deprecating is the same as for
dropping.

This is on top of what I posted earlier (it obviously could be
independent, but I assume we're planning to merge the other bits, and I
don't mind holding this topic hostage for a little while to save some
annoying merging).

-- >8 --
Subject: [PATCH] create_symref: deprecate support for writing symbolic links

Long ago, in 2fabd21 (Disable USE_SYMLINK_HEAD by default,
2005-11-15), we switched git's default behavior to writing
text symrefs instead of symbolic links. Any scripts
accustomed to looking directly at .git/HEAD were updated to
use `rev-parse` instead. The Linux kernel's setlocalversion
script was one, and it was fixed in 117a93d (kbuild: Use git
in scripts/setlocalversion, 2006-01-04).

However, the problem still happened when bisecting the
kernel; pre-117a93d would not build properly with a newer
git, because they wanted to look directly at HEAD. To solve
this, we added 9f0bb90 (core.prefersymlinkrefs: use symlinks
for .git/HEAD, 2006-05-02), which lets the user turn on the
old behavior, theoretically letting you bisect older kernel
history.

But there are a few complications with this solution:

  - packed-refs means you are limited in what you can do
with .git/HEAD. If it is a symlink, you may `readlink`
it to see where it points, but you cannot necessarily
`cat .git/HEAD` to get the sha1, as the pointed-to ref
may be packed.

In particular, this means that the pre-117a93d kbuild
script would sometimes work and sometimes not.

  - These days, we bisect on a detached HEAD. So during
bisection, .git/HEAD _is_ a regular file with the
sha1, and it works to `cat` it, whether or not you set
core.preferSymlinkRefs.

Such scripts will all be broken again if we move to
alternate ref backends. They should have learned to use
`rev-parse` long ago, and it is only bisecting ancient
history that is a problem.

Now that almost ten years have passed, it seems less likely
that developers will bisect so far back in history. And
moreover, this is but one of many possible problems
developers run into when trying to build versions. The
standard solution is to apply a "fixup" patch or other
workaround while test-building the project, and that would
work here, too.

This patch therefore deprecates core.preferSymlinkRefs
completely. There are a few reasons to want to do so:

  1. It drops some code that is probably exercised very
 rarely.

  2. The symlink code is not up to the same standards as the
 rest of the ref code. In particular, it is racy with
 respect to simultaneous readers and writers.

  3. If we want to eventually drop the symlink-reading code,
 this is a good first step to deprecating it.

We print a deprecation warning anytime a symlink is created
using this code. That prevents us from spamming the user
with multiple warnings from read-only operations, but
catches major operations like init, clone, and checkout.

Signed-off-by: Jeff King 
---
There's no advice.* safety valve here. The solution is "fix your
script", and the last-ditch effort is "come to the mailing list and tell
us why it would be a bad thing to remove the feature".

 refs/files-backend.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/refs/files-backend.c b/refs/files-backend.c
index 180c837..22b7c11 100644
--- a/refs/files-backend.c
+++ b/refs/files-backend.c
@@ -2860,12 +2860,27 @@ static int create_symref_locked(struct ref_lock *lock, 
const char *refname,
return 0;
 }
 
+static const char symlink_deprecation_warning[] =
+"The core.preferSymlinkRefs configuration option has been\n"
+"deprecated and will be removed in a future version of Git. If your\n"
+"workflow or script depends on '.git/HEAD' being a symbolic link,\n"
+"it should be adjusted to use:\n"
+"\n"
+"git rev-parse HEAD\n"
+"\n"
+"git rev-parse --symbolic-full-name HEAD\n"
+"\n"
+"to get the sha1 or branch name, respectively.";
+
 int create_symref(const char *refname, const char *target, const char *logmsg)
 {
struct strbuf err = STRBUF_INIT;
struct ref_lock *lock;
int ret;
 
+   if (prefer_symlink_refs)
+   warning("%s", symlink_deprecation_warning);
+
lock = lock_ref_sha1_basic(refname, NULL, NULL, NULL, 

Re: [PATCH 1/2] prepare_packed_git(): refactor garbage reporting in pack directory

[Jeff King]

On Wed, Nov 04, 2015 at 02:08:21PM -0600, Doug Kelly wrote:

> On Wed, Nov 4, 2015 at 2:02 PM, Jeff King  wrote:
> > Definitely cleaning up the .bitmap is sane and not racy (it's in the
> > same boat as the .idx, I think).
> >
> > .keep files are more tricky. I'd have to go over the receive-pack code
> > to confirm, but I think they _are_ racy. That is, receive-pack will
> > create them as a lockfile before moving the pack into place. That's OK,
> > though, if we use mtimes to give ourselves a grace period (I haven't
> > looked at your series yet).
> >
> > But moreover, .keep files can be created manually by the user. If the
> > pack they referenced goes away, they are not really serving any purpose.
> > But it's possible that the user would want to salvage the content of the
> > file, or know that it was there.
> >
> > So I'd argue we should leave them. Or at least leave ones that do not
> > have the generic "{receive,fetch}-pack $pid on $host comment in them,
> > which were clearly created as lockfiles.
> 
> Currently there's no mtime-guarding logic (I dug up that conversation
> earlier, though, but after I'd done the respin on this series)... OK,
> in that case, I'll create a separate patch that tests/cleans up
> .bitmap, but doesn't touch .keep.  This might be a small series since
> I think the logic for finding pack garbage doesn't know anything about
> .bitmap per-se, so it's looking like I'll extend that relevant code,
> before adding the handling in gc and appropriate tests.

I happened to be looking over your series again, and I noticed that we
didn't end up with any mtime logic at all in what got merged.

I _think_ that is probably OK, because we always write the pack,
followed by the .idx, followed by the .bitmap (if any). And we don't
drop .keep files (though I think we would perhaps note them as possible
cruft?).

So I don't think there are any races introduced here, but I wonder if we
want to be a bit more conservative. Sorry to bring this up so much after
the fact; I completely forgot about it when reviewing the patches.

These changes are slated for the v2.7 release. Like I said, I don't
think it's buggy, so we don't necessarily need to address it before the
release. We could add an mtime check in the next cycle as a
belt-and-suspenders safety, rather than a fix.

-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: "git stash pop" is doing an unwanted "git add" when there are conflicts.

[Jeff King]

On Tue, Dec 29, 2015 at 09:20:38PM +, Alan Mackenzie wrote:

> > Yeah, I think I agree. But keep in mind that we have to mention the
> > conflicts _somewhere_, so we're going to touch the index regardless (and
> > the user is going to have to erase the conflicts in the index
> > eventually, either with `git add` or `git reset`).
> 
> When the stash consists entirely of changes in the working directory,
> and "git stash pop" has conflicts, why can't these conflicts simply be
> marked by "" (etc.) in the working directory, leaving the index
> unchanged?  The index is left unchanged when there are no conlicts.

I don't think that's a good idea. Git always marks conflicts in the
index for other operations. Besides being inconsistent with the rest of
git, it drops useful information that other tools can use. For example,
one cannot "git checkout --conflict=diff3" afterwards, or use "git
mergetool" to kick off a third-party merge tool.

Not to mention that the information is lost to the user themselves. If
we touched 10 files and 2 had conflicts, there is now no way for the
user to ask "where were the conflicts?". They can either find the stash
output in their terminal scrollback, or grep for things that look like
conflict markers.

-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: [PATCH 1/2] avoid shifting signed integers 31 bits

[Jeff King]

On Tue, Dec 29, 2015 at 04:09:21PM -0800, Junio C Hamano wrote:

> > diff --git a/diff.h b/diff.h
> > index f7208ad..893f446 100644
> > --- a/diff.h
> > +++ b/diff.h
> > @@ -91,7 +91,7 @@ typedef struct strbuf *(*diff_prefix_fn_t)(struct 
> > diff_options *opt, void *data)
> >  #define DIFF_OPT_DIRSTAT_BY_LINE (1 << 28)
> >  #define DIFF_OPT_FUNCCONTEXT (1 << 29)
> >  #define DIFF_OPT_PICKAXE_IGNORE_CASE (1 << 30)
> > -#define DIFF_OPT_DEFAULT_FOLLOW_RENAMES (1 << 31)
> > +#define DIFF_OPT_DEFAULT_FOLLOW_RENAMES (1U << 31)
> >  
> >  #define DIFF_OPT_TST(opts, flag)((opts)->flags & DIFF_OPT_##flag)
> >  #define DIFF_OPT_TOUCHED(opts, flag)((opts)->touched_flags & 
> > DIFF_OPT_##flag)
> 
> Thanks.
> 
> Seeing (1 << 30) and (1U <<31) together made me feel that we are way
> _too_ explicit being careful about 32-bit archs (iow, it would be
> more consistent to turn all of these "1 <<" into "1U <<"), but at
> the same time, (1 << 30) won't be broken unless we are on 31-bit
> arch in the sense that if we are on 30-bit or smaller arch the
> expression is already broken with or without "U", and if we are on
> 32-bit or more, then with or without "U" we are OK---which made me
> feel somewhat funny.

Yeah, I was tempted to convert them all, but there's no benefit except
consistency. Interestingly, if we spelled these as:

  0x01
  0x02
  ...
  0x8000

that _is_ OK by the C standard (the type of the constant is "the first
thing big enough to hold it" from a list of int, unsigned, etc[1]). I find
that style more error-prone, though, so I don't think it's a good idea
to move to it.

We pretty much assume an int of at least 32-bits anyway; the flags field
itself is a simple "unsigned". We could make that a uint32_t, but in
practice I hope that sub-32-bit platforms are all dead, at least for
general purpose application code like git.

-Peff

[1] The list of possible types is actually _different_ for decimal and
hex constants. Which seems slightly insane, but hey, it's C.
Notably, the decimal equivalent of 0x8000 is guaranteed to be
signed (but would be a "long int" on a 32-bit platform).
--
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 stash pop" is doing an unwanted "git add" when there are conflicts.

[Jeff King]

On Tue, Dec 29, 2015 at 11:04:20AM -0800, Junio C Hamano wrote:

> [...]
> In the above, I suggested to "git reset" when there is no conflict.
> I think this line of thinking can be followed even further to
> selectively reset the paths that were cleanly merged (which is added
> by the call to merge-recursive), leaving _only_ the conflicted paths.
> 
> Would that give us a better outcome?  I dunno.

Yes, I think that is the only sensible change to make. The only other
option (besides leaving it as-is) would be to unstage _everything_
leaving conflict-marker cruft in the working tree, but no conflicts in
the index. I think that's a mistake, but I won't repeat the arguments I
left elsewhere in the thread.

So it's probably something like:

  git ls-files -t |
  grep -v ^M |
  cut -d ' ' -f2- |
  xargs git reset --

(modulo some quoting robustness improvements). But I guess we'd want to
preserve any modifications that were originally in the index. So maybe
the intersection of the files above and the output of "git diff-tree
--name-only" on the stash commit.

There are probably some corner cases to look at (e.g., with "--index").

As I said, I'm not planning to work on it anytime soon, but the above
may give some clues to somebody who wants to pursue it.

-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: [PATCH v2 0/3] nd/clear-gitenv-upon-use-of-alias

[Jeff King]

On Thu, Dec 24, 2015 at 04:35:33PM +0700, Duy Nguyen wrote:

> On Thu, Dec 24, 2015 at 4:31 AM, Jeff King  wrote:
> >   2. I doubt anybody is actually seeing this in practice anymore. But
> >  maybe I am misunderstanding something in Duy's series that changes
> >  this.
> 
> There are two parts in your patch, one (that you two seemed to focus
> on) about return code with "!" aliases. Another, suppressing SIGPIPE,
> affects more than "!" aliases.

Sorry if I was confusing; most of the examples in my previous message
are about the SIGPIPE thing. I was having trouble triggering the message
in practice, even for externals (because the error message goes to the
pager, too!).

> In my case it's execv_dashed_external(). Non-"!" aliases are now
> forced to use that function.

Thanks, this is the part I was missing.

The outer git wrapper doesn't start the pager, so its stderr still gets
seen by the user. But the _inner_ git-log does start the pager, and then
dies of SIGPIPE.

So yeah, I think we want something like this on top of
nd/clear-gitenv-upon-use-of-alias.

-- >8 --
Subject: [PATCH] run-command: don't warn on SIGPIPE deaths

When git executes a sub-command, we print a warning if the
command dies due to a signal, but make an exception for
"uninteresting" cases like SIGINT and SIGQUIT (since the
user presumably just hit ^C).

We should make a similar exception for SIGPIPE, because it's
an expected and uninteresting return in most cases; it
generally means the user quit the pager before git had
finished generating all output.  This used to be very hard
to trigger in practice, because:

  1. We only complain if we see a real SIGPIPE death, not
 the shell-induced 141 exit code. This means that
 anything we run via the shell does not trigger the
 warning, which includes most non-trivial aliases.

  2. The common case for SIGPIPE is the user quitting the
 pager before git has finished generating all output.
 But if the user triggers a pager with "-p", we redirect
 the git wrapper's stderr to that pager, too.  Since the
 pager is dead, it means that the message goes nowhere.

  3. You can see it if you run your own pager, like
 "git foo | head". But that only happens if "foo" is a
 non-builtin (so it doesn't work with "log", for
 example).

However, it may become more common after 86d26f2, which
teaches alias to re-exec builtins rather than running them
in the same process. This case doesn't trigger (1), as we
don't need a shell to run a git command. It doesn't trigger
(2), because the pager is not started by the original git,
but by the inner re-exec of git. And it doesn't trigger (3),
because builtins are treated more like non-builtins in this
case.

Given how flaky this message already is (e.g., you cannot
even know whether you will see it, as git optimizes out some
shell invocations behind the scenes based on the contents of
the command!), and that it is unlikely to ever provide
useful information, let's suppress it for all cases of
SIGPIPE.

Signed-off-by: Jeff King 
---
 run-command.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/run-command.c b/run-command.c
index 13fa452..694a6ff 100644
--- a/run-command.c
+++ b/run-command.c
@@ -245,7 +245,7 @@ static int wait_or_whine(pid_t pid, const char *argv0, int 
in_signal)
error("waitpid is confused (%s)", argv0);
} else if (WIFSIGNALED(status)) {
code = WTERMSIG(status);
-   if (code != SIGINT && code != SIGQUIT)
+   if (code != SIGINT && code != SIGQUIT && code != SIGPIPE)
error("%s died of signal %d", argv0, code);
/*
 * This return value is chosen so that code & 0xff
-- 
2.7.0.rc3.367.g09631da

--
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 0/3] improve symbolic-ref robustness

[Michael Haggerty]

On 12/29/2015 06:55 AM, Jeff King wrote:
> On Sun, Dec 20, 2015 at 02:26:37AM -0500, Jeff King wrote:
> 
>> I noticed that an interrupt "git symbolic-ref" will not clean up
>> "HEAD.lock". So I started this series as an attempt to convert
>> create_symref() to "struct lock_file" to get the usual tempfile cleanup.
> 
> Here's version 2, based on comments from Michael. The first two patches
> were picked out separately for jk/symbolic-ref-maint, so I've dropped
> them here (so 1+2 here are the original 3+4).
> 
> The other differences from v1 are:
> 
>   - use "refname" instead of "ref" to match surrounding code
> 
>   - drop adjust_shared_perm, as lockfile does it for us
> 
>   - adjust reflog writing order (done in a new patch)
> 
> The patches are:
> 
>   [1/3]: create_symref: modernize variable names
>   [2/3]: create_symref: use existing ref-lock code
>   [3/3]: create_symref: write reflog while holding lock

Thanks, Peff. The whole series is

Reviewed-by: Michael Haggerty 

Michael

-- 
Michael Haggerty
mhag...@alum.mit.edu

--
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 19/20] t5500: test for shallow depth excluding a ref

[Nguyễn Thái Ngọc Duy]

Signed-off-by: Nguyễn Thái Ngọc Duy 
---
 t/t5500-fetch-pack.sh | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/t/t5500-fetch-pack.sh b/t/t5500-fetch-pack.sh
index 338b46e..2259631 100755
--- a/t/t5500-fetch-pack.sh
+++ b/t/t5500-fetch-pack.sh
@@ -655,4 +655,22 @@ test_expect_success 'fetch shallow since ...' '
test_cmp expected actual
 '
 
+test_repo_expect_success 'shallow clone exclude tag two' '
+   test_commit one &&
+   test_commit two &&
+   test_commit three &&
+   git clone --not two "file://$(pwd)/." ../shallow12 &&
+   git -C ../shallow12 log --pretty=tformat:%s HEAD >actual &&
+   echo three >expected &&
+   test_cmp expected actual
+'
+
+test_expect_success 'fetch exclude tag one' '
+   git -C shallow12 fetch --not one origin &&
+   git -C shallow12 log --pretty=tformat:%s origin/master >actual &&
+   echo three >expected &&
+   echo two  >>expected &&
+   test_cmp expected actual
+'
+
 test_done
-- 
2.3.0.rc1.137.g477eb31

--
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 12/20] fetch: define shallow boundary with --since

[Nguyễn Thái Ngọc Duy]

Signed-off-by: Nguyễn Thái Ngọc Duy 
---
 Documentation/fetch-options.txt |  4 
 builtin/fetch.c | 12 ++--
 fetch-pack.c| 12 +++-
 fetch-pack.h|  1 +
 transport.c |  4 
 transport.h |  4 
 6 files changed, 34 insertions(+), 3 deletions(-)

diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
index 45583d8..ff6e6ad 100644
--- a/Documentation/fetch-options.txt
+++ b/Documentation/fetch-options.txt
@@ -13,6 +13,10 @@
to the specified number of commits from the tip of each remote
branch history. Tags for the deepened commits are not fetched.
 
+--since=::
+   Deepen or shorten the history of a 'shallow' repository to
+   include all reachable commits after .
+
 --unshallow::
If the source repository is complete, convert a shallow
repository to a complete one, removing all the limitations
diff --git a/builtin/fetch.c b/builtin/fetch.c
index c85f347..3317152 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -36,8 +36,9 @@ static int prune = -1; /* unspecified */
 
 static int all, append, dry_run, force, keep, multiple, update_head_ok, 
verbosity;
 static int progress = -1, recurse_submodules = RECURSE_SUBMODULES_DEFAULT;
-static int tags = TAGS_DEFAULT, unshallow, update_shallow;
+static int tags = TAGS_DEFAULT, unshallow, update_shallow, deepen;
 static const char *depth;
+static const char *deepen_since;
 static const char *upload_pack;
 static struct strbuf default_rla = STRBUF_INIT;
 static struct transport *gtransport;
@@ -112,6 +113,8 @@ static struct option builtin_fetch_options[] = {
OPT_BOOL(0, "progress", , N_("force progress reporting")),
OPT_STRING(0, "depth", , N_("depth"),
   N_("deepen history of shallow clone")),
+   OPT_STRING(0, "since", _since, N_("time"),
+  N_("deepen history of shallow clone based on time")),
{ OPTION_SET_INT, 0, "unshallow", , NULL,
   N_("convert to a complete repository"),
   PARSE_OPT_NONEG | PARSE_OPT_NOARG, NULL, 1 },
@@ -751,7 +754,7 @@ static int quickfetch(struct ref *ref_map)
 * really need to perform.  Claiming failure now will ensure
 * we perform the network exchange to deepen our history.
 */
-   if (depth)
+   if (deepen)
return -1;
return check_everything_connected(iterate_ref_map, 1, );
 }
@@ -867,6 +870,8 @@ static struct transport *prepare_transport(struct remote 
*remote)
set_option(transport, TRANS_OPT_KEEP, "yes");
if (depth)
set_option(transport, TRANS_OPT_DEPTH, depth);
+   if (deepen_since)
+   set_option(transport, TRANS_OPT_DEEPEN_SINCE, deepen_since);
if (update_shallow)
set_option(transport, TRANS_OPT_UPDATE_SHALLOW, "yes");
return transport;
@@ -881,6 +886,7 @@ static void backfill_tags(struct transport *transport, 
struct ref *ref_map)
 
transport_set_option(transport, TRANS_OPT_FOLLOWTAGS, NULL);
transport_set_option(transport, TRANS_OPT_DEPTH, "0");
+   transport_set_option(transport, TRANS_OPT_DEEPEN_SINCE, NULL);
fetch_refs(transport, ref_map);
 
if (gsecondary) {
@@ -1164,6 +1170,8 @@ int cmd_fetch(int argc, const char **argv, const char 
*prefix)
/* no need to be strict, transport_set_option() will validate it again 
*/
if (depth && atoi(depth) < 1)
die(_("depth %s is not a positive number"), depth);
+   if (depth || deepen_since)
+   deepen = 1;
 
if (recurse_submodules != RECURSE_SUBMODULES_OFF) {
if (recurse_submodules_default) {
diff --git a/fetch-pack.c b/fetch-pack.c
index e947514..f26cef4 100644
--- a/fetch-pack.c
+++ b/fetch-pack.c
@@ -21,6 +21,7 @@ static int fetch_unpack_limit = -1;
 static int unpack_limit = 100;
 static int prefer_ofs_delta = 1;
 static int no_done;
+static int deepen_since_ok;
 static int fetch_fsck_objects = -1;
 static int transfer_fsck_objects = -1;
 static int agent_supported;
@@ -326,6 +327,7 @@ static int find_common(struct fetch_pack_args *args,
if (args->no_progress)   strbuf_addstr(, " 
no-progress");
if (args->include_tag)   strbuf_addstr(, " 
include-tag");
if (prefer_ofs_delta)   strbuf_addstr(, " ofs-delta");
+   if (deepen_since_ok)strbuf_addstr(, " 
deepen-since");
if (agent_supported)strbuf_addf(, " agent=%s",

git_user_agent_sanitized());
packet_buf_write(_buf, "want %s%s\n", remote_hex, 
c.buf);
@@ -345,6 +347,10 @@ static int find_common(struct fetch_pack_args *args,
write_shallow_commits(_buf, 1, NULL);
if 

Re: [PATCH] worktree: stop supporting moving worktrees manually

[Duy Nguyen]

On Mon, Dec 28, 2015 at 1:22 PM, Eric Sunshine  wrote:
> On Sun, Dec 27, 2015 at 10:43:16AM +0700, Nguyễn Thái Ngọc Duy wrote:
>> The current update_linked_gitdir() has a bug that can create "gitdir"
>> file in non-multi-worktree setup. Instead of fixing this, we step back a
>> bit. The original design was probably not well thought out. For now, if
>> the user manually moves a worktree, they have to fix up "gitdir" file
>> manually or the worktree will get pruned. In future, we probably will
>> add "git worktree mv" to support this use case.
>>
>> Signed-off-by: Nguyễn Thái Ngọc Duy 
>> ---
>> diff --git a/Documentation/git-worktree.txt b/Documentation/git-worktree.txt
>> @@ -33,10 +33,8 @@ The working tree's administrative files in the repository 
>> (see
>>  If you move a linked working tree to another file system, or
>> -within a file system that does not support hard links, you need to run
>> -at least one git command inside the linked working tree
>> -(e.g. `git status`) in order to update its administrative files in the
>> -repository so that they do not get automatically pruned.
>> +within a file system that does not support hard links, you need to update
>
> Hmm, is this "hard links" feature implemented? If not, then this
> documentation is a bit outdated.

The prune logic is there. But this hard link is not created by
'worktree add'. I think calling link() was done at some point but then
it got dropped. Ah found it, it wasn't a big "no" so maybe we can
revive it at some point.

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

>> +$GIT_DIR/worktrees//gitdir so that they do not get automatically pruned.
>
> Following the example of af189b4 (Documentation/git-worktree: split
> technical info from general description, 2015-07-06), it might be a
> good idea to keep this high-level overview free of such low-level
> details and instead mention $GIT_DIR/worktrees//gitdir in the
> "DETAILS" section.
>
> Perhaps something like this, on top of your patch (assuming that the
> "hard links" feature is not implemented):

Looks good.

How about something like this at the end of the last new paragraph?
"alternatively if your file system supports hard link and the worktree
and $GIT_DIR are on the same file system, you can create a hard link
named "link" back to the .git file. See gitrepository-layout.txt for
more information".

>
> --- 8< ---
> diff --git a/Documentation/git-worktree.txt b/Documentation/git-worktree.txt
> index 4814f48..62c76c1 100644
> --- a/Documentation/git-worktree.txt
> +++ b/Documentation/git-worktree.txt
> @@ -32,9 +32,9 @@ The working tree's administrative files in the repository 
> (see
>  `git worktree prune` in the main or any linked working tree to
>  clean up any stale administrative files.
>
> -If you move a linked working tree to another file system, or
> -within a file system that does not support hard links, you need to update
> -$GIT_DIR/worktrees//gitdir so that they do not get automatically pruned.
> +If you move a linked working tree, you need to manually update the
> +administrative files so that they do not get pruned automatically. See
> +section "DETAILS" for more information.
>
>  If a linked working tree is stored on a portable device or network share
>  which is not always mounted, you can prevent its administrative files from
> @@ -135,6 +135,13 @@ thumb is do not make any assumption about whether a path 
> belongs to
>  $GIT_DIR or $GIT_COMMON_DIR when you need to directly access something
>  inside $GIT_DIR. Use `git rev-parse --git-path` to get the final path.
>
> +If you move a linked working tree, you need to update the 'gitdir' file
> +in the entry's directory. For example, if a linked working tree is moved
> +to `/newpath/test-next` and its `.git` file points to
> +`/path/main/.git/worktrees/test-next`, then update
> +`/path/main/.git/worktrees/test-next/gitdir` to reference 
> `/newpath/test-next`
> +instead.
> +
>  To prevent a $GIT_DIR/worktrees entry from being pruned (which
>  can be useful in some situations, such as when the
>  entry's working tree is stored on a portable device), add a file named
> --- 8< ---



-- 
Duy
--
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 00/20] More flexibility in making shallow clones

[Nguyễn Thái Ngọc Duy]

This series brings three new options to shallow clone/fetch. --since
lets you specify cut point by time. --not cuts by excluding specified
refs. And --deepen= extends shallow boundary in a more predictable
way. Some of these were requested in the past.

An important point of this series is it starts to use rev-list behind
the scene to define shallow boundary, which opens doors to even more
ways of cutting a repository.

The series is good enough to look at but I don't think I have stared
long enough to spot all the bugs. This mail is mostly about checking
if the design (at both code and protocol levels) and the UI make
sense. I'm thinking --since and --not may be too generic, but I don't
see any better names, for example.

Refactor/cleanup patches are sprinkled throughout (bad?). The meat is
in 05, 09, 12, 13, 16, 17, 18 and 20.

HTTP support is not in this series (and I don't intend to do soon).
The amount of filler code just to pass some info from UI down to the
protocol seems too much, and it's even more so when HTTP support is
added. But I don't see anyway around it. Maybe we can share some code
between git-clone, git-fetch and git-fetch-pack, at least the argument
parsing..

Nguyễn Thái Ngọc Duy (20):
  upload-pack: move shallow deepen code out of receive_needs()
  upload-pack: move "shallow" sending code out of deepen()
  upload-pack: remove unused variable "backup"
  upload-pack: move "unshallow" sending code out of deepen()
  shallow.c: implement a generic shallow boundary finder based on rev-list
  upload-pack: glue code to use get_shallow_commits_by_rev_list
  upload-pack: use skip_prefix() instead of starts_with() when possible
  upload-pack: tighten number parsing at "deepen" lines
  upload-pack: add deepen-since to cut shallow repos based on time
  fetch-pack: use a common function for verbose printing
  fetch-pack: use a separate flag for fetch in deepening mode
  fetch: define shallow boundary with --since
  clone: define shallow clone boundary based on time with --since
  Add test_repo_expect_success for running tests in a new repository
  t5500: test for shallow depth since a specific date
  upload-pack: support define shallow boundary by excluding revisions
  fetch: define shallow boundary with --not
  clone: define shallow clone boundary with --not
  t5500: test for shallow depth excluding a ref
  fetch: add --deepen= to extend shallow boundary by  commits

 Documentation/fetch-options.txt   |  14 ++
 Documentation/git-clone.txt   |   8 +
 Documentation/technical/pack-protocol.txt |   4 +-
 Documentation/technical/protocol-capabilities.txt |  25 +++
 builtin/clone.c   |  32 +++-
 builtin/fetch.c   |  44 -
 commit.h  |   2 +
 fetch-pack.c  | 128 --
 fetch-pack.h  |   4 +
 shallow.c |  92 ++
 t/README  |  15 ++
 t/t5500-fetch-pack.sh |  36 
 t/t5510-fetch.sh  |  12 ++
 t/test-lib-functions.sh   |  20 +++
 transport.c   |  11 ++
 transport.h   |  14 ++
 upload-pack.c | 206 --
 17 files changed, 550 insertions(+), 117 deletions(-)

-- 
2.3.0.rc1.137.g477eb31

--
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 14/20] Add test_repo_expect_success for running tests in a new repository

[Duy Nguyen]

On Tue, Dec 29, 2015 at 7:10 PM, Nguyễn Thái Ngọc Duy  wrote:
> This could be convenient when tests are independent from the rest in the
> same file. Normally we would do this
> ...

Before anybody comments about this patch. I missed Junio and Jeff's
comments when the patch was posted separately a few months ago (what
was I doing in September??). I just found this out after some random
search, so this patch may get dropped (or may stay in a different
form).
-- 
Duy
--
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] Fix "inside work tree" detection on case-insensitive filesystems

[Michael Haggerty]

On 09/28/2015 06:12 PM, Johannes Schindelin wrote:
> Git has a config variable to indicate that it is operating on a file
> system that is case-insensitive: core.ignoreCase. But the
> `dir_inside_of()` function did not respect that. As a result, if Git's
> idea of the current working directory disagreed in its upper/lower case
> with the `GIT_WORK_TREE` variable (e.g. `C:\test` vs `c:\test`) the
> user would be greeted by the error message
> 
>   fatal: git-am cannot be used without a working tree.
> 
> when trying to run a rebase.
> 
> This fixes https://github.com/git-for-windows/git/issues/402 (reported by
> Daniel Harding).

I was just going through the 2.7 release notes when I saw this patch. My
understanding was that many of the case-insensitive filesystems also
support Unicode. Is the byte-oriented code in this patch adequate? I
would have thought it necessary to use a Unicode-aware algorithm here,
that knows:

* that bytes != characters
* how to do a case-insensitive comparison of strings that include
non-ASCII characters
* (possibly) insensitivity to NFC vs. NFD vs. non-normalized forms

I suppose that such OSs have built-in functions for deciding whether two
paths are equivalent. Possibly these could be used?

Michael

> Signed-off-by: Johannes Schindelin 
> ---
>  dir.c | 11 ++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/dir.c b/dir.c
> index b90484a..fba938b 100644
> --- a/dir.c
> +++ b/dir.c
> @@ -2107,6 +2107,15 @@ int file_exists(const char *f)
>   return lstat(f, ) == 0;
>  }
>  
> +static int cmp_icase(char a, char b)
> +{
> + if (a == b)
> + return 0;
> + if (ignore_case)
> + return toupper(a) - toupper(b);
> + return a - b;
> +}
> +
>  /*
>   * Given two normalized paths (a trailing slash is ok), if subdir is
>   * outside dir, return -1.  Otherwise return the offset in subdir that
> @@ -2118,7 +2127,7 @@ int dir_inside_of(const char *subdir, const char *dir)
>  
>   assert(dir && subdir && *dir && *subdir);
>  
> - while (*dir && *subdir && *dir == *subdir) {
> + while (*dir && *subdir && !cmp_icase(*dir, *subdir)) {
>   dir++;
>   subdir++;
>   offset++;
> 


-- 
Michael Haggerty
mhag...@alum.mit.edu

--
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 03/20] upload-pack: remove unused variable "backup"

[Nguyễn Thái Ngọc Duy]

After the last patch, "result" and "backup" are the same. "result" used
to move, but the movement is now contained in send_shallow(). Delete
this redundant variable.

Signed-off-by: Nguyễn Thái Ngọc Duy 
---
 upload-pack.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/upload-pack.c b/upload-pack.c
index 0eb9a0b..4774f78 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -554,7 +554,7 @@ static void send_shallow(struct commit_list *result)
 
 static void deepen(int depth, const struct object_array *shallows)
 {
-   struct commit_list *result = NULL, *backup = NULL;
+   struct commit_list *result = NULL;
int i;
if (depth == INFINITE_DEPTH && !is_repository_shallow())
for (i = 0; i < shallows->nr; i++) {
@@ -562,11 +562,11 @@ static void deepen(int depth, const struct object_array 
*shallows)
object->flags |= NOT_SHALLOW;
}
else
-   backup = result =
+   result =
get_shallow_commits(_obj, depth,
SHALLOW, NOT_SHALLOW);
send_shallow(result);
-   free_commit_list(backup);
+   free_commit_list(result);
for (i = 0; i < shallows->nr; i++) {
struct object *object = shallows->objects[i].item;
if (object->flags & NOT_SHALLOW) {
-- 
2.3.0.rc1.137.g477eb31

--
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 01/20] upload-pack: move shallow deepen code out of receive_needs()

[Nguyễn Thái Ngọc Duy]

This is a prep step for further refactoring. Besides reindentation and
s/shallows\./shallows->/g, no other changes are expected.

Signed-off-by: Nguyễn Thái Ngọc Duy 
---
 upload-pack.c | 99 +++
 1 file changed, 52 insertions(+), 47 deletions(-)

diff --git a/upload-pack.c b/upload-pack.c
index b3f6653..97ed620 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -538,6 +538,55 @@ error:
}
 }
 
+static void deepen(int depth, const struct object_array *shallows)
+{
+   struct commit_list *result = NULL, *backup = NULL;
+   int i;
+   if (depth == INFINITE_DEPTH && !is_repository_shallow())
+   for (i = 0; i < shallows->nr; i++) {
+   struct object *object = shallows->objects[i].item;
+   object->flags |= NOT_SHALLOW;
+   }
+   else
+   backup = result =
+   get_shallow_commits(_obj, depth,
+   SHALLOW, NOT_SHALLOW);
+   while (result) {
+   struct object *object = >item->object;
+   if (!(object->flags & (CLIENT_SHALLOW|NOT_SHALLOW))) {
+   packet_write(1, "shallow %s",
+oid_to_hex(>oid));
+   register_shallow(object->oid.hash);
+   shallow_nr++;
+   }
+   result = result->next;
+   }
+   free_commit_list(backup);
+   for (i = 0; i < shallows->nr; i++) {
+   struct object *object = shallows->objects[i].item;
+   if (object->flags & NOT_SHALLOW) {
+   struct commit_list *parents;
+   packet_write(1, "unshallow %s",
+oid_to_hex(>oid));
+   object->flags &= ~CLIENT_SHALLOW;
+   /* make sure the real parents are parsed */
+   unregister_shallow(object->oid.hash);
+   object->parsed = 0;
+   parse_commit_or_die((struct commit *)object);
+   parents = ((struct commit *)object)->parents;
+   while (parents) {
+   add_object_array(>item->object,
+NULL, _obj);
+   parents = parents->next;
+   }
+   add_object_array(object, NULL, _edge_obj);
+   }
+   /* make sure commit traversal conforms to client */
+   register_shallow(object->oid.hash);
+   }
+   packet_flush(1);
+}
+
 static void receive_needs(void)
 {
struct object_array shallows = OBJECT_ARRAY_INIT;
@@ -630,53 +679,9 @@ static void receive_needs(void)
 
if (depth == 0 && shallows.nr == 0)
return;
-   if (depth > 0) {
-   struct commit_list *result = NULL, *backup = NULL;
-   int i;
-   if (depth == INFINITE_DEPTH && !is_repository_shallow())
-   for (i = 0; i < shallows.nr; i++) {
-   struct object *object = 
shallows.objects[i].item;
-   object->flags |= NOT_SHALLOW;
-   }
-   else
-   backup = result =
-   get_shallow_commits(_obj, depth,
-   SHALLOW, NOT_SHALLOW);
-   while (result) {
-   struct object *object = >item->object;
-   if (!(object->flags & (CLIENT_SHALLOW|NOT_SHALLOW))) {
-   packet_write(1, "shallow %s",
-   oid_to_hex(>oid));
-   register_shallow(object->oid.hash);
-   shallow_nr++;
-   }
-   result = result->next;
-   }
-   free_commit_list(backup);
-   for (i = 0; i < shallows.nr; i++) {
-   struct object *object = shallows.objects[i].item;
-   if (object->flags & NOT_SHALLOW) {
-   struct commit_list *parents;
-   packet_write(1, "unshallow %s",
-   oid_to_hex(>oid));
-   object->flags &= ~CLIENT_SHALLOW;
-   /* make sure the real parents are parsed */
-   unregister_shallow(object->oid.hash);
-   object->parsed = 0;
-   parse_commit_or_die((struct commit *)object);
-   parents = ((struct commit *)object)->parents;
-   while (parents) {
-   

[PATCH 05/20] shallow.c: implement a generic shallow boundary finder based on rev-list

[Nguyễn Thái Ngọc Duy]

Instead of a custom commit walker like get_shallow_commits(), this new
function uses rev-list to mark NOT_SHALLOW to all reachable commits,
except borders. The definition of reachable is to be defined by the
protocol later. This makes it more flexible to define shallow boundary.

Note: if a commit has one NOT_SHALLOW parent and one SHALLOW parent,
then it's considered the boundary. Which means in the client side, this
commit has _no_ parents. This could lead to surprising cuts if we're not
careful.

Another option is to include more commits and only mark commits whose
all parents are SHALLOW as boundary.

Signed-off-by: Nguyễn Thái Ngọc Duy 
---
 commit.h  |  2 ++
 shallow.c | 92 +++
 2 files changed, 94 insertions(+)

diff --git a/commit.h b/commit.h
index 5d58be0..b717be1 100644
--- a/commit.h
+++ b/commit.h
@@ -258,6 +258,8 @@ extern int for_each_commit_graft(each_commit_graft_fn, void 
*);
 extern int is_repository_shallow(void);
 extern struct commit_list *get_shallow_commits(struct object_array *heads,
int depth, int shallow_flag, int not_shallow_flag);
+extern struct commit_list *get_shallow_commits_by_rev_list(
+   int ac, const char **av, int shallow_flag, int 
not_shallow_flag);
 extern void set_alternate_shallow_file(const char *path, int override);
 extern int write_shallow_commits(struct strbuf *out, int use_pack_protocol,
 const struct sha1_array *extra);
diff --git a/shallow.c b/shallow.c
index 60f1505..45dffaa 100644
--- a/shallow.c
+++ b/shallow.c
@@ -10,6 +10,8 @@
 #include "diff.h"
 #include "revision.h"
 #include "commit-slab.h"
+#include "revision.h"
+#include "list-objects.h"
 
 static int is_shallow = -1;
 static struct stat_validity shallow_stat;
@@ -137,6 +139,96 @@ struct commit_list *get_shallow_commits(struct 
object_array *heads, int depth,
return result;
 }
 
+static void show_commit(struct commit *commit, void *data)
+{
+   commit->object.flags |= *(int *)data;
+}
+
+/*
+ * Given rev-list arguments, run rev-list. All reachable commits
+ * except border ones are marked with not_shallow_flag. Border commits
+ * are marked with shallow_flag. The list of border/shallow commits
+ * are also returned.
+ */
+struct commit_list *get_shallow_commits_by_rev_list(int ac, const char **av,
+   int shallow_flag,
+   int not_shallow_flag)
+{
+   struct commit_list *result = NULL, *cl;
+   struct rev_info revs;
+   unsigned int i, nr;
+
+   /*
+* SHALLOW and NOT_SHALLOW should not be set at this
+* point. But better be safe than sorry.
+*/
+   nr = get_max_object_index();
+   for (i = 0; i < nr; i++) {
+   struct object *o = get_indexed_object(i);
+   if (!o)
+   continue;
+   o->flags &= ~(shallow_flag | not_shallow_flag);
+   }
+
+   is_repository_shallow(); /* make sure shallows are read */
+
+   init_revisions(, NULL);
+   save_commit_buffer = 0;
+   setup_revisions(ac, av, , NULL);
+
+   /* Mark all reachable commits as NOT_SHALLOW */
+   if (prepare_revision_walk())
+   die("revision walk setup failed");
+   traverse_commit_list(, show_commit, NULL, _shallow_flag);
+
+   /*
+* mark border commits SHALLOW + NOT_SHALLOW.
+* We cannot clear NOT_SHALLOW right now. Imagine border
+* commit A is processed first, then commit B, whose parent is
+* A, later. If NOT_SHALLOW on A is cleared at step 1, B
+* itself is considered border at step 2, which is incorrect.
+*/
+   nr = get_max_object_index();
+   for (i = 0; i < nr; i++) {
+   struct object *o = get_indexed_object(i);
+   struct commit *c = (struct commit *)o;
+   struct commit_list *p;
+   int parent_is_shallow = 0;
+
+   if (!o || o->type != OBJ_COMMIT || !(o->flags & 
not_shallow_flag))
+   continue;
+
+   if (parse_commit(c))
+   die("unable to parse commit %s",
+   oid_to_hex(>object.oid));
+
+   for (p = c->parents; p; p = p->next) {
+   if (p->item->object.flags & not_shallow_flag)
+   continue;
+   parent_is_shallow = 1;
+   if (p->item->object.flags & shallow_flag)
+   continue;
+   p->item->object.flags |= shallow_flag;
+   commit_list_insert(p->item, );
+   }
+
+   if (parent_is_shallow) {
+   o->flags |= shallow_flag;
+   commit_list_insert(c, );
+   }
+   }
+   /* clean up NOT_SHALLOW on border 

[PATCH 08/20] upload-pack: tighten number parsing at "deepen" lines

[Nguyễn Thái Ngọc Duy]

Signed-off-by: Nguyễn Thái Ngọc Duy 
---
 upload-pack.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/upload-pack.c b/upload-pack.c
index e9594d1..573ffa2 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -648,9 +648,9 @@ static void receive_needs(void)
continue;
}
if (skip_prefix(line, "deepen ", )) {
-   char *end;
+   char *end = NULL;
depth = strtol(arg, , 0);
-   if (end == arg || depth <= 0)
+   if (!end || *end || depth <= 0)
die("Invalid deepen: %s", line);
continue;
}
-- 
2.3.0.rc1.137.g477eb31

--
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 15/20] t5500: test for shallow depth since a specific date

[Nguyễn Thái Ngọc Duy]

Signed-off-by: Nguyễn Thái Ngọc Duy 
---
 t/t5500-fetch-pack.sh | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/t/t5500-fetch-pack.sh b/t/t5500-fetch-pack.sh
index 3a9b775..338b46e 100755
--- a/t/t5500-fetch-pack.sh
+++ b/t/t5500-fetch-pack.sh
@@ -637,4 +637,22 @@ test_expect_success MINGW 'fetch-pack --diag-url c:repo' '
check_prot_path c:repo file c:repo
 '
 
+test_repo_expect_success 'clone shallow since ...' '
+   GIT_COMMITTER_DATE="1 +0700" git commit --allow-empty -m one &&
+   GIT_COMMITTER_DATE="2 +0700" git commit --allow-empty -m two &&
+   GIT_COMMITTER_DATE="3 +0700" git commit --allow-empty -m three 
&&
+   git clone --since "3 +0700" "file://$(pwd)/." ../shallow11 &&
+   git -C ../shallow11 log --pretty=tformat:%s HEAD >actual &&
+   echo three >expected &&
+   test_cmp expected actual
+'
+
+test_expect_success 'fetch shallow since ...' '
+   git -C shallow11 fetch --since "2 +0700" origin &&
+   git -C shallow11 log --pretty=tformat:%s origin/master >actual &&
+   echo three >expected &&
+   echo two  >>expected &&
+   test_cmp expected actual
+'
+
 test_done
-- 
2.3.0.rc1.137.g477eb31

--
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 14/20] Add test_repo_expect_success for running tests in a new repository

[Nguyễn Thái Ngọc Duy]

This could be convenient when tests are independent from the rest in the
same file. Normally we would do this

test_expect_success '...' '
git init foo &&
(
cd foo &&

[PATCH 13/20] clone: define shallow clone boundary based on time with --since

[Nguyễn Thái Ngọc Duy]

Signed-off-by: Nguyễn Thái Ngọc Duy 
---
 Documentation/git-clone.txt |  3 +++
 builtin/clone.c | 16 +---
 2 files changed, 16 insertions(+), 3 deletions(-)

diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index 6bf000d..28993c6 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -192,6 +192,9 @@ objects from the source repository into a pack in the 
cloned repository.
Create a 'shallow' clone with a history truncated to the
specified number of revisions.
 
+--since=::
+   Create a 'shallow' clone with a history after the specified time.
+
 --[no-]single-branch::
Clone only the history leading to the tip of a single branch,
either specified by the `--branch` option or the primary
diff --git a/builtin/clone.c b/builtin/clone.c
index a0b3cd9..94bbfef 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -40,7 +40,8 @@ static const char * const builtin_clone_usage[] = {
 
 static int option_no_checkout, option_bare, option_mirror, 
option_single_branch = -1;
 static int option_local = -1, option_no_hardlinks, option_shared, 
option_recursive;
-static char *option_template, *option_depth;
+static int deepen;
+static char *option_template, *option_depth, *option_since;
 static char *option_origin = NULL;
 static char *option_branch = NULL;
 static const char *real_git_dir;
@@ -86,6 +87,8 @@ static struct option builtin_clone_options[] = {
   N_("path to git-upload-pack on the remote")),
OPT_STRING(0, "depth", _depth, N_("depth"),
N_("create a shallow clone of that depth")),
+   OPT_STRING(0, "since", _since, N_("time"),
+   N_("create a shallow clone since a specific time")),
OPT_BOOL(0, "single-branch", _single_branch,
N_("clone only one branch, HEAD or --branch")),
OPT_STRING(0, "separate-git-dir", _git_dir, N_("gitdir"),
@@ -846,8 +849,10 @@ int cmd_clone(int argc, const char **argv, const char 
*prefix)
usage_msg_opt(_("You must specify a repository to clone."),
builtin_clone_usage, builtin_clone_options);
 
+   if (option_depth || option_since)
+   deepen = 1;
if (option_single_branch == -1)
-   option_single_branch = option_depth ? 1 : 0;
+   option_single_branch = deepen ? 1 : 0;
 
if (option_mirror)
option_bare = 1;
@@ -973,6 +978,8 @@ int cmd_clone(int argc, const char **argv, const char 
*prefix)
if (is_local) {
if (option_depth)
warning(_("--depth is ignored in local clones; use 
file:// instead."));
+   if (option_since)
+   warning(_("--since is ignored in local clones; use 
file:// instead."));
if (!access(mkpath("%s/shallow", path), F_OK)) {
if (option_local > 0)
warning(_("source repository is shallow, 
ignoring --local"));
@@ -991,6 +998,9 @@ int cmd_clone(int argc, const char **argv, const char 
*prefix)
if (option_depth)
transport_set_option(transport, TRANS_OPT_DEPTH,
 option_depth);
+   if (option_since)
+   transport_set_option(transport, TRANS_OPT_DEEPEN_SINCE,
+option_since);
if (option_single_branch)
transport_set_option(transport, TRANS_OPT_FOLLOWTAGS, "1");
 
@@ -998,7 +1008,7 @@ int cmd_clone(int argc, const char **argv, const char 
*prefix)
transport_set_option(transport, TRANS_OPT_UPLOADPACK,
 option_upload_pack);
 
-   if (transport->smart_options && !option_depth)
+   if (transport->smart_options && !deepen)
transport->smart_options->check_self_contained_and_connected = 
1;
 
refs = transport_get_remote_refs(transport);
-- 
2.3.0.rc1.137.g477eb31

--
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 20/20] fetch: add --deepen= to extend shallow boundary by commits

[Nguyễn Thái Ngọc Duy]

In git-fetch, --depth argument is always relative with the latest
remote refs. This makes it a bit difficult to cover this use case,
where the user wants to make the shallow history, say 3 levels
deeper. It would work if remote refs have not moved yet, but nobody
can guarantee that, especially when that use case is performed a
couple months after the last clone or "git fetch --depth". Also,
modifying shallow boundary using --depth does not work well with
clones created by --since or --not.

This patch fixes that. A new argument --deepen= will add  more (*)
parent commits to the current history regardless of where remote refs
are. Note that "git fetch --deepen" also fetches latest changes (so
updates happen on both shallow and ref ends). This is mostly to ease
the verification task at server side.

The main work was done by Dongcan Jiang. I fixed it up here and there.
And of course all the bugs belong to me.

(*) We could even support --deepen= where  is negative. In that
case we can cut some history from the shallow clone. This operation
(and --depth=) does not require interaction with remote
side (and more complicated to implement as a result).

Helped-by: Duy Nguyen 
Helped-By: Eric Sunshine 
Helped-By: Junio C Hamano 
Signed-off-by: Dongcan Jiang 
Signed-off-by: Nguyễn Thái Ngọc Duy 
---
 Documentation/fetch-options.txt   |  5 +
 Documentation/technical/protocol-capabilities.txt |  7 +++
 builtin/fetch.c   | 17 +++--
 fetch-pack.c  |  3 +++
 fetch-pack.h  |  1 +
 t/t5510-fetch.sh  | 12 
 transport.c   |  3 +++
 transport.h   |  4 
 upload-pack.c | 14 --
 9 files changed, 62 insertions(+), 4 deletions(-)

diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
index 39fbcc3..c12f1c5 100644
--- a/Documentation/fetch-options.txt
+++ b/Documentation/fetch-options.txt
@@ -13,6 +13,11 @@
to the specified number of commits from the tip of each remote
branch history. Tags for the deepened commits are not fetched.
 
+--deepen=::
+   Similar to --depth, except it specifies the number of commits
+   from the current shallow boundary instead of from the tip of
+   reach remote branch history.
+
 --since=::
Deepen or shorten the history of a 'shallow' repository to
include all reachable commits after .
diff --git a/Documentation/technical/protocol-capabilities.txt 
b/Documentation/technical/protocol-capabilities.txt
index 0e6b57d..f732a41 100644
--- a/Documentation/technical/protocol-capabilities.txt
+++ b/Documentation/technical/protocol-capabilities.txt
@@ -197,6 +197,13 @@ specific revision, instead of depth. Internally it's 
equivalent of
 doing "rev-list --not " on the server side. "deepen-not"
 cannot be used with "deepen", but can be used with "deepen-since".
 
+deepen-relative
+---
+
+If this capacity is requested by the client, the semantics of "deepen"
+command is changed. The "depth" argument is the depth from the current
+shallow boundary, instead of the depth from remote refs.
+
 no-progress
 ---
 
diff --git a/builtin/fetch.c b/builtin/fetch.c
index 02a50e4..0aff238 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -34,7 +34,7 @@ static int fetch_prune_config = -1; /* unspecified */
 static int prune = -1; /* unspecified */
 #define PRUNE_BY_DEFAULT 0 /* do we prune by default? */
 
-static int all, append, dry_run, force, keep, multiple, update_head_ok, 
verbosity;
+static int all, append, dry_run, force, keep, multiple, update_head_ok, 
verbosity, deepen_relative;
 static int progress = -1, recurse_submodules = RECURSE_SUBMODULES_DEFAULT;
 static int tags = TAGS_DEFAULT, unshallow, update_shallow, deepen;
 static const char *depth;
@@ -126,6 +126,8 @@ static struct option builtin_fetch_options[] = {
{ OPTION_CALLBACK, 0, "not", NULL, N_("revision"),
N_("deepen history of shallow clone by excluding rev"),
PARSE_OPT_NONEG, option_parse_deepen_not },
+   OPT_INTEGER(0, "deepen", _relative,
+   N_("deepen history of shallow clone")),
{ OPTION_SET_INT, 0, "unshallow", , NULL,
   N_("convert to a complete repository"),
   PARSE_OPT_NONEG | PARSE_OPT_NOARG, NULL, 1 },
@@ -775,7 +777,7 @@ static int fetch_refs(struct transport *transport, struct 
ref *ref_map)
int ret = quickfetch(ref_map);
if (ret)
ret = transport_fetch_refs(transport, ref_map);
-   if (!ret)
+   if (!ret && !deepen_relative)
ret |= store_updated_refs(transport->url,

[PATCH 10/20] fetch-pack: use a common function for verbose printing

[Nguyễn Thái Ngọc Duy]

This reduces the number of "if (verbose)" which makes it a bit easier
to read imo. It also makes it easier to redirect all these printouts,
to a file for example.

Signed-off-by: Nguyễn Thái Ngọc Duy 
---
 fetch-pack.c | 88 +---
 1 file changed, 42 insertions(+), 46 deletions(-)

diff --git a/fetch-pack.c b/fetch-pack.c
index 01e34b6..16917f9 100644
--- a/fetch-pack.c
+++ b/fetch-pack.c
@@ -50,6 +50,21 @@ static int non_common_revs, multi_ack, use_sideband;
 #define ALLOW_REACHABLE_SHA1   02
 static unsigned int allow_unadvertised_object_request;
 
+__attribute__((format (printf, 2, 3)))
+static inline void print_verbose(const struct fetch_pack_args *args,
+const char *fmt, ...)
+{
+   va_list params;
+
+   if (!args->verbose)
+   return;
+
+   va_start(params, fmt);
+   vfprintf(stderr, fmt, params);
+   va_end(params);
+   fputc('\n', stderr);
+}
+
 static void rev_list_push(struct commit *commit, int mark)
 {
if (!(commit->object.flags & mark)) {
@@ -375,8 +390,7 @@ static int find_common(struct fetch_pack_args *args,
retval = -1;
while ((sha1 = get_rev())) {
packet_buf_write(_buf, "have %s\n", sha1_to_hex(sha1));
-   if (args->verbose)
-   fprintf(stderr, "have %s\n", sha1_to_hex(sha1));
+   print_verbose(args, "have %s", sha1_to_hex(sha1));
in_vain++;
if (flush_at <= ++count) {
int ack;
@@ -397,9 +411,9 @@ static int find_common(struct fetch_pack_args *args,
consume_shallow_list(args, fd[0]);
do {
ack = get_ack(fd[0], result_sha1);
-   if (args->verbose && ack)
-   fprintf(stderr, "got ack %d %s\n", ack,
-   
sha1_to_hex(result_sha1));
+   if (ack)
+   print_verbose(args, "got ack %d %s", 
ack,
+ sha1_to_hex(result_sha1));
switch (ack) {
case ACK:
flushes = 0;
@@ -438,8 +452,7 @@ static int find_common(struct fetch_pack_args *args,
} while (ack);
flushes--;
if (got_continue && MAX_IN_VAIN < in_vain) {
-   if (args->verbose)
-   fprintf(stderr, "giving up\n");
+   print_verbose(args, "giving up");
break; /* give up */
}
}
@@ -449,8 +462,7 @@ done:
packet_buf_write(_buf, "done\n");
send_request(args, fd[1], _buf);
}
-   if (args->verbose)
-   fprintf(stderr, "done\n");
+   print_verbose(args, "done");
if (retval != 0) {
multi_ack = 0;
flushes++;
@@ -462,9 +474,8 @@ done:
while (flushes || multi_ack) {
int ack = get_ack(fd[0], result_sha1);
if (ack) {
-   if (args->verbose)
-   fprintf(stderr, "got ack (%d) %s\n", ack,
-   sha1_to_hex(result_sha1));
+   print_verbose(args, "got ack (%d) %s", ack,
+ sha1_to_hex(result_sha1));
if (ack == ACK)
return 0;
multi_ack = 1;
@@ -509,9 +520,8 @@ static void mark_recent_complete_commits(struct 
fetch_pack_args *args,
 unsigned long cutoff)
 {
while (complete && cutoff <= complete->item->date) {
-   if (args->verbose)
-   fprintf(stderr, "Marking %s as complete\n",
-   oid_to_hex(>item->object.oid));
+   print_verbose(args, "Marking %s as complete",
+ oid_to_hex(>item->object.oid));
pop_most_recent_commit(, COMPLETE);
}
 }
@@ -652,18 +662,12 @@ static int everything_local(struct fetch_pack_args *args,
o = lookup_object(remote);
if (!o || !(o->flags & COMPLETE)) {
retval = 0;
-   if (!args->verbose)
-   continue;
-   fprintf(stderr,
-   "want %s (%s)\n", sha1_to_hex(remote),
-   ref->name);
+   print_verbose(args, "want %s (%s)", sha1_to_hex(remote),
+ ref->name);
continue;

[PATCH 11/20] fetch-pack: use a separate flag for fetch in deepening mode

[Nguyễn Thái Ngọc Duy]

The shallow repo could be deepened or shortened when then user gives
--depth. But in future that won't be the only way to deepen/shorten a
repo. Stop relying on args->depth in this mode. Future deepening
methods can simply set this flag on instead of updating all these if
expressions.

The new name "deepen" was chosen after the command to define shallow
boundary in pack protocol. New commands also follow this tradition.

Signed-off-by: Nguyễn Thái Ngọc Duy 
---
 fetch-pack.c | 14 --
 fetch-pack.h |  1 +
 2 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/fetch-pack.c b/fetch-pack.c
index 16917f9..e947514 100644
--- a/fetch-pack.c
+++ b/fetch-pack.c
@@ -197,7 +197,7 @@ enum ack_type {
 
 static void consume_shallow_list(struct fetch_pack_args *args, int fd)
 {
-   if (args->stateless_rpc && args->depth > 0) {
+   if (args->stateless_rpc && args->deepen) {
/* If we sent a depth we will get back "duplicate"
 * shallow and unshallow commands every time there
 * is a block of have lines exchanged.
@@ -348,7 +348,7 @@ static int find_common(struct fetch_pack_args *args,
packet_buf_flush(_buf);
state_len = req_buf.len;
 
-   if (args->depth > 0) {
+   if (args->deepen) {
char *line;
const char *arg;
unsigned char sha1[20];
@@ -557,7 +557,7 @@ static void filter_refs(struct fetch_pack_args *args,
}
 
if (!keep && args->fetch_all &&
-   (!args->depth || !starts_with(ref->name, "refs/tags/")))
+   (!args->deepen || !starts_with(ref->name, "refs/tags/")))
keep = 1;
 
if (keep) {
@@ -627,7 +627,7 @@ static int everything_local(struct fetch_pack_args *args,
}
}
 
-   if (!args->depth) {
+   if (!args->deepen) {
for_each_ref(mark_complete_oid, NULL);
for_each_alternate_ref(mark_alternate_complete, NULL);
commit_list_sort_by_date();
@@ -813,6 +813,8 @@ static struct ref *do_fetch_pack(struct fetch_pack_args 
*args,
 
if ((args->depth > 0 || is_repository_shallow()) && 
!server_supports("shallow"))
die("Server does not support shallow clients");
+   if (args->depth > 0)
+   args->deepen = 1;
if (server_supports("multi_ack_detailed")) {
print_verbose(args, "Server supports multi_ack_detailed");
multi_ack = 2;
@@ -873,7 +875,7 @@ static struct ref *do_fetch_pack(struct fetch_pack_args 
*args,
 
if (args->stateless_rpc)
packet_flush(fd[1]);
-   if (args->depth > 0)
+   if (args->deepen)
setup_alternate_shallow(_lock, _shallow_file,
NULL);
else if (si->nr_ours || si->nr_theirs)
@@ -940,7 +942,7 @@ static void update_shallow(struct fetch_pack_args *args,
int *status;
int i;
 
-   if (args->depth > 0 && alternate_shallow_file) {
+   if (args->deepen && alternate_shallow_file) {
if (*alternate_shallow_file == '\0') { /* --unshallow */
unlink_or_warn(git_path_shallow());
rollback_lock_file(_lock);
diff --git a/fetch-pack.h b/fetch-pack.h
index bb7fd76..4d0adb0 100644
--- a/fetch-pack.h
+++ b/fetch-pack.h
@@ -25,6 +25,7 @@ struct fetch_pack_args {
unsigned self_contained_and_connected:1;
unsigned cloning:1;
unsigned update_shallow:1;
+   unsigned deepen:1;
 };
 
 /*
-- 
2.3.0.rc1.137.g477eb31

--
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 17/20] fetch: define shallow boundary with --not

[Nguyễn Thái Ngọc Duy]

Signed-off-by: Nguyễn Thái Ngọc Duy 
---
 Documentation/fetch-options.txt |  5 +
 builtin/fetch.c | 17 -
 fetch-pack.c| 15 ++-
 fetch-pack.h|  1 +
 transport.c |  4 
 transport.h |  6 ++
 6 files changed, 46 insertions(+), 2 deletions(-)

diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
index ff6e6ad..39fbcc3 100644
--- a/Documentation/fetch-options.txt
+++ b/Documentation/fetch-options.txt
@@ -17,6 +17,11 @@
Deepen or shorten the history of a 'shallow' repository to
include all reachable commits after .
 
+--not=::
+   Deepen or shorten the history of a 'shallow' repository to
+   exclude commits reachable from a specified remote branch or tag.
+   This option can be specified multiple times.
+
 --unshallow::
If the source repository is complete, convert a shallow
repository to a complete one, removing all the limitations
diff --git a/builtin/fetch.c b/builtin/fetch.c
index 3317152..02a50e4 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -40,6 +40,7 @@ static int tags = TAGS_DEFAULT, unshallow, update_shallow, 
deepen;
 static const char *depth;
 static const char *deepen_since;
 static const char *upload_pack;
+struct string_list deepen_not = STRING_LIST_INIT_NODUP;
 static struct strbuf default_rla = STRBUF_INIT;
 static struct transport *gtransport;
 static struct transport *gsecondary;
@@ -49,6 +50,13 @@ static int shown_url = 0;
 static int refmap_alloc, refmap_nr;
 static const char **refmap_array;
 
+static int option_parse_deepen_not(const struct option *opt,
+  const char *arg, int unset)
+{
+   string_list_append(_not, arg);
+   return 0;
+}
+
 static int option_parse_recurse_submodules(const struct option *opt,
   const char *arg, int unset)
 {
@@ -115,6 +123,9 @@ static struct option builtin_fetch_options[] = {
   N_("deepen history of shallow clone")),
OPT_STRING(0, "since", _since, N_("time"),
   N_("deepen history of shallow clone based on time")),
+   { OPTION_CALLBACK, 0, "not", NULL, N_("revision"),
+   N_("deepen history of shallow clone by excluding rev"),
+   PARSE_OPT_NONEG, option_parse_deepen_not },
{ OPTION_SET_INT, 0, "unshallow", , NULL,
   N_("convert to a complete repository"),
   PARSE_OPT_NONEG | PARSE_OPT_NOARG, NULL, 1 },
@@ -872,6 +883,9 @@ static struct transport *prepare_transport(struct remote 
*remote)
set_option(transport, TRANS_OPT_DEPTH, depth);
if (deepen_since)
set_option(transport, TRANS_OPT_DEEPEN_SINCE, deepen_since);
+   if (deepen_not.nr)
+   set_option(transport, TRANS_OPT_DEEPEN_NOT,
+  (const char *)_not);
if (update_shallow)
set_option(transport, TRANS_OPT_UPDATE_SHALLOW, "yes");
return transport;
@@ -887,6 +901,7 @@ static void backfill_tags(struct transport *transport, 
struct ref *ref_map)
transport_set_option(transport, TRANS_OPT_FOLLOWTAGS, NULL);
transport_set_option(transport, TRANS_OPT_DEPTH, "0");
transport_set_option(transport, TRANS_OPT_DEEPEN_SINCE, NULL);
+   transport_set_option(transport, TRANS_OPT_DEEPEN_NOT, NULL);
fetch_refs(transport, ref_map);
 
if (gsecondary) {
@@ -1170,7 +1185,7 @@ int cmd_fetch(int argc, const char **argv, const char 
*prefix)
/* no need to be strict, transport_set_option() will validate it again 
*/
if (depth && atoi(depth) < 1)
die(_("depth %s is not a positive number"), depth);
-   if (depth || deepen_since)
+   if (depth || deepen_since || deepen_not.nr)
deepen = 1;
 
if (recurse_submodules != RECURSE_SUBMODULES_OFF) {
diff --git a/fetch-pack.c b/fetch-pack.c
index f26cef4..45f69de 100644
--- a/fetch-pack.c
+++ b/fetch-pack.c
@@ -22,6 +22,7 @@ static int unpack_limit = 100;
 static int prefer_ofs_delta = 1;
 static int no_done;
 static int deepen_since_ok;
+static int deepen_not_ok;
 static int fetch_fsck_objects = -1;
 static int transfer_fsck_objects = -1;
 static int agent_supported;
@@ -328,6 +329,7 @@ static int find_common(struct fetch_pack_args *args,
if (args->include_tag)   strbuf_addstr(, " 
include-tag");
if (prefer_ofs_delta)   strbuf_addstr(, " ofs-delta");
if (deepen_since_ok)strbuf_addstr(, " 
deepen-since");
+   if (deepen_not_ok)  strbuf_addstr(, " 
deepen-not");
if (agent_supported)strbuf_addf(, " agent=%s",

git_user_agent_sanitized());

[PATCH 18/20] clone: define shallow clone boundary with --not

[Nguyễn Thái Ngọc Duy]

Signed-off-by: Nguyễn Thái Ngọc Duy 
---
 Documentation/git-clone.txt |  5 +
 builtin/clone.c | 18 +-
 2 files changed, 22 insertions(+), 1 deletion(-)

diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index 28993c6..3589e57 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -195,6 +195,11 @@ objects from the source repository into a pack in the 
cloned repository.
 --since=::
Create a 'shallow' clone with a history after the specified time.
 
+--not=::
+   Create a 'shallow' clone with a history, excluding commits
+   reachable from a specified remote branch or tag.  This option
+   can be specified multiple times.
+
 --[no-]single-branch::
Clone only the history leading to the tip of a single branch,
either specified by the `--branch` option or the primary
diff --git a/builtin/clone.c b/builtin/clone.c
index 94bbfef..0e99354 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -44,6 +44,7 @@ static int deepen;
 static char *option_template, *option_depth, *option_since;
 static char *option_origin = NULL;
 static char *option_branch = NULL;
+static struct string_list option_not = STRING_LIST_INIT_NODUP;
 static const char *real_git_dir;
 static char *option_upload_pack = "git-upload-pack";
 static int option_verbosity;
@@ -52,6 +53,13 @@ static struct string_list option_config;
 static struct string_list option_reference;
 static int option_dissociate;
 
+static int option_parse_deepen_not(const struct option *opt,
+  const char *arg, int unset)
+{
+   string_list_append(_not, arg);
+   return 0;
+}
+
 static struct option builtin_clone_options[] = {
OPT__VERBOSITY(_verbosity),
OPT_BOOL(0, "progress", _progress,
@@ -89,6 +97,9 @@ static struct option builtin_clone_options[] = {
N_("create a shallow clone of that depth")),
OPT_STRING(0, "since", _since, N_("time"),
N_("create a shallow clone since a specific time")),
+   { OPTION_CALLBACK, 0, "not", NULL, N_("revision"),
+   N_("deepen history of shallow clone by excluding rev"),
+   PARSE_OPT_NONEG, option_parse_deepen_not },
OPT_BOOL(0, "single-branch", _single_branch,
N_("clone only one branch, HEAD or --branch")),
OPT_STRING(0, "separate-git-dir", _git_dir, N_("gitdir"),
@@ -849,7 +860,7 @@ int cmd_clone(int argc, const char **argv, const char 
*prefix)
usage_msg_opt(_("You must specify a repository to clone."),
builtin_clone_usage, builtin_clone_options);
 
-   if (option_depth || option_since)
+   if (option_depth || option_since || option_not.nr)
deepen = 1;
if (option_single_branch == -1)
option_single_branch = deepen ? 1 : 0;
@@ -980,6 +991,8 @@ int cmd_clone(int argc, const char **argv, const char 
*prefix)
warning(_("--depth is ignored in local clones; use 
file:// instead."));
if (option_since)
warning(_("--since is ignored in local clones; use 
file:// instead."));
+   if (option_not.nr)
+   warning(_("--not is ignored in local clones; use 
file:// instead."));
if (!access(mkpath("%s/shallow", path), F_OK)) {
if (option_local > 0)
warning(_("source repository is shallow, 
ignoring --local"));
@@ -1001,6 +1014,9 @@ int cmd_clone(int argc, const char **argv, const char 
*prefix)
if (option_since)
transport_set_option(transport, TRANS_OPT_DEEPEN_SINCE,
 option_since);
+   if (option_not.nr)
+   transport_set_option(transport, TRANS_OPT_DEEPEN_NOT,
+(const char *)_not);
if (option_single_branch)
transport_set_option(transport, TRANS_OPT_FOLLOWTAGS, "1");
 
-- 
2.3.0.rc1.137.g477eb31

--
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 16/20] upload-pack: support define shallow boundary by excluding revisions

[Nguyễn Thái Ngọc Duy]

This should allow the user to say "create a shallow clone of this branch
after version ".

deepen-not cannot be used with deepen the same way deepen-since cannot
be used with deepen. But deepen-not can be mixed with deepen-since. The
result is exactly how you do the command "git rev-list --since=... --not
ref".

FIXME: restrict dwim_ref. Access to reflog at server side may not be a
good idea. Either that or force the user to specify full ref names at
client side (a bit annoying).

Signed-off-by: Nguyễn Thái Ngọc Duy 
---
 Documentation/technical/pack-protocol.txt |  3 ++-
 Documentation/technical/protocol-capabilities.txt |  9 +
 upload-pack.c | 24 +--
 3 files changed, 33 insertions(+), 3 deletions(-)

diff --git a/Documentation/technical/pack-protocol.txt 
b/Documentation/technical/pack-protocol.txt
index 9251df1..dee33a6 100644
--- a/Documentation/technical/pack-protocol.txt
+++ b/Documentation/technical/pack-protocol.txt
@@ -220,7 +220,8 @@ out of what the server said it could do with the first 
'want' line.
   shallow-line  =  PKT-LINE("shallow" SP obj-id)
 
   depth-request =  PKT-LINE("deepen" SP depth) /
-  PKT-LINE("deepen-since" SP timestamp)
+  PKT-LINE("deepen-since" SP timestamp) /
+  PKT-LINE("deepen-not" SP ref)
 
   first-want=  PKT-LINE("want" SP obj-id SP capability-list)
   additional-want   =  PKT-LINE("want" SP obj-id)
diff --git a/Documentation/technical/protocol-capabilities.txt 
b/Documentation/technical/protocol-capabilities.txt
index f08cc4e..0e6b57d 100644
--- a/Documentation/technical/protocol-capabilities.txt
+++ b/Documentation/technical/protocol-capabilities.txt
@@ -188,6 +188,15 @@ specific time, instead of depth. Internally it's 
equivalent of doing
 "rev-list --max-age=" on the server side. "deepen-since"
 cannot be used with "deepen".
 
+deepen-not
+--
+
+This capability adds "deepen-not" command to fetch-pack/upload-pack
+protocol so the client can request shallow clones that are cut at a
+specific revision, instead of depth. Internally it's equivalent of
+doing "rev-list --not " on the server side. "deepen-not"
+cannot be used with "deepen", but can be used with "deepen-since".
+
 no-progress
 ---
 
diff --git a/upload-pack.c b/upload-pack.c
index 100b604..90ecb5b 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -617,6 +617,7 @@ static void deepen_by_rev_list(int ac, const char **av,
 static void receive_needs(void)
 {
struct object_array shallows = OBJECT_ARRAY_INIT;
+   struct string_list deepen_not = STRING_LIST_INIT_DUP;
int depth = 0;
int has_non_tip = 0;
unsigned long deepen_since = 0;
@@ -667,6 +668,18 @@ static void receive_needs(void)
deepen_rev_list = 1;
continue;
}
+   if (skip_prefix(line, "deepen-not ", )) {
+   char *ref = NULL;
+   unsigned char sha1[20];
+   if (dwim_ref(arg, strlen(arg), sha1, ) != 1)
+   die("Ambiguous deepen-not: %s", line);
+   if (!ref || check_refname_format(ref, 0))
+   die("Invalid deepen-not: %s", line);
+   string_list_append(_not, ref);
+   free(ref);
+   deepen_rev_list = 1;
+   continue;
+   }
if (!skip_prefix(line, "want ", ) ||
get_sha1_hex(arg, sha1_buf))
die("git upload-pack: protocol error, "
@@ -721,7 +734,7 @@ static void receive_needs(void)
if (depth == 0 && !deepen_rev_list && shallows.nr == 0)
return;
if (depth > 0 && deepen_rev_list)
-   die("--depth and --since cannot be used together");
+   die("--depth and --since (or --not) cannot be used together");
if (depth > 0)
deepen(depth, );
else if (deepen_rev_list) {
@@ -735,6 +748,13 @@ static void receive_needs(void)
struct object *o = want_obj.objects[i].item;
argv_array_push(, oid_to_hex(>oid));
}
+   if (deepen_not.nr) {
+   argv_array_push(, "--not");
+   for (i = 0; i < deepen_not.nr; i++) {
+   struct string_list_item *s = deepen_not.items + 
i;
+   argv_array_push(, s->string);
+   }
+   }
deepen_by_rev_list(av.argc, av.argv, );
argv_array_clear();
}
@@ -786,7 +806,7 @@ static int send_ref(const char *refname, const struct 
object_id *oid,
int flag, void *cb_data)
 {
static const char *capabilities = "multi_ack thin-pack side-band"

[PATCH 04/20] upload-pack: move "unshallow" sending code out of deepen()

[Nguyễn Thái Ngọc Duy]

Signed-off-by: Nguyễn Thái Ngọc Duy 
---
 upload-pack.c | 33 -
 1 file changed, 20 insertions(+), 13 deletions(-)

diff --git a/upload-pack.c b/upload-pack.c
index 4774f78..4bb104c 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -552,21 +552,10 @@ static void send_shallow(struct commit_list *result)
}
 }
 
-static void deepen(int depth, const struct object_array *shallows)
+static void send_unshallow(const struct object_array *shallows)
 {
-   struct commit_list *result = NULL;
int i;
-   if (depth == INFINITE_DEPTH && !is_repository_shallow())
-   for (i = 0; i < shallows->nr; i++) {
-   struct object *object = shallows->objects[i].item;
-   object->flags |= NOT_SHALLOW;
-   }
-   else
-   result =
-   get_shallow_commits(_obj, depth,
-   SHALLOW, NOT_SHALLOW);
-   send_shallow(result);
-   free_commit_list(result);
+
for (i = 0; i < shallows->nr; i++) {
struct object *object = shallows->objects[i].item;
if (object->flags & NOT_SHALLOW) {
@@ -589,6 +578,24 @@ static void deepen(int depth, const struct object_array 
*shallows)
/* make sure commit traversal conforms to client */
register_shallow(object->oid.hash);
}
+}
+
+static void deepen(int depth, const struct object_array *shallows)
+{
+   struct commit_list *result = NULL;
+   int i;
+   if (depth == INFINITE_DEPTH && !is_repository_shallow())
+   for (i = 0; i < shallows->nr; i++) {
+   struct object *object = shallows->objects[i].item;
+   object->flags |= NOT_SHALLOW;
+   }
+   else
+   result =
+   get_shallow_commits(_obj, depth,
+   SHALLOW, NOT_SHALLOW);
+   send_shallow(result);
+   free_commit_list(result);
+   send_unshallow(shallows);
packet_flush(1);
 }
 
-- 
2.3.0.rc1.137.g477eb31

--
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 02/20] upload-pack: move "shallow" sending code out of deepen()

[Nguyễn Thái Ngọc Duy]

Signed-off-by: Nguyễn Thái Ngọc Duy 
---
 upload-pack.c | 25 +++--
 1 file changed, 15 insertions(+), 10 deletions(-)

diff --git a/upload-pack.c b/upload-pack.c
index 97ed620..0eb9a0b 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -538,6 +538,20 @@ error:
}
 }
 
+static void send_shallow(struct commit_list *result)
+{
+   while (result) {
+   struct object *object = >item->object;
+   if (!(object->flags & (CLIENT_SHALLOW|NOT_SHALLOW))) {
+   packet_write(1, "shallow %s",
+oid_to_hex(>oid));
+   register_shallow(object->oid.hash);
+   shallow_nr++;
+   }
+   result = result->next;
+   }
+}
+
 static void deepen(int depth, const struct object_array *shallows)
 {
struct commit_list *result = NULL, *backup = NULL;
@@ -551,16 +565,7 @@ static void deepen(int depth, const struct object_array 
*shallows)
backup = result =
get_shallow_commits(_obj, depth,
SHALLOW, NOT_SHALLOW);
-   while (result) {
-   struct object *object = >item->object;
-   if (!(object->flags & (CLIENT_SHALLOW|NOT_SHALLOW))) {
-   packet_write(1, "shallow %s",
-oid_to_hex(>oid));
-   register_shallow(object->oid.hash);
-   shallow_nr++;
-   }
-   result = result->next;
-   }
+   send_shallow(result);
free_commit_list(backup);
for (i = 0; i < shallows->nr; i++) {
struct object *object = shallows->objects[i].item;
-- 
2.3.0.rc1.137.g477eb31

--
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 09/20] upload-pack: add deepen-since to cut shallow repos based on time

[Nguyễn Thái Ngọc Duy]

This should allow the user to say "create a shallow clone containing the
work from last year" (once the client side is fixed up, of course).

In theory deepen-since and deepen (aka --depth) can be used together to
draw the shallow boundary (whether it's intersection or union is up to
discussion, but if rev-list is used, it's likely intersection). However,
because deepen goes with a custom commit walker, we can't mix the two
yet.

Signed-off-by: Nguyễn Thái Ngọc Duy 
---
 Documentation/technical/pack-protocol.txt |  3 ++-
 Documentation/technical/protocol-capabilities.txt |  9 +++
 upload-pack.c | 33 +--
 3 files changed, 42 insertions(+), 3 deletions(-)

diff --git a/Documentation/technical/pack-protocol.txt 
b/Documentation/technical/pack-protocol.txt
index c6977bb..9251df1 100644
--- a/Documentation/technical/pack-protocol.txt
+++ b/Documentation/technical/pack-protocol.txt
@@ -219,7 +219,8 @@ out of what the server said it could do with the first 
'want' line.
 
   shallow-line  =  PKT-LINE("shallow" SP obj-id)
 
-  depth-request =  PKT-LINE("deepen" SP depth)
+  depth-request =  PKT-LINE("deepen" SP depth) /
+  PKT-LINE("deepen-since" SP timestamp)
 
   first-want=  PKT-LINE("want" SP obj-id SP capability-list)
   additional-want   =  PKT-LINE("want" SP obj-id)
diff --git a/Documentation/technical/protocol-capabilities.txt 
b/Documentation/technical/protocol-capabilities.txt
index eaab6b4..f08cc4e 100644
--- a/Documentation/technical/protocol-capabilities.txt
+++ b/Documentation/technical/protocol-capabilities.txt
@@ -179,6 +179,15 @@ This capability adds "deepen", "shallow" and "unshallow" 
commands to
 the  fetch-pack/upload-pack protocol so clients can request shallow
 clones.
 
+deepen-since
+
+
+This capability adds "deepen-since" command to fetch-pack/upload-pack
+protocol so the client can request shallow clones that are cut at a
+specific time, instead of depth. Internally it's equivalent of doing
+"rev-list --max-age=" on the server side. "deepen-since"
+cannot be used with "deepen".
+
 no-progress
 ---
 
diff --git a/upload-pack.c b/upload-pack.c
index 573ffa2..100b604 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -14,6 +14,7 @@
 #include "sigchain.h"
 #include "version.h"
 #include "string-list.h"
+#include "argv-array.h"
 
 static const char upload_pack_usage[] = "git upload-pack [--strict] 
[--timeout=] ";
 
@@ -618,6 +619,8 @@ static void receive_needs(void)
struct object_array shallows = OBJECT_ARRAY_INIT;
int depth = 0;
int has_non_tip = 0;
+   unsigned long deepen_since = 0;
+   int deepen_rev_list = 0;
 
shallow_nr = 0;
for (;;) {
@@ -654,6 +657,16 @@ static void receive_needs(void)
die("Invalid deepen: %s", line);
continue;
}
+   if (skip_prefix(line, "deepen-since ", )) {
+   char *end = NULL;
+   deepen_since = strtoul(arg, , 0);
+   if (!end || *end || !deepen_since ||
+   /* revisions.c's max_age -1 is special */
+   deepen_since == -1)
+   die("Invalid deepen-since: %s", line);
+   deepen_rev_list = 1;
+   continue;
+   }
if (!skip_prefix(line, "want ", ) ||
get_sha1_hex(arg, sha1_buf))
die("git upload-pack: protocol error, "
@@ -705,10 +718,26 @@ static void receive_needs(void)
if (!use_sideband && daemon_mode)
no_progress = 1;
 
-   if (depth == 0 && shallows.nr == 0)
+   if (depth == 0 && !deepen_rev_list && shallows.nr == 0)
return;
+   if (depth > 0 && deepen_rev_list)
+   die("--depth and --since cannot be used together");
if (depth > 0)
deepen(depth, );
+   else if (deepen_rev_list) {
+   struct argv_array av = ARGV_ARRAY_INIT;
+   int i;
+
+   argv_array_push(, "rev-list");
+   if (deepen_since)
+   argv_array_pushf(, "--max-age=%lu", deepen_since);
+   for (i = 0; i < want_obj.nr; i++) {
+   struct object *o = want_obj.objects[i].item;
+   argv_array_push(, oid_to_hex(>oid));
+   }
+   deepen_by_rev_list(av.argc, av.argv, );
+   argv_array_clear();
+   }
else
if (shallows.nr > 0) {
int i;
@@ -757,7 +786,7 @@ static int send_ref(const char *refname, const struct 
object_id *oid,
int flag, void *cb_data)
 {
static const char *capabilities = "multi_ack thin-pack side-band"
-   " side-band-64k ofs-delta shallow 

[PATCH 06/20] upload-pack: glue code to use get_shallow_commits_by_rev_list

[Nguyễn Thái Ngọc Duy]

The remaining thing to do is protocol extensions and translate the
requests to rev-list options.

Signed-off-by: Nguyễn Thái Ngọc Duy 
---
 upload-pack.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/upload-pack.c b/upload-pack.c
index 4bb104c..9ae09a0 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -599,6 +599,18 @@ static void deepen(int depth, const struct object_array 
*shallows)
packet_flush(1);
 }
 
+static void deepen_by_rev_list(int ac, const char **av,
+  struct object_array *shallows)
+{
+   struct commit_list *result;
+
+   result = get_shallow_commits_by_rev_list(ac, av, SHALLOW, NOT_SHALLOW);
+   send_shallow(result);
+   free_commit_list(result);
+   send_unshallow(shallows);
+   packet_flush(1);
+}
+
 static void receive_needs(void)
 {
struct object_array shallows = OBJECT_ARRAY_INIT;
-- 
2.3.0.rc1.137.g477eb31

--
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 07/20] upload-pack: use skip_prefix() instead of starts_with() when possible

[Nguyễn Thái Ngọc Duy]

Signed-off-by: Nguyễn Thái Ngọc Duy 
---
 upload-pack.c | 26 +++---
 1 file changed, 15 insertions(+), 11 deletions(-)

diff --git a/upload-pack.c b/upload-pack.c
index 9ae09a0..e9594d1 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -276,7 +276,7 @@ static void create_pack_file(void)
die("git upload-pack: %s", abort_msg);
 }
 
-static int got_sha1(char *hex, unsigned char *sha1)
+static int got_sha1(const char *hex, unsigned char *sha1)
 {
struct object *o;
int we_knew_they_have = 0;
@@ -382,6 +382,8 @@ static int get_common_commits(void)
 
for (;;) {
char *line = packet_read_line(0, NULL);
+   const char *arg;
+
reset_timeout();
 
if (!line) {
@@ -403,8 +405,8 @@ static int get_common_commits(void)
got_other = 0;
continue;
}
-   if (starts_with(line, "have ")) {
-   switch (got_sha1(line+5, sha1)) {
+   if (skip_prefix(line, "have ", )) {
+   switch (got_sha1(arg, sha1)) {
case -1: /* they have what we do not */
got_other = 1;
if (multi_ack && ok_to_give_up()) {
@@ -623,14 +625,16 @@ static void receive_needs(void)
const char *features;
unsigned char sha1_buf[20];
char *line = packet_read_line(0, NULL);
+   const char *arg;
+
reset_timeout();
if (!line)
break;
 
-   if (starts_with(line, "shallow ")) {
+   if (skip_prefix(line, "shallow ", )) {
unsigned char sha1[20];
struct object *object;
-   if (get_sha1_hex(line + 8, sha1))
+   if (get_sha1_hex(arg, sha1))
die("invalid shallow line: %s", line);
object = parse_object(sha1);
if (!object)
@@ -643,19 +647,19 @@ static void receive_needs(void)
}
continue;
}
-   if (starts_with(line, "deepen ")) {
+   if (skip_prefix(line, "deepen ", )) {
char *end;
-   depth = strtol(line + 7, , 0);
-   if (end == line + 7 || depth <= 0)
+   depth = strtol(arg, , 0);
+   if (end == arg || depth <= 0)
die("Invalid deepen: %s", line);
continue;
}
-   if (!starts_with(line, "want ") ||
-   get_sha1_hex(line+5, sha1_buf))
+   if (!skip_prefix(line, "want ", ) ||
+   get_sha1_hex(arg, sha1_buf))
die("git upload-pack: protocol error, "
"expected to get sha, not '%s'", line);
 
-   features = line + 45;
+   features = arg + 40;
 
if (parse_feature_request(features, "multi_ack_detailed"))
multi_ack = 2;
-- 
2.3.0.rc1.137.g477eb31

--
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/6] apply: fix adding new files on i-t-a entries

[Duy Nguyen]

On Mon, Dec 28, 2015 at 10:01 AM, Junio C Hamano  wrote:
> Nguyễn Thái Ngọc Duy   writes:
>
>> Suppose that you came up with some contents to register at path F in
>> your working tree, told Git about your intention with "add -N F", and
>> then tried to apply a patch that wants to _create_ F:
>>
>> Without this patch, we would say "F already exists so a patch to
>> create is incompatible with our current state".
>>
>> With this patch, i-t-a entries are ignored and we do not say that, but
>> instead we'll hopefully trigger "does it exist in the working tree"
>> check, unless you are running under "--cached".
>>
>> Which means that this change will not lead to data loss in the
>> "untracked" file F in the working tree that was merely added to the
>> index with i-t-a bit.
>>
>> (commit message mostly from Junio)
>
> Hmm, I do not quite recall.

For reference ;)

https://www.mail-archive.com/git@vger.kernel.org/msg76461.html

> The above looks under-explained anyway;
> ...

Not enough energy to go through this. Will do later and post new
proposed commit message.
-- 
Duy
--
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